Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On Wednesday, 28 March 2018 at 23:29:28 UTC, Walter Bright wrote: On 3/28/2018 1:50 PM, Dmitry Olshansky wrote: Safety - not so much. I remember back in the olden dayz when Microsoft was pushing ActiveX controls hard. ActiveX controls were blobs of code automatically downloaded from the internet that were embedded in your spreadsheet, word document, etc. What could possibly go wrong? :-) I remember it... I even used some :) And it was efficient! But look at it today - many websites are basically a huge program running in a sandbox. And with more APIs they don’t need a particular page open to run in background and many other limitations are lifted. Still don’t understand why code signing became required on desktop, but not in the web.
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On Wed, Mar 28, 2018 at 04:29:28PM -0700, Walter Bright via Digitalmars-d-announce wrote: > On 3/28/2018 1:50 PM, Dmitry Olshansky wrote: > > Safety - not so much. > > I remember back in the olden dayz when Microsoft was pushing ActiveX > controls hard. ActiveX controls were blobs of code automatically > downloaded from the internet that were embedded in your spreadsheet, > word document, etc. > > What could possibly go wrong? :-) +1. And today, even after Javascript-delivered Meltdown, people still don't get it. *shrug* T -- MASM = Mana Ada Sistem, Man!
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On 3/28/2018 1:50 PM, Dmitry Olshansky wrote: Safety - not so much. I remember back in the olden dayz when Microsoft was pushing ActiveX controls hard. ActiveX controls were blobs of code automatically downloaded from the internet that were embedded in your spreadsheet, word document, etc. What could possibly go wrong? :-)
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On 3/28/2018 1:27 PM, Jacob Carlborg wrote: There's usually nothing that prevents the build tool to write files at build time. Dub can do this. It's expected with a build tool. Not a compiler.
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On Wednesday, 28 March 2018 at 20:50:51 UTC, Dmitry Olshansky
wrote:
On Tuesday, 27 March 2018 at 21:49:16 UTC, Walter Bright wrote:
On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
- ability to write file during CTFE is not necessarily
positive. THough I can't tell why from the top of my mind.
The act of compiling a buggy program not influence the global
state of the computer. It should not be necessary to vet code
downloaded from the internet before even compiling it to
ensure it doesn't mess up the system.
The moment there is make or other build tool this is all futile.
CTFE should run in a sandbox. It must be safe to compile code.
I agree but mostly on the grounds of purity and
reproducibility. It also enables caching and incremental builds.
Safety - not so much.
Indeed, even without such high level tools using the linker is
dangerous due to issues that nobody wants to consider
vulnerabilities.
For demo:
$ mkdir test ; cd test
$ echo 'import std.stdio; void main(){ writeln("test"); }' >
test.d
$ ln -s shouldntexist test
$ dmd test.d
$ ls -l
total 760K
-rw-r--r-- 1 cym13 cym13 90 Mar 29 00:28 test.d
lrwxrwxrwx 1 cym13 cym13 13 Mar 29 00:33 test -> shouldntexist*
-rw-r--r-- 1 cym13 cym13 14K Mar 29 00:33 test.o
-rwxr-xr-x 1 cym13 cym13 740K Mar 29 00:33 shouldntexist*
This can easily lead to privilege escalation by creating
sensitive files in specific locations with arbitrary content
(~/.ssh/authorized_keys comes to mind).
Ok, this needs a specially crafted symlink, but it's one more
thing to check before compiling anything... Compiling just can't
reasonably be assumed to be secure (although I'd very much like
it to be).
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On Tuesday, 27 March 2018 at 21:49:16 UTC, Walter Bright wrote: On 3/27/2018 5:11 AM, Guillaume Piolat wrote: - ability to write file during CTFE is not necessarily positive. THough I can't tell why from the top of my mind. The act of compiling a buggy program not influence the global state of the computer. It should not be necessary to vet code downloaded from the internet before even compiling it to ensure it doesn't mess up the system. The moment there is make or other build tool this is all futile. CTFE should run in a sandbox. It must be safe to compile code. I agree but mostly on the grounds of purity and reproducibility. It also enables caching and incremental builds. Safety - not so much.
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On 2018-03-27 23:49, Walter Bright wrote: The act of compiling a buggy program not influence the global state of the computer. It should not be necessary to vet code downloaded from the internet before even compiling it to ensure it doesn't mess up the system. There's usually nothing that prevents the build tool to write files at build time. Dub can do this. -- /Jacob Carlborg
Re: DLS : an attempt at a language server
On Tuesday, 27 March 2018 at 18:08:14 UTC, Laurent Tréguier wrote: Hello, D community! I've been looking at D for a while now, but never got to really use it. And now that Microsoft initiated the Language Server Protocol, I thought about trying to make a language server using DCD, DFMT and D-Scanner. It only supports formatting with DFMT and basic autocompletion with DCD (for now). I've successfully got it working with both VSCode [1] and Atom [2], maybe I'll try to make extensions for some other editors as well. Also now that I've actually tried the language, I have to say I really like it :) [1]: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.vscode-dls [2]: https://atom.io/packages/ide-dlang I really can't thank you enough for `ide`dlang`. Thank you very much for your atom package. I hope you include Dscanner in near future.
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
Did they figure out how to pass data between threads?
Re: DLS : an attempt at a language server
On Tuesday, 27 March 2018 at 21:08:20 UTC, WebFreak001 wrote: neat, I am also planning on including dcd inside my language server, did everything just work or did you have issues with threading and messaging etc and what were your experiences on it? I'm not doing anything threaded except for special cases like updating. But otherwise DCD seems to just work, I haven't had any problems with it. I see that you have an auto updater, I might as well steal that functionality for me :p Well, I stole your fix of using `stdout.rawWrite` instead of `stdout.write` to make it work on Windows :p Can you list what else makes your language server special? Have you maybe also considered contributing on workspace-d/serve-d? ;) Nothing makes it really special for now, the major differences compared to serve-d is that I'm using DCD as a library, and the update system. Regarding contributing to workspace-d or serve-d, I have something else in mind now : you work on code-d while I have worked on dlang-vscode, so I named my Atom package ide-dlang because for naming consistency the package named ide-d should be the one using serve-d and workspace-d. As I'm now familiar with Atom packages again, and if you implement auto-updating, making ide-d might become quite easy :)
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On Tuesday, 27 March 2018 at 04:46:21 UTC, meppl wrote: On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote: ... Sometimes I want to use a debugger like gdc. If it works, it can be really useful. I skipped trying out Nim, because debugging was not really supported. I wonder, if this is fixed now I wanted to write "gdb" of course. There is an article about debugging nim: https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#using-gdb-lldb
