Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Thursday, 22 June 2017 at 00:27:38 UTC, Timon Gehr wrote:

On 21.06.2017 19:39, MysticZach wrote:
My counterargument to that is that it's possible that the 
cognitive dissonance only occurs because of what people are 
used to, rather than what is inherent to the syntax.


This is a purely philosophical distinction without empirical 
basis.


Well I never experienced the dissonance myself, and was surprised 
to find that others did experience it. I just thought my proposal 
was a better syntax for `in` and `out` contracts.


Well my impression was that Walter liked it too, although I 
could have misinterpreted his comment here:


http://forum.dlang.org/post/ogvt66$1bcp$1...@digitalmars.com


He is saying it is good that a DIP to improve contract syntax 
/exists/. I agree with that.


It's really not clear what he meant. I guessed that the highest 
probability of what he meant was that he actually liked the DIP, 
as opposed to the mere fact that it _was_ a DIP. But as I already 
said, I could have misinterpreted his comment. In the face of 
lack of knowledge, it's a sign of wisdom to admit that one might 
be wrong, I think.



If such an alternative checking system is utilized,


there should be a way to hook into the checking logic.

Improving the checking logic interface may solve at a higher 
level the problem I'm trying to solve at a very low one, with 
mere syntax changes, and it might be (is probably?) the best 
way forward.


Your proposal does not solve this problem, and there is no need 
for this DIP to do that.


The goal of this DIP, and the problem I'm trying to solve, is 
"Improve Contract Usability." And for this, H.S. Teoh's proposal 
is a very good one. But it still has a sticking point, which I 
want to resolve, namely that it elevates the existing `assert` 
functionality beyond the current requirement that one must 
explicitly write `assert`, going so far as to imply it in the 
grammar itself. But because of many complaints about the 
limitations of the assert mechanism as it currently exists, I 
would hesitate to install it into the grammar as the "One Chosen 
Way" to bail out of contracts with the new syntax.


However, if the functioning of the `assert` mechanism were more 
customizable, then it would be easier to entrust it, in my 
opinion, with the "sacred responsibility" of being installed into 
the grammar. H.S. Teoh's proposal would then stand on a firmer 
foundation, and my initial proposed syntax would become the 
inferior optionl. At that point, this DIP could be rewritten to 
advocate his syntax instead. (I think it would be better to just 
retain the number and title "DIP1009: Improve Contract Usability" 
than to make a new one for the same issue. Other DIPs have 
followed this pattern, where it was the goal and title that 
remained the same, while the specifics changed.)


We are looking for a significant improvement. Otherwise, what's 
the point? We need to justify the cost.


The intent of my proposal was to make a small improvement. The 
cost (or so I thought, and may still believe) was also small. 
Small improvements are still improvements. DIP1003 is an example 
of this.


https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

The point of contracts is assigning blame by documenting 
assumptions and guarantees. If something within the function 
body crashes, it's ideally the fault of the function 
implementation.

...
I like new as long as it is an improvement. This is not. Having 
syntax subtrees that do not actually logically belong to their 
parent in the grammar is awkward language design, especially if 
they affect the parent's signature.


I'm still wondering what, in practice, the difference really is. 
With existing syntax:


int fun(int a)
in { assert(a); } // 1
do {
assert(a); // 2
...
}

What will the compiler or programmer actually learn from 1 if it 
violates that they won't learn from 2 if it violates? What is the 
practical incentive for `in` contracts at all? All my new syntax 
does is assume that there is in fact a difference between 1 and 
2, and makes 1 easier to write, as:


int fun(int a) {
in assert(a); // 1
assert(a); // 2
...
}

As far as syntax subtrees not belonging to their parent, I can 
see where the cognitive dissonance comes from. But it just 
doesn't seem that bad to me, since contracts are always executed 
as if they are sequential statements anyway. I would imagine that 
new programmers who only ever encountered the new proposed syntax 
would be surprised that the old syntax ever existed in the first 
place, as it's so unnecessarily awkward.


But at this point, we might as well wait for more feedback from 
other people.

Re: What is your favorite D feature?

[ketmar via Digitalmars-d]

"friendship ".writeln = ((_) => "is"~_)(" magic");


"friendship ".writeln = ((_) => "is"~_)(" magic");

just couldn't resist the temptaion, sorry.

Re: gdc is in

[ANtlord via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)


I join in the congratulations. Iain, you rock!

Re: How can I use ldc2 and link to full runtime on arm with no OS

[Mike via Digitalmars-d]

On Wednesday, 21 June 2017 at 22:11:04 UTC, David Nadlinger wrote:

This way, you'll end up having to port all of druntime to your 
target, though, only to then throw away considerable amounts of 
work that went into the parts you don't want to use.


You are correct, but if you omit certain parts of the runtime, 
you end up with things like these:


https://github.com/ldc-developers/ldc/issues/2174
https://github.com/ldc-developers/ldc/issues/552
https://github.com/ldc-developers/ldc/issues/781

The compiler and druntime are too tightly-coupled to make 
pay-as-you-go D development practical.  Some support to remedy 
that would be most welcome.


Mike

Re: What is your favorite D feature?

[Jon Degenhardt via Digitalmars-d]

On Thursday, 22 June 2017 at 00:48:25 UTC, Seb wrote:

Hi,

I am currently trying to modernize the D code example roulette 
on the dlang.org front page [1]. Hence, I would love to hear 
about your favorite feature(s) in D.


A couple more:
- std.conv.to - Safe, convenient conversions that just work.
- std.regex - Really well done. May be hard to illustrate all the 
capabilities in a few examples
- Pragmatic functional programming constructs. No guessing about 
performance. Purity with local mutable variables. Interaction 
with UCFS.


--Jon

Re: What is your favorite D feature?

[Seb via Digitalmars-d]

On Thursday, 22 June 2017 at 01:42:10 UTC, Brad Anderson wrote:
A very simple vibe app could be added using dub's single-file 
package format.


Hmm this is a great idea, but it wouldn't be "runnable" on the 
web.

Here's a PR for discussion:

https://github.com/dlang/dlang.org/pull/1763


Something like (I haven't tried this):


You can even go more minimal - the following works:

#!/usr/bin/env dub
/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0-rc.1"
versions "VibeDefaultMain"
+/
import vibe.d;

shared static this() @safe
{
auto settings = new HTTPServerSettings;
settings.port = 8080;
listenHTTP(settings, (req, res) {
res.writeBody("Hello, World: " ~ req.path);
});
}

Re: What is your favorite D feature?

[Seb via Digitalmars-d]

On Thursday, 22 June 2017 at 01:13:43 UTC, H. S. Teoh wrote:
Slices!  And preferably in an example where it beats C 
performance by not needing to duplicate strings everywhere.


There's one in the queue, feel free to vote for or destroy it:

https://github.com/dlang/dlang.org/pull/1756

Built-in unittests... ddoc'd unittests!  Though it's hard to 
think of an example showing this off that's short enough to 
work for the roulette.


Yes ... ideas welcome ;-)

Sane template syntax. Template alias parameters. Manipulation 
of template argument lists.


Do you have anything specific in mind?


UFCS.


Absolutely agreed, but how do we show this?
Range - one of the best uses cases - are already shown.

Compile-time introspection + UDAs.  Loop over a struct defining 
a set of program configuration parameters, and generate code 
for parsing command-line arguments that fills in the struct 
based on field definitions.  (You could just transform the 
struct members into getopt arguments, as implementing this from 
scratch could be a bear... and ugly to look at. :-D)


Ok - I gave it a shot, but it got quite long. Any ideas on 
trimming it down?


https://github.com/dlang/dlang.org/pull/1762

std.process making it dead easy to invoke an external program, 
capture
its output, all without the ugliness of manually dealing with 
fork(),

execv(), and waitpid().



I realized std.parallelism gives an excellent showcase as well:

https://github.com/dlang/dlang.org/pull/1760

And created another one for std.process:

https://github.com/dlang/dlang.org/pull/1761

Feedback welcome!

You could search for "your code here" in the forum -- that used 
to be the instructions on submitting code examples back before 
the website was revamped, and IIRC there have been a handful of 
suggestions, though AFAIK none was ever actually added to the 
roulette.


Thanks, but I can only remember spam being posted with "your code 
here".

The search also doesn't show any results for me...

Re: dmd -betterC

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:37:03 UTC, Adam D. Ruppe wrote:

we have a *working* "better C".



I applied my two PRs along with Walter's patch and now have 
runtimeless D actually working.



Take a look at this:


// dmd still assumes these are present
// and they are in the C lib, but no without it
extern(C) void _Unwind_Resume() { asm { int 3; } }
extern(C) void __assert(bool c, in char* msg) {}


struct Foo {
int x;
char y;
Foo* next;

~this() {
printf("goodbye world %d\n", x);
}
}

enum Test {
a, b
}

extern (C) int main(char** argv, int argc) {
scope(exit) printf("cruel world\n");
try {
Foo foo;
foo.x = 10;

int[6] buffer;
int[] bar = buffer[1 .. 4];

printf("hello world %d\n", foo.x);
} finally {
printf("sweet\n");
}
//assert(argc > 4, "foo");
return 0;
}

void printf(T...)(string a, T t) {
write(a);
char[16] buffer;
foreach(arg; t)
write(intToString(arg, buffer[]));
}


char[] intToString(int i, char[] buffer) {
int pos = cast(int) buffer.length - 1;

if(i == 0) {
buffer[pos] = '0';
pos--;
}

while(pos > 0 && i) {
buffer[pos] = (i % 10) + '0';
pos--;
i /= 10;
}

return buffer[pos + 1 .. $];
}


void write(in char[] a) {
auto sptr = a.ptr;
auto slen = a.length;
size_t fd = 1;
version(D_InlineAsm_X86)
asm {
mov ECX, sptr;
mov EDX, slen;
mov EBX, fd;
mov EAX, 4; // sys_write
int 0x80;
}
else version(D_InlineAsm_X86_64)
asm {
mov RSI, sptr;
mov RDX, slen;
mov RDI, fd;
mov RAX, 1; // sys_write
syscall;
}
}

extern(C) void _start() {
size_t code = main(null, 0);

version(D_InlineAsm_X86)
asm {
mov EAX, 1; // sys_exit
mov EBX, code;
int 0x80;
}
else version(D_InlineAsm_X86_64)
asm {
mov RAX, 60; // sys_exit
mov RDI, code;
syscall;
}
}



# Note that the -I is not necessary if your compiler is
# actually installed; I just need it here since it is a
# hacked up compiler
src/dmd hello.d -I../druntime/import -betterC -release -c
ld hello.o -nostdlib
$ ls -lh a.out
-rwxr-xr-x 1 me users 2.5K Jun 21 22:13 a.out
$ ldd a.out
not a dynamic executable



Wow. If you remember my old minimal.d, it took about 15 lines of 
stub runtime to even get it to compile and was still 3.3 K in 
my best attempt.


Now it works - including structs with dtors (if you have my two 
PRs merged) - and makes a tiny 2.5 K exe (on Linux here), with 
zero dependencies. This could run on bare metal. I've done that 
before, but never this simple.


* * *

What about using the C library?

---
import core.stdc.stdio;

struct Test {
int x;
int y;

this(int x, int y) {
this.x = y;
this.y = y;
printf("Constructed\n");
foo();
}

~this() {
printf("Destructed\n");
foo();
}

void foo() {
printf("Values are: %d, %d\n", x, y);
}
}

extern(C) int main() {
printf("Hello!\n");
scope(exit) printf("Bye!\n");

Test test = Test(10, 20);
test.x += 45;
test.foo();

return 0;
}
---


Look at that - looks like a reasonably useful program, with 
structs, printing, members, even a destructor. How hard was it to 
build?



$ src/dmd hello2.d -betterC  -I../druntime/import
$ ./hello2
Hello!
Constructed
Values are: 20, 20
Values are: 65, 20
Destructed
Values are: 65, 20
Bye!

