Re: dmd -betterC
On 6/20/2017 11:54 PM, Jacob Carlborg wrote: On 2017-06-20 22:44, Walter Bright wrote: For a C implementation that doesn't support TLS, using it in D with -betterC won't work. I'm thinking more of a C implementation where it *does* work. But perhaps you're not expected to do anything besides what you can do in C when it comes to TLS. It does work with C on Windows, Linux, OSX, and FreeBSD, and so it works with -betterC, too.
Re: What is the state of Microcontroller support in d?
On Wednesday, 21 June 2017 at 00:50:35 UTC, Mike wrote: On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote: [...] The more I think about this, the more it seems like the best approach. All this time I've been trying to find a way to build just enough runtime code to support the features I'm using, and I've only encountered frustration. It's a shame that we have to build such a massive amount of infrastructure just to get a build, only to have the linker strip it all away, but apparently that's just the way things are. Forget -betterC and -no-rtti; embrace it all! We might just be be able to turn this lemon into lemonade afterall. I'm having a bit of a change of heart (or maybe there's something in my coffee). I'll be traveling overseas for the next month, so when I return I'll revisit this and see if it still appeals to me. Mike When iv been using c++ on stm32 I have had to rely on gcsections to produce a workable binary. Have a good holiday, ill try as much as I can to improve things in the mean time 😀
Re: What is the state of Microcontroller support in d?
On Wednesday, 21 June 2017 at 00:08:24 UTC, Mike wrote:
GDC may have fixed the problem recently with [2], but I haven't
tested it. Lucia Cojocaru is (was?) also working on addressing
the problem by lowering TypeInfo calls in the compiler to
templates [3].
I've decoupled the code generating compiler (gdc) from runtime
(druntime), and will generate pseudo typeinfo if any are missing
- this is in contrast to dmd which would complain about missing
TypeInfo/corrupt object.d.
This should mean that object.d can be distilled down to just:
module object;
class Object { }
From a minilibd perspective, and the compiler will just fill in
the blanks and continue without complaint. However you'll still
get linker errors if you don't define TypeInfo anywhere. (If
there are any other compile-time errors, it's likely the dmd
front-end complaining because it can't generate some artificial
helper function).
Pay-as-you-go TypeInfo generation could be done stemming from
this. Currently, the strategy is to always generate TypeInfo in
the module that "owns" the type, on premise that although it may
not be used itself, some external module may want it.
Really though, this is probably about as far as I can push it
without making changes to the dmd frontend or druntime library
itself. IMO the right thing to do is to not push the compiler,
but to push the D runtime library into improving it's runtime
interface.
i.e: https://github.com/dlang/druntime/pull/1792
Replacing the old legacy functions with templates that don't
require typeinfo is the direction that people should be pushing
in. Without this, I can't see -fno-rtti being possible without
severely restricting users to a slim subset.
Regards,
Iain.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner wrote:
What *I* need from a DIP that addresses DbC in D (to make it
viable for me) is to make the simple case as easy as possible
to read while not introducing language inconsistencies.
With that in mind I am strongly in favor of the syntax H. S.
Teoh already proposed:
---
int myFunc(Args...)(Args args)
if (Args.length > 2)
in (args[0] != 0)
in (args[1] > 1)
out (result => result > 0);
int myFunc(Args...)(Args args)
if (Args.length > 2)
in (args[0] != 0)
in (args[1] > 1)
out (result => result > 0) { ... }
---
- in contracts take a parenthesis delimited bool expression
- out contracts take a parenthesis delimited bool function
literal.
`out` contracts would also have to account for the case where
they don't check the return value. This would confuse the grammar
a little in the case of function literals as boolean expressions.
A different possible grammar that wouldn't have this problem is:
OutStatement:
out ( IfCondition )
out ( Identifier ) ( IfCondition )
plus the existing ones:
OutStatement:
out BlockStatement
out ( Identifier ) BlockStatement
Re: What is the state of Microcontroller support in d?
On Wednesday, 21 June 2017 at 00:50:35 UTC, Mike wrote: On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote: [...] The more I think about this, the more it seems like the best approach. All this time I've been trying to find a way to build just enough runtime code to support the features I'm using, and I've only encountered frustration. It's a shame that we have to build such a massive amount of infrastructure just to get a build, only to have the linker strip it all away, but apparently that's just the way things are. [...] Mike, is there an email address I can contact you outside the forum?
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 14:12:36 UTC, Dan Walmsley wrote: Firstly who do we need to talk to about the bloat in LDC? I'll be happy to help with the LDC stuff once I hand in my Honours thesis on the 3rd of July, just ask on https://gitter.im/ldc-developers/main or send me a message on gitter.
Re: What is the state of Microcontroller support in d?
On Wednesday, 21 June 2017 at 08:25:35 UTC, Dan Walmsley wrote: Mike, is there an email address I can contact you outside the forum? "slavo"~"5150"~AT_SYMBOL~"yahoo"~PERIOD~"com";
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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
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.
While D currently gives you the flexibility of arbitrary code
inside a contract, a contract is not supposed to do anything
other than to verify that the caller has passed in arguments
that are valid.[1]
To me, it's still a question of whether `assert` is the only
valid way to bail out of a program. I agree that arbitrary other
code inside contracts is bad practice, and that wanting to
prohibit it makes sense.
Furthermore, contracts specify what constitutes valid input to
the function -- this serves both as documentation to would-be
callers, and also as specification to the compiler as to what
are acceptable arguments. The built-in assert mechanism serves
both purposes -- especially the second purpose because the
compiler understands it directly, as opposed to some other
user-defined mechanism that the compiler wouldn't understand.
This wouldn't change just with a syntax rewrite. If the compiler
wanted to use `assert` for optimization purposes, it could do
that just as well with any of the proposed syntaxes. People who
didn't want to use `assert` would be at a disadvantage in this
regard. But at least they would have that option.
Besides, this is a matter of semantics, whereas this DIP is
addressing the DbC syntax. If people demand an alternative to
the built-in assert, it's not hard to have the compiler lower
the syntax into some globally-defined symbol that can be
redefined by the user. Or, indeed, simply funnel the expression
into a user-defined assert alternative, e.g.:
int myFunc(Args...)(Args args)
if (args.length > 1)
in (myAssert(args[0] > 0))
{
return doStuff(args);
}
bool myAssert(T)(T t) {
// do whatever alternative assert stuff you need to do
// here
return true; // bypass the built-in assert
}
I guess the optimizer can elide the assert if it knows it's
always true. If this method was sure not to incur a performance
penalty, then it may be better than my approach.
But the semantics is a different issue than the syntax, which
is the scope of this DIP.
The scope of the DIP can change, if need be. My primary goal is
in the title, to "Improve Contract Usability". I used this title
on purpose because I didn't want to get stuck if my proposal
turned out to be worse than some other one. If adding a new
semantics is actually preferable I can rewrite the DIP (and give
you credit — or you can do it yourself, if you want). It was just
as important to me to get the ball rolling as to have my
particular suggestion accepted. I wanted to stay close to the
shore, because I thought it was a little outlandish to propose a
whole new semantics. I still think it's a little outlandish,
because I can imagine a large organization wanting to rig up its
own bailout mechanism, and the new semantics would prevent them
from doing that. But so far, the comments suggest that it's worth
it to many people.
Re: What is the state of Microcontroller support in d?
On Wednesday, 21 June 2017 at 08:38:21 UTC, Nicholas Wilson wrote: On Tuesday, 20 June 2017 at 14:12:36 UTC, Dan Walmsley wrote: Firstly who do we need to talk to about the bloat in LDC? I'll be happy to help with the LDC stuff once I hand in my Honours thesis on the 3rd of July, just ask on https://gitter.im/ldc-developers/main or send me a message on gitter. whats your gitter handle?
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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) { ... }
---
- in contracts take a parenthesis delimited bool expression
- out contracts take a parenthesis delimited bool function
literal.
`out` contracts would also have to account for the case where
they don't check the return value. This would confuse the
grammar a little in the case of function literals as boolean
expressions. A different possible grammar that wouldn't have
this problem is:
OutStatement:
out ( IfCondition )
out ( Identifier ) ( IfCondition )
plus the existing ones:
OutStatement:
out BlockStatement
out ( Identifier ) BlockStatement
I may have spoke too soon. If the grammar were:
OutStatement:
out ( IfCondition )
out ( FunctionLiteral )
It might still work okay. A little hiccup in the semantics,
figuring out that the first parameter to the function literal is
meant to be the return identifier. Maybe it's not a big deal.
Re: What is the state of Microcontroller support in d?
On Wednesday, 21 June 2017 at 09:12:56 UTC, Dan Walmsley wrote: On Wednesday, 21 June 2017 at 08:38:21 UTC, Nicholas Wilson wrote: On Tuesday, 20 June 2017 at 14:12:36 UTC, Dan Walmsley wrote: Firstly who do we need to talk to about the bloat in LDC? I'll be happy to help with the LDC stuff once I hand in my Honours thesis on the 3rd of July, just ask on https://gitter.im/ldc-developers/main or send me a message on gitter. whats your gitter handle? thewilsonator
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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 { ... }
Re: dmd -betterC
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: dmd -betterC
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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
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
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
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
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
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: dmd -betterC
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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
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: dmd -betterC
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
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: Replacing Make for the DMD build
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: dmd -betterC
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: dmd -betterC
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: Replacing Make for the DMD build
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: How can I use ldc2 and link to full runtime on arm with no OS
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: How can I use ldc2 and link to full runtime on arm with no OS
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
gdc is in
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: gdc is in
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/
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: dmd -betterC
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
Re: gdc is in
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: gdc is in
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
On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote: Congratulations to Iain and the gdc team. :) BTW: Thanks, Ian!
Re: How can I use ldc2 and link to full runtime on arm with no OS
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
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: gdc is in
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: How can I use ldc2 and link to full runtime on arm with no OS
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: dmd -betterC
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: gdc is in
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: gdc is in
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
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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
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: gdc is in
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: D needs to get its shit together!
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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.
Re: D needs to get its shit together!
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: dmd -betterC
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: gdc is in
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: gdc is in
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
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
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: How can I use ldc2 and link to full runtime on arm with no OS
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
Unittests and extern(C)
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: Unittests and extern(C)
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.
Re: dmd -betterC
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: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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").)
What is your favorite D feature?
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: What is your favorite D feature?
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
Re: What is your favorite D feature?
My fav is that familiar code just works.
Re: What is your favorite D feature?
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?
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, &handleRequest);
}
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?
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?
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: dmd -betterC
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: dmd -betterC
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: What is your favorite D feature?
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: What is your favorite D feature?
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?
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: How can I use ldc2 and link to full runtime on arm with no OS
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: gdc is in
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: What is your favorite D feature?
"friendship ".writeln = ((_) => "is"~_)(" magic");
"friendship ".writeln = ((_) => "is"~_)(" magic");
just couldn't resist the temptaion, sorry.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
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: Windows integration [was: Re: There really needs to be some moderation]
On Sunday, 18 June 2017 at 21:47:48 UTC, Laeeth Isharc wrote: [snip] Windows has been a bit of a pain, but mostly from the native code library side. It should be easy to install google snappy right? On Linux it is. On Windows, not so much... And that's just one library. vcpkg is making it pretty easy to get C and C++ libraries on Windows. Snappy is supported. https://github.com/Microsoft/vcpkg
Re: What is your favorite D feature?
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 These: https://p0nce.github.io/d-idioms/
Re: What is your favorite D feature?
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 Being a GC enabled systems programming language, following the footsteps of Mesa/Cedar and Modula-3.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
On Wednesday, 21 June 2017 at 19:34:53 UTC, H. S. Teoh wrote: 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. It's related. A design flaw in D's DbC means that contracts on the whole are less important. Which means, unfortunately, that improving them is less important. Which could affect the final decision. But on the other side, binary-only libraries published in release mode are actually rare in D, right?
Re: dmd -betterC
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote: Is getting a whole lot better: https://github.com/dlang/dmd/pull/6918 You can now build D executables that do not link in anything from Phobos - only from the standard C library. Very cool - this plus Adam's changes. The next logical step for some might be to want to be able to use the bits of Phobos that don't necessarily need the runtime. Which might be a bad step. But it's oh so tempting to want to have bits that are version(NoRuntime)...
Re: gdc is in
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. :) Congratulations! Great achievement. - Johan
Re: What is your favorite D feature?
Lack of verbosity.
Clear concise code, thanks to the automatic initialization of
class members, native strings/arrays/maps/slices, UFCS,
declaration-order independence, etc.
class TOTO
{
bool IsCool;
int Age;
TUTU[] Tutus;
TOTO[string] Totos;
void Foo( TUTU tutu )
{
Tutus ~= tutu;
Totos[ tutu.Name ] = tutu.Toto;
}
}
class TUTU
{
string Name;
TOTO Toto;
this( string name )
{
Name = name;
Toto = new TOTO;
}
}
void Bar(
ref TOTO toto
)
{
toto.IsCool = !toto.IsCool;
}
void main()
{
TUTU tutu;
TOTO toto;
tutu = new TUTU( "tutu" );
toto = new TOTO;
toto.Foo( tutu );
toto.Bar();
}
Absolutely no syntactic noise !!!
This is often overlooked, while D easily beats all its direct
competitors (C++, Java, C#, etc) on that point.
Just try to implement the same code as simply in C++ and you will
be convinced that this is D's strongest feature...
And this is also what makes D feel like a super-powered
JavaScript when I use it :)
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
On Thu, Jun 22, 2017 at 05:46:06AM +, MysticZach via Digitalmars-d wrote: [...] > 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. [...] Then possibly you're missing the point behind DbC. The idea of "executing" a contract seems to indicate that you're taking the current D implementation of it as normative. However, that is not the case. The concept behind DbC is that the function specifies a set of conditions the caller must satisfy before calling it (the in-contract), and in return it promises to satisfy another set of conditions (the out-contract). Conceptually speaking, the contracts are not "executed" as if they were part of the code in the function's body; rather, they are checks that are made by the runtime (as a conceptual entity -- one might think of it as a circuit breaker or some such safeguarding device) such that if they are violated, the program is aborted because it has entered an invalid state from which further execution would lead to UB. Of course, how you implement the DbC concept is a different (albeit related) issue. In languages targeted for a VM like Java, one could conceivably implement contract verification as part of the VM itself, so that it is done "transparently" to user code. In languages like D, however, because we're targeting the machine directly, no such intermediate layer exists, and hence the natural choice of implementing contracts as part of the code. (Though, as I've said in another post, D's implementation leaves some things to be desired, such as in-contracts being part of the callee rather than the caller, which IMO would have been a better choice.) But in any case, the so-called "cognitive dissonance" comes from conflating contracts, which conceptually is part of the function's user-facing API, as opposed to the implementation details in the function body. It's like saying that the locking mechanism of the safety cap of a medicine bottle is part of the medicine's chemistry. The locking mechanism is intended to protect the medicine, e.g., from children who would suffer unintended consequences of the medicine's chemistry by their incorrect usage of it. But that hardly makes the safety mechanism the same thing as the medicine itself. Similarly, the in-contract of a function is intended to protect it from incorrect usage by buggy callers, but that hardly makes it a part of the function's body. T -- Береги платье снову, а здоровье смолоду.
