Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote: Hi everyone (= I've just added a new proposal to add a new attribute to ensure TCO is applied. The proposal is really simple, but I'm clueless on how to implement it and also interested on getting feedback on it. The proposal it's ready for merge on the new [DIPs repo](https://github.com/dlang/DIPs/pull/6) -- Dietrich That's crap...I disassemble DMD output some time to time. It already does TCO. Definitively a lol day...
DIP: Tail call optimization
Hi everyone (= I've just added a new proposal to add a new attribute to ensure TCO is applied. The proposal is really simple, but I'm clueless on how to implement it and also interested on getting feedback on it. The proposal it's ready for merge on the new [DIPs repo](https://github.com/dlang/DIPs/pull/6) -- Dietrich
Re: Vision document for H2 2016
On Sat, 09 Jul 2016 19:17:31 +, Eugene wrote: > On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote: >> https://wiki.dlang.org/Vision/2016H2 -- Andrei > > is it possible to make a modular D language(and a compiler), so one just > could release new features of the language without releasing a new > version of a compiler(ldc, etc.), and these features would be just > extensions of the compilers? That would be kind of terrible by default. What ensures that two different modules are compatible? Nothing, by default. What happens if you try including two incompatible compiler modules in one project? Presumably an error. What if I try to depend on two libraries that have incompatible compiler modules? I can't. So it's a lot of work and would just fragment the language.
Re: Announcing new DIP handling process
On Saturday, 9 July 2016 at 21:21:54 UTC, Dicebot wrote: On 07/09/2016 09:11 PM, ZombineDev wrote: Can the new DIP process be used to evaluate library proposals? That way a high level design could be fleshed out and approved before the contributor goes too far with implementing a design which would be rejected. It is quite hard. To reasonably evaluate library proposal one has to have at least proof of concept implementation showing intended API. It isn't easy to fit into abstract DIP format. It depends on the domain and scope of the proposal. See for example the C++17 file system API: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0218r0.html#class-path. I think you'll agree that such a proposal can easily be evaluated solely on its interface, without any need to look at the implementation. In other domains, such as algorithms, metaprogramming and concurrency / parallelism a proof of concept is much more needed. I think the main question is: Is this design feasible? If there's any doubt, a proof of concept should be required. I can't advise much on this part because I have been trying to stay away from Phobos affairs for a long time and don't know existing status quo about it. The status quo is that all larger library additions should be approved by Walter or Andrei and new modules should go through the review process http://wiki.dlang.org/Review/Process. What I currently find missing in the review process is a way to get a consensus on the high-level design. If a larger design issue is brought up during the review process it may require a significant rewrite which is a waste of the contributor's time and can be very demotivating.
Re: Announcing new DIP handling process
On 07/09/2016 09:11 PM, ZombineDev wrote: > Can the new DIP process be used to evaluate library proposals? That way > a high level design could be fleshed out and approved before the > contributor goes too far with implementing a design which would be > rejected. It is quite hard. To reasonably evaluate library proposal one has to have at least proof of concept implementation showing intended API. It isn't easy to fit into abstract DIP format. I can't advise much on this part because I have been trying to stay away from Phobos affairs for a long time and don't know existing status quo about it.
Re: Battle-plan for CTFE
On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. [ ] I will post more details as soon as I dive deeper into the code. I decided to keep a gist updated to represent the current state the new engine can handle. https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e This is the currentState after approx. 50 hours of work
Re: Vision document for H2 2016
On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote: https://wiki.dlang.org/Vision/2016H2 -- Andrei is it possible to make a modular D language(and a compiler), so one just could release new features of the language without releasing a new version of a compiler(ldc, etc.), and these features would be just extensions of the compilers?
Re: Announcing new DIP handling process
On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote: After quite some preliminary discussions and preparations, new D Improvement Proposals handling process is finally happenning. Please read description and explanation here: https://github.com/dlang/DIPs ## Rationale There are two main goals for going this way: 1) Ensure communication between language authors and DIP authors, establish better sense of actually contributing as opposed to simply throwing ideas into the black box. 2) Improve overall quality of DIP documents to the point where language authors can reasonably review them without spending too much time on trivialities. Additional benefit I am hoping for is to have a centralized place to subscribe to learn about all coming major changes coming to language for those who can't keep up with NG regularly. ## Old DIPs Right now https://github.com/dlang/DIPs repository contains archive folder with already implemented proposals imported from wiki (please tell me if there are any other already implemented DIPs that were not marked as such in wiki). All authors of existing DIPs who want to keep pursuing the idea will have to re-submit them as a pull requests towards new repo. This is required so that we can filter abandoned proposals and focus on documents that have active authors backing them. ## DIP manager I will act as a DIP manager for the time being. Please note that role of DIP manager does not imply any decision power regarding DIP approval, it remains an exclusive domain of language authors. Can the new DIP process be used to evaluate library proposals? That way a high level design could be fleshed out and approved before the contributor goes too far with implementing a design which would be rejected.
Re: Vision document for H2 2016
On 2016-07-08 20:46:21 +, Walter Bright said: On 7/8/2016 6:51 AM, Robert M. Münch wrote: 1. Fixing (all) bugs before doing new things: If I look as a CTO, CIO or CEO on ... I have yet to find any engineering product in any field that doesn't have open issues. A more practical question is does the product deliver enough value to make up for its deficiencies. I totally agree. But often it takes quite some time & experience to understand how the open deficiencies impact my context. I have seen to many tools where you can reach 80% and than things get hard / impossible. IMO a good or bad products is decided on the last 20%... 3. How about a "D Master" online certificate? scrum.org is doing that. You have ... It's a great idea, do you want to work on it? I would love to but it's unrealistic within the next 6 months... sorry. I brought it up as an idea that can be put on the mid / long term roadmap, to shape the picture of D in the long run. I think these things are important for companies to see / know about before they will make a decision. It's a long, very long journey to establish a language in the "mainstream"... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Vision document for H2 2016
On 2016-07-08 18:07:39 +, Andrei Alexandrescu said: On 07/08/2016 09:51 AM, Robert M. Münch wrote: 1. Fixing (all) bugs before doing new things: If I look as a CTO, CIO or CEO on D I the first thing I ask is: "Are they doing a lot of new stuff? And if, is this thing / last releasae that bullet proof stable that there are not annoying open issued?" Any other answer then "yes" would get my "no" to use D. This needs to be balanced with the zeroth thing you ask, which is: "how does it help us with our work better than the competition?" We're not working on many new things, but we do work on things that impact that question. IMO D has a lot to put on the table, and that should work seemlessly. So, the elevator-pitch for D is possible. However, it's a personal taste what is "better than..." and if helps or not. My rule of thumb, after many years of experience is, that I'm very conservative when it comes to base technology stuff. Less is more, slow moving & high quality is better than fast & fancy. 2. Case-Studies: ... There are some. I'd love to see such. Are these listed somewhere? 3. How about a "D Master" online certificate? scrum.org is doing that. ... Will keep that in mind, although there's some stigma associated with this. Which? That these things are of low quality? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: NanoSVG port
just make sure to download the latest version by the given link before you want to try it. ;-) glad to see that you found it useful
Re: Announcing new DIP handling process
On 07/09/2016 09:11 AM, Seb wrote: On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote: After quite some preliminary discussions and preparations, new D Improvement Proposals handling process is finally happenning. Please read description and explanation here: [...] Sweet! A bit of noise: https://www.reddit.com/r/programming/comments/4s08h4/the_d_language_has_a_new_dip_d_improvement/ https://news.ycombinator.com/item?id=12061181 Thanks! Don't forget hackerne.ws looks at referrer and automatically bans posts that come from an explicit link (like the one above). What you need to do is post and then let people know what time the post was. Then they can see the post by going to the "new" section and look for posts around that time. -- Andrei
Re: Announcing new DIP handling process
On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote: After quite some preliminary discussions and preparations, new D Improvement Proposals handling process is finally happenning. Please read description and explanation here: [...] Sweet! A bit of noise: https://www.reddit.com/r/programming/comments/4s08h4/the_d_language_has_a_new_dip_d_improvement/ https://news.ycombinator.com/item?id=12061181
Re: NanoSVG port
On Saturday, 9 July 2016 at 11:06:34 UTC, ketmar wrote: i also made NanoSVG[1] port[2]: simple SVG parser and rasterizer. it is using `malloc()` to allocate memory, but otherwise was rewritten to use `const(char)[]` input for svg, and do not use `sscanf()` from libc. the port lives in NanoVG package, but it is actually completely independent. [1] https://github.com/memononen/nanosvg [2] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/nanovg/svg.d I will definitely try it (but not very soon). Thank you!
Announcing new DIP handling process
After quite some preliminary discussions and preparations, new D Improvement Proposals handling process is finally happenning. Please read description and explanation here: https://github.com/dlang/DIPs ## Rationale There are two main goals for going this way: 1) Ensure communication between language authors and DIP authors, establish better sense of actually contributing as opposed to simply throwing ideas into the black box. 2) Improve overall quality of DIP documents to the point where language authors can reasonably review them without spending too much time on trivialities. Additional benefit I am hoping for is to have a centralized place to subscribe to learn about all coming major changes coming to language for those who can't keep up with NG regularly. ## Old DIPs Right now https://github.com/dlang/DIPs repository contains archive folder with already implemented proposals imported from wiki (please tell me if there are any other already implemented DIPs that were not marked as such in wiki). All authors of existing DIPs who want to keep pursuing the idea will have to re-submit them as a pull requests towards new repo. This is required so that we can filter abandoned proposals and focus on documents that have active authors backing them. ## DIP manager I will act as a DIP manager for the time being. Please note that role of DIP manager does not imply any decision power regarding DIP approval, it remains an exclusive domain of language authors.
NanoSVG port
i also made NanoSVG[1] port[2]: simple SVG parser and rasterizer. it is using `malloc()` to allocate memory, but otherwise was rewritten to use `const(char)[]` input for svg, and do not use `sscanf()` from libc. the port lives in NanoVG package, but it is actually completely independent. [1] https://github.com/memononen/nanosvg [2] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/nanovg/svg.d
Re: Battle-plan for CTFE
p.s. it is, btw, completely possible to add at least something like "ctfe tracer" (something like old basic "trace on" command), or even some kind of gdb-like debugger to ctfe engine. it won't, of course, find it's way into mainline, but may still be a fun project to do.
Re: Battle-plan for CTFE
On Friday, 8 July 2016 at 23:31:38 UTC, Stefan Koch wrote: and mine is segfaulting in some bizarre ways (i failed my basic ++ and -- math, and so the stack ;-). still, it is almost working, with support for both compiled and interpreted function calls, almost full range of integer math and some string ops. druntime still compiles and passes unittests, but phobos segfaulted somewhere deep in my CTFE engine. i really need to re-check all added opcodes and codegen. writing that was surprisingly easy. and sometimes simply surprisingly: "how did you came to me with this, DMD?! eh? aha, i see now, thank you, grep." ;-) some stats: virtual machine is <30KB of code now. compiler is ~70KB, but there is alot of copypasta in there (you know, it happens when the code grows organically). if someone is interested in interop between frontend and backend, writing engine like this is a nice way to make yourself familiar, as CTFE interpreter effectively gets already semanticed AST, with most things correctly lowered and so on. so you only have to copy dummy CtfeCompiler from dinterpret.d (it only count vars there, otherwise doing nothing), and start extending it. even when we'll get new shiny engine from Stefan, i still recommend to anyone who wish to understand how compiled and processed code looks inside the frontend at least try to implement some simple bytecode compiler. with some care seeing that you are effectively replacing compiler parts, and it is still able to compile complex unittests is... yeah, go find the word. ;-)
