Re: New (second) release candidate vibe.d 0.7.30-rc.2
On Friday, 14 October 2016 at 19:57:09 UTC, Sönke Ludwig wrote: https://github.com/rejectedsoftware/vibe.d/commit/ab1ac33c564ad8d593104e30cc93eb1779c88d4a Plus some regression fixes for issues that got introduced since the last alpha release (not mentioned in the change log). The release has been rescheduled for next Thursday. consider please https://github.com/rejectedsoftware/vibe.d/pull/1592
Re: code-d 0.12.0 - The user friendly release (code-d for noobs)
On Sunday, 9 October 2016 at 15:42:51 UTC, WebFreak001 wrote: On Sunday, 9 October 2016 at 15:41:17 UTC, Dmitry wrote: On Sunday, 9 October 2016 at 10:19:06 UTC, Wild wrote: After all Atom and Vscode are open source clones of Sublime. Sublime is fast, unlike Atom and VSCode. Yeah I noticed that too when I started making sublime-d yesterday. Like instant startup time and no lags So sublime plugin using workspace-d in progress: https://github.com/Pure-D/sublime-d Awesome. Sublime-D seems pretty good. I was surprised it came with the ability to build D-code built in. I don't see any kind of file/project browser though..will symbols still be recognized across files for autocomplete, etc..?
Re: code-d 0.12.0 - The user friendly release (code-d for noobs)
On Saturday, 15 October 2016 at 18:54:32 UTC, bitwise wrote: On Sunday, 9 October 2016 at 15:42:51 UTC, WebFreak001 wrote: On Sunday, 9 October 2016 at 15:41:17 UTC, Dmitry wrote: On Sunday, 9 October 2016 at 10:19:06 UTC, Wild wrote: After all Atom and Vscode are open source clones of Sublime. Sublime is fast, unlike Atom and VSCode. Yeah I noticed that too when I started making sublime-d yesterday. Like instant startup time and no lags So sublime plugin using workspace-d in progress: https://github.com/Pure-D/sublime-d Awesome. Sublime-D seems pretty good. I was surprised it came with the ability to build D-code built in. I don't see any kind of file/project browser though..will symbols still be recognized across files for autocomplete, etc..? uh I'm still working on the plugin. Building probably comes from sublime because sublime-d doesn't currently add anything except auto completion, goto definition and documentation when hovering over something. Searching for symbols will be implemented and outlining the current file might get implemented like in code-d with a list of all symbols on command.
Re: Battle-plan for CTFE
On Sunday, 16 October 2016 at 10:58:57 UTC, Dmitry Olshansky wrote: That LLVM thing is surely nice to have but I highly doubt it will be allowed as dependency for DMD. --- Dmitry Olshansky LLVM is purely optional. A pure D interpreter exists. LLVM optimises most ctfe btw and returns constants.
Re: Battle-plan for CTFE
On Wednesday, 5 October 2016 at 08:34:06 UTC, Rory McGuire wrote: No worries, I've been watching this space for over a decade. I really believe you are working on one of the most important parts of IT for the next decade. I am planning/making a library that uses CTFE extensively and feel much more confident about it purely because of your work on getting CTFE performance to be a non-issue. R Little update here: The LLVM backend is almost on feature parity. Meaning that that soon the new CTFE engine is a real jit. In the process I discoverd quite a few horrible bugs and inconsistency in the API. I am quite astonished that it ever ran before :)
Re: Battle-plan for CTFE
On 10/16/16 2:27 AM, Uplink_Coder wrote: On Wednesday, 5 October 2016 at 08:34:06 UTC, Rory McGuire wrote: No worries, I've been watching this space for over a decade. I really believe you are working on one of the most important parts of IT for the next decade. I am planning/making a library that uses CTFE extensively and feel much more confident about it purely because of your work on getting CTFE performance to be a non-issue. R Little update here: The LLVM backend is almost on feature parity. Meaning that that soon the new CTFE engine is a real jit. In the process I discoverd quite a few horrible bugs and inconsistency in the API. I am quite astonished that it ever ran before :) That LLVM thing is surely nice to have but I highly doubt it will be allowed as dependency for DMD. --- Dmitry Olshansky
Re: Battle-plan for CTFE
On Sunday, 16 October 2016 at 13:51:55 UTC, Uplink_Coder wrote: On Sunday, 16 October 2016 at 10:58:57 UTC, Dmitry Olshansky wrote: That LLVM thing is surely nice to have but I highly doubt it will be allowed as dependency for DMD. --- Dmitry Olshansky LLVM is purely optional. A pure D interpreter exists. LLVM optimises most ctfe btw and returns constants. If anyone want to take a look the lastest llvm_backend development is happening here : https://github.com/UplinkCoder/dmd/blob/_ctfe/src/bc_llvm_backend.d
Re: [GSoC] Precise GC
On Friday, 14 October 2016 at 03:26:31 UTC, FrankLike wrote: On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote: Hi everyone, I know I'm super late to the party for this, and sorry for that. While my work on the precise GC didn't go as planned, it is closer than it was to be getting merged. [...] On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote: Hi,how about the precise GC, now? I want to known too.