$ ls -lh hello2
-rwxr-xr-x 1 me users 11K Jun 21 22:18 hello2
$ ldd hello2
linux-vdso.so.1 (0x7ffe4b3fc000)
libpthread.so.0 => /lib64/libpthread.so.0 
(0x7fabb78f6000)

libm.so.6 => /lib64/libm.so.6 (0x7fabb75f3000)
librt.so.1 => /lib64/librt.so.1 (0x7fabb73ea000)
libdl.so.2 => /lib64/libdl.so.2 (0x7fabb71e6000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 
(0x7fabb6fd)

libc.so.6 => /lib64/libc.so.6 (0x7fabb6c04000)
/lib64/ld-linux-x86-64.so.2 (0x5595dec5f000)


11K executable, linking in standard C stuff.


With my PRs combined with Walter's, we actually have something 
useful here.


Note that I used -release on the top program because otherwise 
there's linker errors for array bounds checks. I am 100% happy 
with this behavior.

Re: dmd -betterC

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 21 June 2017 at 20:11:25 UTC, Walter Bright wrote:

All I did was make them do what the host C compiler does.


I propose that the reason the host C compiler does it is because 
it is a useful behavior.


If these little strings actually are too large, you can easily 
suppress it by saying `assert(condition, "");` - just pass a 
shorter / reused message in the second argument.

Re: What is your favorite D feature?

[Jon Degenhardt via Digitalmars-d]

On Thursday, 22 June 2017 at 01:13:43 UTC, H. S. Teoh wrote:
On Thu, Jun 22, 2017 at 12:48:25AM +, Seb via Digitalmars-d 
wrote:


[snip]

Slices!  And preferably in an example where it beats C 
performance by not needing to duplicate strings everywhere.

...


For slices the example in blog post I wrote might serve 
(https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/). To shorten it drop the associative array component. For example, sum the values in a specific field.


--Jon

Re: What is your favorite D feature?

[Eugene Wissner via Digitalmars-d]

On Thursday, 22 June 2017 at 00:48:25 UTC, Seb wrote:

Hi,

I am currently trying to modernize the D code example roulette 
on the dlang.org front page [1]. Hence, I would love to hear 
about your favorite feature(s) in D.

Ideas:
- favorite language construct
- favorite code sample
- "only possible in D"

Before you ask, yes - I want to add a couple of cool examples 
to dlang.org (and yep the roulette rotation is currently broken 
[2]).


[1] 
https://github.com/dlang/dlang.org/pulls?q=is%3Apr+is%3Aopen+label%3A%22Frontpage+example%22

[2] https://github.com/dlang/dlang.org/pull/1757


ranges
nice operator overloading

Re: What is your favorite D feature?

[Brad Anderson via Digitalmars-d]

On Thursday, 22 June 2017 at 00:48:25 UTC, Seb wrote:

Hi,

I am currently trying to modernize the D code example roulette 
on the dlang.org front page [1]. Hence, I would love to hear 
about your favorite feature(s) in D.

Ideas:
- favorite language construct
- favorite code sample
- "only possible in D"

Before you ask, yes - I want to add a couple of cool examples 
to dlang.org (and yep the roulette rotation is currently broken 
[2]).


[1] 
https://github.com/dlang/dlang.org/pulls?q=is%3Apr+is%3Aopen+label%3A%22Frontpage+example%22

[2] https://github.com/dlang/dlang.org/pull/1757


A very simple vibe app could be added using dub's single-file 
package format. Something like (I haven't tried this):


#!/usr/bin/env dub
/+ dub.sdl:
name "hello"
dependency "vibe-d" version="~>0.8.0-rc.1"
+/
import vibe.d;

shared static this()
{
auto settings = new HTTPServerSettings;
settings.port = 8080;

listenHTTP(settings, );
}

void handleRequest(HTTPServerRequest req,
  HTTPServerResponse res)
{
if (req.path == "/")
res.writeBody("Hello, World!", "text/plain");
}

// Dependencies fetched, compiled, cached, built against, and 
result executed

// in one command:
// $ ./hello.d

Re: What is your favorite D feature?

[H. S. Teoh via Digitalmars-d]

On Thu, Jun 22, 2017 at 12:48:25AM +, Seb via Digitalmars-d wrote:
> Hi,
> 
> I am currently trying to modernize the D code example roulette on the
> dlang.org front page [1]. Hence, I would love to hear about your
> favorite feature(s) in D.
>
> Ideas:
> - favorite language construct
> - favorite code sample
> - "only possible in D"

Slices!  And preferably in an example where it beats C performance by
not needing to duplicate strings everywhere.

Built-in unittests... ddoc'd unittests!  Though it's hard to think of an
example showing this off that's short enough to work for the roulette.

Sane template syntax. Template alias parameters. Manipulation of
template argument lists.

UFCS.

Compile-time introspection + UDAs.  Loop over a struct defining a set of
program configuration parameters, and generate code for parsing
command-line arguments that fills in the struct based on field
definitions.  (You could just transform the struct members into getopt
arguments, as implementing this from scratch could be a bear... and ugly
to look at. :-D)

std.process making it dead easy to invoke an external program, capture
its output, all without the ugliness of manually dealing with fork(),
execv(), and waitpid().


> Before you ask, yes - I want to add a couple of cool examples to
> dlang.org
[...]

You could search for "your code here" in the forum -- that used to be
the instructions on submitting code examples back before the website was
revamped, and IIRC there have been a handful of suggestions, though
AFAIK none was ever actually added to the roulette.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

Re: What is your favorite D feature?

[Adam D. Ruppe via Digitalmars-d]

My fav is that familiar code just works.

Re: What is your favorite D feature?

[Mike via Digitalmars-d]

On Thursday, 22 June 2017 at 00:48:25 UTC, Seb wrote:


I would love to hear about your favorite feature(s) in D.


Beginning with most favorite:
 - CTFE
 - static if - If you don't consider that part of CTFE
 - Template Mixins
 - Templates - Pretty much goes along with the top 2
 - String Mixins
 - Unit Tests

DIP1000 may make that list too, if I ever get around to trying it 
out.


Mike

What is your favorite D feature?

[Seb via Digitalmars-d]

Hi,

I am currently trying to modernize the D code example roulette on 
the dlang.org front page [1]. Hence, I would love to hear about 
your favorite feature(s) in D.

Ideas:
- favorite language construct
- favorite code sample
- "only possible in D"

Before you ask, yes - I want to add a couple of cool examples to 
dlang.org (and yep the roulette rotation is currently broken [2]).


[1] 
https://github.com/dlang/dlang.org/pulls?q=is%3Apr+is%3Aopen+label%3A%22Frontpage+example%22

[2] https://github.com/dlang/dlang.org/pull/1757

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Timon Gehr via Digitalmars-d]

On 21.06.2017 19:39, MysticZach wrote:

On Wednesday, 21 June 2017 at 15:18:21 UTC, Timon Gehr wrote:

On 21.06.2017 02:51, MysticZach wrote:


I think people could get used to the cognitive dissonance.


That's really not what D is about.


My counterargument to that is that it's possible that the cognitive 
dissonance only occurs because of what people are used to, rather than 
what is inherent to the syntax.

...


This is a purely philosophical distinction without empirical basis.


I've already gotten used to it just by writing this DIP.


I think it is likely that you are an outlier.


Well my impression was that Walter liked it too, although I could have 
misinterpreted his comment here:


http://forum.dlang.org/post/ogvt66$1bcp$1...@digitalmars.com
...


He is saying it is good that a DIP to improve contract syntax /exists/. 
I agree with that.



If such an alternative checking system is utilized,


If so, there should be a way to hook into the checking logic. This has 
nothing at all to do with contract syntax. asserts and contracts are 
coupled already, as in-contracts form a disjunction on override by 
catching AssertErrors.


Improving the checking logic interface may solve at a higher level the 
problem I'm trying to solve at a very low one, with mere syntax changes, 
and it might be (is probably?) the best way forward.

...


Your proposal does not solve this problem, and there is no need for this 
DIP to do that.



the syntax for  writing contracts should be as easy
for them as for those using `assert`.


Maybe, but your DIP does not pull its own weight as long as the latter 
syntax is not a notable improvement over what we have now.


Well, my view is that my DIP is actually a very lightweight syntax 
change, and an equally lightweight improvement in contract syntax, so 
it's a lost-cost, mild improvement .


We are looking for a significant improvement. Otherwise, what's the 
point? We need to justify the cost.


The cognitive dissonance argument 


(Just to be clear: I think framing it as a psychological issue does not 
have much merit.)


is the main one against it, and I really don't know if that dissonance 
is based on fundamental flaws in the way I'm thinking about it,


The point of contracts is assigning blame by documenting assumptions and 
guarantees. If something within the function body crashes, it's ideally 
the fault of the function implementation.



or just the "Shock of the New" [1].


I like new as long as it is an improvement. This is not. Having syntax 
subtrees that do not actually logically belong to their parent in the 
grammar is awkward language design, especially if they affect the 
parent's signature.



...
As far as Teoh's proposal, I would say that its quality is highly 
correlated to the percentage of projects that find built-in `assert` 
adequate to their needs,


The two issues might need to be decoupled, but that is not the job of 
the contract syntax overhaul.


which is hard to assess precisely - the better 
`assert` is, or can be made to be, the better Teoh's proposal is, I'd 
say.


Projects that want to do fancy things within contracts can use the 
existing contract syntax, but all they can legitimately do is throw 
AssertErrors, possibly with a message, just as assert does; the new 
syntax does not change this fact.


(BTW: There should be an optional message, as in: in(test(), "test 
failed").)

Re: dmd -betterC

[Walter Bright via Digitalmars-d]

On 6/21/2017 9:24 AM, Adam D. Ruppe wrote:

If you want bugzilla entries


It isn't a question of me "wanting" bugzilla entries or me "liking" bugzilla (as 
another member recently put it). It's our process so that issues can be logged, 
tracked, changelogs compiled, etc. Please follow our process.



> you can make them yourself from the patches.

I can do everything. But that doesn't scale at all, and progress on D would 
grind to a virtual halt if I tried.

Re: Unittests and extern(C)

[Meta via Digitalmars-d]

On Wednesday, 21 June 2017 at 22:19:48 UTC, H. S. Teoh wrote:
Finally, the moral of the story is that had I written unittests 
for compile(), I would have caught this bug much earlier than I 
did.


Also, DRY. Writing the same code more than once is always a 
recipe for disaster. It's bitten me so many times and continues 
to even when I think I'm safe.

Unittests and extern(C)

[H. S. Teoh via Digitalmars-d]

Never thought to mention these two things in the same subject line?
Haha, well today I finally have reason to. This post is about an obscure
bug I encountered today in one of my projects, with a moral lesson on
why you really, really, ought to be using unittest blocks everywhere.

First, a bit of a background.  The program in which said bug occurred
consists of a module that takes user input, preprocesses it, and
instantiates a code template that produces a D code snippet. This
snippet is then saved into a temporary file, and compiled with the local
D compiler to produce a shared object. Subsequently, it makes use of
Posix's dlopen() family of functions to load the shared object, lookup
the symbol of the generated function, and return a function pointer to
it.  The main module then does its own processing in which it calls the
generated code via this function pointer.

The actual code is, of course, rather involved, but here's a
highly-simplified version of it that captures the essentials:

// The code template.
//
// The q"..." syntax is D's built-in heredoc syntax, convenient
// for multi-line string literals.
//
// Basically, this template is just a boilerplate function
// declaration to wrap around the generated D code snippet. It's
// written as a format string, with the "%s" specifying where
// the code snippet should be inserted.
static immutable string codeTemplate = q"ENDTEMPLATE
module funcImpl;
double funcImpl(double x, double y)
{
return %s;
}
ENDTEMPLATE";

// A convenient alias for the function pointer type that will be
// returned by the JIT compiler.
alias FuncImpl = double function(double, double);

// Compiles the given input into a shared object, load it, and
// return a function pointer to its entry point.
FuncImpl compile(string preprocessedInput)
{
// Instantiate code template and write it into a
// temporary source file.
import std.format : format;
string code = format(codeTemplate, preprocessedInput);

import std.file : write;
enum srcFile = "/path/to/tmpfile.d";
write(srcFile, code);

// Compile it into a shared object with the D compiler.
// Thanks to the wonderful API of std.process, this is a
// cinch, no need to fiddle with fork(), execv(),
// waitpid(), etc..
import std.process;
enum soFile = "/path/to/tmpfile.so";
auto ret = execute([
"/path/to/dmd",
"-fPIC",
"-shared",  // make it a shared object
"-of" ~ soFile,
srcFile
]);
if (ret.status != 0) ... // compile failed

// Load the result as a shared library
import core.sys.posix.dlfcn;
import std.string : toStringz;

void* lib = dlopen(soFile.toStringz, RTLD_LAZY | RTLD_LOCAL);
if (lib is null) ... // handle error

// Lookup the symbol of the generated function
auto symbol = "_D8funcImpl8funcImplFddZd"; // mangled name of 
funcImpl()
impl = cast(FuncImpl) dlsym(lib, symbol);
if (impl is null) ... // handle error
return impl;
}

void main(string[] args)
{
auto input = getUserInput(...);
auto snippet = preprocessInput(input);
auto impl = compile(snippet);

... // do stuff
auto result = impl(x, y); // call generated function
... // more stuff
}

The symbol "_D8funcImpl8funcImplFddZd" is basically the mangled version
of funcImpl(). A mangled name is basically a way of encoding a function
signature into a legal identifier for an object file symbol -- the
system linker does not (and should not) understand D overloading rules,
for example, so the compiler needs to generate a unique name for every
function overload. Generally, the D compiler takes care of this for us,
so we never have to worry about it in usual D code, and can simply use
the human-readable name "funcImpl", or the fully-qualified name
"funcImpl.funcImpl". However, since dlsym() doesn't understand the D
mangling scheme, in this case we need to tell it the mangled name so
that it can find the right symbol in the shared object.

This was the original version of the program. So far so good.

In this version of the program, I didn't write many unittests for
compile(), because I felt it was ugly for unittests to have side-effects
on the host system (creating / deleting files, running external
programs, etc.). So, to my shame, this 

Re: How can I use ldc2 and link to full runtime on arm with no OS

[David Nadlinger via Digitalmars-d]

On Wednesday, 21 June 2017 at 16:10:41 UTC, Dan Walmsley wrote:
My idea is to build the whole thing, see what the code size and 
performance is, and then one by one reduce things down as 
needed.


Starting from nothing so far has been a bit of a none starter!


This way, you'll end up having to port all of druntime to your 
target, though, only to then throw away considerable amounts of 
work that went into the parts you don't want to use.


I don't think the notion of implementing a feature being easier 
than understanding how to rip it out is very realistic.


 — David

Re: gdc is in

[Jonathan Marler via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)

I found out because it's on the front page of HN right now, 
where commenters are asking questions about D.


Terrific news, congratulations!

Re: gdc is in

[Wulfklaue via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)


Nice job Iain ... Especially after 6 years pushing for it and the 
whole rewrite.

Re: gdc is in

[Eugene Wissner via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)

I found out because it's on the front page of HN right now, 
where commenters are asking questions about D.


Many thanks and congratulations to Johannes and Ian!

Re: gdc is in

[Walter Bright via Digitalmars-d]

On 6/21/2017 8:11 AM, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)

I found out because it's on the front page of HN right now, where commenters are 
asking questions about D.


Pretty dazz! Made my week!

Re: dmd -betterC

[Walter Bright via Digitalmars-d]

On 6/21/2017 6:21 AM, Adam D. Ruppe wrote:
If you are seriously 
concerned about the bytes, why include them in -betterC?


All I did was make them do what the host C compiler does.

Re: Read conditional function parameters during compile time using __traits

[Eugene Wissner via Digitalmars-d-learn]

On Wednesday, 21 June 2017 at 19:39:14 UTC, timvol wrote:
Hi! I've a simple array of bytes I received using sockets. What 
I want to do is to calculate the target length of the message. 
So, I defined a calcLength() function for each function code 
(it's the first byte in my array). My problem is that I defined 
the calcLength() function using conditions so that each 
calcLength should be called depending on the respective 
function code, see below:


module example;

private
{
size_t calcLength(ubyte ubFuncCode)() if ( ubFuncCode == 1 )
{
return 10; // More complex calculated value
}

size_t calcLength(ubyte ubFuncCode)() if ( ubFuncCode == 2 )
{
return 20; // More complex calculated value
}

size_t calcLength(ubyte ubFuncCode)() if ( ubFuncCode == 3 )
{
return 30; // More complex calculated value
}
}

size_t doCalcLength(ubyte ubFuncCode)
{
return calcLength!(ubFuncCode)();
}

int main()
{
doCalcLength(1);
return 0;
}

But... how can I execute these functions? I mean, calling 
doCalcLength(1) function says "Variable ubFuncCode cannot be 
read at compile time". So my idea is to create an array during 
compile time using traits (e.g. __traits(allMembers)) and to 
check this later during runtime. For illustration purposes 
something like this:


--> During compile time:

void function()[ubyte] calcLengthArray;

auto tr = __traits(allMembers, example);
foreach ( string s; tr )
{
calcLengthArray[__trait(get, s)] = s;
}

--> During runtime:

size_t doCalcLength(ubyte ubFuncCode)
{
auto length = 0;

if ( ubFuncCode in calcLengthArray )
{
length = calcLengthArray[ubFuncCode]!(ubFuncCode)();
}

return length;
}

I hope everyone knows what I want to do :). But... does anyone 
know how I can realize that? I don't want to use a switch/case 
structure because the calcLength() functions can be very 
complex and I've over 40 different function codes. So, I think 
the best approach is to use something similar to the one I 
described.


Let us to look at your function:

size_t calcLength(ubyte ubFuncCode)() if ( ubFuncCode == 1 )
{
return 10; // More complex calculated value
}

This function accepts only one template parameter and no other 
parameters. Template parameter should be known at compile time. 
You can't pass a value read from socket, because you can read 
from socket only at runtime. It is what the error message says.

You calls such function as follows:

calcLength!1()
calcLength!2()
and so on.

Your doCalcLength won't work for the same reason. You try to pass 
"ubFuncCode" known at runtime as a template parameter, you will 
get the same error.
You can try to instantiate all calcLength overloads and save them 
in calcLengthArray at some index just like you already do, but 
without any template parameters. The call would look something 
like:


   length = calcLengthArray[ubFuncCode]();

But it is simplier and shorter just to use a switch statement:

switch (ubFuncCode)
{
  case 1:
Do what calcLength!1() would do
break;
  case 2:
Do what calcLength!2() would do
break;
  default:
break;
}

Re: Using array slices with C-style fread() from file

[Ali Çehreli via Digitalmars-d-learn]

On 06/21/2017 12:20 PM, uncorroded wrote:

> So @trusted is me guaranteeing to the compiler that this
> function is safe?

Yes and you shouldn't lie. :)

> Is there any way of auditing this code through
> valgrind, etc.

That's a good idea, which you can do yourself but I don't think you can 
be sure beyond the tests that you've ran. There can always be corner 
cases where the library you use may not be memory-safe. You have to 
trust... :)


