Re: Boston D Meetup: Strawman Structs
On Sunday, 23 July 2017 at 02:15:18 UTC, Steven Schveighoffer
wrote:
On 7/21/17 8:49 PM, Nicholas Wilson wrote:
On Friday, 21 July 2017 at 21:55:01 UTC, Steven Schveighoffer
wrote:
On 7/2/17 6:35 AM, Steven Schveighoffer wrote:
I'll have a short presentation on a weird trick I discovered
while writing some MySQL serialization code. Hope you can
attend!
https://www.eventbrite.com/e/d-lang-presentation-strawman-structs-tickets-35120523431
I've set up a live stream for this. No guarantees of the
quality, it will be audio + slideshow.
Waiting for people to arrive, so probably won't start until
at least 6:30.
https://www.youtube.com/watch?v=ZxzczSDaobw
Great talk!
Thanks!
Regarding the inferred attribute problem with the concepts
like Straw-man usage, this should not be a problem with my
attributes DIP, since all special attributes become normal
attributes and you could just have an AliasSeq of the required
values.
Maybe I'm misunderstanding you, but my concern is that
something like this:
struct StrawmanRange(T)
{
...
void popFront() {}
}
So popFront would be inferred to be pure, @safe, and nothrow.
However, since really we want to only do what was specified, we
don't want the compiler inferring this. More specifically, I
wouldn't want the `implements` function generating requirements
that a suitable range struct must have @safe nothrow pure
popFront. I don't think introspection can tell whether the
attributes were specified or inferred.
I don't see how being able to combine attributes is going to be
able to prevent compiler inference of them. Or maybe I am
missing something?
-Steve
Its the combining with AliasSeq in conjunction with being normal
(albeit compiler recognised) attributes that makes it work. It
doesn't matter what the compiler infers because the struct knows,
with RequiredAttributes, what attributes are _actually_ required
E.g.
struct RequiredAttributes(Values...)
if(AllSatisfy!(isCoreAttributeValue, Values))
{
alias values = AliasSeq!(Values);
}
struct StrawmanRange(T)
{
@RequiredAttributes!(): // i.e. no attributes required
// or use
//@RequiredAttributes!(safe,nothrow,nogc,pure): for very
strict functions
// can apply this on a per symbol basis too.
@property T front();
bool empty();
void popFront() {}
}
and reflect on the RequiredAttributes.values to force the
"correct" attributes in `implements` and `describeDifferences`.
// roughly and ignoring optional methods
bool Implements(Strawman,T)()
{
foreach(m; __traits(allMembers, Strawman)
{
static if (!hasMember!(T,m)
return false;
else static if (!isCovariantWith!(__traits(getMember, T,
m),getUDA!(__traits(getMember, Strawman, m), RequiredAttributes).
values)
return false;
}
return true;
}
Re: static foreach is now in github master
On 7/22/17 5:26 PM, Seb wrote: On Saturday, 22 July 2017 at 21:13:47 UTC, Steven Schveighoffer wrote: On Thursday, 20 July 2017 at 21:02:20 UTC, Seb wrote: Oh because I thought run.dlang.io wasn't using `rdmd`. However, there was a minor glitch today when I added support for flags and stdin to the docker images [2]. The good news is that it has been fixed [2] & everything should behave as usual. Sorry for the inconvenience and continued happy hacking! [1] https://github.com/dlang-tour/core-exec/pull/2 [2] https://github.com/dlang-tour/core-exec/pull/4 Now: Compilation or running program took longer than 25 seconds. Aborted! Hmm, seems to be a temporary error. It works fine for me. Are you still experiencing this? Just tried again, now working (and displaying only one list of numbers) thanks. -Steve
Re: static foreach is now in github master
On Saturday, 22 July 2017 at 21:13:47 UTC, Steven Schveighoffer wrote: On Thursday, 20 July 2017 at 21:02:20 UTC, Seb wrote: Oh because I thought run.dlang.io wasn't using `rdmd`. However, there was a minor glitch today when I added support for flags and stdin to the docker images [2]. The good news is that it has been fixed [2] & everything should behave as usual. Sorry for the inconvenience and continued happy hacking! [1] https://github.com/dlang-tour/core-exec/pull/2 [2] https://github.com/dlang-tour/core-exec/pull/4 Now: Compilation or running program took longer than 25 seconds. Aborted! -Steve Hmm, seems to be a temporary error. It works fine for me. Are you still experiencing this?
Re: Release D 2.075.0
On 7/22/2017 2:04 AM, Martin Nowak wrote: Also translating the C++ backend to D zero benefit to D users (at worst it introduces codegen bugs). I'm inclined to say we should rather spent our time on the various more important issues. It was a good move for the frontend as that will allow us to make use of D features to improve the code/architecture and to eventually turn it into a proper library. Converting the stable and well tested codebase of the backend, which will hardly receive any feature development, is unlikely to ever pay off. It'll be converted anyway. :-) I'm about half way through converting the DMC++ front end. It isn't as difficult as I expected. The -betterC is helping a lot, as well as the fact that DMC++ is still pretty much C code. Some years back Daniel Murphy and I removed a lot of the preprocessor trickery from it, which helps, too. Note that DMC++ is now Boost licensed as well. Putting the entire set in D (C compiler, C++ compiler, C preprocessor, htod converter, optimizer, code generator) makes the whole thing much more tractable, and who knows what we will be able to do with it!
Re: Release D 2.075.0
On 7/20/2017 1:20 AM, Vladimir Panteleev wrote: Later that day, I mentioned in passing that we might make building D part of the build process (of a project using D code), since building the compiler took only 3 seconds on my machine. To quote my colleague: "Whaaat? How can a compiler compile in 3 seconds?!" Back in the 80's (!) computer magazines regularly ran C compiler benchmark results. (At one time I counted 30 C compilers available for the PC.) I took a class at Standford on compilers, which included a lot of info on data flow analysis. I decided to implement it. Data flow analysis optimizations basically deleted the benchmark code, because it didn't do anything (lots of dead assignments). This compiler was released as Datalight Optimum C. The article writer concluded that the compiler had a giant bug in it, because it ran the benchmarks impossibly fast, because it deleted the dead code. Instead of being lauded as the only C compiler on the PC that did global data flow analysis, it was labeled as a buggy piece of crap. By the time we dug ourselves out of that PR disaster, other compilers had implemented it, too. Ironically, these days DMD gets repeatedly charged with not doing data flow analysis, and clang is assumed to have invented data flow analysis. Just goes to show the power of marketing :-)
Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept
Am 21.07.2017 um 09:40 schrieb Andrea Fontana: It has a lot of potential. I always hope that someone will start a 3d Printer firmware written in D for a 32bit microcontroller. I've actually started to implement a GCode processor in D a while ago, because I was unsatisfied with the open source firmwares that exist. It's more tailored towards CNC routers, but since those are pretty similar that shouldn't be a big problem. The bad news is that I don't have time to work on it anymore and it was still at a relatively early stage.
Re: Release D 2.075.0
On Thursday, 20 July 2017 at 18:22:36 UTC, Patrick Schluter wrote: 1 cpu on 2.4 GHz Westmere, gcc 6.2 version 2.067 They don't sell single-core CPUs any longer ;). What matters is the time you have to wait.
