Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On Thursday, 14 August 2014 at 00:54:07 UTC, Brian Schott wrote: On Thursday, 14 August 2014 at 00:43:38 UTC, Damian Day wrote: I'm not sure you'd want to do that. The DParser completion engine has a few features that DCD doesn't have. (I'm not sure if this is true the other way around) That's true, but duplicated work and all that.. It would be a nice way to battle test DCD and the lexer. Keep in mind that integrating a lexer/parser written in C# into an IDE written in C# is much easier than integrating libdparse would be. The same argument applies to Eclipse and Visual Studio. Invoking stuff is easy. I'd rather reimplement the communication to the dcd server instead to not get such a bottleneck if you're on windows or typing really fast. Executing an entire program for each keystroke is a real unsustainable solution, imho. I'm particularly interested in dscanner integration myself :) Are you talking about displaying static analysis hints in the editor window, or something else? Yes precisely. This should be easy. I have Textadept set up to do this and the implementation is only a few lines long. https://github.com/Hackerpilot/TextadeptModules/blob/master/modules/dmd/init.lua#L29-54 This seems rather easy to implement.
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On Thursday, 14 August 2014 at 07:07:59 UTC, Alex wrote: Invoking stuff is easy. I'd rather reimplement the communication to the dcd server instead to not get such a bottleneck if you're on windows or typing really fast. Executing an entire program for each keystroke is a real unsustainable solution, imho. https://github.com/Hackerpilot/DCD/blob/master/client.d#L72 Alright. :-)
Recompiling D code
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. You're welcome to atest my speeds that I have gotten so far (older well used hdd, Win7 x64), its around 2-3 seconds for a basic go download webpage and not much more. I've done a bit of working with it and with 2.066-rc2 got it to the lower end of 2s. Atleast from my experience with this, its dmd thats actually taking the time. I know my code isn't the best and optimized, so I have compared mine against dmd itself. 100-200ms difference normally. For those who don't know why I'm making a fuss over 2 seconds, its because you actually do notice this when doing web dev stuff. Without including start up time, this could become a lot larger. [0] https://github.com/rikkimax/livereload
Re: Recompiling D code
On Thursday, 14 August 2014 at 11:54:57 UTC, Rikki Cattermole wrote: Atleast from my experience with this, its dmd thats actually taking the time. I can't glean this from looking at the code, but are you recompiling the entire program? Web development is a perfect fit for incremental compilation, so when changing one web page's template or view code, you should need to compile only one .d file. ld and gold seem to support incremental linking, that could help speed things up as well.
Re: Recompiling D code
On 15/08/2014 12:47 a.m., Vladimir Panteleev wrote: On Thursday, 14 August 2014 at 11:54:57 UTC, Rikki Cattermole wrote: Atleast from my experience with this, its dmd thats actually taking the time. I can't glean this from looking at the code, but are you recompiling the entire program? Web development is a perfect fit for incremental compilation, so when changing one web page's template or view code, you should need to compile only one .d file. ld and gold seem to support incremental linking, that could help speed things up as well. 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). 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. But in this case none of this matters much. Pretty much I'm only testing against a single route module. No dependencies outside phobos and vibe-d.
Re: Recompiling D code
On Thursday, 14 August 2014 at 12:56:10 UTC, Rikki Cattermole wrote: On 15/08/2014 12:47 a.m., Vladimir Panteleev wrote: On Thursday, 14 August 2014 at 11:54:57 UTC, Rikki Cattermole wrote: Atleast from my experience with this, its dmd thats actually taking the time. I can't glean this from looking at the code, but are you recompiling the entire program? Web development is a perfect fit for incremental compilation, so when changing one web page's template or view code, you should need to compile only one .d file. ld and gold seem to support incremental linking, that could help speed things up as well. 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). 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. But in this case none of this matters much. Pretty much I'm only testing against a single route module. No dependencies outside phobos and vibe-d. 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.
Re: Recompiling D code
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.
Re: Recompiling D code
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. -- /Jacob Carlborg
Re: DMD v2.066.0-rc1
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.
Re: DMD v2.066.0-rc1
On Thursday, 14 August 2014 at 19:14:32 UTC, Nick Sabalausky wrote: On 8/7/2014 1:05 PM, Manu via Digitalmars-d-announce wrote: 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. Somehow, I doubt that anyone claims that you pull your punches or that you don't speek your mind... :) - Jonathan M Davis
Dutyl - a Vim plugin for running D tools
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)