> invaluable resource in getting me started.

Thank you! Makes me very happy to hear that. :)

Ali

Re: Dealing with the interior pointers bug

[Cym13 via Digitalmars-d-learn]

On Wednesday, 21 June 2017 at 17:11:41 UTC, TheGag96 wrote:

On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it 
sees something that *might* be a pointer, it assumes it *is* a 
pointer and thus had better not get freed.


So is the GC then simply made to be "better-safe-than-sorry" or 
is this a consequence of how the GC does things? Or rather, 
does the GC know the type of any references to its memory at 
all? I suppose I should really ask if there's a document other 
than druntime's source that describes how the GC really works 
under the hood haha.


You may like reading 
http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html

Re: D needs to get its shit together!

[jmh530 via Digitalmars-d]

On Wednesday, 21 June 2017 at 18:35:33 UTC, data pulverizer wrote:

On Monday, 19 June 2017 at 12:46:19 UTC, jmh530 wrote:
I just hope that we can get some operator overloading so that 
I don't have to write mtimes all over the place. My ideal 
would be a DIP that adds the option to overload opBinary for 
\, .+, .-, .*, ./. Lubeck could use \ for inverse, .+ etc. for 
element-wise matrix operations, and * for mtimes, etc. Very 
Matlab-like.


I double-checked and noticed that Matlab doesn't actually have 
.+/.-, just +/-. Since D's a[] + b[] doesn't seem all that 
different from Matlab's a + b, with the restriction that there 
needs to be destination memory, it seems like it would be a 
confusing to add in another way of doing things. So maybe just 
add \ and another operator for matrix multiplication. I don't 
really know.




I'd like to second more flexibility around unary and binary 
operators, perhaps we can have another keyword for instance 
"record" that is essentially a D struct but allows the user to 
specify their own operators - it could be included unofficially 
at first without impacting the rest of the D language with the 
stipulation that it is not used in D's core libraries or in 
anything important. This functionality would allow notation 
native to different fields in analysis to be used.


An interesting idea, but I don't know if they would go to for it.

If you want more operator overloading on a class, you could put 
the class as a member of the "record" and alias this it?

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[H. S. Teoh via Digitalmars-d]

On Wed, Jun 21, 2017 at 07:18:18PM +, MysticZach via Digitalmars-d wrote:
> [...] Or are all contracts basically just fancy sugar for asserts at
> the beginning and end of a function body?
[...]

This is a sticky point about D's current DbC implementation that myself
and several others feel is a design flaw. In particular, that
in-contracts are executed as part of the *callee*, when the intent of
DbC is really that it is the obligation of the *caller* to fulfill its
stipulations, and therefore the contract verification should happen at
*caller* site rather than at the beginning of the callee.

This particular implementation detail causes problems with binary-only
libraries: most library vendors would prefer to ship the library
compiled with -release rather than not, but in -release, the asserts in
any in-contracts would be elided, making them essentially non-existent
by the user uses the library.  So you either have to dispense with DbC
altogether, or be forced to ship two versions of your library, one with
contracts compiled in and one without, in order for your users to
benefit from DbC *and* not have to suffer performance penalties in their
own release builds.

Had in-contracts been implemented on the caller's side instead, this
would no longer be a problem: the contracts will still be part of the
library API, so the user can benefit from them when not compiling with
-release, but now the library itself can be shipped only with the
binaries compiled with -release for best performance.

This is probably something outside the scope of this DIP, however.


T

-- 
Political correctness: socially-sanctioned hypocrisy.

Read conditional function parameters during compile time using __traits

[timvol via Digitalmars-d-learn]

Hi! I've a simple array of bytes I received using sockets. What I 
want to do is to calculate the target length of the message. So, 
I defined a calcLength() function for each function code (it's 
the first byte in my array). My problem is that I defined the 
calcLength() function using conditions so that each calcLength 
should be called depending on the respective function code, see 
below:


module example;

private
{
size_t calcLength(ubyte ubFuncCode)() if ( ubFuncCode == 1 )
{
return 10; // More complex calculated value
}

size_t calcLength(ubyte ubFuncCode)() if ( ubFuncCode == 2 )
{
return 20; // More complex calculated value
}

size_t calcLength(ubyte ubFuncCode)() if ( ubFuncCode == 3 )
{
return 30; // More complex calculated value
}
}

