Re: Digger 1.0
Am Mon, 22 Sep 2014 18:59:12 + schrieb Vladimir Panteleev vladi...@thecybershadow.net: On Monday, 22 September 2014 at 17:28:50 UTC, ketmar via Digitalmars-d-announce wrote: On Mon, 22 Sep 2014 15:24:55 +0200 simendsjo via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: My guess is the average for developers is ~8GB. 2GB RAM is really not enough for pretty much anything these days - the browser alone easily chews 3-4GB on moderate use. I recommend you just upgrade your computer (or compile on a better iron). are your primary language is java? i'm asking just out of curiousity. That was uncalled for. Firefox requires 4GB of memory to build. Chromium requires 8GB of memory to build. Android requires 16GB of memory to build. I've been compiling Firefox and Chromium with 4GB of RAM + 4GB of swap on Linux 64-bit in the past. I don't know if I had to close any applications for that. I think 4GB for a modern programming language's implementation is not an unreasonable requirement, even if it could be brought down in the future. Especially considering that you can't even buy a new laptop today with less than 4GB of RAM, and 3GB is becoming the norm for smartphones. So why would Apple be able to get away with 1GB on its just released iPhone 6? Maybe 1048576 kilobytes is enough for everyone? -- Marco
Re: Dutyl - a Vim plugin for running D tools
On Tuesday, 30 September 2014 at 08:27:27 UTC, Idan Arye wrote: On Monday, 29 September 2014 at 16:09:04 UTC, John Colvin wrote: On Sunday, 28 September 2014 at 11:51:21 UTC, Idan Arye wrote: On Thursday, 25 September 2014 at 15:40:22 UTC, John Colvin wrote: 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) How does dutyl know where to look for dub.json? It doesn't seem to find it on my system. It looks for a file named dub.json in the current folder. If it can not find it, it looks for package.json. Ah, ok. Is it feasible to have it check up the directory tree as well, like git does? I often find myself in this situation: myProject |- dub.json |- source - vim pwd here |- app.d and so Dutyl misses myProject/dub.json Seems a little weird to do so, considering that DUB itself does not look up in the directory tree... True, but it does make auto-complete work properly when you open a single source file in a project, without having to manually set the current directory. Vim's current directory (either global or per-window) isn't part of my workflow*. It could be an optional feature (a flag in .vimrc would be fine) with an override (temporarily manually specify the location of dub.json), but I think it makes a significant usability improvement. I'm trying to think of a pathological case where it would be a bad idea, but I can't think of anything realistic. *Am I doing something very wrong here? If using (l)cd in vim is part of almost everyone's workflow I should probably just start using it more and stop complaining :)
Re: Digger 1.0
On 23/09/2014 11:20, Nick Treleaven wrote: Linking phobos.lib is the first time I've got OOM, I use Firefox heavily. phobos.lib is only 10 MB, which is why I thought it odd that linking uses well over 1 GB. I'm now building Phobos 'myself' with win32.mak rather than with Digger, and it seems to use under 1 GB (~750 KB). YMMV. Also I think I was wrong to say just 'linking', it seems to be compiling Phobos as well, so it's understandable why it uses that amount of memory.
Re: Dutyl - a Vim plugin for running D tools
On Tuesday, 30 September 2014 at 08:47:43 UTC, John Colvin wrote: True, but it does make auto-complete work properly when you open a single source file in a project, without having to manually set the current directory. Vim's current directory (either global or per-window) isn't part of my workflow*. It could be an optional feature (a flag in .vimrc would be fine) with an override (temporarily manually specify the location of dub.json), but I think it makes a significant usability improvement. I'm trying to think of a pathological case where it would be a bad idea, but I can't think of anything realistic. *Am I doing something very wrong here? If using (l)cd in vim is part of almost everyone's workflow I should probably just start using it more and stop complaining :) I usually open Vim at the project's and use NERDTree to navigate the file, but I suppose people that start Vim directly on the file they want to edit won't bother `cd`ing to the project's root every time, so we shouldn't force them to do so just so they can use Dutyl... If I'm going to look up the tree to find dub.json anyways, I might as well export the project's root as part of the API. I can add a `dutyl#projectRoot()` that returns that value, and I can also add `:DUexecute` command that'll run a command in the project's root. That'll make it easier to call DUB from Vim using your type of workflow. I'm still pondering though what to with the ConfigFile feature. `.dutyl.configFile` should mark the project's root, but it's creation could prove problematic. If the user opens a file deep in the source tree and runs `:DUConfigFileEditImportPaths` from there it'll create the config file in the wrong place...
Re: Programming in D book is 100% translated
On Monday, 29 September 2014 at 06:09:35 UTC, Ali Çehreli wrote: On 07/24/2014 06:29 AM, Bienlein wrote: The PDF version seems not to have a table of contents. Would be really helpful if it had :-). Now there is a 'Table of Contents' section in the PDF version: http://ddili.org/ders/d.en/pdf_indir.html It is automatically generated, useful, but not perfect. :) Next: - Fix cross references in the PDF version - Generate the index section - Publish the book in paper form Ali Great work, it's the book that made me start D.
Re: Programming in D book is 100% translated
On Thursday, 24 July 2014 at 08:11:01 UTC, Ali Çehreli wrote: I have completed the translation of the book. Phew... :) However, there is still more work, like adding a UDA chapter and working on many little TODO items. The following was the final chapter, which actually only scratches the surface of the very broad topic: * Memory Management As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali Wait, what ? How long have I been in cryogenic chamber ?
Re: Programming in D book is 100% translated
On 09/30/2014 04:36 PM, deadalnix wrote: On Thursday, 24 July 2014 at 08:11:01 UTC, Ali Çehreli wrote: I have completed the translation of the book. Phew... :) However, there is still more work, like adding a UDA chapter and working on many little TODO items. The following was the final chapter, which actually only scratches the surface of the very broad topic: * Memory Management As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali Wait, what ? How long have I been in cryogenic chamber ? I am currently adding the anchors for the index section. :) It is lacking in some areas as the whole thing started without an actual book format in mind but all of that can be fixed later. Ali
Re: Digger 1.0
On Tuesday, 30 September 2014 at 12:19:05 UTC, Nick Treleaven wrote: On 23/09/2014 11:20, Nick Treleaven wrote: Linking phobos.lib is the first time I've got OOM, I use Firefox heavily. phobos.lib is only 10 MB, which is why I thought it odd that linking uses well over 1 GB. I'm now building Phobos 'myself' with win32.mak rather than with Digger, and it seems to use under 1 GB (~750 KB). YMMV. Also I think I was wrong to say just 'linking', it seems to be compiling Phobos as well, so it's understandable why it uses that amount of memory. I don't think Digger should use much more memory than when building things manually. Can you check what's using up memory when using Digger?
[OT Security PSA] Shellshock: Update your bash, now!
Don't mean to be alarmist, but I'm posting this in case anyone else is
like me and hasn't been paying attention since this news broke (AIUI)
about a week ago.
Apparently bash has it's own heartbleed now, dubbed shellshock. Warm
fuzzy flashbacks of TMNT: The Arcade Game aside, this appears to be
pretty nasty *and* it affects pretty much every version of bash ever
released. And of course bash exists on practically everything,
so...pretty big deal. Security sites, blogs-o'-spheres, cloudosphere,
etc are all over this one. (Don't know how I managed to miss it until now.)
Patches have been issued (and likely more to come from what I gather), so:
Go update bash on all your computers and server, NOW. No, don't hit
reply, do it now. Personally, I'd keep updating fairly frequently until
the whole matter settles down a bit.
Since the security folks have been jumping at this, getting a fixed bash
should be trivial. Debian already has patched versions in its repos
(even for Debian 6 if you're using the LTS repo). Other distros likely
have patched versions now too. So you have no excuse!
More info:
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
https://www.digitalocean.com/community/tutorials/how-to-protect-your-server-against-the-shellshock-bash-vulnerability
https://startpage.com/do/search?query=bash+shellshock
HOW TO CHECK/UPDATE:
Test for vulnerability like this (supposed to be one line):
$ env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;};
echo Bash is vulnerable!' bash -c echo Bash Test
Update to a fixed bash:
Debian Testing (and probably Deb 7, though I don't have an installation
of 7 to confirm):
$ sudo apt-get update sudo apt-get install bash
Debian 6: (Including setting up the LTS repos):
$ sudo cat 'deb http://http.debian.net/debian squeeze-lts main contrib
non-free' /etc/apt/sources.list
$ sudo cat 'deb-src http://http.debian.net/debian squeeze-lts main
contrib non-free' /etc/apt/sources.list
$ sudo apt-get update sudo apt-get install bash
Other OSes/distros are likely equally easy. Please, reply with examples
to help ensure other people on the same OS/distro as you have no excuse
not to update!
Re: [OT Security PSA] Shellshock: Update your bash, now!
On 10/01/2014 01:09 AM, Nick Sabalausky wrote: Debian 6: (Including setting up the LTS repos): $ sudo cat 'deb http://http.debian.net/debian squeeze-lts main contrib non-free' /etc/apt/sources.list $ sudo cat 'deb-src http://http.debian.net/debian squeeze-lts main contrib non-free' /etc/apt/sources.list $ sudo apt-get update sudo apt-get install bash Pffft, ok, so I'm a little brain-fried. Obviously those first two lines should be: $ sudo echo 'deb http://http.debian.net/debian squeeze-lts main contrib non-free' /etc/apt/sources.list $ sudo echo 'deb-src http://http.debian.net/debian squeeze-lts main contrib non-free' /etc/apt/sources.list Keep or omit the non-free and contrib as you wish. Or, you know, just get off of Debian 6 to say, Debian 7 or something ;)
