Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
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. CTFE should run in a sandbox. It must be safe to compile code.
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 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 see that you have an auto updater, I might as well steal that functionality for me :p Can you list what else makes your language server special? Have you maybe also considered contributing on workspace-d/serve-d? ;)
Re: DLS : an attempt at a language server
On Tuesday, 27 March 2018 at 18:32:40 UTC, Anton Pastukhov wrote: Ahem... https://github.com/Pure-D/serve-d I know, but I still wanted to have a bit of fun anyway
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 Ahem... https://github.com/Pure-D/serve-d
DLS : an attempt at a language server
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
Re: DConf 2018 Hackathon -- now open to the public free of charge
On Tuesday, 27 March 2018 at 14:04:29 UTC, Mike Parker wrote: Yesterday, I made the announcement that the Hackathon would be open to anyone willing to pay $100 to get in. That idea has now been nixed. Instead, anyone can come in for the full day completely free. It's like a big Munich Meetup! Wow, it's great news that the D Foundation can afford to do that ;)
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
On Tue, Mar 27, 2018 at 09:27:16AM -0400, Steven Schveighoffer via Digitalmars-d-announce wrote: > On 3/26/18 9:26 AM, Atila Neves wrote: > > On Friday, 23 March 2018 at 14:54:57 UTC, Steven Schveighoffer wrote: [...] > > > It's simple. Unittests in imported modules should not be visible. > > > They should be compiled as if -unittest was not passed. > > > > > > Even Walter and Andrei are supportive: > > > https://github.com/dlang/dmd/pull/6375#issuecomment-373487247 > > > > > > > That would completely break __traits(getUnitTests). > > I'm sure we could find a way to keep the features here, 99.99% of the > time, you don't care about, nor want to parse or semantic, an imported > module's unit tests. Only specialized unit test frameworks care about > this feature. > > It could be as simple as, if you use __traits(getUnitTests, > modulename) anywhere in a module, then that module is imported the > traditional way. Or we could create a specialized "import unittest" > syntax for this purpose. [...] Yeah, since __traits(getUnitTests) is inside the compiler, it could in theory be as simple as: - `import abc;` - compiler lexes and parses abc, but leaves unittests alone (but still present as AST nodes with no semantic run). Basically, module abc is parsed as if `-unittest` is not present. - `__traits(getUnitTests)` triggers semantic on unittest AST nodes of the target module. Does __traits(getUnitTests) work if you don't specify `-unittest`? If so, then the solution is probably already there. T -- Written on the window of a clothing store: No shirt, no shoes, no service.
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 14:51:30 UTC, bachmeier wrote: On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote: D and nim are both very promising. I created this git repo to compare them: https://github.com/timotheecour/D_vs_nim/ Goal: up to date and objective comparison of features between D and nim (to help deciding what language to use), and 1:1 map of features and libraries to help D users learn nim and vice versa. PRs are welcome and merged fast Named parameter arguments is an advantage? I would not consider using a language with named parameter arguments. At best, claiming it's an advantage is arbitrary. You might have better luck comparing the languages if you got rid of the +1/-1 thing. I agree with you. A lot of the parameters selected seem arbitrary. A lot of the advantages and disadvantages aren't absolute, but rather things that depend on the exact situation at hand
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 01:25:42 UTC, timotheecour wrote: D and nim are both very promising. I created this git repo to compare them: https://github.com/timotheecour/D_vs_nim/ Goal: up to date and objective comparison of features between D and nim (to help deciding what language to use), and 1:1 map of features and libraries to help D users learn nim and vice versa. PRs are welcome and merged fast Named parameter arguments is an advantage? I would not consider using a language with named parameter arguments. At best, claiming it's an advantage is arbitrary. You might have better luck comparing the languages if you got rid of the +1/-1 thing.
Re: DConf 2018 Hackathon -- now open to the public free of charge
On 28/03/2018 3:04 AM, Mike Parker wrote: Yesterday, I made the announcement that the Hackathon would be open to anyone willing to pay $100 to get in. That idea has now been nixed. Instead, anyone can come in for the full day completely free. It's like a big Munich Meetup! I was a little offended (from a community POV) that it wasn't free for all. No matter, good news for all that can attend!
DConf 2018 Hackathon -- now open to the public free of charge
Yesterday, I made the announcement that the Hackathon would be open to anyone willing to pay $100 to get in. That idea has now been nixed. Instead, anyone can come in for the full day completely free. It's like a big Munich Meetup! So, if you are in the area and can't make the conference, now you've got even more reason to drop by the Hackathon. If you know someone in the area who might be interested, drop them a line about it and encourage them to go. The food provided is for registered attendees, so those coming in for the Hackathon will need to bring their own lunch, but other than that they have access to the entire day, from the opening talk to the time they kick us out.
ErupteD v2.0 + Vulkan v1.1 breaking changes and NEW transition strategy
The deprecated ErupteD was un-deprecated again. Version v2.0 comes with Vulkan 1.1 support and breaking changes regarding its dependency mechanism. Details in the projects dub and github [0] pages. Regarding [1]: ErupteD-V1 will be destroyed, ErupteD-V2 continued to implement a valid automation and testing scenario. If this is in placed a transition will be reconsider. Apologies for your inconveniences, lessons learned. Put less on the plate and decrease the gradient of the gradual transition. [0] https://github.com/ParticlePeter/ErupteD [1] https://forum.dlang.org/thread/ljuodxxxqocakcczw...@forum.dlang.org
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
On 3/26/18 9:26 AM, Atila Neves wrote: On Friday, 23 March 2018 at 14:54:57 UTC, Steven Schveighoffer wrote: On 3/22/18 6:59 AM, Atila Neves wrote: Blog post: https://atilanevesoncode.wordpress.com/ Atila It's simple. Unittests in imported modules should not be visible. They should be compiled as if -unittest was not passed. Even Walter and Andrei are supportive: https://github.com/dlang/dmd/pull/6375#issuecomment-373487247 That would completely break __traits(getUnitTests). I'm sure we could find a way to keep the features here, 99.99% of the time, you don't care about, nor want to parse or semantic, an imported module's unit tests. Only specialized unit test frameworks care about this feature. It could be as simple as, if you use __traits(getUnitTests, modulename) anywhere in a module, then that module is imported the traditional way. Or we could create a specialized "import unittest" syntax for this purpose. I think we can have the best of both worlds, with the common case being preferred. -Steve
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 12:11:58 UTC, 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. Only thing I can think of is that 3rd party modules can end up writing to your file-system during compilation and could potentially access data etc. they're not allowed to. That is because you may invoke your compiler with the highest permissions possible, but not necessarily the compiled binary file. Which means that the compile-time may not have any restrictions at all and thus potentially security holes are open. Whereas the run-time will be limited and restricted. However by allowing writes etc. at compile-time then the restriction at run-time suddenly doesn't matter, because libraries can just do what they want during compile-time and you don't really want to limit the compiler's permissions etc. because some things may be needed at compile-time that aren't necessarily things you want your run-time to access. I don't know if that makes sense though, but I tried to explain my reasoning as much as I could. In my eyes, it's definitely a no-go to allow writes at compile-time, especially without restrictions. (I don't know if Nim has any restrictions, but doesn't sound like it.) - AST macros are not necessarily easier or more tractable, which have been argued repeatedly by Walter in these forums. The avoidance of AST macros is a plus, not a minus. Sometimes it's much simpler to use mixins, mixin templates etc. than constructing AST nodes. I think this really comes down to taste. However AST nodes seem to be more flexible to manage, but they also open up a lot of complexity. I guess there is no real answer to that, as it'll always be a biased answer.
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 01:25:42 UTC, timotheecour wrote: D and nim are both very promising. I created this git repo to compare them: https://github.com/timotheecour/D_vs_nim/ Goal: up to date and objective comparison of features between D and nim (to help deciding what language to use), and 1:1 map of features and libraries to help D users learn nim and vice versa. PRs are welcome and merged fast It seems you made up your mind, but some of your points are definately up to debate: - ability to write file during CTFE is not necessarily positive. THough I can't tell why from the top of my mind. - Nim doesn't lose points for not being able to use heap objects in CTFE. - the ability to generate C breaks type system guarantees like memory safety. It's like how inline assembly breaks optimizers and type system, and is annoying to implement. It makes the language more "powerful" hence less easy to reason about. - Some of use prefer DDoc to Markdown, which is a language where everything always parses. - AST macros are not necessarily easier or more tractable, which have been argued repeatedly by Walter in these forums. The avoidance of AST macros is a plus, not a minus. - Likewise, distinction between traced and untraced pointers is exactly what D designers didn't want. Last time I tried Nim, the Javascript generation didn't preserve semantics. You would write "a.member = 2" and it would generate "a.member = 2", without consideration of memory model. It seems Nim's memory model depend on whatever language it generates.
Re: Vulkan ErupteD breaking changes and transition strategy
On Sunday, 25 March 2018 at 22:23:06 UTC, Peter Particle wrote: ErupteD [0] is deprecated (one of its major modules). [snip] Rewind and Undo --- I must apologize for the mess I have created, ErupteD is un-deprecated again. It will be further developed until ErupteD-V2 has a proper automation and testing system in place. There will be a separate announcement, when ErupteD v2.0.0 reaches vulkan 1.1 status.