size_t doCalcLength(ubyte ubFuncCode)
{
return calcLength!(ubFuncCode)();
}

int main()
{
doCalcLength(1);
return 0;
}

But... how can I execute these functions? I mean, calling 
doCalcLength(1) function says "Variable ubFuncCode cannot be read 
at compile time". So my idea is to create an array during compile 
time using traits (e.g. __traits(allMembers)) and to check this 
later during runtime. For illustration purposes something like 
this:


--> During compile time:

void function()[ubyte] calcLengthArray;

auto tr = __traits(allMembers, example);
foreach ( string s; tr )
{
calcLengthArray[__trait(get, s)] = s;
}

--> During runtime:

size_t doCalcLength(ubyte ubFuncCode)
{
auto length = 0;

if ( ubFuncCode in calcLengthArray )
{
length = calcLengthArray[ubFuncCode]!(ubFuncCode)();
}

return length;
}

I hope everyone knows what I want to do :). But... does anyone 
know how I can realize that? I don't want to use a switch/case 
structure because the calcLength() functions can be very complex 
and I've over 40 different function codes. So, I think the best 
approach is to use something similar to the one I described.

Re: Dealing with the interior pointers bug

[ag0aep6g via Digitalmars-d-learn]

On 06/21/2017 07:23 PM, H. S. Teoh via Digitalmars-d-learn wrote:

Being a systems programming language means you should be able to do
things outside the type system (in @system code, of course, not in @safe
code), including storing pointers as int values.  Any C code that your D
program interoperates with may also potentially do similar things.


The GC doesn't scan the C heap. You didn't say that it does, but it 
might be understood that way.



Because of this, the GC cannot simply assume that an int value isn't
actually a pointer value in disguise, so if that int value happens to
coincide with an address of an allocated memory block, the only sane
thing it can do is to assume the worst and assume that the memory is
still live (via that (assumed) reference).


There are cases where the GC does assume that ints are not pointers. For 
example, an int[] on the GC heap won't be scanned for pointers. The GC 
is neither completely precise nor completely conservative.

Re: Using array slices with C-style fread() from file

[uncorroded via Digitalmars-d-learn]

On Wednesday, 21 June 2017 at 19:11:44 UTC, Ali Çehreli wrote:

On 06/21/2017 12:06 PM, uncorroded wrote:

> Is
> there any way of making the function with @safe as well? I
get the
> errors "cannot call @system function
'core.stdc.stdio.fread,fopen,fclose'.

@trusted is exactly for that. It can be called from @safe code:

@trusted @nogc ubyte[n] rand_bytes(uint n)() {
// ...
}

@safe auto foo() {
return rand_bytes!3();
}

Ali


Thanks! So @trusted is me guaranteeing to the compiler that this 
function is safe? Is there any way of auditing this code through 
valgrind, etc. Also, thanks a lot for your book on D. It has been 
an invaluable resource in getting me started.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 18:04:07 UTC, Moritz Maxeiner wrote:

On Wednesday, 21 June 2017 at 17:55:05 UTC, MysticZach wrote:
Question: If `assert` itself allowed a user-defined hook, what 
would the remaining justification be for decoupling `in` and 
`out` contracts from the `assert` logic?


Because then you won't have normal asserts and contracts be 
subject to different semantics?
If I use a library, I may very well want to disable the 
library's internal assert checks (because I have enough 
experience that it's working properly), but keep it's contracts 
alive, because my code is still shiny new and riddled with bugs.


Timon appears to think that the checking logic is more 
monolithic. From his reply above [1]:


"If [an alternative checking system is utilized], there should be 
a way to hook into the checking logic. This has nothing at all to 
do with contract syntax. asserts and contracts are coupled 
already, as in-contracts form a disjunction on override by 
catching AssertErrors."


So I'm hoping more people will weigh in on this issue. For 
example, how easy is it to separate a library's internal 
contracts from its external ones? Would you have to write 
internal contracts in a different way from the ones facing the 
user? How often is this distinction the one causing problems with 
productivity?


The way I'm thinking about it would be that if there were a 
pragma to turn off contracts in a particularly hot code path, 
then the rest of the program could remain safe, while the fast 
part was allowed to go as fast as possible, addressing the 
performance issue.


But regarding the information issue, what kind of error 
information is better delivered specifically through compiler 
knowledge of `in` and `out` contracts, versus what it would 
deliver in the same way via regular `assert`s? Or are all 
contracts basically just fancy sugar for asserts at the beginning 
and end of a function body? What can the compiler do with the 
extra information? What can it say to the user that the user 
wouldn't already be able to figure out if it were a regular 
assert?


[1] http://forum.dlang.org/post/oie2nt$emf$1...@digitalmars.com

Re: Using array slices with C-style fread() from file

[Ali Çehreli via Digitalmars-d-learn]

On 06/21/2017 12:06 PM, uncorroded wrote:

> Is
> there any way of making the function with @safe as well? I get the
> errors "cannot call @system function 
'core.stdc.stdio.fread,fopen,fclose'.


@trusted is exactly for that. It can be called from @safe code:

@trusted @nogc ubyte[n] rand_bytes(uint n)() {
// ...
}

@safe auto foo() {
return rand_bytes!3();
}

Ali

Re: Using array slices with C-style fread() from file

[uncorroded via Digitalmars-d-learn]

On Wednesday, 21 June 2017 at 18:58:58 UTC, tetyys wrote:

On Wednesday, 21 June 2017 at 18:49:01 UTC, uncorroded wrote:
Is there a way of making this work with D slices? Can they be 
used as C-style pointers?


What about this:

@nogc ubyte[n] rand_bytes(uint n)() {
import core.stdc.stdio;
FILE *fp;
fp = fopen("/dev/urandom", "r");
ubyte[n] buf;
uint bread = 0;
while (bread < n) {
auto toread = n - bread;
auto read = fread(buf[bread .. $].ptr, ubyte.sizeof, 
toread, fp);

bread += read;
}
fclose(fp);
return buf;
}

?


Thanks a lot! That works. Did not know about the .ptr for a 
slice. Is there any way of making the function with @safe as 
well? I get the errors "cannot call @system function 
'core.stdc.stdio.fread,fopen,fclose'.

Re: Using array slices with C-style fread() from file

[tetyys via Digitalmars-d-learn]

On Wednesday, 21 June 2017 at 18:58:58 UTC, tetyys wrote:

On Wednesday, 21 June 2017 at 18:49:01 UTC, uncorroded wrote:
Is there a way of making this work with D slices? Can they be 
used as C-style pointers?


What about this



Or simpler,

while (left)
left -= fread(buf[n-left .. $].ptr, ubyte.sizeof, left, fp);

Re: Using array slices with C-style fread() from file

[Ali Çehreli via Digitalmars-d-learn]

- Fixed-length arrays are value types. You may not want to return them 
if n is very large.


- Every array has the .ptr property that gives the pointer to the first 
element.


- What can be helpful to you here is the fact that you can treat any 
memory as a slice:


import core.stdc.stdlib;

struct S {
double d;
}

void main() {
ubyte * p = cast(ubyte*)malloc(10);
ubyte[] slice = p[0..10];// 10 is number of elements

// Another example with a struct object:
auto objectCount = 7;
S * objects = cast(S*)malloc(objectCount * S.sizeof);
auto S_slice = objects[0..objectCount];
}

Of course, you must be careful with slice lifetimes in this case; you 
shouldn't use the slices after freeing the memory.


Ali

Re: Using array slices with C-style fread() from file

[tetyys via Digitalmars-d-learn]

On Wednesday, 21 June 2017 at 18:49:01 UTC, uncorroded wrote:
Is there a way of making this work with D slices? Can they be 
used as C-style pointers?


What about this:

@nogc ubyte[n] rand_bytes(uint n)() {
import core.stdc.stdio;
FILE *fp;
fp = fopen("/dev/urandom", "r");
ubyte[n] buf;
uint bread = 0;
while (bread < n) {
auto toread = n - bread;
auto read = fread(buf[bread .. $].ptr, ubyte.sizeof, 
toread, fp);

bread += read;
}
fclose(fp);
return buf;
}

?

Using array slices with C-style fread() from file

[uncorroded via Digitalmars-d-learn]

Hi all,

