Re: Battle-plan for CTFE
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!
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: Release 2.071.2
On Monday, 19 September 2016 at 13:08:34 UTC, Martin Nowak wrote: On Monday, 19 September 2016 at 12:26:21 UTC, Jack Stouffer wrote: On a slightly related note, I think it would be a good idea to branch off 2.072 and start beta testing right away, as it's been five months since the last point release, and A LOT has changed since then. I fear that we may see a huge number of regressions for this beta cycle because they've just been compounding over this time. Yes, that was my intention as well. We'll discuss how to proceed in the next few days. On the good side those have mostly been phobos instead of language changes. https://github.com/dlang/dmd/compare/stable...master AFAIK the dmd work was mostly on C->D conversion and a few smaller fixes for @safe and @nogc. On the bad side phobos changes had the tendency to not care too much about compatibility in the past. As I've been on vacation the past 3-4 weeks, I still need to catch up and get a better overview. Thank you for the release! Please merge 2 ndslice PRs [1] for 2.072. They are required for Mir to exclude ndslice package except experimental ndslice.algotithm and future modules. It is very costly to maintain both Phobos and Mir versions. So I would like to exclude already accepted ndslice modules from Mir. 3 PRs are already merged by Andrei, he also reviewed #4780. #4781 is main preparation for Mir and it contains mapSlice, which was reviewed as ndMap in #4652. [1] https://github.com/dlang/phobos/milestone/9 Best regards, Ilya
Re: Release 2.071.2
On Monday, 19 September 2016 at 12:26:21 UTC, Jack Stouffer wrote: On a slightly related note, I think it would be a good idea to branch off 2.072 and start beta testing right away, as it's been five months since the last point release, and A LOT has changed since then. I fear that we may see a huge number of regressions for this beta cycle because they've just been compounding over this time. Yes, that was my intention as well. We'll discuss how to proceed in the next few days. On the good side those have mostly been phobos instead of language changes. https://github.com/dlang/dmd/compare/stable...master AFAIK the dmd work was mostly on C->D conversion and a few smaller fixes for @safe and @nogc. On the bad side phobos changes had the tendency to not care too much about compatibility in the past. As I've been on vacation the past 3-4 weeks, I still need to catch up and get a better overview.
Re: Release 2.071.2
On Monday, 19 September 2016 at 11:08:33 UTC, Martin Nowak wrote: Glad to announce D 2.071.2. http://dlang.org/download.html This point release fixes many issues with the new lookup and import rules. It should be used as a stopgap version when updating older code. The deprecations, the old access checks, and the -transition=import/checkimports switches are planned to be removed with 2.073.x. Those new rules should now be finalized and semantic changes, deprecations, as well as the -transition=import and -transition=checkimports switches should work as expected. Please file a bug if you have any problems. Also see the changelog for more details. http://dlang.org/changelog/2.071.2.html -Martin Thanks for releasing this. On a slightly related note, I think it would be a good idea to branch off 2.072 and start beta testing right away, as it's been five months since the last point release, and A LOT has changed since then. I fear that we may see a huge number of regressions for this beta cycle because they've just been compounding over this time.
Release 2.071.2
Glad to announce D 2.071.2. http://dlang.org/download.html This point release fixes many issues with the new lookup and import rules. It should be used as a stopgap version when updating older code. The deprecations, the old access checks, and the -transition=import/checkimports switches are planned to be removed with 2.073.x. Those new rules should now be finalized and semantic changes, deprecations, as well as the -transition=import and -transition=checkimports switches should work as expected. Please file a bug if you have any problems. Also see the changelog for more details. http://dlang.org/changelog/2.071.2.html -Martin
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: LDC: Speed up incremental builds with object file caching
On Sunday, 18 September 2016 at 09:10:41 UTC, Johan Engelen wrote: I think LDC has the same problems (template instances are emitted in the first module not the one that needed the instantiation?). Knowing this, you may be able to set up a case where things break, but I think it would have to involve recompilation with a different set of sources than the first compile. E.g. `ldc2 -c a.d b.d c.d` first, then `ldc2 -c b.d c.d`, and then trying to link. Which probably doesn't work well without caching either... We should deprecate non-singleobj compiles. Yes, it's difficult to make that work correctly when the object cache is outside of the compiler. Maybe archives would provide a good way to build a better incremental rebuild support into the compiler. At least with dmd's multiobj archives, template instances become their own object file. It's definitely worth to put some more thought into how we can leverage parallel builds and incremental rebuilds. https://trello.com/c/dBfiJHEM/72-spec-better-parallel-incremental-build-strategies-for-bigger-projects
