Re: DConf '23 Talk Videos
On Wednesday, 20 September 2023 at 00:35:47 UTC, Mike Parker wrote: On Sunday, 17 September 2023 at 15:35:59 UTC, FeepingCreature wrote: Thank you for your work! You're welcome! Unfortunately, last night my GPU started to consistently overheat and shut down when doing anything graphics intensive, including rendering video. I've done everything I can reasonably do locally, so today I'm going to see if my goto computer dude can make room for me. Either he'll fix it or I'll buy a new card from him. How soon I'm able to render again depends on how soon I can see him. I don't want to just go out and buy a new gpu unless I absolutely have to. My feeling is this could be a faulty power supply. You should try a new PSU first. How old is the hardware?
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 01:39:14 UTC, Walter Bright wrote: On 4/25/2023 1:15 PM, ryuukk_ wrote: Or perhaps, listen to this person: https://github.com/dlang/dmd/pull/14650 That only does a subset of the proposal. The inference only works in specific cases. Things like function overloading are not addressed. While it is true that it only implements a subset of the proposal. It does implemnent function overloading for non-templated functions the specific code for this is here: https://github.com/dlang/dmd/pull/14650/files#diff-fdd319cc59bac2d5ef6bc04f806fd564a3549e1cce44c7d01b4ec9e40792e3daR7172-R7190
Re: Beta 2.094.0
On Sunday, 13 September 2020 at 17:51:49 UTC, Steven Schveighoffer wrote: On 9/13/20 1:25 PM, MrSmith wrote: On Sunday, 13 September 2020 at 15:12:00 UTC, Steven Schveighoffer wrote: The first part of the change seems disruptive. If you just fix the second part (that you can now retrieve all members of std), doesn't it fix the problem? Main problem is that allMembers returns strings and you can't tell if member is an import from it. If it returned aliases then you could do is(m == module), etc. It's always been string, and should always be. We should have the ability to get compiler tuple with the actual symbols. allMembers within type functions works that way as well, within a type functions you don't get strings but references to the actual things. We should do this with a separate __trait though. Perhaps __traits(getMembers) ?
Re: Symmetry Investments and the D Language Foundation are Hiring
On Tuesday, 1 September 2020 at 13:30:33 UTC, Stefan Koch wrote: On Tuesday, 1 September 2020 at 13:28:07 UTC, Steven Schveighoffer wrote: On 9/1/20 5:38 AM, Stefan Koch wrote: On Tuesday, 1 September 2020 at 09:09:36 UTC, Jacob Carlborg wrote: BTW, is timestamps vs SHA-1 hashing really the most pressing issue with Dub? We think that not recompiling certain modules which have not changed will improve our build times. And the task proposed is actually something that can go in without too much struggle. Whereas deeper issues in dub likely take much longer. I have to agree with Jacob -- what common situation is changing the timestamps of your files but not the data? -Steve git update. on CI. at least I think that was the problem. I have not looked into this personally.
Re: Symmetry Investments and the D Language Foundation are Hiring
On Tuesday, 1 September 2020 at 13:28:07 UTC, Steven Schveighoffer wrote: On 9/1/20 5:38 AM, Stefan Koch wrote: On Tuesday, 1 September 2020 at 09:09:36 UTC, Jacob Carlborg wrote: BTW, is timestamps vs SHA-1 hashing really the most pressing issue with Dub? We think that not recompiling certain modules which have not changed will improve our build times. And the task proposed is actually something that can go in without too much struggle. Whereas deeper issues in dub likely take much longer. I have to agree with Jacob -- what common situation is changing the timestamps of your files but not the data? -Steve git update. on CI.
Re: Symmetry Investments and the D Language Foundation are Hiring
On Tuesday, 1 September 2020 at 09:09:36 UTC, Jacob Carlborg wrote: On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote: Looking for a full-time or part-time gig? Not only is Symmetry Investments hiring D programmers, they are also generously funding two positions for ecosystem work under the D Language Foundation. And they've put up a bounty for a new DUB feature. Read all about it here: https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/ As an alternative to use SHA-1 hashing. There's the option to have a daemon running the background listing on filesystem events. BTW, is timestamps vs SHA-1 hashing really the most pressing issue with Dub? -- /Jacob Carlborg We think that not recompiling certain modules which have not changed will improve our build times. And the task proposed is actually something that can go in without too much struggle. Whereas deeper issues in dub likely take much longer.
Re: Where are the DConf Online Submissions?
On Saturday, 29 August 2020 at 10:30:50 UTC, Mike Parker wrote: In my experience with DConf and SAOC, a number of submissions/applications come in on the last day, but I usually receive a some before then. So far, I haven't seen a single submission for DConf Online. If need be, I will extend the deadline by a week. I've been hoping to have enough submissions for at least six videos per day, including the keynotes from Walter and Atila. Anything less than that isn't going to be much of a conference. So if you guys want to see DConf Online happen, then you need to send me some video submissions! https://dconf.org/2020/online/index.html You don't need to do the whole talk on the video submission right?
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Monday, 15 June 2020 at 20:54:27 UTC, 12345swordy wrote: On Monday, 15 June 2020 at 20:51:38 UTC, Stefan Koch wrote: On Monday, 15 June 2020 at 20:47:16 UTC, 12345swordy wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy [...] Wouldn't a top type be a better way to achieve this? -Alex the Talias in type functions is a top type. (If I do understand correctly that it is something it's another word for an Any type.) it's a pain in the ass, to work with if you are not dynamically typed language. Speaking of type functions, have you been working on a dip for that? I am quite curious to see what it looks like currently. -Alex Oh no, I haven't. And I am not really a visionary. I am trying to solve a few concrete problems. To language addition is a means to an end, for a DIP which is is supposed to consider the language at large, I would need help. Furthermore, I have to see how the implementation plays out. It would be unwise to spec something that I couldn't implement.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Monday, 15 June 2020 at 20:47:16 UTC, 12345swordy wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy [...] Wouldn't a top type be a better way to achieve this? -Alex the Talias in type functions is a top type. (If I do understand correctly that it is something it's another word for an Any type.) it's a pain in the ass, to work with if you are not dynamically typed language.
Re: This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!
On Thursday, 4 June 2020 at 12:46:51 UTC, Andrei Alexandrescu wrote: PLDI (Programming Language Design and Implementation) is a top academic conference. This year PLDI will be held online and registration is free. This is an amazing treat. https://conf.researchr.org/home/pldi-2020 Workshops and tutorials (also free) are of potential interest. These caught my eye: https://pldi20.sigplan.org/home/SOAP-2020 (on the 15th) https://conf.researchr.org/track/ismm-2020/ismm-2020 (on the 16th) Very cool!
Re: DIP1028 - Rationale for accepting as is
On Wednesday, 27 May 2020 at 10:06:41 UTC, rikki cattermole wrote: On 27/05/2020 10:03 PM, Walter Bright wrote: Frankly, I feel that if I could sit down with you folks, I can get the idea across what I'm trying to accomplish. Okay, how is your camera and mic situation? Lets do a Twitch stream, make sure there are some moderators in place as well. Open to everybody and it can be recorded by Twitch. Youtube streams work better in my experience.
Re: DIP1028 - Rationale for accepting as is
On Sunday, 24 May 2020 at 09:47:37 UTC, Walter Bright wrote: On 5/24/2020 2:29 AM, Panke wrote: I've always understood that the @safe,@trusted,@system machinery provides the following guarantee once all holes are fixed: If I have a memory corruption in my code than I need to only look at the @trusted and @system parts to find it. Marking whatevs @safe violates this, marking it @trusted does not. It's a fair point, but without the source code the distinction is meaningless. The distinction is that you can find a slapped on trusted with a grep. Rather than valgrind.
Re: dmdcache
On Saturday, 25 April 2020 at 10:17:50 UTC, Ali Çehreli wrote: A colleague of mine has written dmdcache which may be very useful for some projects: https://github.com/seeraven/dmdcache It drops our build time from 8 minutes to 45 seconds on a particular build environment for about half a dozen D programs, one of which ends up being a 2G executable! WAT! :) And the total cache size is 5.5G. Wow! This build is with dmd 2.084.1 and that one particular application uses tons of template instantiations most of which are in generated source code. If I remember correctly, 2.084.1 does not contain template symbol name improvements and that may be the reason for the large size. Enjoy! Ali The main problem with this is that it does not take string imports into account, (or does it ???, I don't see how it could ) Also the compilers output can depend on the timestamp at which the compilation was done.
Re: describe-d: an introspection library
On Wednesday, 22 April 2020 at 17:27:48 UTC, Jean-Louis Leroy wrote: On Wednesday, 22 April 2020 at 17:16:28 UTC, Stefan Koch wrote: I am working on a much more powerful and efficient meta programming system. Great! Is it going to be in a library, or part of the compiler? Can we get a preview somewhere? It's going to be part of the compiler. You can look at the ... expression DIP. which Manu posted in General, for taste of where my stuff is going. Basically I will give CTFE the ability to modify type-lists directly.
Re: describe-d: an introspection library
On Wednesday, 22 April 2020 at 13:32:03 UTC, Jean-Louis Leroy wrote: I tried compiling my example with `dmd -vcg-ast -c tmt.d` and I did got neither an AST nor an error, and the option is not in `dmd -h`, where can I read about it? -vcg-ast is a debugging tool I original built to fix an bug in the inliner. when you through the switch a new file of the form "soucefilename.d.cg" should get written out for every sourcefile in the same directory that the source file is in. As for your other point. I am working on a much more powerful and efficient meta programming system. It's no where near done. So I will not commit to any release date ... I've learned my lesson.
Re: describe-d: an introspection library
On Tuesday, 21 April 2020 at 14:43:04 UTC, Jean-Louis Leroy wrote: I wonder if templates are lazily expanded. I haven't looked at the compiler's code, my guess is: maybe not. If the template gets used it gets instantiated (and cached). if not than not. you can use the -vcg-ast switch to look at how your souce code looks "expandend". If these techniques get traction, it will incite compiler developers to improve template instantiation, hopefully. They already gained traction, unfortunately. Making this system fast is not easy. And will need a few language changes, and some work from users (programmers) as well.
Re: Our HOPL IV submission has been accepted!
On Monday, 2 March 2020 at 21:39:01 UTC, Murilo wrote: On Saturday, 29 February 2020 at 01:00:40 UTC, Andrei Alexandrescu wrote: [...] Hi Mr. Andrei, I've searched the official website of HOPL but I didn't find the cost of the ticket to attend it. Do you know if there is a cost at all or if it's open to everyone? It's not free. They'll announce the official price in 2 months should be around 600$. Everyone who can afford it can attend.
Re: Going on holiday for the next 3 weeks...
On Wednesday, 4 September 2019 at 15:18:15 UTC, Atila Neves wrote: ... So not going to be available until I'm back. Have fun and relax! Happy holidays!
Re: Munich D Meetup July 2019
On Sunday, 7 July 2019 at 19:45:28 UTC, Stefan wrote: Join us in July for our next event. Last event before the summer break. We will have a look at the GSoC projects, recent DIPs and after that play around with the D Jupyter Notebook Kernel. https://www.meetup.com/de-DE/Munich-D-Programmers/events/262900460/ You are all warmly invited. We will meet at a new location. Also if anyone of you plans a visit in Munich, give us a call, drop us a line, then we can meet and/or introduce you into the local D community. Great I'll be coming!
Re: Darser: A LL(1) to Recursive Decent Parser/AST/Visitor Generator
On Wednesday, 20 March 2019 at 17:22:07 UTC, Robert Schadek wrote: https://code.dlang.org/packages/darser https://github.com/burner/Darser Have you had a look at fancypars? if not you might want to look at the lexer_generation of it. And the way it represents the grammar.
Re: DLP - D Language Processing 0.1.0
On Monday, 18 March 2019 at 18:52:10 UTC, Jacob Carlborg wrote: Currently it has only one command, "leaf-functions", that will print all leaf functions. A leaf function is a function that doesn't call any other functions or doesn't have a body. Functions without bodies cannot be considered leaf functions as there are declarations which may call.
Re: How is your DConf proposal looking?
On Friday, 8 March 2019 at 18:53:27 UTC, Ali Çehreli wrote: On 03/08/2019 02:18 AM, Bastiaan Veelo wrote: On Thursday, 7 March 2019 at 16:57:11 UTC, Ali Çehreli wrote: Reminder... :) http://dconf.org/2019/index.html Ali It's shaping up :-) Bastiaan. Great! :) I've decided to submit a proposal myself this year because I did use D at work recently. There must be some interesting things to talk about in there. Actually, I know that's the case because when I mention my D work to colleagues, I feel like I can talk for hours. I'm pretty sure it's the same with others; so, please submit something. Ali I'll submit mine in a few hours. It's going to be about a hot topic :)
Re: dlang tutorial just posted on Derek Banas's YouTube channel
On Wednesday, 6 March 2019 at 01:44:45 UTC, Zaydek wrote: tl;dr Derek Banas is a YouTuber that makes long-form programming tutorials. He has almost one million subscribers. He just posted a 90-minute tutorial that covers D beginning to end. This could be great promotional for this community to share with people learning D! [...] It's a good thing that D is becoming more public (I hope.) However there were a few mistakes in the explanation of mixins.
Re: progress-dmd: compilation with a progress bar
On Friday, 22 February 2019 at 08:36:24 UTC, FeepingCreature wrote: https://gist.github.com/FeepingCreature/6c67479c99bc0f20544d1e455622ae82 Usage: DMD= progress-dmd The script sets -v and then uses the code and semantic stages logged in the output to paint a cute little ANSI-colored progress bar, with one character for every file listed on the command line. Problems: - lots of time spent in function compilation cannot be cleanly attributed to a source module - sometimes with very long progress bars, regular compiler output can leave pieces of progress bar behind - colored progress bar painting is surprisingly hard Nice idea awesome stuff! Cheers, Stefan
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Friday, 18 January 2019 at 20:32:35 UTC, Jacob Carlborg wrote: On 2019-01-18 20:28, Stefan Koch wrote: The only difference that type-functions have from what you describe is that it does not need to occupy a keyword 'type'. You're using "alias" instead of my "type" keyword? yes. After all what type-functions do when returning types, is to return an alias. Since it's unable to create types this is all it can do.
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Friday, 18 January 2019 at 10:23:11 UTC, Jacob Carlborg wrote:
On 2019-01-17 23:44, H. S. Teoh wrote:
YES! This is the way it should be. Type-tuples become first
class
citizens, and you can pass them around to functions and return
them from
functions
No no no, not only type-tuples, you want types to be first
class citizens. This makes it possible to store a type in a
variable, pass it to and return from functions. Instead of a
type-tuple, you want a regular array of types. Then it would be
possible to use the algorithms in std.algorithm to manipulate
the arrays. I really hate that today one needs to resort to
things like staticMap and staticIndexOf.
Of course, if we both get tuples and types as first class
citizens it would be possible to store types in these tuples as
well. But a tuple is usually immutable and I'm not sure if it
would be possible to use std.algorithm on that.
It would be awesome to be able to do things like this:
type foo = int;
type bar(type t)
{
return t;
}
auto u = [byte, short, int, long].map!(t => t.unsigned).array;
assert(u == [ubyte, ushort, uint, ulong];
Yes, you will be able to do exactly what you describe above.
type-tuples are strictly a superset of types; which also include
true compile-time constants. (e.g. things you can use to
instantiate a template with.)
Within type functions you are able to create `alias[]` which is
in some ways equivalent to type-tuple (and will be converted to
one upon being returned outside of compile-functions),which you
can append to if you own it and type functions can also take
other type-functions as parameters.
Therefore it's perfectly possible to implement staticMap in terms
of type functions.
I already did the semantic sanity checks, and it shows promise.
The only difference that type-functions have from what you
describe is that it does not need to occupy a keyword 'type'.
Cheers,
Stefan
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Thursday, 17 January 2019 at 22:44:08 UTC, H. S. Teoh wrote:
On Thu, Jan 17, 2019 at 10:20:24PM +, Stefan Koch via
Digitalmars-d-announce wrote:
P.S. There is one caveat: because of how type-functions work
they cannot, you cannot create a non-anonymous symbol inside a
type-function, because there is no way to infer a mangle.
You can however create an anonymous symbol and alias it inside
a template body, which gives it a mangle and it can behave
like a regular symbol.
Interesting. Is it possible to assign a "fake" mangle to type
functions that never actually gets emitted into the object
code, but just enough to make various internal compiler stuff
that needs to know the mangle work properly?
No this is not possible, a symbol which is only used at
compile-time is actually really rare. Actually If the symbol is
constrained to a compile-time only context (e.g. inside is() or
taking the .sizeof) this problem does not arise, and it could be
allowed.
Imagine you want to return a struct type which has all the
fields of a given base struct but adds a member.
module ct_helper;
alias f(alias baseT, alias newMemberType, string newMember_name)
{
struct Extended
{
baseT base;
mixin("newMemberType " ~ newMemberName);
}
return typeof(Extended.init);
}
--
module user
struct S1 { int x; }
alias S2 = f!(S1, float, "y") // looks like a
template-instantiation but it's not!, I am just reusing it, to
not confuse the parser to much.
which mangle should this get?
S2 ? - doesn't work there is no mangle for an alias.
ct_helper.f.Extended? doesn't work if we call the type-function
again with diffrent arguments
make it an anonymous type ? - If we do that than this means that
the type-function is no longer pure as two anonymous types can
never Equal each other
include the arguments to the type-function and it's parameters in
the mangle? - that's possible but type-functions are not meant to
leave any sign of their existence in order to not introduce ABI
issues.
In short for now I'd rather side-step the problem by not allowing
freshly minted types to escape into a runtime context without
going through a template wrapper (which also handles caching and
has proper behavior in is-expressions).
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Thursday, 17 January 2019 at 19:31:24 UTC, H. S. Teoh wrote: On Thu, Jan 17, 2019 at 06:03:07PM +, Paul Backus via Digitalmars-d-announce wrote: [...] [2] https://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/ [...] Coming back to the D example at the end, I totally agree with the sentiment that D templates, in spite of their significant improvements over C++ syntax, ultimately still follow the same recursive model. Yes, you can use CTFE to achieve the same thing at runtime, but it's not the same thing, and CTFE cannot manipulate template argument lists (aka AliasSeq aka whatever it is you call them). This lack of symmetry percolates down the entire template system, leading to the necessity of the hack that Bartosz refers to. Had template argument lists / AliasSeq been symmetric w.r.t. runtime list manipulation, we would've been able to write a foreach loop that manipulates the AliasSeq in the most readable way without needing to resort to hacks or recursive templates. For 2 years I have pondered this problem, and I did come up with a solution. It's actually not that hard to have CTFE interact with type-tuples. You can pass them as function parameters, or return them if you wish. Of course a type-tuple returning ctfe function, is compile-time only. This solved one more problem that ctfe has: helper functions required for ctfe can only be omitted from the binary, if you use the trick of putting them into a module which is the import path but never explicitly given on the command line. newCTFE has the facility to be extended for this, and implementing type-functions is at least on my personal roadmap. At Dconf 2018 Andrei and Walter said, a DIP which is substantiated enough might make it. However due to lack of time, (and productivity-reducing internal changes) it will take some time until I can get started on this. Also I plan for newCTFE to be in shape before I add type-manipulation abilities. Cheers, Stefan P.S. There is one caveat: because of how type-functions work they cannot, you cannot create a non-anonymous symbol inside a type-function, because there is no way to infer a mangle. You can however create an anonymous symbol and alias it inside a template body, which gives it a mangle and it can behave like a regular symbol.
Re: The New Fundraising Campaign
On Wednesday, 2 January 2019 at 15:17:36 UTC, Martin Tschierschke wrote: On Wednesday, 2 January 2019 at 11:11:31 UTC, Stefan Koch wrote: On Wednesday, 2 January 2019 at 10:16:11 UTC, Martin Tschierschke wrote: I would love to have a campaign to increase compilation speed for std.regex and std.format... You could defer the generation of utf-tables to runtime, which should yield some improvement. But I'll measure the reasons for slowness again and post em. What do you mean by "you" :-) is it related to this? New LDC feature: dynamic compilation https://forum.dlang.org/thread/bskpxhrqyfkvaqzoo...@forum.dlang.org No you'd have to change the Moduls. You means someone tackling the compilespeed issues oft std.Format/std.uni.
Re: The New Fundraising Campaign
On Wednesday, 2 January 2019 at 10:16:11 UTC, Martin Tschierschke wrote: I would love to have a campaign to increase compilation speed for std.regex and std.format... You could defer the generation of utf-tables to runtime, which should yield some improvement. But I'll measure the reasons for slowness again and post em.
Re: now it's possible! printing floating point numbers at compile-time
Hi Ketmar, thanks for sharing your work! On Friday, 28 December 2018 at 19:03:02 UTC, ketmar wrote: Stefan Koch wrote: [ ... ] [1] https://github.com/UplinkCoder/fpconv/blob/master/src/fpconv_ctfe.d of course, it is not all that fancy, but i ported STB converter quite a long time ago, and it is ctfe-able too. ;-) [0] https://repo.or.cz/iv.d.git/blob_plain/HEAD:/ctfefloat.d I've benchmarked it[0] against fpconv_ctfe[1] and yours is almost as fast! However it has a a little more error when converting floats than grisu2 has. Meaning generally the output cannot round-trip. Warm greetings, Stefan
Re: now it's possible! printing floating point numbers at compile-time
On Saturday, 22 December 2018 at 21:06:48 UTC, Basile B. wrote: On Saturday, 22 December 2018 at 20:24:46 UTC, Stefan Koch wrote: On Saturday, 22 December 2018 at 20:08:12 UTC, Stefan Koch wrote: Thus enabling you to convert doubles into strings at compiletime. Cool, CTFE formating is something that occasionaly comes in the forum. Now i remember there's also RYU [1] that could have worked too [1] https://github.com/ulfjack/ryu Thanks for pointing it out, ryu however looks less fast for ctfe purposes.
Re: now it's possible! printing floating point numbers at compile-time
On Saturday, 22 December 2018 at 20:08:12 UTC, Stefan Koch wrote: Thus enabling you to convert doubles into strings at compiletime. Aww I am dumb ... should have waited 2 days :) Anyhow I hope that this is helpful to some of you. Please note that grisu 2 will give you representation which will convert into the same(!) floatingpoint number you passed in >92% of all possible inputs. Meaning you can round trip from string to double without loss of bits, for very many number but not all of them, that said the accuracy in general should be better than what a usual sprintf would give you. Cheers and Merry Christmas, Stefan
now it's possible! printing floating point numbers at compile-time
Hi Guys, during my research on floating point numbers I came across a short and efficient implementation[0] of the grisu2 algorithm for converting floating point numbers into strings. Which I then ported into CTFEable D code. Thus enabling you to convert doubles into strings at compiletime. Cheers Stefan Koch P.S. You can find it at my fork of fpconv[1]. [0] https://github.com/night-shift/fpconv [1] https://github.com/UplinkCoder/fpconv/blob/master/src/fpconv_ctfe.d
Re: Fuzzed - a program to find DMDFE parser crash
On Monday, 17 December 2018 at 10:12:44 UTC, Stefan Koch wrote: On Sunday, 16 December 2018 at 14:24:54 UTC, Jacob Carlborg wrote: On 2018-12-15 16:37, Basile B. wrote: This poisoning kills the interest of using a fuzzer. 99% of the crashes will be in hdrgen. Does that matter as long as the bug is found? Well it's hard to tell if it's begin. meant to say benign.
Re: Fuzzed - a program to find DMDFE parser crash
On Sunday, 16 December 2018 at 14:24:54 UTC, Jacob Carlborg wrote: On 2018-12-15 16:37, Basile B. wrote: This poisoning kills the interest of using a fuzzer. 99% of the crashes will be in hdrgen. Does that matter as long as the bug is found? Well it's hard to tell if it's begin. Generally in a compiler which is focused on speed, you accept crashing an really bogus input if it makes the parser run faster, because there is no chance of accepting corrupted code, which is what you need to be worried about.
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 21 November 2018 at 13:05:27 UTC, Nicholas Wilson wrote: On Wednesday, 21 November 2018 at 11:58:25 UTC, Vladimir Panteleev wrote: Have we tried disabling -unittest for modules that aren't on the compiler's command line yet (or, in case of -i, not excluded)? Not that I know of, thats a great idea! Maybe this hack could be developed further into a more generic "compiler server" idea. Wasn't that Robert's Masters thesis (Dconf 2013(?) presentation)? ;) The main problem with this, is the amount of context a compilers needs. And the current design of DMD does not lend itself splitting out the context. If you wanted you could consider the semantic pass of the compiler as a database, which answers queries such as: - which size does this type have. - which arguments does this function have - can the type A be casted to type B - which conversion function should be invoked for (B)A ? - is this function known to be pure? The data-base containing this information needs to be maintained on the compile-nodes, and that possibly leads to many data-dependencies. Which may degrade the performance of the "compiler server" to the point where it is quicker to do it locally. I am currently working (albeit very slowly due to lack of time and focus) to enable programmers to circumvent slow parts in compiler. When completed this should make a compiler-server unnecessary for some time to come.
Re: Pre-DConf Meetup on May 1
On Wednesday, 25 April 2018 at 14:13:55 UTC, Seb wrote: Hi all, I hope you are all looking forward to DConf. [...] I request a lighting talk slot :)
Re: Seeking lecturer - D language (Moscow)
On Wednesday, 14 March 2018 at 11:44:10 UTC, Simen Kjærås wrote: On Wednesday, 14 March 2018 at 11:38:20 UTC, Dmitry Olshansky wrote: - I owe you a bottle of your favorite beverage and your favorite bug in Bugzilla if you agree ;) https://issues.dlang.org/show_bug.cgi?id=5710 might be worth it, even if it means moving from friends and a comfy job in Norway... -- Simen Oh that one. Actually that'd isn't too hard. If you can live with a potential performance penalty of less well optimizing backends. I am currently with research for faster meta-programming facilities. But I could probably spare a few hours to get a 5710 fix ready. But I need a convincing usage example.
Re: I'm the new package maintainer for D on ArchLinux
On Wednesday, 9 August 2017 at 20:42:48 UTC, Wild wrote: I hope I can maintain ArchLinux as a great environment to use D. You are not only the new package mainainer but also my new Hero :)
Re: Munich D Meetup July 2017
On Monday, 3 July 2017 at 18:23:27 UTC, Dragos Carp wrote: Hi all, On 18 July, we will have our next Munich meetup. Mario will give a talk with the title "Avoiding the Big Ball of Mud". As usual before and after the talk we will also have good conversations with pizza and drinks. Please RSVP on: https://www.meetup.com/de-DE/Munich-D-Programmers/events/241264180/ Thanks, Dragos Is it going to be worth 11 hours by train ? If so I am there tomarrow.
Re: Work on ARM backend for DMD started
On Monday, 3 July 2017 at 23:16:07 UTC, solidstate1991 wrote: While I currently don't have an ARM based hardware that would be easy to develop on, I'm planning to use QEMU to emulate some form of ARMv6 CPU, as it'll be the main target, as it's still being used in devices like the Raspberry Pi. ARMv5 is being considered if it doesn't need a lot of work, although I don't see a lot of reason behind doing it besides of the possibility of enabling the development of homebrew GBA, NDS, GP32, etc stuff. As I became unemployed recently, I have a lot more time for development, so time now isn't an issue. Or at least until I find a job, which is hard due to my state as a college student, which I'm on the verge of losing it. I would accept your input on various things, like if I should do some adjustments to the in-line assembly stuff, whether I should care about thumb (reduced size instruction set, not available on some newer targets) or not, etc. Got my hands on some official reference manual, it wouldn't hurt if I could research other ones too. Far be it from be to discourage such efforts. But you should be aware that writing a backend for dmd from scratch is not an easy task. It will take time alot of time. Even if you have previous experience with codegen. And it is unlikely to yield satisfactory results. Most arm implementation are not as forgiving as contemporary x86 processors when it comes to bad register scheduling and the like. What exactly is your motivation for doing this ?
Re: Berlin D Meetup June 2017
On Tuesday, 13 June 2017 at 13:51:02 UTC, Ben Palmer wrote: Hi All, The Berlin June D meetup is happening on this Friday the 16th at 19:30 at Berlin Co-Op (http://co-up.de/) on the fifth floor. Mathias Lang will be giving a short talk on metaprogramming tricks in D. In particular on a "Self generating visitor pattern and a safe and correct tagged union in less than 100 LoC". As always we will have both alcoholic and non-alcoholic drinks available and time for discussions after the talk. The meetup page is: https://www.meetup.com/Berlin-D-Programmers/events/240756635/ Thanks, Ben. 19.30 ... I am not going to make it.
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 16:50:15 UTC, H. S. Teoh wrote: Yes, please add ctfeWriteln(). ctfeWriteln has it's own set of problems. I resurrected a PR for it a while back. And somewhere along the lines it broke again. newCTFE's debugging facilities which will come later this year, will provide a much better alternative. (though the debugging facilities will only be available using the slow bytecode backend)
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 15:16:56 UTC, Steven Schveighoffer wrote: On 6/9/17 10:49 AM, Stefan Koch wrote: If I'd had to worry about an interface to runtime code I'd be a little unhappy. I kind of remember you saying at dconf2016 "If only CTFE could write to the filesystem, I could fully support sqlite at compile time!" or something like that. It's amazing how modest your feature requests become once you have to implement them yourself ;))
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer wrote: [it] can use the *actual* i/o routines [at compile-time] you would use at runtime is pretty impressive. Stefan would have a field day with this power :) -Steve Infact I think this would scale pretty badly. I do not want to debug some ctfe which loads dlls and does god what to the environment. Even the restricted form of ctfe D supports is pretty hard to get right. If I'd had to worry about an interface to runtime code I'd be a little unhappy.
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 01:34:14 UTC, Mike Parker wrote: On Thursday, 8 June 2017 at 19:07:50 UTC, cym13 wrote: Seeing that the one and only D example in the nim article is a broken one (using static instead of enum or static immutable for 'b') we should have started with a correct example before showing the broken one... Good to know for next time. static variables are initialized with compile-time values. They don't need be immutable for that. they need immutable if you want to use them again at compile-time. Therefore it is a good habit to get into.
Re: Compile-Time Sort in D
On Wednesday, 7 June 2017 at 21:47:58 UTC, John Carter wrote: On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html We should make another post showing the string import feature.
Re: Bultins .reverse and .sort are likely going to be removed soon.
On Sunday, 28 May 2017 at 09:23:01 UTC, Ivan Kazmenko wrote: On Wednesday, 24 May 2017 at 22:56:15 UTC, Stefan Koch wrote: I just finished the PR to remove the builtin array properties .sort and .reverse. That's nice! Finally, we could get rid of the awkward reverse() or sort!() in UFCS chains while all the rest don't need the parentheses. while the dmd changes were trivial fixing all the broken tests were not. Even tests that were supposed to call std.algorithm.sort turned out to use the property by accident; (because of a small error which caused the sort template not to instantiate). So, the process exposed latent bugs in the tests, which is another indication that the change is a Good Thing. I wonder how the deprecation message didn't make it happen sooner though. Ivan Kazmenko. If the test is supposed to succseed we don't check the deprecation messages.
Bultins .reverse and .sort are likely going to be removed soon.
Hi guys, I just finished the PR to remove the builtin array properties .sort and .reverse. while the dmd changes were trivial fixing all the broken tests were not. Even tests that were supposed to call std.algorithm.sort turned out to use the property by accident; (because of a small error which caused the sort template not to instantiate). If you do have code which still relays on this, please update. Cheers, Stefan
Re: Generating checked integral operations [WAS: Trip notes from Israel]
On Tuesday, 23 May 2017 at 15:43:24 UTC, Andrei Alexandrescu
wrote:
On 05/23/2017 11:37 AM, Stefan Koch wrote:
The compiler does indeed seem to optimize the code somewhat.
Although the generated asm still looks wired.
http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3
That call enters a different overload:
pragma(inline, true)
uint mulu(uint x, uint y, ref bool overflow)
{
ulong r = ulong(x) * ulong(y);
if (r > uint.max)
overflow = true;
return cast(uint)r;
}
which is of efficiency comparable with code using seto. I'm not
too worried about that. https://goo.gl/eRXUpr is of interest.
Andrei
Well
Since core.checkedint is in druntime, we _could_ detected the
checking operations and generate better code for them.
But right now, I am convinced it is worth the effort.
Re: Trip notes from Israel
On Tuesday, 23 May 2017 at 15:37:39 UTC, Stefan Koch wrote: The compiler does indeed seem to optimize the code somewhat. Although the generated asm still looks wired. http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3 The jbe (jump-below-equal) does check the overflow flag (and redundantly the zero-flag) here and sets the bool which represents overflow to one.
Re: Trip notes from Israel
On Tuesday, 23 May 2017 at 15:19:39 UTC, Andrei Alexandrescu
wrote:
On 05/23/2017 09:42 AM, Stefan Koch wrote:
On Tuesday, 23 May 2017 at 13:27:42 UTC, Andrei Alexandrescu
wrote:
On 5/22/17 4:51 PM, Johan Engelen wrote:
[...]
Thanks! Yes, seto is what I thought of - one way or another,
it gets down to using a bit of machine-specific code to get
there. I'll note that dmd does not generate seto (why?):
https://goo.gl/nRjNMy. -- Andrei
it does this
overflow_flag = 0
op
if (overflowed)
{
overflow_flag = 1;
}
Where did you see this pattern? Couldn't find it anywhere in
core.checkedint. And how is "overflowed" tested?
this can in some circumstances be faster then using seto!
If the inliner does a good enough job :)
The code in core.checkedint is conservative:
pragma(inline, true)
ulong mulu(ulong x, ulong y, ref bool overflow)
{
ulong r = x * y;
if (x && (r / x) != y)
overflow = true;
return r;
}
The compiler is supposed to detect the pattern and generate
optimal code.
Andrei
That code is written nowhere.
It was my hand translation of the asm.
(And it was wrong)
The compiler does indeed seem to optimize the code somewhat.
Although the generated asm still looks wired.
http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3
Re: Trip notes from Israel
On Tuesday, 23 May 2017 at 13:27:42 UTC, Andrei Alexandrescu
wrote:
On 5/22/17 4:51 PM, Johan Engelen wrote:
On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu
wrote:
[...]
A fun read!
"(Late at night, I double checked. Mozilla’s CheckedInt is
just as bad as I remembered. They do a division to test for
multiplication overflow. Come on, put a line of assembler in
there! Portability is worth a price, just not any price.)"
Shocked: do you use assembly in Checked and cripple the
optimizer?!?!
Luckily, no. But LDC and GDC do create the `seto` instruction
I think you were hinting at:
https://godbolt.org/g/0jUhgs
(LDC doesn't do as good as it could,
https://github.com/ldc-developers/ldc/issues/2131)
Thanks! Yes, seto is what I thought of - one way or another, it
gets down to using a bit of machine-specific code to get there.
I'll note that dmd does not generate seto (why?):
https://goo.gl/nRjNMy. -- Andrei
it does this
overflow_flag = 0
op
if (overflowed)
{
overflow_flag = 1;
}
this can in some circumstances be faster then using seto!
If the inliner does a good enough job :)
Re: llvm-d 2.2 Dynamic loading (yet again)
On Wednesday, 17 May 2017 at 14:55:12 UTC, Moritz Maxeiner wrote: In response to a DConf 2017 request regarding this, llvm-d again supports dynamic loading. The API is essentially the same as is was for llvm 1.x, though you have to enable it with D versions. [...] Many Thanks.
Re: The New CTFE Engine on the Blog
On Wednesday, 12 April 2017 at 05:51:20 UTC, Ali Çehreli wrote:
On 04/10/2017 06:07 AM, Mike Parker wrote:
Stefan has been diligently keeping us all updated on NewCTFE
here in the
forums. Now, he's gone to the blog to say something to tell
the world
about it.
The blog:
https://dlang.org/blog/2017/04/10/the-new-ctfe-engine/
Reddit:
https://www.reddit.com/r/programming/comments/64jfes/an_introduction_to_ds_new_engine_for_compiletime/
The first code sample is
private immutable ubyte[128] uri_flags = // indexed by character
({
// ...
})();
and the text says "The ({ starts a function-literal, the })
closes it.". Why the extra parentheses? Just the curly brackets
works, no?
private immutable ubyte[128] uri_flags = // indexed by character
{
// ...
}();
Ali
Yes it would work.
But I like to distinguish function-literals from blocks :)
Re: excel-d v0.0.1 - D API to write functions callable from Excel
On Monday, 20 March 2017 at 20:09:58 UTC, Atila Neves wrote: http://code.dlang.org/packages/excel-d This dub package allows D code to be called from Excel. It uses compile-time reflection to register the user's code in an XLL (a DLL loaded by Excel) so no boilerplate is necessary. Not even `DllMain`! It works like this: [...] Ah Interesting to see how this turned out.
Re: Need help
On Wednesday, 15 March 2017 at 07:37:53 UTC, Jack Applegame wrote: Dear developers. I need help fixing issue #17257 (https://issues.dlang.org/show_bug.cgi?id=17257) and related bug (https://forum.dlang.org/post/zpxzbctiijfhjujsz...@forum.dlang.org). I can't fix it myself, because know almost nothing about the internals of the compiler. But I'm willing to pay for this work. PayPal, Bountysource, donation, all that you want. I am going to take a look at this issue, later today.
Re: Release D 2.073.2
On Thursday, 9 March 2017 at 21:32:20 UTC, Martin Nowak wrote: Glad to announce D 2.073.2. http://dlang.org/download.html This point release fixes a few issues over 2.073.1, see the changelog for more details. http://dlang.org/changelog/2.073.2.html -Martin It says: D LATEST.
Re: Moonshot: a DMD fork that outputs Lua
On Tuesday, 21 February 2017 at 12:45:47 UTC, Mithun Hunsur wrote: Hi all, Introducing Moonshot (https://github.com/Philpax/moonshot)! Hi Mithun, Looking over the code for lua it seems that you use std.format a lot a ctfe. I would advise against that as it needlessly increases compile times. The built-in concat operator is supposed to be faster in many cases. I am interested in how you handle complex types i.e. structs with pointers of the same struct type and the like. I think moonshot is a worthwhile effort. Congrats for getting something like this to work.
Re: Getters/setters generator
On Tuesday, 17 January 2017 at 06:26:35 UTC, Eugene Wissner wrote:
On Friday, 9 December 2016 at 18:53:55 UTC, Andrei Alexandrescu
wrote:
Love it, and was toying with similar ideas too. One good
extension is to add a predicate to the setter, which guards
the assignment. -- Andrei
What kind of predicate do you mean? Can you give an example
please?
setValue(uint _under24)
{
assert(_under24 < 24);
under24 = _under24;
}
Re: Reminder - DConf 2017 is May 4-6 !!
On Saturday, 7 January 2017 at 00:46:31 UTC, Walter Bright wrote: It's 2017 already - sharpen your pencils and start on a proposal for a presentation! Time is moving fast! Thanks for the remainder. I am still torn between talking about the past of building the new CTFE engine or the future my plan for O(N log N) templates!
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei I claim dips on templates. (as in the colloquial english for asserting rights/ownership ) I can't wait to improve that situation.
Re: Blog Post - profiling with perf and friends
On Sunday, 25 December 2016 at 19:16:03 UTC, Martin Nowak wrote: Just a few infos on using perf and related tools for profiling on linux. https://code.dawg.eu/profiling-with-perf-and-friends.html Nice article. There is a nice gui tool for the same purpose, http://developer.amd.com/tools-and-sdks/opencl-zone/codexl/ I find it easier to use then perf since it lists the useful statistics as a table. Also very useful is valgrind --tool=callgrind and the gui for it kcachegrind. http://kcachegrind.sourceforge.net/ I used it to optimize the newCTFE code with great success. Also I would recommend to compile the executable you are profiling with -g -gc, as you will be able to see which lines of code asm instructions correspond to.
Re: Milestone - DMD front end is now 100% D!
On Thursday, 15 December 2016 at 05:53:42 UTC, Ilya Yaroshenko wrote: Please, no :-( Mir needs betterC DMD FE What for ? Are you using the compiler frontend ? And the frontend is not only using the betterC subset. So you could not be using it right now.
Re: Getters/setters generator
On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote:
Hello,
we've just open sourced a small module ("accessors") that helps
to generate getters and setters automatically:
https://github.com/funkwerk/accessors
http://code.dlang.org/packages/accessors
It takes advantage of the UDAs and mixins. A simple example
would be:
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
mixin(GenerateFieldAccessors);
}
It would generate 2 methods "num": one to set num_ and one to
get its value. Of cause you can generate only @Read without
@Write and vice versa. There are some more features, you can
find the full documentation in the README.
"GenerateFieldAccessors" mixin should be added into each
class/struct that wants to use auto generated accessors.
Oh my this is going to be a compiletime hog if used excessively.
Due the use of fqn.
Re: Release D 2.072.1
On Wednesday, 30 November 2016 at 22:49:12 UTC, Martin Nowak wrote: Glad to announce D 2.072.1. http://dlang.org/download.html This point release fixes a few issues over 2.072.0, see the changelog for more details. http://dlang.org/changelog/2.072.1.html -Martin Congrats!
Re: SQLite-D goes beta!
I just updated ~master with a little tool that will print a dot-file with describing the internal Tree-structure of database. All you need to do is to import layout2dot. And call TreeLayoutToDot on your database. it will give you back a string which you can then give to graph-viz. If dot produces anything but a small-height big-width picture you should really vacuum your database.
Re: Got a post for the D Blog?
On Tuesday, 1 November 2016 at 06:23:29 UTC, Mike Parker wrote: On Monday, 31 October 2016 at 20:29:13 UTC, Jacob Carlborg wrote: Would it be interesting to have a blog post about implement support for Objective-C in D? That would be very technical and quite low level. Absolutely! I could write something about the CTFE engine. And how I plan to beat the llvm jit :)
Re: Battle-plan for CTFE
On Sunday, 30 October 2016 at 21:09:19 UTC, Stefan Koch wrote:
On Sunday, 30 October 2016 at 03:07:13 UTC, Stefan Koch wrote:
I just made progress on another fundamental feature,
function call support.
It's does not [fully] work yet, but it shows promise.
The following just compiled :
int fn(int a)
{
return a + fn2(2);
}
int fn2(int a)
{
return a + 2;
}
static assert(fn2(4) == 6);
static assert(fn(4) == 8);
static assert(fn(fn(2)) == 10);
Oh shoot!
I did not enable the new call system :(
This computed by the old interpreter.
The new engine fails :(
Re: Battle-plan for CTFE
On Sunday, 30 October 2016 at 03:07:13 UTC, Stefan Koch wrote:
I just made progress on another fundamental feature,
function call support.
It's does not [fully] work yet, but it shows promise.
The following just compiled :
int fn(int a)
{
return a + fn2(2);
}
int fn2(int a)
{
return a + 2;
}
static assert(fn2(4) == 6);
static assert(fn(4) == 8);
static assert(fn(fn(2)) == 10);
Re: Battle-plan for CTFE
On Friday, 28 October 2016 at 16:52:46 UTC, Stefan Koch wrote: Another update on CTFE. I have found a few errors in my handling of switch-statments. An efficient solution for this is still pending, Futhermore I have begun to work on ctfe handling refernces. These are a little bit harder to do in bytecode and do pessimise performance if overused. I hope to make another leap at the end of this month. We should have string Concat-support fairly soon. Cheers, stefan I just made progress on another fundamental feature, function call support. It's does not work yet, but it shows promise.
Re: Battle-plan for CTFE
Another update on CTFE. I have found a few errors in my handling of switch-statments. An efficient solution for this is still pending, Futhermore I have begun to work on ctfe handling refernces. These are a little bit harder to do in bytecode and do pessimise performance if overused. I hope to make another leap at the end of this month. We should have string Concat-support fairly soon. Cheers, stefan
Re: Battle-plan for CTFE
On Wednesday, 26 October 2016 at 08:19:46 UTC, Andrea Fontana
wrote:
On Wednesday, 26 October 2016 at 03:58:05 UTC, Stefam Koch
wrote:
On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg
wrote:
Very impressive :)
Thanks.
I just got the following code to compile and execute correctly.
bool strEq(string a, string b)
{
if (a.length != b.length)
{
return false;
}
uint length = cast(uint) a.length;
while(length--)
{
auto c1 = a[length];
auto c2 = b[length];
if (c1 != c2)
{
return false;
}
}
return true;
}
static assert(!strEq("Hello","World"));
static assert(strEq("World","World"));
I used the generated bytecode to make == for strings work.
Why did you cast size_t to uint in this example?
Currently I am limited to 32bit Arithmetic.
Changing this is on the Table but I have not gotten to it yet.
Re: Battle-plan for CTFE
On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote: On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote: If all goes well there will be a separate nightly release build from the newCTFE branch, sometime in October. I hope to get alpha bug reports that way. Have you benchmarked CTFE-heavy projects like Pegged? It is not yet able to handle pegged. And I suspect alot of slowness is caused by templates not by CTFE.
Re: Munich D Meetup
On Sunday, 25 September 2016 at 20:49:47 UTC, Stefan wrote: We would be very glad to meet other people from the forum at the Meetups. Already pitiful enough, that Andrei will have no time this year for a visit. Will keep you informed once we scheduled the next Meetup. I'll try to come next time :) And I am always ready to talk about some nasty compiler internals :)
Re: Battle-plan for CTFE
On Sunday, 25 September 2016 at 18:21:27 UTC, Rory McGuire wrote: :D congrats! I appreciate it. If all goes well there will be a separate nightly release build from the newCTFE branch, sometime in October. I hope to get alpha bug reports that way. Also I am now starting experimentation with actual JIT to make sure my API and ABI definitions are not bogus. (For the record an earlier design made slices impossible) Luckily I spotted this before I went to far with it. Unfortunately many basic features are still very brittle or completely dysfunctional. (Such as function calls or structs.) Again I apologize for the delay. My adventures in template-land, were quite time consuming. Although arguably with interesting results. If you have any questions regarding my work with the DMD, please ask away. Greetings, Stefan
Re: Battle-plan for CTFE
On Tuesday, 20 September 2016 at 05:06:57 UTC, Nordlöw wrote:
On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote:
Compiling all of phobos does not crash my engine anymore!
Great work! Keep up still!
I am proud to announce,
(and slightly embarssed because it took to long)
that the following code can now be executed using the new CTFE
engine :
string fn(bool b)
{
return b ? "true" : "false";
}
static assert(fn(true) == "true");
static assert(fn(false) == "false");
although this seems trivial it took me about 3 months to get to
this point.
I believe from here on the road will be less steep.
Re: SQLite-D goes beta!
On Tuesday, 20 September 2016 at 20:34:19 UTC, Karabuta wrote: Great work! Can't wait to see sample code :) It's in app.d also see test.d
Re: SQLite-D goes beta!
On Monday, 30 May 2016 at 18:07:09 UTC, Stefan Koch wrote: It is my pleasure to announce that I now consider SQLite-D to be in Beta stage. The reader is now stable enough to read all the test tables I have been given. The fact that it took around 20 minutes to complete index-tree support convinced mt that I have chosen a solid design. I have received the request to add examples and documentation to sqlite-d. And I will do so as time permits. This project will be boost licensed. So don't be shy :) https://github.com/UplinkCoder/sqlite-d It took a few months for me to get to the point, but now it is officially boost licensed.
Re: Battle-plan for CTFE
On Monday, 19 September 2016 at 18:05:34 UTC, Lurker wrote: Good news anyway! Do you have any preliminary results or goals and expectations that you are going to achieve with your rework? Is it mostly perf/memory improvements, are there any new features that this rework will unlock? Thanks for your hard work! I stated my expectations earlier I think there will be a 2-6x performance increase in the non-jited version and around 10-14x for the jit. My preliminary results do support that claim. As for new features I do not plan on doing language-changes as I do not have the ability to anticipate the outcome of doing so. My work will probably have side-effects on the rest of dmd, for example the AST is hard to work with in some cases. I would to add like some support for frontend-optimisations as well. I will also improve documentation in some areas and hope to lower the entry-barrier for dmd-development.
Re: Battle-plan for CTFE
On Thursday, 8 September 2016 at 18:54:52 UTC, Stefan Koch wrote: On Thursday, 8 September 2016 at 13:11:23 UTC, Stefan Koch wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :) I think I have taken care of the incorrect bytecode. It was not an issue with the engine itself but rather with the way I plugged it in. The new engine is not supposed being called if the old one has already started to interpret the function, because the two do not and should not share state. I found more incorrect code. this time it's located more deeply in the engine. I am investigating the cause. It seems to be related closures somehow. Compiling all of phobos does not crash my engine anymore! However running the unittests does show incorrect results :( This is concerning since I am mostly bailing out. I think this too seems to be related to closures produced in templates. Really nasty stuff.
Re: Berlin D Meetup September 2016
On Friday, 16 September 2016 at 20:35:18 UTC, default0 wrote: On Friday, 16 September 2016 at 20:32:46 UTC, Stefan Koch wrote: On Friday, 16 September 2016 at 20:20:23 UTC, default0 wrote: On Monday, 12 September 2016 at 17:26:25 UTC, Ben Palmer wrote: [...] Standing outside at entrance. Plane was late. There's a closed gate here where gmaps tells me this is. [...] Yes that is it. But it is probably over by now. Open Hackathon and shorter than 3h I'm surprised The meetups are usually not too long :) Where did you fly from ?
Re: Berlin D Meetup September 2016
On Friday, 16 September 2016 at 14:15:28 UTC, Steven Schveighoffer wrote: On 9/16/16 8:38 AM, Stefan Koch wrote: On Monday, 12 September 2016 at 17:26:25 UTC, Ben Palmer wrote: [...] Oh crap. I missed it :( You sure? It's still only Friday, well before 20:00 :) -Steve I am in the opposite corner of germany :)
Re: Berlin D Meetup September 2016
On Monday, 12 September 2016 at 17:26:25 UTC, Ben Palmer wrote: Hi All, The September Berlin D Meetup will be happening at 20:00 on Friday the 16th of September at Berlin Co-Op (http://co-up.de/) on the fifth floor. This month we will be having an open hackathon so feel free to bring along anything you are currently working on. Sociomantic have come to the party once more and will be sponsoring food (including vegetarian options) and drinks (both alcoholic and non-alcoholic). More details are available on the meetup page here: http://www.meetup.com/Berlin-D-Programmers/events/234060672/ Thanks, Ben. Oh crap. I missed it :(
Re: DlangUI 0.9.0: Console backend added
On Tuesday, 13 September 2016 at 07:51:06 UTC, Vadim Lopatin wrote: On Friday, 9 September 2016 at 11:21:07 UTC, Vadim Lopatin wrote: [...] Screenshot of DlangIDE working in console: http://i68.tinypic.com/2hrmkup.png Looks great! can you fix dlang-ui to build on XP ?
Re: Battle-plan for CTFE
On Thursday, 8 September 2016 at 13:11:23 UTC, Stefan Koch wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :) I think I have taken care of the incorrect bytecode. It was not an issue with the engine itself but rather with the way I plugged it in. The new engine is not supposed being called if the old one has already started to interpret the function, because the two do not and should not share state. I found more incorrect code. this time it's located more deeply in the engine. I am investigating the cause. It seems to be related closures somehow.
Re: Battle-plan for CTFE
On Thursday, 8 September 2016 at 14:48:25 UTC, Rory McGuire wrote: On Thu, Sep 8, 2016 at 3:11 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :) I think I have taken care of the incorrect bytecode. It was not an issue with the engine itself but rather with the way I plugged it in. The new engine is not supposed being called if the old one has already started to interpret the function, because the two do not and should not share state. !! Does this mean I can start testing new ctfe and only some of my CT will be faster? You can start yes. However it is very limited right now I would expect it to slow you down by a little bit.
Re: Battle-plan for CTFE
On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :) I think I have taken care of the incorrect bytecode. It was not an issue with the engine itself but rather with the way I plugged it in. The new engine is not supposed being called if the old one has already started to interpret the function, because the two do not and should not share state.
Re: Battle-plan for CTFE
compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :)
Re: Battle-plan for CTFE
FunctionCall support is done. (with a lot of room for improvement) you can already return strings. now I just have to finish string-comparison and string-concat support to make it usable. And of course the correct translation of logical-expressions...
Re: Battle-plan for CTFE
On Thursday, 1 September 2016 at 20:43:16 UTC, David Nadlinger wrote: See also: https://github.com/dlang/dmd/pull/692 – it's about time we finally got __ctfeWrite() merged. — David Oh yeah. Let me get this into PR shape.
Re: Battle-plan for CTFE
On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote: At the moment I just have a verbose logging mode with pragma(msg) for my CTFE stuff. I have something that will help with that a little bit. https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln when you apply this patch __ctfeWriteln() will output every compiletime avilable string to the console. It's a little bit nicer then using pragma(msg);
Re: Battle-plan for CTFE
On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote: the _checkCTFE() function is just a function that does something we're not allowed to do at CTFE, but current implementation does not respect __traits(compiles, ); As far as I can tell that is a bug. Thoughts? It is not a bug, because there is no way to mark something as CTFE-only. static ifs are not visible at the time where ctfe sees the function, they have already been resolved. getting a static if (__ctfe) to work would require significant changes to the semantic-analysis path for functions.
Re: Battle-plan for CTFE
On Tuesday, 30 August 2016 at 22:01:45 UTC, tsbockman wrote: On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote: I just came up with a nifty little patch that makes it possible to ensure that a function is _only_ used at ctfe. Or the opposite. static assert(__ctfe, "This function is not supposed to be called outside of ctfe"); and static assert(!__ctfe, "This function is not supposed to be called during ctfe"); similarly you can use static if (__ctfe). Is it worth trying to get it into master ? Yes, please. I've often wished I could use `__ctfe` in a `static if`. Sorry. It I overlooked a something rather important. static __ctfe is currently not possible and it's rather expensive to make it possible.
Re: Battle-plan for CTFE
On Tuesday, 30 August 2016 at 17:29:19 UTC, deadalnix wrote: worth trying to get it into master ? I would say maybe, but let's keep separate things separate. This is a language change. I would not include it in the same series of patch that change CTFE behavior. Yes. It would be confusing. And it is not done with the patch I mentioned.
Re: Battle-plan for CTFE
On Tuesday, 30 August 2016 at 08:18:47 UTC, Johannes Pfau wrote: There are some nice use cases for this: * Do not enforce @nogc for CTFE only functions, so you can mark a complete module nogc: and CTFE only functions will get ignored * Do not emit code for CTFE only functions. This is useful for bare metal programming: The CTFE only function can depend on druntime functions not available in the bare metal runtime. These are common problems when using string mixins: The functions to generate the mixed in code use string manipulation which is usually not @nogc and might require runtime functions. But the code generation function is exclusively used in CTFE. I do not see how this could affect @nogc. But yes you can circumvent the code-generation and pulling in the druntime dependency using a static if.
Re: Battle-plan for CTFE
On Monday, 29 August 2016 at 08:05:10 UTC, Rory McGuire wrote: On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via The work you are doing is just awesome! Many thanks. +1 your work is key for our success as a community. R Thanks guys. I just came up with a nifty little patch that makes it possible to ensure that a function is _only_ used at ctfe. Or the opposite. static assert(__ctfe, "This function is not supposed to be called outside of ctfe"); and static assert(!__ctfe, "This function is not supposed to be called during ctfe"); similarly you can use static if (__ctfe). Is it worth trying to get it into master ?
Re: Battle-plan for CTFE
Hi Guys, First of all, parsers will not make it before September. I am sorry about that. Currently I am fixing issues with the design, that for example prevent slices of slices to work. Also I am writing analysis and debugging code to (such as generating a call-graph and primitive DFA) that will hopefully make function-calls work reliably. The DMD-AST does not make it easy to track things like variables originating from a parent-scope. I feel that this can have a positive impact on the whole of dmd, since that will allow better frontend-optimisations. I am happy for all comments or suggestions. Cheers, Stefan
Re: Battle-plan for CTFE
On Wednesday, 17 August 2016 at 18:24:37 UTC, Rory McGuire wrote: On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: Just a small update today. if(__ctfe) and if(!__ctfe) now get special treatment. Also working on getting compiletime-parsers to run. Nice tease with the "compile time parsers to run" aside. We're salivating here. What exactly did you mean by that? Which compile time parser are you using for testing? PS: thanks for the updates! I am using ctfe-bf for a start and others of my own design. Of course pegged is also on the menu.