I am writing a program to read device /dev/urandom file to get 
some random bytes. I am trying to bypass D's GC as I know the 
length of the buffer needed. I tried using std.stdio.File and 
rawRead but File cannot be used with @nogc. So I used 
core.stdc.stdio and used traditional C style. My code is here - 
https://dpaste.dzfl.pl/36e1df4cb99b (Also at end of post). I am 
using fread instead of read because /dev/urandom can be accessed 
by other programs (From this post - 
http://insanecoding.blogspot.in/2014/05/a-good-idea-with-bad-usage-devurandom.html ). As you can see from code, I ended up doing pointer arithmetic. Is there a way of making this work with D slices? Can they be used as C-style pointers?


My D function used for getting random bytes:

@nogc ubyte[n] rand_bytes(uint n)() {
import core.stdc.stdio;
FILE *fp;
fp = fopen("/dev/urandom", "r");
ubyte[n] buf;
ubyte *bp = [0];
uint bread = 0;
while (bread < n) {
auto toread = n - bread;
auto read = fread(bp, ubyte.sizeof, toread, fp);
bread += read;
bp += read;
}
fclose(fp);
return buf;
}

Re: D needs to get its shit together!

[data pulverizer via Digitalmars-d]

On Monday, 19 June 2017 at 12:46:19 UTC, jmh530 wrote:
I just hope that we can get some operator overloading so that I 
don't have to write mtimes all over the place. My ideal would 
be a DIP that adds the option to overload opBinary for \, .+, 
.-, .*, ./. Lubeck could use \ for inverse, .+ etc. for 
element-wise matrix operations, and * for mtimes, etc. Very 
Matlab-like.


I'd like to second more flexibility around unary and binary 
operators, perhaps we can have another keyword for instance 
"record" that is essentially a D struct but allows the user to 
specify their own operators - it could be included unofficially 
at first without impacting the rest of the D language with the 
stipulation that it is not used in D's core libraries or in 
anything important. This functionality would allow notation 
native to different fields in analysis to be used.

Re: gdc is in

[Paulo Pinto via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)

I found out because it's on the front page of HN right now, 
where commenters are asking questions about D.


As already mentioned on HN, congratulations to everyone that 
helped this come true.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 17:55:05 UTC, MysticZach wrote:


This would be added flexibility, rather than a 
one-size-fits-all solution. So the word "universal" is a little 
deceptive. The options could also include a user-defined hook 
for assert.


Question: If `assert` itself allowed a user-defined hook, what 
would the remaining justification be for decoupling `in` and 
`out` contracts from the `assert` logic?


Because then you won't have normal asserts and contracts be 
subject to different semantics?
If I use a library, I may very well want to disable the library's 
internal assert checks (because I have enough experience that 
it's working properly), but keep it's contracts alive, because my 
code is still shiny new and riddled with bugs.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 17:38:02 UTC, Moritz Maxeiner wrote:


Well, for me it would be this:
- The compact syntax with `in (cond)` and `out (ident)(cond)`
- Don't lower those contracts directly to any fixed 
implementation; lower them to a template (similar to what I 
posted) that you stick in druntime instead
- Allow configuring the template's checking semantics via D 
versions (you can still then have one implementation choice in 
the template be asserts, if you want, though I would go with a 
more riguruous kill switch such as the one I posted)


I would definitely be interested in helping out with the 
template implementation for druntime, btw.


I think this should be taken even further and follow the 
footsteps of std.experimental.allocator (being thus consistent 
with what's becoming idiomatic D):


- Introduce the abstract concept of an Allocator analogue called 
"Insister", which can provide DbI-detectable "insist" functions 
(e.g. for in contracts, for out contracts, etc.)
- Introduce an interface like IInsister akin to IAllocator, with 
insisterObject akin to allocatorObject
- Create a thread-local `IInsister theInsister` that can be 
swapped out at will

- Lower contracts to calls to `theInsister.insist(...)`
- Create some Insister implementations and load theInsister up 
with one that uses `assert` semantics

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 17:38:02 UTC, Moritz Maxeiner wrote:
But another option is simply to upgrade `assert` to make sure 
it offers what everyone wants.


That would be really cool, but I doubt it will be feasible 
here. I think that in this case it will more likely end up with 
everyone hating that universal solution equally.


Well the universal solution could be, for example, the 
suggestions from my post in the other thread:


3. Allow an additional compiler flag for more informative, but 
heavier asserts, e.g. `-release=informativeAsserts`.


 4. Allow a pragma in the code, e.g. `pragma(asserts, 
none/regular/informative)` for what kinds of asserts are to be 
used at a given moment.


This would be added flexibility, rather than a one-size-fits-all 
solution. So the word "universal" is a little deceptive. The 
options could also include a user-defined hook for assert.


Question: If `assert` itself allowed a user-defined hook, what 
would the remaining justification be for decoupling `in` and 
`out` contracts from the `assert` logic?


That's what I mean by thinking the problem might be fixable by 
upgrading `assert`.

Re: gdc is in

[kinke via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

Congratulations to Iain and the gdc team. :)


+1. Awesome!

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:18:21 UTC, Timon Gehr wrote:

On 21.06.2017 02:51, MysticZach wrote:


I think people could get used to the cognitive dissonance.


That's really not what D is about.


My counterargument to that is that it's possible that the 
cognitive dissonance only occurs because of what people are used 
to, rather than what is inherent to the syntax.



I've already gotten used to it just by writing this DIP.


I think it is likely that you are an outlier.


Well my impression was that Walter liked it too, although I could 
have misinterpreted his comment here:


http://forum.dlang.org/post/ogvt66$1bcp$1...@digitalmars.com


If such an alternative checking system is utilized,


If so, there should be a way to hook into the checking logic. 
This has nothing at all to do with contract syntax. asserts and 
contracts are coupled already, as in-contracts form a 
disjunction on override by catching AssertErrors.


Improving the checking logic interface may solve at a higher 
level the problem I'm trying to solve at a very low one, with 
mere syntax changes, and it might be (is probably?) the best way 
forward.



the syntax for  writing contracts should be as easy
for them as for those using `assert`.


Maybe, but your DIP does not pull its own weight as long as the 
latter syntax is not a notable improvement over what we have 
now.


Well, my view is that my DIP is actually a very lightweight 
syntax change, and an equally lightweight improvement in contract 
syntax, so it's a lost-cost, mild improvement . The cognitive 
dissonance argument is the main one against it, and I really 
don't know if that dissonance is based on fundamental flaws in 
the way I'm thinking about it, or just the "Shock of the New" 
[1]. If allowing contracts in the function body really is a 
fundamentally flawed concept, then I won't keep advocating for it.


H. S. Teoh's counter-proposal is, and I think your DIP has a 
much higher chance of acceptance if you go with it.


I'm not actually worried about whether the proposal is accepted 
or not, as long the best ideas and arguments come forward and are 
heard. I have more faith in the process than I do in any 
particular proposal.


As far as Teoh's proposal, I would say that its quality is highly 
correlated to the percentage of projects that find built-in 
`assert` adequate to their needs, which is hard to assess 
precisely - the better `assert` is, or can be made to be, the 
better Teoh's proposal is, I'd say. Moritz [2] suggests solving 
the problem by decoupling `in` and `out` contract syntax from the 
checking logic. This seems like a good way to go too. But I'd 
like to see a little more justification for it.


[1] Robert Hughes documentary, "The Shock of the New" 
https://www.youtube.com/watch?v=J3ne7Udaetg
[2] 
http://forum.dlang.org/post/uzzwmgqoqxuxhusjv...@forum.dlang.org

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 16:52:24 UTC, MysticZach wrote:


Well I'd be just as happy expanding the design limits of the 
language, i.e. `assert`, if that were a better option. The 
issue you raise is just how different are `in` and `out` 
contracts from regular `assert` contracts.


Well, a contract is an abstraction, asserts are just one possible 
implementation; so yeah, they are different things.
Technically in the current (verbose) syntax, the `assert` just 
happen to be part of the contract's implementation; it could 
really be just anything, including `in { if (!cond) throw 
Exception }`.


They _are_ all listed in the same section of the documentation 
[1], for whatever that's worth.


Well, yeah, because assert's are the most common contract 
implementation in D.




The practical question is whether one can assume that the same 
semantics used for `assert`, whatever they may be, will in all 
cases be desirable for `in` and `out` too. The flexibility of 
decoupling them is one solution, if they are clearly 
sufficiently different.


They are (see abstraction vs implementation argument above). We 
can just as well use another implementation in the new syntax and 
then we don't have to worry about asserts semantics possibly 
changing in the future anymore. Also, people arguing for changes 
in assert semantics don't have to care about contracts if they 
don't also do DbC. I think decoupling is the way to go here.


But another option is simply to upgrade `assert` to make sure 
it offers what everyone wants.


That would be really cool, but I doubt it will be feasible here. 
I think that in this case it will more likely end up with 
everyone hating that universal solution equally.


I don't know what to suggest, because I don't if `assert` can 
be made good enough to warrant direct inclusion into the 
grammar. If it could, then all contracts, including plain 
`assert` statements, would benefit from them.


Well, for me it would be this:
- The compact syntax with `in (cond)` and `out (ident)(cond)`
- Don't lower those contracts directly to any fixed 
implementation; lower them to a template (similar to what I 
posted) that you stick in druntime instead
- Allow configuring the template's checking semantics via D 
versions (you can still then have one implementation choice in 
the template be asserts, if you want, though I would go with a 
more riguruous kill switch such as the one I posted)


I would definitely be interested in helping out with the template 
implementation for druntime, btw.

Re: Dealing with the interior pointers bug

[H. S. Teoh via Digitalmars-d-learn]

On Wed, Jun 21, 2017 at 05:11:41PM +, TheGag96 via Digitalmars-d-learn 
wrote:
> On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
> > This comes from the fact that D's GC is conservative - if it sees
> > something that *might* be a pointer, it assumes it *is* a pointer
> > and thus had better not get freed.
> 
> So is the GC then simply made to be "better-safe-than-sorry" or is
> this a consequence of how the GC does things? Or rather, does the GC
> know the type of any references to its memory at all?

The reason the GC must be conservative is because (1) D is a systems
programming language, and also because (2) D interfaces directly with C.

Being a systems programming language means you should be able to do
things outside the type system (in @system code, of course, not in @safe
code), including storing pointers as int values.  Any C code that your D
program interoperates with may also potentially do similar things.

Because of this, the GC cannot simply assume that an int value isn't
actually a pointer value in disguise, so if that int value happens to
coincide with an address of an allocated memory block, the only sane
thing it can do is to assume the worst and assume that the memory is
still live (via that (assumed) reference).  It's not safe for the GC to
assume that it's merely an int, because if it actually turns out to be a
pointer, then you'll end up with a dangling pointer and the ensuing
memory corruption, security holes, and so forth.  But assuming that the
value is a pointer is generally harmless -- the memory block just
doesn't get freed right away, but if the int is mutated afterwards,
eventually the GC will get around to cleaning it up.

The only big problem is in 32-bit code, where because of the very
limited space of pointer values, the chances of a random int value
coinciding with a valid pointer value is somewhat high, so if you have a
large allocated memory block, the chances of a random int being mistaken
for a reference to the block is somewhat high, so you could potentially
run out of memory due to large blocks not being freed when they could
be.  Fortunately, though, in 64-bit land the space of pointer values is
generally so large that it's highly unlikely that a random int would
look like a pointer, so this generally isn't a problem if you're using
64-bit, which is the case more and more now as vendors are slowly
phasing out 32-bit support.


T

-- 
People tell me that I'm skeptical, but I don't believe them.

[Issue 17540] std.net.curl: HTTP no possibillity to set CURLOPT_NOPROXY

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #1 from Vladimir Panteleev  ---
You can set arbitrary Curl settings that are not covered by the D wrapper by
accessing the .handle property, e.g. "http.handle.set(CurlOption.noproxy,
"www.example.com")". I don't think the HTTP wrapper type strives to provide an
interface to all the Curl options in the CurlOption enum.

--

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 16:23:53 UTC, MysticZach wrote:

void foo()
{
   int bar(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out /*whoops, forgot `( )`*/(result) { ... }

   do { ... }
   while (true); // Error: while statement cannot contain just 
`;`

}

Honestly this doesn't seem like a big deal, as I'd imagine it'd 
be hard not to notice that code like this wasn't working as 
expected. And also extremely rare. So I'm still in favor.


I see. Well, I would only see that as an issue if it would 
compile and then generate code that differs from what one 
intended. But since it errors out, I don't see a problem, either, 
though it would be best to enhance that error message to give a 
hint that the programmer may have triggered that ambiguous case 
by accident. Something like "Did you mean `out() (result)`?"

Re: Dealing with the interior pointers bug

[TheGag96 via Digitalmars-d-learn]

On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it 
sees something that *might* be a pointer, it assumes it *is* a 
pointer and thus had better not get freed.


So is the GC then simply made to be "better-safe-than-sorry" or 
is this a consequence of how the GC does things? Or rather, does 
the GC know the type of any references to its memory at all? I 
suppose I should really ask if there's a document other than 
druntime's source that describes how the GC really works under 
the hood haha.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 14:49:09 UTC, Moritz Maxeiner wrote:

On Wednesday, 21 June 2017 at 13:24:24 UTC, MysticZach wrote:


So weird how this discussion is happening in parallel with 
this other discussion :-) :


http://forum.dlang.org/post/rkdpuuggltowhqmcm...@forum.dlang.org


It is, though as I have pointer out over there, I would really 
like to decouple assert semantics from the new contract 
semantics to achieve the maximum elegance we can within the 
design limits of the language.


Well I'd be just as happy expanding the design limits of the 
language, i.e. `assert`, if that were a better option. The issue 
you raise is just how different are `in` and `out` contracts from 
regular `assert` contracts. They _are_ all listed in the same 
section of the documentation [1], for whatever that's worth.


The practical question is whether one can assume that the same 
semantics used for `assert`, whatever they may be, will in all 
cases be desirable for `in` and `out` too. The flexibility of 
decoupling them is one solution, if they are clearly sufficiently 
different. But another option is simply to upgrade `assert` to 
make sure it offers what everyone wants. I don't know what to 
suggest, because I don't if `assert` can be made good enough to 
warrant direct inclusion into the grammar. If it could, then all 
contracts, including plain `assert` statements, would benefit 
from them.


[1] https://dlang.org/spec/contracts.html

Re: gdc is in

[Meta via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)

I found out because it's on the front page of HN right now, 
where commenters are asking questions about D.


Congratulations indeed. Isn't this something like 8 years in the 
making? Looks like GCC finally relented and accepted GDC.

Re: dmd -betterC

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:37:03 UTC, Adam D. Ruppe wrote:
Then, the last thing from my complaint list (which I wrote in 
TWID and emailed to you back October) is that struct 
destructors don't work


https://github.com/dlang/dmd/pull/6923


If you want bugzilla entries you can make them yourself from the 
patches. But these two follow up fix the issues I laid out in 
that first one you linked to earlier.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 14:22:52 UTC, Moritz Maxeiner wrote:
If you do accidentally forget the extra set of parens on the 
`out` contract, you would get "Error: `do` expected before 
function body after a bracketed `out` contract" at the end of 
the function.


(If, however, it a happens to be a nested function, and the 
next statement in that function happens to be `do`, then the 
parser will think the `do` loop is the function body... Mmmm, 
is this worth worrying about??)


Could you give a specific (short) example of what you think of?
I don't see any potential for ambiguity in the following at a 
quick glance, so I'm not sure I got where you think the problem 
lies:


---
void foo()
{
int bar(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result)(result > 0) { ... }
do {} while (true);
}
---


The only problem is if a programmer forgets to add the additional 
parentheses, in which case the bracketed block is then mistaken 
for the `out` contract, which will lead to a confusing error 
message. For example:


void foo()
{
   int bar(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out /*whoops, forgot `( )`*/(result) { ... }

   do { ... }
   while (true); // Error: while statement cannot contain just `;`
}

Honestly this doesn't seem like a big deal, as I'd imagine it'd 
be hard not to notice that code like this wasn't working as 
expected. And also extremely rare. So I'm still in favor.

Re: libc dependency

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-06-21 17:51, David Nadlinger wrote:


This is not relevant for cross-compilation, as long as you have the
libraries available. You can actually link a D Windows x64/MSVCRT
executable from Linux today if you copy over the necessary libraries.
The question is just how we can make this as easy as possible for users.


Perhaps not when targeting Windows but when targeting Linux. Can you 
target a specific version of libc or do you need to use static linking?


--
/Jacob Carlborg

[Issue 17540] New: std.net.curl: HTTP no possibillity to set CURLOPT_NOPROXY

[via Digitalmars-d-bugs]

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

  Issue ID: 17540
   Summary: std.net.curl: HTTP no possibillity to set
CURLOPT_NOPROXY
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

HTTP does not provide any possibility to set the NO_PROXY value
(CURLOPT_NOPROXY). Please add a method to set the NO PROXY value.

--

Re: How can I use ldc2 and link to full runtime on arm with no OS

[Dan Walmsley via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:45:32 UTC, David Nadlinger wrote:

On Wednesday, 21 June 2017 at 14:53:04 UTC, Dan Walmsley wrote:
when trying to compile I'm getting lots of errors like this 
one:


C:\dev\repos\druntime\src\gc\impl\manual\gc.d(28): Error: 
module config is in file 'gc\config.d' which cannot be read


import path[0] = 
C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import\ldc


import path[1] = 
C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import


Build Failed

any ideas what could be the cause?


You are not adding druntime/src to the import path.

I'd suggest you focus on other things first, though. Having D's 
GC on a platform with less than 1 MiB RAM is a rather sketchy 
proposition.


 — David


My idea is to build the whole thing, see what the code size and 
performance is, and then one by one reduce things down as needed.


Starting from nothing so far has been a bit of a none starter!

Re: GDC generate wrong .exe ("not a valid win32 application")

[David Nadlinger via Digitalmars-d-learn]

On Monday, 19 June 2017 at 14:08:56 UTC, Patric Dexheimer wrote:

Fresh install of GDC. (tried with 32x ad 32_64x)


Where did you get the GDC executable from? The GDC project 
doesn't currently offer any official builds that target Windows; 
the 6.3.0 builds from https://gdcproject.org/downloads in fact 
generate Linux binaries.


 — David

Re: gdc is in

[Johannes Pfau via Digitalmars-d]

Am Wed, 21 Jun 2017 15:44:08 +
schrieb Nordlöw :

> On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:
> > the gcc tree:
> >
> > https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
> >
> > Congratulations to Iain and the gdc team. :)
> >
> > I found out because it's on the front page of HN right now, 
> > where commenters are asking questions about D.  
> 
> Which frontend version (2.0xx) is GDC currently at?

2.068 was the last C++ version then Iain backported changes to the C++
version get phobos 2.071.2 working. So it's effectively a C++ version of
2.071.2 or maybe slighly newer.

(The main reason for this backporting was to get a C++ version
which provides the same interface/headers as the current D frontend
version. This should allow for 'seamless' switching between the C++ and
D frontends)

-- Johannes

Re: libc dependency

[David Nadlinger via Digitalmars-d-learn]

On Wednesday, 21 June 2017 at 06:58:43 UTC, Jacob Carlborg wrote:
Musl (or similar) should be available as an alternative. That 
will make it easier to cross-compile as well.


This is not relevant for cross-compilation, as long as you have 
the libraries available. You can actually link a D Windows 
x64/MSVCRT executable from Linux today if you copy over the 
necessary libraries. The question is just how we can make this as 
easy as possible for users.


 — David

Re: gdc is in

[Johannes Pfau via Digitalmars-d]

Am Wed, 21 Jun 2017 15:11:39 +
schrieb Joakim :

> the gcc tree:
> 
> https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
> 
> Congratulations to Iain and the gdc team. :)
> 
> I found out because it's on the front page of HN right now, where 
> commenters are asking questions about D.

Awesome! And here's our status page for the patch review:

https://wiki.dlang.org/GDC/GCCSubmission

-- Johannes

Re: How can I use ldc2 and link to full runtime on arm with no OS

[David Nadlinger via Digitalmars-d]

On Wednesday, 21 June 2017 at 14:53:04 UTC, Dan Walmsley wrote:

when trying to compile I'm getting lots of errors like this one:

C:\dev\repos\druntime\src\gc\impl\manual\gc.d(28): Error: 
module config is in file 'gc\config.d' which cannot be read


import path[0] = 
C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import\ldc


import path[1] = 
C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import


Build Failed

any ideas what could be the cause?


You are not adding druntime/src to the import path.

I'd suggest you focus on other things first, though. Having D's 
GC on a platform with less than 1 MiB RAM is a rather sketchy 
proposition.


 — David

Re: gdc is in

[Nordlöw via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

Congratulations to Iain and the gdc team. :)


BTW: Thanks, Ian!

Re: gdc is in

[Nordlöw via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)

I found out because it's on the front page of HN right now, 
where commenters are asking questions about D.


Which frontend version (2.0xx) is GDC currently at?

And how soon can we expect more recent ones?

Re: gdc is in

[Kapps via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)

I found out because it's on the front page of HN right now, 
where commenters are asking questions about D.


Awesome, congratulations!

Re: dmd -betterC

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 20 June 2017 at 04:45:21 UTC, Walter Bright wrote:

Please file bugzilla issues for remaining problems.


I'll do you one better: https://github.com/dlang/dmd/pull/6922

It is a trivial patch to hack fix the big issue I have. Then the 
real fix is what Lucia is working on, based on her dconf talk. 
But since betterC is a hack fix in the first place, I say pull 
that in with your PR and together, we have a *working* "better C".


Then, the last thing from my complaint list (which I wrote in 
TWID and emailed to you back October) is that struct destructors 
don't work

Dealing with the interior pointers bug

[TheGag96 via Digitalmars-d-learn]

I saw this Tip of the Week a while ago 
(http://arsdnet.net/this-week-in-d/2017-mar-12.html) and was kind 
of perplexed at it. It seems like a crazy potential bug... How 
exactly is the GC implemented that causes this problem to crop 
up? Does the GC just blindly scan memory until it finds pointers 
to heap memory to mark as "don't delete"? Could it ever be fixed?

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Timon Gehr via Digitalmars-d]

On 21.06.2017 02:51, MysticZach wrote:


I think people could get used to the cognitive dissonance.


That's really not what D is about.


I've already gotten used to it just by writing this DIP.


I think it is likely that you are an outlier.


If such an alternative checking system is utilized,


If so, there should be a way to hook into the checking logic. This has 
nothing at all to do with contract syntax. asserts and contracts are 
coupled already, as in-contracts form a disjunction on override by 
catching AssertErrors.



the syntax for  writing contracts should be as easy
for them as for those using `assert`. 


Maybe, but your DIP does not pull its own weight as long as the latter 
syntax is not a notable improvement over what we have now. H. S. Teoh's 
counter-proposal is, and I think your DIP has a much higher chance of 
acceptance if you go with it.

Re: gdc is in

[Mike Parker via Digitalmars-d]

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)

I found out because it's on the front page of HN right now, 
where commenters are asking questions about D.


It's on reddit, too:

https://www.reddit.com/r/programming/comments/6im1yo/david_edelsohn_d_language_accepted_for_inclusion/

gdc is in

[Joakim via Digitalmars-d]

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)

