Re: Recompiling D code
On 15/08/2014 3:09 a.m., Justin Whear wrote: On Thu, 14 Aug 2014 14:58:20 +, John Colvin wrote: My experience with these sort of things suggests that it'll be the linker taking the time. Dynamic libraries are the solution. Dub needs proper support for dynamic library dependencies. I'll second that suggestion. Can you run the timings using -c? Obviously you won't get binaries out the end, but it'd help diagnose the problem. Yes its definitely a lot faster. Around 600ms - 800ms. Even with other applications running.
Re: Recompiling D code
On 15/08/2014 2:58 a.m., Vladimir Panteleev wrote: On Thursday, 14 August 2014 at 12:56:10 UTC, Rikki Cattermole wrote: Dub automatically handles caching of dependencies such as vibe-d. So they are not rebuilt. The only things that get recompiled for example is a single code unit. This is defined as being the dependency between a route file and template files (simplified). How many D modules / object files is that? I haven't gone into that, I don't really want to go around modifying dub if I can help it. The necessary dependencies such as vibe-d then should be added as part of the build process. Incremental builds of things such as routes and templates are not a good idea. Same goes for data models. It could change the code unit output a little too much. Possibly even cause a corrupt binary from missing symbols ext. That approach sounds much more high-level than what I meant, and I don't see why you'd need to abstract things to that level. I'm not familiar with how dub builds things, but inter-module dependencies are a solved problem, thanks to DMD's -v and -deps switches. Incremental compilation was implemented in older (D1-era) build tools, such as xfbuild, however has never picked up due to DMD bugs with incrementally compiling more than one object file at a time (which might very well be fixed by now).
Re: Recompiling D code
On 15/08/2014 6:06 a.m., Jacob Carlborg wrote: On 2014-08-14 13:54, Rikki Cattermole wrote: Hello everyone. As you all may know I've been working on recompiling D for web services last few weeks. Its both good news and bad news. Good: Reloading definitely possible. With dependency handling using dub. Bad: Its slow. And not in my code sort of way. Has anyone thought of trying to JIT using LDC. Supposedly the llvm is slower for generation then dmd's backend. Atleast what was said during the SDC DCONF talk. But I'm all for this, could also use it to cache code that is generated ext. in memory. Less usage on the hdd can only be a good thing. I'll leave this to somebody who does know this area of things.
Re: Dutyl - a Vim plugin for running D tools
nice, thanks
Re: DMD v2.066.0-rc1
On 15 August 2014 05:14, Nick Sabalausky via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 8/7/2014 1:05 PM, Manu via Digitalmars-d-announce wrote: I've never encountered anybody try and use MSC from the command line in about 15 years professionally. I've tried to. When using Marmalade. Marmalade's mandatory build system is very closed-off and VS-integrated, so when I needed to include other stuff into my workflow (forget exactly why/what), I had to invoke from a script. And it worked *very* poorly. The fact that so few people use VS from the cmd line could partly be *because* it works so poorly: Ex 1: There's a lot of apple fans who have rationalized all sorts of limitations as good, or at least acceptable, long as the apple didn't support them. Then the moment apple would offer it, suddenly it'd be hailed as the greatest thing since sliced bread. Ex 2: Linux users rarely use GUI file managers. I love GUI file managers, but when I'm on Linux, I find even I do a lot more of my file management on the cmdline than I normally would. I do that *because* linux file managers tend to be pretty bad (esp the Nautilus-based ones IMO). So I'm not surprised other Linux users aren't really into GUI file managers either. We could be seeing a similar thing here. Something is shunned as bad *because* that particular world's version of it is very poorly done or otherwise unavailable. That's what I mean about this culture; it's the opposite of linux, and it outright rejects practises that are linux-like. While I don't doubt that's true of a lot of people in the industry, I have to question how much stubbornly clinging to ignorance can really count as a culture. I'm tempted to claim that isn't culture at all, it's just pandemic pigheaded ignorance. It is what it is... I'm just making an argument for the importance of the seamlessness of the download - hello world experience. There's a large number of developers who find this to be a sign of quality, and they will pre-judge accordingly. You won't win these people over by telling them the reality of their condition ;)
Re: DMD v2.066.0-rc2
On Friday, 8 August 2014 at 12:01:43 UTC, Andrew Edwards wrote: DMD v2.066.0-rc2 binaries are available for testing: http://wiki.dlang.org/Beta_Testing very good.The compile time is shorter than v2.065, Memory Used is smaller ,and the exe file'size is smaller . Frank
LDC 0.14.0 released!
Hi everyone, LDC 0.14.0, the LLVM-based D compiler, is available for download! This release is based on the 2.065.0 frontend and standard library and supports LLVM 3.1-3.4.2 (OS X: 3.2/3.4 only). As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/ynlnfdqwkweenkwct...@forum.dlang.org Regards, Kai
Re: Dutyl - a Vim plugin for running D tools
On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote: GitHub repo: https://github.com/idanarye/vim-dutyl vim.org page: http://www.vim.org/scripts/script.php?script_id=5003 The main problem with my Vim plugin for DCD(placed inside the DCD repo) is the need to set the import paths manually. It was a manual task that the user had to do: DCD doesn't know the import path the current project is using. Vim doesn't know either. Luckily - DUB knows. So instead of separate Vim plugins for different tools, each operating it's own tool alone, I wanted to create one plugin that'll operate both DUB and DCD - one that can get the list of import modules from DUB and send it to DCD. That's how Dutyl was born. Currently, Dutyl's only features are using DCD for autocompletion and for DDocs, but it has a module system that allows it to add other tools, either to get more functionality or to get backup for features that some tools can't support for specific projects. Like dependency injection but with a real usecase: for projects that don't use DUB, Dutyl can back up to a manually written list of import paths saved in a hidden file in the project's dir. I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them) Nice, I was planning on doing something just like this someday.
Re: DMD v2.066.0-rc2
I've found a regression in the release candidate: https://issues.dlang.org/show_bug.cgi?id=13299
Re: DMD v2.066.0-rc2
On Monday, 11 August 2014 at 23:44:26 UTC, deadalnix wrote: On Friday, 8 August 2014 at 12:01:43 UTC, Andrew Edwards wrote: DMD v2.066.0-rc2 binaries are available for testing: http://wiki.dlang.org/Beta_Testing Upped https://issues.dlang.org/show_bug.cgi?id=12754 to regression. It is causing code that used to link on mac to not link anymore (in my case SDC). For the N-th time, please include a reproducible test case! I had downgraded that bug earlier today because I couldn't find a DMD version in which OP's code worked.
Re: Recompiling D code
On Friday, 15 August 2014 at 06:54:28 UTC, Rikki Cattermole wrote: On 15/08/2014 2:58 a.m., Vladimir Panteleev wrote: How many D modules / object files is that? I haven't gone into that, I don't really want to go around modifying dub if I can help it. Well, to be blunt, I doubt you'll get satisfactory results unless you're ready to get down to the nitty-gritty.
Re: Recompiling D code
On 16/08/2014 11:29 a.m., Vladimir Panteleev wrote: On Friday, 15 August 2014 at 06:54:28 UTC, Rikki Cattermole wrote: On 15/08/2014 2:58 a.m., Vladimir Panteleev wrote: How many D modules / object files is that? I haven't gone into that, I don't really want to go around modifying dub if I can help it. Well, to be blunt, I doubt you'll get satisfactory results unless you're ready to get down to the nitty-gritty. Unfortunately I agree with you. But from what I've heard this isn't bad results considering native language and all. I may work towards using something like parrotVM or lua. Could be interesting for dev vs production. Don't see why I can't get that working rather well.
