Re: My ACCU 2016 keynote video available online
On Tuesday, 17 May 2016 at 08:42:42 UTC, Bill Hicks wrote: And here you go again with your borderline racist jokes. Not very cool. If you honestly want to find out if it's "confusing to Africans", I suggest you go to a black neighborhood and ask them. Haha, that is probably the most racist statement. When you say "black neighborhood" are you talking about in Africa or Americans in the US?
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 16:24:31 UTC, jmh530 wrote: On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: http://jackstouffer.com/blog/d_auto_decoding_and_you.html Based on the recent thread in General, I wrote this blog post that's designed to be part beginner tutorial, part objective record of the debate over it, and finally my opinions on the matter. I probably would have preferred this split up into two parts with one on the tutorial and one on the record of the debate. It seems to focus more on the debate. That wasn't my intent. I wanted the debate to be a lens into a discussion of the technical merits and demerits of auto decoding. I have reworded some of the article in order to reflect this. Maybe you could get add a section that was like "for THIS type of string, do X for performance" with clear explanations of why that is the best way and why other ways will be slower. Then, you can have other sub-sections for "for THAT type of string, do Y for performance." You have some of this detail in there, but it's organized more with respect to the context of the debate, I think. I will add this, thanks.
Re: D's Auto Decoding and You
On Tue, May 17, 2016 at 02:06:37PM +, Jack Stouffer via Digitalmars-d-announce wrote: > http://jackstouffer.com/blog/d_auto_decoding_and_you.html [...] Thanks for writing up this article! T -- What did the alien say to Schubert? "Take me to your lieder."
Re: Battle-plan for CTFE
On 05/17/2016 12:42 PM, Don Clugston wrote: > There's no need for grandiose plans, as if there is some > almost-insurmountable problem to be solved. THIS IS NOT DIFFICULT. With > the interface cleaned up, it is the well-studied problem of creating an > interpreter. Everyone knows how to do this, it's been done thousands of > times. The complete test suite is there for you. Someone just needs to > do it. Yes, exactly my words. > I think I took the approach of using syntax trees about as far as it can > go. It's possible, but it's really vile. Look at the code for doing > assignments. Bleagh. The only thing in its favour is that originally it > was the only implementation that was possible at all. Even the first, > minimal step towards creating a ctfe backend -- introducing a > syntax-tree-validation step -- simplified parts of the code immensely. Yes, this https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/dinterpret.d#L3418 is really ugly and complex, but you won't get rid of this inherent complexity. The e2ir code for AssingExp looks almost the same https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/e2ir.c#L2466. > You might imagine that it's easier to work with syntax trees than to > start from scratch but I'm certain that's not true. I'm pretty sure that > the simplest approach is to use the simplest possible > machine-independent bytecode that you can come up with. I had got to the > point of starting that, but I just couldn't face doing it in C++. All I'm saying is that interpreting the AST to generate bytecode is going to be as complex as interpreting the AST directly, but then you still a bytecode interpreter and later might still want a JIT. Using dedicated value types during interpretation instead of recycling the AST for that will also make the transitions clearer and get rid of some of the lifetime complexities in the current code. -Martin
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 17:26:59 UTC, Steven Schveighoffer wrote: However, it's perfectly legal for a front function not to be tagged @property. BTW, where is this coming from? Is it simply an emergent property of the existing implementations of isInputRange and ElementType, or is it actually by design?
Re: unit-threaded v0.6.13 - tags, autotags and support for integration tests
On 05/17/2016 10:22 AM, Meta wrote:
On Tuesday, 17 May 2016 at 09:54:15 UTC, Marc Schütz wrote:
You surely mean "used to be destroy", right?
Good question... If I write this:
struct Test
{
~this() { writeln("destroying Test"); }
}
with (Test())
{
//Do stuff
}
Will Test's destructor be run once we exit the `with` scope?
Should.
Re: My ACCU 2016 keynote video available online
On 05/16/2016 05:45 PM, QAston wrote: On Monday, 16 May 2016 at 13:46:11 UTC, Andrei Alexandrescu wrote: Uses D for examples, showcases Design by Introspection, and rediscovers a fast partition routine. It was quite well received. https://www.youtube.com/watch?v=AxnotgLql0k Andrei Funny, useful, advertises the best parts of D very well. Thanks. And of course on reddit there's the Slaves Chorus of Nabucco chiming in right on cue how it could be done in C++. -- Andrei
Re: D's Auto Decoding and You
On 5/17/16 2:23 PM, Vladimir Panteleev wrote: On Tuesday, 17 May 2016 at 17:26:59 UTC, Steven Schveighoffer wrote: On 5/17/16 1:18 PM, Vladimir Panteleev wrote: On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: http://jackstouffer.com/blog/d_auto_decoding_and_you.html Thanks for writing this. Great article. Some remarks: static assert(is(typeof(s.front()) == dchar)); I believe .front is a property (so some ranges can implement it as a field, not a @property function). Hence, no parens. Right, but s is a string. So front is a function. Then what happened to writing generic code? This isn't generic code, it's just demonstrating that string's front does not yield immutable(char). It's very specific to string. In my recommendation to add the parens, I wasn't sure if front is marked @property or not. In any case, this is a lot of conversation about something that isn't that important :) -Steve
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 17:26:59 UTC, Steven Schveighoffer wrote: On 5/17/16 1:18 PM, Vladimir Panteleev wrote: On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: http://jackstouffer.com/blog/d_auto_decoding_and_you.html Thanks for writing this. Great article. Some remarks: static assert(is(typeof(s.front()) == dchar)); I believe .front is a property (so some ranges can implement it as a field, not a @property function). Hence, no parens. Right, but s is a string. So front is a function. Then what happened to writing generic code? There is an inconsistency in the compiler for this. If s.front is a function is(typeof(s.front)) will not be what front *returns*, but the function type itself. Unless you tag with @property. However, it's perfectly legal for a front function not to be tagged @property. There is a simple answer to this, and it is to either use ElementType or do what it does (is(typeof(R.init.front.init) T)).
Re: unit-threaded v0.6.13 - tags, autotags and support for integration tests
On Tuesday, 17 May 2016 at 14:22:51 UTC, Meta wrote:
On Tuesday, 17 May 2016 at 09:54:15 UTC, Marc Schütz wrote:
You surely mean "used to be destroy", right?
Good question... If I write this:
struct Test
{
~this() { writeln("destroying Test"); }
}
with (Test())
{
//Do stuff
}
Will Test's destructor be run once we exit the `with` scope?
Yes, it was fixed almost two years ago:
https://github.com/dlang/dmd/pull/3855
Re: D's Auto Decoding and You
On 17 May 2016 16:21, "Steven Schveighoffer via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On 5/17/16 10:06 AM, Jack Stouffer wrote: >> >> http://jackstouffer.com/blog/d_auto_decoding_and_you.html >> >> Based on the recent thread in General, I wrote this blog post that's >> designed to be part beginner tutorial, part objective record of the >> debate over it, and finally my opinions on the matter. >> >> When I first learned about auto-decoding, I was kinda miffed that there >> wasn't anything in the docs or on the website that went into more >> detail. So I wrote this in order to introduce people who are getting >> into D to the concept, it's benefits, and downsides. When people are >> confused in Learn why typeof(s.front) == dchar then this can just be >> linked to them. >> >> If you think there should be any more information included in the >> article, please let me know so I can add it. > > > Starting to read it, see errors in your examples: > > is(s[0] == immutable char) -> is(typeof(s[0]) == immutable(char)) > is(s.front == dchar) -> is(typeof(s.front()) == dchar) > > I'm not sure if you need the parens after front, but if it's not marked as @property, then this returns a function. > > -Steve If I remember correctly adding the brackets then goes against best practices because you can't be sure the underlying implementation of a range is using a function for .front.
Re: My ACCU 2016 keynote video available online
On Tuesday, 17 May 2016 at 08:42:42 UTC, Bill Hicks wrote: On Monday, 16 May 2016 at 13:46:11 UTC, Andrei Alexandrescu wrote: Uses D for examples, showcases Design by Introspection, and rediscovers a fast partition routine. It was quite well received. https://www.youtube.com/watch?v=AxnotgLql0k Andrei Incidentally, 2_000_000 D users have been waiting 10 years for one guy, you, to complete the containers/allocators and many other things. Man, this sh*t writes itself. And here you go again with your borderline racist jokes. Not very cool. If you honestly want to find out if it's "confusing to Africans", I suggest you go to a black neighborhood and ask them. If you want to be a troll please go to the Rust forums. They need you there to protect "underrepresented minorities". Piotrek
Re: D's Auto Decoding and You
On 5/17/16 1:18 PM, Vladimir Panteleev wrote: On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: http://jackstouffer.com/blog/d_auto_decoding_and_you.html Thanks for writing this. Great article. Some remarks: static assert(is(typeof(s.front()) == dchar)); I believe .front is a property (so some ranges can implement it as a field, not a @property function). Hence, no parens. Right, but s is a string. So front is a function. There is an inconsistency in the compiler for this. If s.front is a function is(typeof(s.front)) will not be what front *returns*, but the function type itself. Unless you tag with @property. However, it's perfectly legal for a front function not to be tagged @property. -Steve
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: http://jackstouffer.com/blog/d_auto_decoding_and_you.html Thanks for writing this. Great article. Some remarks: static assert(is(typeof(s.front()) == dchar)); I believe .front is a property (so some ranges can implement it as a field, not a @property function). Hence, no parens. So, why is typeof(s.front) == dchar. Question mark? In plain English, this means when iterating over strings in D, D will look ahead in the string and combine any code units that make up a single code point. Perhaps clarify that this only applies to ranges. `foreach` on a string will iterate over chars, but you can iterate over code points if you specify the dchar type explicitly. More confusing text on the same issue lower, and in the intro: Iterating a char array with C style for loops produces different results than foreach loops due to auto decoding. One feature of D that is confusing to a lot of new comers is the behavior of strings in relation to range based features like the foreach statement and range algorithms. --- E.g. for ë the code units C3 AB (for UTF-8) would turn into a single code point. Perhaps choose a character that is not also expressable via composite characters, to avoid potential for confusion. string s = "cassé"; Ditto (unless the goal was to complement the example from my .d file below) These glaring inconsistencies are the cause of a lot of confusion for new comers. (Opinion) I would say that they also cause issues in generic code. Every time one wants a generic algorithm to work with both strings and ranges, you wind up special casing via static if-ing narrow strings to defeat the auto decoding, or to decode the ranges. Case in point. Link to the exact SHA to prevent the link from getting outdated. On Github, just hit 'y' on your keyboard to go to the "permalink" version. Auto decoding has two choices when encountering invalid code units: throw, or produce an error dchar like std.utf.byUTF does. (Aside) This was an interesting discussion on the subject: https://issues.dlang.org/show_bug.cgi?id=14519 However, in my opinion D is too far along to to suddenly ask people "to to" --- Some more info / links on the subject I collected a few years ago: http://wiki.dlang.org/Language_issues#Unicode_and_ranges
Re: mago-mi: GDB/MI compatible frontend for Mago debugger
On Tuesday, 17 May 2016 at 13:04:23 UTC, Bruno Medeiros wrote: Interesting. I was about to ask what was the main advantage over GDB? I reckon it is that Mago can debug executables with the COFF and/or OMF formats, right? (as opposed to GDB's DWARF format) Mago currently has the best D language support on Windows. Can debug DMD generated executables. Do you know any GDB version + compiler version which works ok on Windows? Even w/o D demangling. At least able to create breakpoints, step, continue, examining threads, stack frames, local variables. In gdb+gdc combination I tried, gdb shows global variables instead of stack variables. Does DDT work ok with GDB on Windows? What compiler can be used to get GDB debugging working?
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: http://jackstouffer.com/blog/d_auto_decoding_and_you.html Based on the recent thread in General, I wrote this blog post that's designed to be part beginner tutorial, part objective record of the debate over it, and finally my opinions on the matter. I probably would have preferred this split up into two parts with one on the tutorial and one on the record of the debate. It seems to focus more on the debate. Maybe you could get add a section that was like "for THIS type of string, do X for performance" with clear explanations of why that is the best way and why other ways will be slower. Then, you can have other sub-sections for "for THAT type of string, do Y for performance." You have some of this detail in there, but it's organized more with respect to the context of the debate, I think.
Re: Berlin D Meetup May 2016
On Tuesday, 17 May 2016 at 11:28:10 UTC, Ben Palmer wrote: Hi All, Apologies for the late notice but the May Berlin D Meetup will be happening at 19:30 on Friday the 20th at Berlin Co-Op (http://co-up.de/) on the fifth floor. The basic idea is to have a hackathon on improving the First 5 Minutes as was discussed at the conference. This will be the first in a series of meetups/hackathons for working on this topic along with some future meetups planned for working with dub. Both alcoholic and non-alcoholic drinks will be available. Details are also on the meetup page here: http://www.meetup.com/Berlin-D-Programmers/ Thanks, Ben. Thanks for the info. I'll try to be there.
Re: unit-threaded v0.6.13 - tags, autotags and support for integration tests
On Tuesday, 17 May 2016 at 14:22:51 UTC, Meta wrote:
On Tuesday, 17 May 2016 at 09:54:15 UTC, Marc Schütz wrote:
You surely mean "used to be destroy", right?
Good question... If I write this:
struct Test
{
~this() { writeln("destroying Test"); }
}
with (Test())
{
//Do stuff
}
Will Test's destructor be run once we exit the `with` scope?
It did for me on the latest release.
Atila
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 14:44:06 UTC, Steven Schveighoffer wrote: ... Thanks, fixed all issues. Like the article, pretty much sums up my thoughts too. Thanks!
Re: D's Auto Decoding and You
Grammar: "This will tie in later because the string types front has special behavior" ...because for string types, front has... Content: "For C style strings, you can use ubyte[] and call std.string.assumeUTF where necessary" Actually, C style strings are ASCII, no? UTF8 includes ASCII. And D treats C strings as char *, not ubyte[] Content: D will look ahead in the string and combine things like e and U+0308 into ë Nope :) This is a grapheme, and D does not decode these into one dchar. Grammar: "about it's inclusion" it's -> its Typo: "Pared with the inability to turn it off," Pared -> Paired Typo: "Phobos String type would be the best option and a deprecation of the sting front function" sting -> string Like the article, pretty much sums up my thoughts too. IMO, the only path forward is something that aliases string to something that auto-decodes, but that is NOT a char array. Then you have to deprecate implicit access to the backing array, and make it explicit. Probably would take 2 years or so to migrate. -Steve
Re: 2DRPG - Small console game
On Thursday, 12 May 2016 at 18:30:04 UTC, Vladimirs Nordholm wrote: ... I have had lots of fun during the development of 2DRPG. There have been many difficulties, but I have learned much from making this game. Sadly this game is Windows only, meaning POSIX users cannot play it. This is due to technical limitations in my own console engine, scone (https://github.com/vladdeSV/scone), which cannot read input on POSIX terminals. Please make it work on posix ;)
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 14:16:48 UTC, Steven Schveighoffer wrote: Starting to read it, see errors in your examples: is(s[0] == immutable char) -> is(typeof(s[0]) == immutable(char)) is(s.front == dchar) -> is(typeof(s.front()) == dchar) Thanks, fixed.
Re: unit-threaded v0.6.13 - tags, autotags and support for integration tests
On Tuesday, 17 May 2016 at 09:54:15 UTC, Marc Schütz wrote:
You surely mean "used to be destroy", right?
Good question... If I write this:
struct Test
{
~this() { writeln("destroying Test"); }
}
with (Test())
{
//Do stuff
}
Will Test's destructor be run once we exit the `with` scope?
Re: D's Auto Decoding and You
On 5/17/16 10:06 AM, Jack Stouffer wrote: http://jackstouffer.com/blog/d_auto_decoding_and_you.html Based on the recent thread in General, I wrote this blog post that's designed to be part beginner tutorial, part objective record of the debate over it, and finally my opinions on the matter. When I first learned about auto-decoding, I was kinda miffed that there wasn't anything in the docs or on the website that went into more detail. So I wrote this in order to introduce people who are getting into D to the concept, it's benefits, and downsides. When people are confused in Learn why typeof(s.front) == dchar then this can just be linked to them. If you think there should be any more information included in the article, please let me know so I can add it. Starting to read it, see errors in your examples: is(s[0] == immutable char) -> is(typeof(s[0]) == immutable(char)) is(s.front == dchar) -> is(typeof(s.front()) == dchar) I'm not sure if you need the parens after front, but if it's not marked as @property, then this returns a function. -Steve
D's Auto Decoding and You
http://jackstouffer.com/blog/d_auto_decoding_and_you.html Based on the recent thread in General, I wrote this blog post that's designed to be part beginner tutorial, part objective record of the debate over it, and finally my opinions on the matter. When I first learned about auto-decoding, I was kinda miffed that there wasn't anything in the docs or on the website that went into more detail. So I wrote this in order to introduce people who are getting into D to the concept, it's benefits, and downsides. When people are confused in Learn why typeof(s.front) == dchar then this can just be linked to them. If you think there should be any more information included in the article, please let me know so I can add it.
DDT 1.0.0 released.
New DDT release out: dfmt support, performance improvements to semantic operations, more build command customization, fixes. Please see changelog for full list: https://github.com/DDT-IDE/DDT/releases/tag/v1.0.0 Since DDT has generally been quite stable, and since the current release is very close to the end-game vision I had for a D IDE - at least as far as my free time would allow to create - I've decided to version this as 1.0. I've been working for nearly 8 years on this project after all (with some intermission periods), so I guess 1.0 was a bit due... O.o' I expect it will mainly be small updates from now on, not any major new features (other than perhaps DCD support). -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: mago-mi: GDB/MI compatible frontend for Mago debugger
On 17/05/2016 09:06, Vadim Lopatin wrote: Hello, I'm working on GDB/MI compatible interface for Mago debugger on Windows. GDB/MI is line based machine interface for debugger. IDEs are using GDB via this interface. GDB/MI docs: https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html Project page (mago fork) https://github.com/buggins/mago Currently mago-mi supports subset of GDB commands enough for current DlangIDE functionality. Tested on DMD generated 32bit executables. See readme details list of implemented commands: https://github.com/buggins/mago/tree/master/MagoMI/mago-mi Difference from baseline https://github.com/rainers/mago files are minimal: - Static linking for MagoNatDE and MagoNatEE - Disabled some Mago debug logging Building mago-mi from source is easy. I've tried MS Visual Studio 2013 and 2015. Don't forget to edit properties in mago/PropSheets. Buld mago-mi project. Since DlangIDE v0.6.1, it includes prebuilt mago-mi.exe (it will be copied into bin directory by dub build) and default Debugger settings are changed from gdb to mago-mi by default on Windows. If you already used DlangIDE on your computer, check Edit/Preferences/Debugger setting - change to "mago-mi" if "gdb" is specified. If you want to try mago-mi and DlangIDE which is using it, you can download binaries from https://sourceforge.net/projects/crengine/files/DlangUI/dlangide-v061-magomi-v010-x86.zip/download (or just sync to latest dlangide and use `dub run`). Bundle includes DlangIDE, mago-mi, dub, and sample workspaces (helloworld and tetris). Download size is 5.4Mb (seems small enough for IDE+debugger). I hope my work will be useful for other IDE developers who is targeting on Windows. (Any IDE which uses gdb/mi interface) I tried gdb and lldb-mi before, but did not managed to find working compiler + debugger configuration. (Best combination was gdb + gdc, but it was showing global variables instead of locals. For lldb-mi, I haven't managed to find compiler which produces compatible debug info). Best regards, Vadim Interesting. I was about to ask what was the main advantage over GDB? I reckon it is that Mago can debug executables with the COFF and/or OMF formats, right? (as opposed to GDB's DWARF format) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: LDC 1.0.0-beta2 has been released!
On Tuesday, 17 May 2016 at 10:15:28 UTC, Vadim Lopatin wrote: On Tuesday, 17 May 2016 at 05:51:29 UTC, Kai Nacke wrote: Hi everyone, LDC 1.0.0-beta2, the LLVM-based D compiler, is available for download! This BETA release is based on the 2.070.2 frontend and standard library and supports LLVM 3.5-3.8. The 1.0 release will be a major milestone. Please help testing to make it the best release ever! We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf). :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/yryvlznqafivqznwz...@forum.dlang.org Regards, Kai Does it contain Android support patches? Most, but not all. Also, the Android support depends on a slightly patched llvm for emulated TLS, so you'd have to build that modified llvm yourself. However, llvm 3.8 finally came with its own emulated TLS support for ELF, so the plan is to move over to that and have Android support baked into these official ldc releases at some point.
Re: Battle-plan for CTFE
On Sunday, 15 May 2016 at 10:29:21 UTC, Martin Nowak wrote: On 05/10/2016 08:45 AM, Jacob Carlborg wrote: I was listening to a discussion Don and Daniel had about the current implementation of CTFE. They talked about using a byte code interpreter. Even implementing a really crappy byte code interpreter would be a huge improvement. No need for a byte-code interpreter, it mostly just adds overhead and complexity over an AST interpreter. If you want to go really fast you need some sort of JIT anyhow, but a proper interpreter will be orders of mangnitude faster than the current implementation. I might refer you to http://dconf.org/2013/talks/chevalier_boisvert.pdf page 59 ff. +1 . One need to walk the tree anyway to generate bytecode, which makes it impossible to make it faster for a one time execution. For frequent executions, then a JIT is preferable, which let the bytecode the favorite choice for more than one, but not too many executions.
Berlin D Meetup May 2016
Hi All, Apologies for the late notice but the May Berlin D Meetup will be happening at 19:30 on Friday the 20th at Berlin Co-Op (http://co-up.de/) on the fifth floor. The basic idea is to have a hackathon on improving the First 5 Minutes as was discussed at the conference. This will be the first in a series of meetups/hackathons for working on this topic along with some future meetups planned for working with dub. Both alcoholic and non-alcoholic drinks will be available. Details are also on the meetup page here: http://www.meetup.com/Berlin-D-Programmers/ Thanks, Ben.
Re: Battle-plan for CTFE
On Tuesday, 17 May 2016 at 10:42:30 UTC, Don Clugston wrote: TL;DR: CTFE is actually a backend, so don't be afraid of creating a glue layer for it. My point exactly. The AST is not something I want to handle while inside the interpreter. It introduces too much complexity. There needs to be some kind of further lowering.
Re: Battle-plan for CTFE
On Sunday, 15 May 2016 at 12:17:30 UTC, Daniel Murphy wrote: On 15/05/2016 9:57 PM, Martin Nowak wrote: On 05/15/2016 01:58 PM, Daniel Murphy wrote: The biggest advantage of bytecode is not the interpreter speed, it's that by lowering you can substitute VarExps etc with actual references to memory without modifying the AST. By working with something lower level than the AST, you should end up with something much less complex and with fewer special cases. Which is a bad assessment, you can stick variable indexes into VarDeclaration (we already do that) and thereby access them in O(1). Converting control flow and references into byte code is far from trivial, we're talking about another s2ir and e2ir here. -Martin For simple types that's true. For more complicated reference types... Variable indexes are not enough, you also need heap memory, but slices and pointers (and references) can refer to values either on the heap or the stack, and you can have a slice of a member static array of a class on the stack, etc. Then there are closures... Neither e2ir or s2ir are actually that complex. A lot of the mess there comes from the backend IR interface being rather difficult to work with. We can already save a big chunk of complexity by not having to translate the frontend types. E.g. implementing the logic in the interpreter to correctly unwind through destructors is unlikely to be simpler than lowering to an IR. Exactly. I think the whole idea of trying to avoid a glue layer is a mistake. CTFE is a backend. It really is. And it should be treated as one. A very simple one, of course. Once you do this, you'll find all sorts of commonalities with the existing glue layers. We should end up with at least 4 backends: DMD, GCD, LDC, and CTFE. Many people here are acting like this is something complicated, and making dangerous suggestions like using Phobos inside the compiler. (I think everyone who has fixed a compiler bug that was discovered in Phobos, will know what a nightmare that would be. The last thing compiler development needs is another level of complexity in the compiler). As I've tried to explain, the problems with CTFE historically were never with the CTFE engine itself. They were always with the interface between CTFE and the remainder of the compiler -- finding every case where CTFE can be called, finding all the bizarre cases (tuple variables, variables without a stack because they are local variables declared in comma expressions in global scope, local 'ref' variables, etc), finding all the cases where the syntax trees were invalid... There's no need for grandiose plans, as if there is some almost-insurmountable problem to be solved. THIS IS NOT DIFFICULT. With the interface cleaned up, it is the well-studied problem of creating an interpreter. Everyone knows how to do this, it's been done thousands of times. The complete test suite is there for you. Someone just needs to do it. I think I took the approach of using syntax trees about as far as it can go. It's possible, but it's really vile. Look at the code for doing assignments. Bleagh. The only thing in its favour is that originally it was the only implementation that was possible at all. Even the first, minimal step towards creating a ctfe backend -- introducing a syntax-tree-validation step -- simplified parts of the code immensely. You might imagine that it's easier to work with syntax trees than to start from scratch but I'm certain that's not true. I'm pretty sure that the simplest approach is to use the simplest possible machine-independent bytecode that you can come up with. I had got to the point of starting that, but I just couldn't face doing it in C++. TL;DR: CTFE is actually a backend, so don't be afraid of creating a glue layer for it.
Re: LDC 1.0.0-beta2 has been released!
On Tuesday, 17 May 2016 at 05:51:29 UTC, Kai Nacke wrote: Hi everyone, LDC 1.0.0-beta2, the LLVM-based D compiler, is available for download! This BETA release is based on the 2.070.2 frontend and standard library and supports LLVM 3.5-3.8. The 1.0 release will be a major milestone. Please help testing to make it the best release ever! We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf). :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/yryvlznqafivqznwz...@forum.dlang.org Regards, Kai Does it contain Android support patches?
Re: unit-threaded v0.6.13 - tags, autotags and support for integration tests
On Monday, 16 May 2016 at 14:39:22 UTC, Meta wrote:
On Monday, 16 May 2016 at 08:37:48 UTC, Atila Neves wrote:
with(immutable Sandbox()) {
writeFile("foo.txt", "foobarbaz\ntoto"); // can also pass
string[] for lines
shouldExist("foo.txt");
shouldNotExist("bar.txt");
shouldEqualLines("foo.txt", ["foobarbaz", "toto"]);
}
That's a really neat trick and an interesting use of `with`. I
remember that variables initialized in the argument list of
`with` used to not be destroyed after exiting the scope, I'm
guessing that's not the case anymore? I vaguely remember a PR
that fixed that.
You surely mean "used to be destroy", right? Yes, that's been
fixed.
Anyway, congratulations on the new release!
Re: My ACCU 2016 keynote video available online
On Tue, May 17, 2016 at 10:42 AM, Bill Hicks via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Monday, 16 May 2016 at 13:46:11 UTC, Andrei Alexandrescu wrote: > >> Uses D for examples, showcases Design by Introspection, and rediscovers a >> fast partition routine. It was quite well received. >> https://www.youtube.com/watch?v=AxnotgLql0k >> >> Andrei >> > > Incidentally, 2_000_000 D users have been waiting 10 years for one guy, > you, to complete the containers/allocators and many other things. > > Man, this sh*t writes itself. > > And here you go again with your borderline racist jokes. Not very cool. > If you honestly want to find out if it's "confusing to Africans", I suggest > you go to a black neighborhood and ask them. > > > As a South African, I can only say that you are talking nonsense regarding the horse/zebra joke. If you've been to Africa you will understand; there really are a lot more Zebra than horses. Although I must admit I think of horses or Monty Python when I hear hoofbeats. Andrei: Really good talk, thanks for sharing!
Re: The D language online tour - tour.dlang.org
On Monday, 16 May 2016 at 20:39:26 UTC, Jack Stouffer wrote: On Monday, 16 May 2016 at 18:02:29 UTC, Andrei Alexandrescu wrote: This is great work, thanks! Please announce in social media as well! -- Andrei Reddit: https://www.reddit.com/r/programming/comments/4jn6ks/the_online_d_language_tour/ Thanks!
Re: The D language online tour - tour.dlang.org
On Tuesday, 17 May 2016 at 08:52:57 UTC, Vadim Lopatin wrote: It would be great to have translations of this tour to other languages. Is it hard to add language selection? I could help with Russian translation... It shouldn't be hard, because the technical basis is there; it just needs to be made available to the user. But I would suggest waiting until to start an effort to translate the tour into other languages until the content has gone through some rounds of reviewing and the number of pulls/errors in the content is very low. Another more fundamental question: Is a translation really needed for the tour? I am not a native speaker but I still prefer reading technical stuff in English especially when English is the language of the original. It's hard for me to estimate the value of a translation.. Thanks & regards, André
Re: The D language online tour - tour.dlang.org
On Monday, 16 May 2016 at 17:32:06 UTC, André wrote: Hi, after another round of polishing, bug fixing, very useful user contributions and suggestions, I'd like to present the new home of the D language online tour: http://tour.dlang.org/ Thank you very much to the D foundation for hosting this service! If you would like to report errors or have suggestions, please use GitHub: https://github.com/stonemaster/dlang-tour Thanks & regards, André This is really great! It is a good step into making D friendlier for new users.