I found out because it's on the front page of HN right now, where 
commenters are asking questions about D.

Re: How can I use ldc2 and link to full runtime on arm with no OS

[Dan Walmsley via Digitalmars-d]

On Wednesday, 21 June 2017 at 14:53:04 UTC, Dan Walmsley wrote:

On Tuesday, 20 June 2017 at 19:44:46 UTC, kinke wrote:

[...]


when trying to compile I'm getting lots of errors like this one:

C:\dev\repos\druntime\src\gc\impl\manual\gc.d(28): Error: 
module config is in file 'gc\config.d' which cannot be read


import path[0] = 
C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import\ldc


import path[1] = 
C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import


Build Failed

any ideas what could be the cause?


and also:


LLVM ERROR: unsupported relocation on symbol
[CC 9/164][druntime]convert.d

Build Failed

LLVM ERROR: unsupported relocation on symbol

after changing flags to:

-c -O0 -lib -betterC -release -boundscheck=off -march=thumb 
-mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi

Re: How can I use ldc2 and link to full runtime on arm with no OS

[Dan Walmsley via Digitalmars-d]

On Tuesday, 20 June 2017 at 19:44:46 UTC, kinke wrote:

On Tuesday, 20 June 2017 at 17:52:59 UTC, Dan Walmsley wrote:

How do I link in the run time and gc, etc?


In your case, you firstly need to cross-compile druntime to 
your target. This means compiling most files in the src 
subdirectory of LDC's druntime [1], excluding obvious ones like 
src\test_runner.d, src\core\sys, src\core\stdcpp etc. There are 
also a bunch of C and assembly files which need to be 
cross-compiled with a matching gcc. You'll need to do this 
manually via something along these lines:


cross-gcc -c <.c files and .asm/S files>
ldc2 -mtriple=... -lib -betterC -release -boundscheck=off <.o 
files generated above>  
-of=libdruntime.a


Then try linking your minimal code against that druntime (and 
static C libs, as druntime is built on top of the C runtime, 
see [2]). Depending on what features you make use of in your 
code, you'll need to patch linked-in druntime modules to remove 
the OS dependencies and possibly reduce the C runtime 
dependencies as well.


[1] https://github.com/ldc-developers/druntime.
[2] 
http://forum.dlang.org/thread/mojmxbjwtfmioevuo...@forum.dlang.org


when trying to compile I'm getting lots of errors like this one:

C:\dev\repos\druntime\src\gc\impl\manual\gc.d(28): Error: module 
config is in file 'gc\config.d' which cannot be read


import path[0] = 
C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import\ldc


import path[1] = 
C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import


Build Failed

any ideas what could be the cause?

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 13:24:24 UTC, MysticZach wrote:


So weird how this discussion is happening in parallel with this 
other discussion :-) :


http://forum.dlang.org/post/rkdpuuggltowhqmcm...@forum.dlang.org


It is, though as I have pointer out over there, I would really 
like to decouple assert semantics from the new contract semantics 
to achieve the maximum elegance we can within the design limits 
of the language.

Re: Replacing Make for the DMD build

[jmh530 via Digitalmars-d]

On Wednesday, 21 June 2017 at 14:11:58 UTC, Atila Neves wrote:


I'm not the best at documentation. Funnily enough, I made an 
effort with reggae, which might just show how bad I am at this.




Ha, well maybe ask one of the users then?

There's not much to compare/constrast - dub is a package 
manager that also builds your code, as long as your 
requirements are simple, it doesn't have a DAG. reggae is a 
build system. You wouldn't be able to replace the Makefiles 
with dub. You _would_ be able to build phobos, but that's not 
all the Makefiles do.


Atila


This is what I was thinking: start with a simple project, show 
how you can build it with dub or with reggae, then show a 
slightly more complicated project that dub cannot handle well and 
show how you can use reggae (and integrate it with dub).

Re: dmd -betterC

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 13:53:02 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 10:51:39 UTC, ketmar wrote:
there, of course, *IS* The difference. besides the aesthetical 
one (seeing failed condition immediately "clicks" in your 
head, and generic "assertion failed" message is only 
frustrating), there may be the case when source code changed 
since binary was built. here, line number gives you zero 
information, and you have to checkout that exact version, and 
go check the line. but when failed condition dumped, most of 
the time it allows you to see what is wrong even without 
switching to the old codebase (yes, "most of the time" is from 
RL -- it is literally *most* of the time for me, for example).


How would you solve this issue? By pure chance, we're debating 
this exact same issue right now in the DIP1009 thread [1].


Solutions:

 1. Make more informative asserts the compiler default. This 
threatens performance, which argues against it.


 2. Status quo. Make people use whatever asserts they want, 
e.g. fluent asserts [2]. This would mean that H.S Teoh's 
proposed syntax for DIP1009 [3] would carry less weight, and 
the existing proposal would carry more. Elegance is sacrificed 
for the sake of versatility.


[...]


The verbose (existing) syntax already allows such versatility. I 
see little reason to make the new syntax support that as well, 
since there is (AFAIK) no proposal to drop the verbose syntax 
(and I would be against dropping it, anyway).

I would prefer this:
- Keep the verbose (already existing) syntax with assert 
statements in brace-delimited in/out blocks for people who need 
versatility over elegance
- Make the new syntax elegant for the common cases (as discussed 
in the DIP 1009 round 1 review thread), dropping explicit asserts
- Decouple the semantics of contract checking for the new syntax 
from assert's implementation and define those semantics similar 
to what I wrote here[1]
- Regarding contract conditions printed verbatim on failure: I 
would support that in the implementation sketched by [1] via a D 
version like `PrintViolatedContracts` and not couple that with 
regular asserts at all


[1] 
http://forum.dlang.org/post/vgxvdpqcjobngmzrv...@forum.dlang.org

Re: dmd -betterC

[Kagamin via Digitalmars-d]

On Wednesday, 21 June 2017 at 14:00:33 UTC, ketmar wrote:
i did in aliced: just added printing of `assert` condition. 
that's all. no variable dumps, no other things -- just 
`.toChar()` the condition, and print it. and you know what? it 
is *surprisingly* effective, eats *no* additional compiler 
resources, and solved all the problems with "dumb asserts" i 
had.


You use it to locate the assert?

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 13:11:10 UTC, MysticZach wrote:

[...]

My fix would be to require two sets of parentheses for the new 
conditional, like so:


OutStatement:
   ...
   // new version
   out ( Identifier ) ( IfCondition )
   out ( ) ( IfCondition )

This makes the grammar unambiguous and clean. And because 
normally `out` contracts want to check the return value, the 
last case, `out ( ) ( ... )` will be the rare one.


If I read that correctly as

---
int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result)(result > 0) { ... }
---

then yeah, I would be happy with that, as well (and would love 
for the DIP to do this instead).



If you do accidentally forget the extra set of parens on the 
`out` contract, you would get "Error: `do` expected before 
function body after a bracketed `out` contract" at the end of 
the function.


(If, however, it a happens to be a nested function, and the 
next statement in that function happens to be `do`, then the 
parser will think the `do` loop is the function body... Mmmm, 
is this worth worrying about??)


Could you give a specific (short) example of what you think of?
I don't see any potential for ambiguity in the following at a 
quick glance, so I'm not sure I got where you think the problem 
lies:


---
void foo()
{
int bar(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result)(result > 0) { ... }
do {} while (true);
}
---

Re: Replacing Make for the DMD build

[Atila Neves via Digitalmars-d]

On Tuesday, 20 June 2017 at 19:38:14 UTC, jmh530 wrote:
On Tuesday, 20 June 2017 at 19:06:05 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 06/19/2017 04:06 AM, Russel Winder via Digitalmars-d wrote:


Reggae is D's pitch in the CMake and Meson class of 
meta-build tools.

Why aren't all the D compiler and tool developments using it?


I'm convinced a big part of that is because DUB is ubiquitous 
and incredibly helpful in the D world for package management, 
but plays very poorly with any build system that isn't DUB's 
internal one.




While the dub documentation is not always the best, it seems to 
me to be in a better state than reggae's. I've heard about 
reggae a bit on the forum, but I never really made any attempt 
to try to use it. dub seems a lot simpler for small projects.


Maybe Atila could do a blog post with some simple examples and 
compare/contrast with dub?


I'm not the best at documentation. Funnily enough, I made an 
effort with reggae, which might just show how bad I am at this.


There's not much to compare/constrast - dub is a package manager 
that also builds your code, as long as your requirements are 
simple, it doesn't have a DAG. reggae is a build system. You 
wouldn't be able to replace the Makefiles with dub. You _would_ 
be able to build phobos, but that's not all the Makefiles do.


Atila

Re: dmd -betterC

[ketmar via Digitalmars-d]

p.s.: `assert` is not there to debug your code, it is there to *guard* your 
code. if it is not clear what is wrong from printing ONLY failed condition 
(without variable values), then you have to debug it "for real".

Re: dmd -betterC

[ketmar via Digitalmars-d]

MysticZach wrote:


On Wednesday, 21 June 2017 at 10:51:39 UTC, ketmar wrote:
there, of course, *IS* The difference. besides the aesthetical one 
(seeing failed condition immediately "clicks" in your head, and generic 
"assertion failed" message is only frustrating), there may be the case 
when source code changed since binary was built. here, line number gives 
you zero information, and you have to checkout that exact version, and 
go check the line. but when failed condition dumped, most of the time it 
allows you to see what is wrong even without switching to the old 
codebase (yes, "most of the time" is from RL -- it is literally *most* 
of the time for me, for example).


How would you solve this issue?


i did in aliced: just added printing of `assert` condition. that's all. no 
variable dumps, no other things -- just `.toChar()` the condition, and 
print it. and you know what? it is *surprisingly* effective, eats *no* 
additional compiler resources, and solved all the problems with "dumb 
asserts" i had.


for some reason people insisting on printing every thing that is possible 
to print in `assert`. it is rarely interesting IRL, 'cause most of the time 
it will print nonsence anyway. failed assert usually means either that 
something went *very* wrong long before it, or it is almost immediately 
obvious *what* exactly is wrong, without dumping garbage variables.

Re: dmd -betterC

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 10:51:39 UTC, ketmar wrote:
there, of course, *IS* The difference. besides the aesthetical 
one (seeing failed condition immediately "clicks" in your head, 
and generic "assertion failed" message is only frustrating), 
there may be the case when source code changed since binary was 
built. here, line number gives you zero information, and you 
have to checkout that exact version, and go check the line. but 
when failed condition dumped, most of the time it allows you to 
see what is wrong even without switching to the old codebase 
(yes, "most of the time" is from RL -- it is literally *most* 
of the time for me, for example).


How would you solve this issue? By pure chance, we're debating 
this exact same issue right now in the DIP1009 thread [1].


Solutions:

 1. Make more informative asserts the compiler default. This 
threatens performance, which argues against it.


 2. Status quo. Make people use whatever asserts they want, e.g. 
fluent asserts [2]. This would mean that H.S Teoh's proposed 
syntax for DIP1009 [3] would carry less weight, and the existing 
proposal would carry more. Elegance is sacrificed for the sake of 
versatility.


 3. Allow an additional compiler flag for more informative, but 
heavier asserts, e.g. `-release=informativeAsserts`.


 4. Allow a pragma in the code, e.g. `pragma(asserts, 
none/regular/informative)` for what kinds of asserts are to be 
used at a given moment.


 5. ???

[1] 
http://forum.dlang.org/post/mailman.3531.1498022870.31550.digitalmar...@puremagic.com

[2] http://fluentasserts.szabobogdan.com/
[3] 
http://forum.dlang.org/post/mailman.3511.1497981037.31550.digitalmar...@puremagic.com

Re: Linking external *.lib files

[Mike Parker via Digitalmars-d-learn]

On Saturday, 17 June 2017 at 00:37:18 UTC, Jolly James wrote:

Unfortunately, the public DUB package requires to be linked 
with the libs from pkgBASE/lib. What do I have to add to 
pkgBASE's dub.json?


Side-note: the lib/ should not be moved for portability 
reasons if this is possible




My bad solution:


"lflags": [
"-Llib\\"
],



but this requires the lib folder to be part of pkgAPP, not 
pkgBASE where I would like to have it. Does anyone have an idea?


Replace the lflags directive with this in the pkgBase dub.json:

"libs": [
"$PACKAGE_DIR/libs/foo"
]

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 09:10:33 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 05:19:26 UTC, H. S. Teoh wrote:
Umm... I think we're not quite on the same page here.  What 
*else* are people supposed to use inside their contracts 
besides the built-in assert??


I believe `assert` would have to be extremely robust to merit 
being included directly into the syntax of the language. I'm 
not opposed to this in principle. But I'm no expert, and not 
willing to assume it's desirable. On the other hand, if 
`assert` were made so perfect as to ensure that no one would 
prefer a different method of bailing out of their programs, 
then you're right, and the problem of contract syntax could be 
solved at that level instead of the more "pedestrian" approach 
I'm taking.


So weird how this discussion is happening in parallel with this 
other discussion :-) :


http://forum.dlang.org/post/rkdpuuggltowhqmcm...@forum.dlang.org

Re: dmd -betterC

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 20 June 2017 at 23:43:47 UTC, Walter Bright wrote:
Those strings eat up space and are of pretty marginal utility. 
Don't want to make assert's so bloatsome that people are 
discouraged from using them.


Ah, so that's why you exclude the strings in -betterC whose main 
reason for existing is targeting resource-limited 
microcontrollers, yet include them now in a default build, which 
is aimed at main computers with gigabytes of space. I understand 
now.



...oh wait it currently does EXACTLY THE OPPOSITE. If you are 
seriously concerned about the bytes, why include them in -betterC?

Re: Linking external *.lib files

[bachmeier via Digitalmars-d-learn]

On Wednesday, 21 June 2017 at 13:07:31 UTC, Jolly James wrote:

*push*


Have you asked on the Dub forum?

http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 12:05:55 UTC, Moritz Maxeiner wrote:

On Wednesday, 21 June 2017 at 09:53:40 UTC, meppl wrote:

On Wednesday, 21 June 2017 at 09:27:20 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner
Adding `if (...)` should not be different from adding `in 
(...)` or `out (...)` in terms of syntax rules: it's 
inconsistent. If you want to have that `do` there, I would 
argue that it should also become required if only an `if (...)` 
is present, so


---
 int myFunc(Args...)(Args args)
   if (Args.length > 2)
   { ... }
---

should then become illegal and must be rewritten as

---
 int myFunc(Args...)(Args args)
   if (Args.length > 2)
   do { ... }
---

I doubt that's going to happen, though (too much code 
breakage), and I also don't like it. Simply drop the `do`.


I tend to agree. I think the grammar for `out` contracts is still 
murky, though, because the normal existing case is:


OutStatement:
   out ( Identifier ) { OutContractsBody }
   out { OutContractsBody }

My fix would be to require two sets of parentheses for the new 
conditional, like so:


OutStatement:
   ...
   // new version
   out ( Identifier ) ( IfCondition )
   out ( ) ( IfCondition )

This makes the grammar unambiguous and clean. And because 
normally `out` contracts want to check the return value, the last 
case, `out ( ) ( ... )` will be the rare one. If you do 
accidentally forget the extra set of parens on the `out` 
contract, you would get "Error: `do` expected before function 
body after a bracketed `out` contract" at the end of the function.


(If, however, it a happens to be a nested function, and the next 
statement in that function happens to be `do`, then the parser 
will think the `do` loop is the function body... Mmmm, is this 
worth worrying about??)

Re: Linking external *.lib files

[Jolly James via Digitalmars-d-learn]

*push*

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 12:43:46 UTC, meppl wrote:


yeah, i was probably not thinking too carefully about it. My 
idea was to keep the code readable, if the contracts are long. 
but as long as the "do" must appear behind a '}', everything is 
still fine, more or less.


both are readable, but one time we write `do` and the other 
time we dont. furthermore the second function body looks a 
little bit like belonging to "out". someone who is learning the 
D-language might get confused.


Oh, I hadn't thought about mixing the two syntax forms. I would 
just forbid it. Your signature then uses *either* the verbose 
form, *or* the compact form.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[meppl via Digitalmars-d]

On Wednesday, 21 June 2017 at 12:05:55 UTC, Moritz Maxeiner wrote:

On Wednesday, 21 June 2017 at 09:53:40 UTC, meppl wrote:

On Wednesday, 21 June 2017 at 09:27:20 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner 
wrote:

int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result => result > 0) { ... }


avoiding the "anonymous scope"-extra wouldnt hurt much?

int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result => result > 0)
  do { ... }


Adding `if (...)` should not be different from adding `in 
(...)` or `out (...)` in terms of syntax rules: it's 
inconsistent. If you want to have that `do` there, I would 
argue that it should also become required if only an `if (...)` 
is present, so


---
 int myFunc(Args...)(Args args)
   if (Args.length > 2)
   { ... }
---

should then become illegal and must be rewritten as

---
 int myFunc(Args...)(Args args)
   if (Args.length > 2)
   do { ... }
---

I doubt that's going to happen, though (too much code 
breakage), and I also don't like it. Simply drop the `do`.



yeah, i was probably not thinking too carefully about it. My idea 
was to keep the code readable, if the contracts are long. but as 
long as the "do" must appear behind a '}', everything is still 
fine, more or less.



int myFunc1(Args...)(Args args)
if (Args.length > 2)
in
{
// much code
}
do
{
...
}


int myFunc2(Args...)(Args args)
if (Args.length > 2)
in
{
// much code
}
out (result => result > 0)
{
...
}


both are readable, but one time we write `do` and the other time 
we dont. furthermore the second function body looks a little bit 
like belonging to "out". someone who is learning the D-language 
might get confused.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 09:53:40 UTC, meppl wrote:

On Wednesday, 21 June 2017 at 09:27:20 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner 
wrote:

int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result => result > 0) { ... }


avoiding the "anonymous scope"-extra wouldnt hurt much?

int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result => result > 0)
  do { ... }


Adding `if (...)` should not be different from adding `in (...)` 
or `out (...)` in terms of syntax rules: it's inconsistent. If 
you want to have that `do` there, I would argue that it should 
also become required if only an `if (...)` is present, so


---
 int myFunc(Args...)(Args args)
   if (Args.length > 2)
   { ... }
---

should then become illegal and must be rewritten as

---
 int myFunc(Args...)(Args args)
   if (Args.length > 2)
   do { ... }
---

I doubt that's going to happen, though (too much code breakage), 
and I also don't like it. Simply drop the `do`.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 11:31:41 UTC, Moritz Maxeiner wrote:

[...]


Sorry for double post, please ignore this one.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 09:10:33 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 05:19:26 UTC, H. S. Teoh wrote:
On Wed, Jun 21, 2017 at 01:06:40AM +, MysticZach via 
Digitalmars-d wrote:
On Tuesday, 20 June 2017 at 21:04:16 UTC, Steven 
Schveighoffer wrote:
> This is much much better. The verbosity of contracts isn't 
> really the brace, it's the asserts.


I think it's both, and I think the brace is the only thing 
that can be improved upon. How could you justify insisting 
that everyone use the built-in asserts for their contracts?

[...]

Umm... I think we're not quite on the same page here.  What 
*else* are people supposed to use inside their contracts 
besides the built-in assert??


Many people have expressed discontent with existing asserts. In 
fact, they were just changed yesterday to address one of these 
concerns:


https://github.com/dlang/dmd/pull/6901


Just my two cents, again: DbC prohibits broken contracts, i.e. 
any violation is a bug. From my point of view, a broken contract 
in the simple syntax as proposed by H.S.Teoh, should by default
- in debug mode: Give you debug information (stack trace, etc.) 
then terminate

- in release mode: Print file and line number and then terminate
No cleanup by default.

People I've observed voicing issues with assert have happened to 
fall into one of these three categories:


- People who agree with the terminate approach, but want custom 
cleanup


I remain skeptical about the sanity of calling arbitrary code 
with the knowledge of a previously triggered bug (in release 
mode), but that can be easily addressed by allowing to register a 
hook that gets called on contract violations; the process will 
still terminate after the hook is finished, though.


- People whose use cases (allegedly) allows recovery of bugs

I would consider these as niche cases that are already covered by 
the preexisting verbose syntax: `in { if (!cond) throw 
Exception(); }`. I would simply not include support for that in 
the easy-to-read variant.


- People who use assert (or other Errors) for user input 
validation


That's not what they are for.

To sum it up, I would like semantics similar to this (simplified) 
code for this syntax:


---
void delegate() nothrow onContractViolation;

template validateContract(T) if (isInputContract!T || 
isOutputContract!T)

{
version (ValidateContracts) void violated(ref T contract)
{
import core.stdc.stdlib : _Exit;

debug printDebugInfo(contract);
else  printFileAndLIne(contract);

if (onContractViolation !is null) onContractViolation();

_Exit(1); // without scope guard since 
onContractViolation is `nothrow`

}

static if (isInputContract!T) {
void validateContract(T contract)
{
version (ValidateContracts) if (!contract) 
violated(contract);

}
} else {
void validateContract(T contract, T.ResultType result)
{
version (ValidateContracts) if (!contract(result)) 
violated(contract);

}
}
}
---

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 09:10:33 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 05:19:26 UTC, H. S. Teoh wrote:
On Wed, Jun 21, 2017 at 01:06:40AM +, MysticZach via 
Digitalmars-d wrote:
On Tuesday, 20 June 2017 at 21:04:16 UTC, Steven 
Schveighoffer wrote:
> This is much much better. The verbosity of contracts isn't 
> really the brace, it's the asserts.


I think it's both, and I think the brace is the only thing 
that can be improved upon. How could you justify insisting 
that everyone use the built-in asserts for their contracts?

[...]

Umm... I think we're not quite on the same page here.  What 
*else* are people supposed to use inside their contracts 
besides the built-in assert??


Many people have expressed discontent with existing asserts. In 
fact, they were just changed yesterday to address one of these 
concerns:


https://github.com/dlang/dmd/pull/6901


Just my two cents, again: DbC prohibits broken contracts, i.e. 
any violation is a bug. From my point of view, a broken contract 
in the simple syntax as proposed by H.S.Teoh, should by default
- in debug mode: Give you debug information (stack trace, etc.) 
then terminate

- in release mode: Print file and line number and then terminate
No cleanup by default.

People I've observed voicing issues with assert have happened to 
fall into one of these three categories:


- People who agree with the terminate approach, but want custom 
cleanup


I remain skeptical about the sanity of calling arbitrary code 
with the knowledge of a previously triggered bug (in release 
mode), but that can be easily addressed by allowing to register a 
hook that gets called on contract violations; the process will 
still terminate after the hook is finished, though.


- People whose use cases supposedly allows recovery of bugs

These are niche cases that can be covered by the preexisting 
verbose syntax: `in { if (!cond) throw Exception(); }`. I would 
simply not include support for that in the easy-to-read variant.


- People who use assert (or other Errors) for user input 
validation


That's not what they are for.

To sum it up, I would like semantics similar to this (simplified 
code) for this syntax:


---
void delegate() @nothrow onContractViolation;

void validateContract(bool)(lazy bool cond)
{
version (CheckContracts) if (!cond)
{
import core.stdc.stdlib : _Exit;

debug printDebugInfo(...);
else  printFileAndLIne();


{

if (onContractViolation !is null) 
onContractViolation();

_Exit(1);
} else {
print
}
}
}
---

Re: implib.exe no output files

[Ivan Kazmenko via Digitalmars-d-learn]

On Monday, 19 June 2017 at 23:11:29 UTC, Joel wrote:

On Sunday, 18 June 2017 at 09:48:31 UTC, Ivan Kazmenko wrote:

On Sunday, 18 June 2017 at 07:41:27 UTC, Joel wrote:

I got the file here: http://ftp.digitalmars.com/bup.zip

It works on other computers.

I was trying to update to the latest DAllegro 
(https://github.com/SiegeLord/DAllegro5).


Though, I used another computer for the lib files and still 
couldn't get the latest DAllegro5 working.


The .bat files in https://github.com/SiegeLord/DAllegro5 work 
fine for me.


Could you please be more specific about what exactly you are 
doing, and what went wrong?


Keep in mind that you need Allegro binaries (e.g. from 
http://liballeg.org/download.html#windows) to use implib.


Ivan Kazmenko.


I have the dll's in the same directory where I run the create 
lib .bat file. It displays the normal stuff, but no lib files!


I'm wondering if implib needs to be worked on.


Sorry, that's still not specific enough.

I've just tested this in a fresh directory:
1. Get https://github.com/SiegeLord/DAllegro5
2. Get 
https://github.com/liballeg/allegro5/releases/download/5.2.2.0/allegro-mingw-gcc6.2.0-x86-static-5.2.2.zip
3. Put, for example, allegro-5.2.dll from the archive to 
DAllegro5 directory.

4. Run create_import_libs.bat, here is the output:
-
...>rem This batch file creates import dlls in the current folder 
and strips the version number

...>rem because OPTLINK sucks.
Digital Mars Import Library Manager Version 7.6B1n
Copyright (C) Digital Mars 2000.  All Rights Reserved.
Input is a Windows NT DLL file 'allegro-5.2.dll'.
Output is a Windows NT import library.
Digital Mars Import Library Creator complete.
-
5. Now I got allegro.lib in the directory.

Which of these steps fails for you, and how?

Ivan Kazmenko.

Re: dmd -betterC

[ketmar via Digitalmars-d]

Kagamin wrote:


On Wednesday, 21 June 2017 at 06:21:37 UTC, ketmar wrote:

but refusing to generate such strings for *all* code


They are not useful enough for that, in 99% of cases location of assert 
is enough to know what's wrong, when it isn't, the string is not going to 
tell where it went wrong, so you need to debug it, in which case there's 
no difference again.


there, of course, *IS* The difference. besides the aesthetical one (seeing 
failed condition immediately "clicks" in your head, and generic "assertion 
failed" message is only frustrating), there may be the case when source 
code changed since binary was built. here, line number gives you zero 
information, and you have to checkout that exact version, and go check the 
line. but when failed condition dumped, most of the time it allows you to 
see what is wrong even without switching to the old codebase (yes, "most of 
the time" is from RL -- it is literally *most* of the time for me, for 
example).



Don't fluent asserts already do what you want? See 
http://fluentasserts.szabobogdan.com/


nope. those aren't assertions at all, compiler cannot even remove 'em with 
"-release" flag (not that i'm using it much, but still no, thanks).


mind you, assertions is not only for unittesting.

Re: dmd -betterC

[Kagamin via Digitalmars-d]

On Wednesday, 21 June 2017 at 06:21:37 UTC, ketmar wrote:

but refusing to generate such strings for *all* code


They are not useful enough for that, in 99% of cases location of 
assert is enough to know what's wrong, when it isn't, the string 
is not going to tell where it went wrong, so you need to debug 
it, in which case there's no difference again. Don't fluent 
asserts already do what you want? See 
http://fluentasserts.szabobogdan.com/

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[meppl via Digitalmars-d]

On Wednesday, 21 June 2017 at 09:27:20 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner 
wrote:

int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result => result > 0) { ... }


avoiding the "anonymous scope"-extra wouldnt hurt much?

int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result => result > 0)
  do { ... }