Re: DIP1028 - Rationale for accepting as is
On Tuesday, 26 May 2020 at 13:21:08 UTC, Johannes Loher wrote: Am 26.05.20 um 15:10 schrieb Panke: The bazel community has lots of such switches. Basically every new behaviour get's introduced with a --preview switch, that will turn into a --revert after some time. For each switch there is a github issue, explaining the change it detail. Why it was necessary, what the changed behaviour is, how to migrate and the timeline for this particular switch. D has the same thing (e.g. -preview=safedefault will enable this DIP). The main difference to Johannes T's suggestion is that these preview and revert switches are only a temporary measure to ease the transition. They do not create different versions of the language permanently. What we don't have is good documentation and a clear timeline for the switches.
Re: DIP1028 - Rationale for accepting as is
On Tuesday, 26 May 2020 at 12:38:54 UTC, Johannes Loher wrote: A switch might help but the whole purpose of this DIP is to get the defaults right. In my opinion, such a switch should be enabled by default. There is also the danger of creating 2 versions of the language that are incompatible with each other. Only giving this a quick thought, I believe it could work (you can still link libraries compiled with and without the switch) but I'm not completely sure. The bazel community has lots of such switches. Basically every new behaviour get's introduced with a --preview switch, that will turn into a --revert after some time. For each switch there is a github issue, explaining the change it detail. Why it was necessary, what the changed behaviour is, how to migrate and the timeline for this particular switch.
Re: DIP1028 - Rationale for accepting as is
On Tuesday, 26 May 2020 at 12:20:31 UTC, Johannes T wrote: On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote: [..] Thank you very much for your patience with all the negative feedback. Yes, good think to stop once in a while and appreciate it. "To not complain is sufficient praise", does not always cut it.
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote: A few years ago I submitted several PRs to Phobos to mark all unittests that could with @safe explicitly. I'd say that was a good example of nobody reviewing them for their @systemness. Ideally you should be able to blindly mark every function definition with @safe, because the compiler will catch you if you fall. Only if you type @trusted you should need to be careful.
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 12:22:25 UTC, Zoadian wrote: there is no such thing as a trustworthy @trusted. not with how the whole safety system work now. you can break previously verified @trusted code by just writing @safe code today. Do you have an example of code that was correctly labeled @trusted in DMD version X, which may not be labeled @trusted in DMD version Y because of changes to @safe/@trusted@/@system?
Re: DIP1028 - Rationale for accepting as is
On Sunday, 24 May 2020 at 08:55:32 UTC, Walter Bright wrote: I infer your position is the idea that putting @trusted on the declarations isn't greenwashing, while @safe is. I can't see a practical difference between: @safe extern (C) void whatevs(parameters); @trusted extern (C) void whatevs(parameters); Both require that whatevs() provide a safe interface. The difference between them is in the implementation of those functions, not the interface. Since the D compiler cannot see those implementations, they are immaterial to the compiler and user. I've always understood that the @safe,@trusted,@system machinery provides the following guarantee once all holes are fixed: If I have a memory corruption in my code than I need to only look at the @trusted and @system parts to find it. Marking whatevs @safe violates this, marking it @trusted does not.
Re: Hunt Framework 3.0.0 Released, Web Framework for DLang!
On Friday, 8 May 2020 at 06:41:59 UTC, Jan Hönig wrote: On Thursday, 7 May 2020 at 05:04:12 UTC, zoujiaqing wrote: On Wednesday, 6 May 2020 at 22:28:28 UTC, Dukc wrote: On Friday, 1 May 2020 at 10:54:55 UTC, zoujiaqing wrote: [snip] Thanks, but: Some of the files have Apache license, but some have none. I think you should add a license to the whole repository that would cover those files that don't have their own. OK, thanks ;) I have a somewhat stupid question. I asked it on reddit, but I got no answer there. I haven't done much with web or networking in general until now, thus excuse my ignorance. What is the difference between hunt and vibe-d? I can say anything about hunt, but vibe-d is three things: 1. https://github.com/vibe-d/eventcore This is the core of it and gives you a proactor for async programming with callbacks. Instead of a blocking 'write(data)' call you do 'write(data, dlg)' where dlg is a delegate that is called once the write has finished. 2. https://github.com/vibe-d/vibe-core Writing non-trivial programs with a bare proactor quickly leads to callback hell. Far easier is to hide the callback behind fibers. This is what vibe-core does. Everything runs as a fiber, which gets suspended on call to eventcore's async interface and is automatically resumed after the async call finishes. 3. https://github.com/vibe-d/vibe.d This implements stuff that's useful for web programming on top of 2. HTTP, WebSockets, databases, serialization, stuff like that.
Re: Luneta: terminal fuzzy finder
On Monday, 4 May 2020 at 22:49:49 UTC, Felipe wrote: Hi, I develop an interactive terminal fuzzy finder in D with ncurses. Feel free to check it out and contribute. Any feedback is welcome. Thanks, Felipe [1] https://github.com/fbeline/luneta [2] https://code.dlang.org/packages/luneta [3] https://code.dlang.org/packages/fuzzyd What's the difference to fzf?
Re: swaywm-ipc
On Sunday, 8 March 2020 at 16:34:24 UTC, Martin Brezel wrote: If you are using swaywm (swaywm.org), then it may interest you that i started to implement its IPC interface: https://github.com/mab-on/swaywm-ipc `swaywmipc.core` is the implementation of https://www.mankier.com/7/sway-ipc `swaywmipc.client` is a higher-level client, easy to use. (https://github.com/mab-on/swaywm-ipc/blob/master/examples/client/source/app.d) Have fun! Nice to see that. I am a recent sway user myself. What are you using it for?
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 17:37:17 UTC, jmh530 wrote: On Wednesday, 26 February 2020 at 16:17:06 UTC, Panke wrote: [snip] If you had an RSS feed, I would subscribe. Wasn't there a planet D in the past? I've been subscribed on feedly without any issues. I can't recall what I actually did to subscribe as I can't seem to replicate it, but you can try https://atilaoncode.blog/feed/ Can't say for sure with other RSS readers. That works great, thanks!
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves wrote: On Wednesday, 19 February 2020 at 16:30:04 UTC, Atila Neves wrote: https://atilaoncode.blog/2020/02/19/want-to-call-c-from-python-use-d/ Discussion elsewhere: https://www.reddit.com/r/programming/comments/f6agvt/want_to_call_c_from_python_use_d/ https://news.ycombinator.com/item?id=22365166 A lot of the comments were about how stupid I was for not just using ctypes or cffi. I tried today and both of them are horrible. As I say in the blog post below, either they didn't read the article (people on the internet commenting on things they didn't even read? Shock! Horror!) or just aren't lazy enough. My followup: https://atilaoncode.blog/2020/02/26/seriously-just-use-d-to-call-c-from-python/ Very good read. I my opinion your work with integrating different languages with D is the most exciting stuff going on in the moment. If you had an RSS feed, I would subscribe. Wasn't there a planet D in the past?
Re: GSOC 2020 projects
On Monday, 24 February 2020 at 02:52:04 UTC, RazvanN wrote: On Tuesday, 18 February 2020 at 05:59:47 UTC, RazvanN wrote: Hello everyone! In a couple of days we should find out if The Dlang Foundation was accepted as a mentoring organization for Google Summer of Code 2020. If we get accepted, I think that we should have a list of priority projects that we should propose to students. I have started tagging what I find the most useful projects with the gsoc2020 tag [1]. If you want to help in this process you can: [...] Unfortunately, Dlang has not been accepted this year as a GSOC mentoring organization. Maybe we will have better luck next year, Cheers, RazvanN Do we know why?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Umm that was me... I don't feel confident enough to write at a Phobos standard yet and might be a little while before I am experienced enough. But I see your point. Fastest way to get better is to submit PRs and get reviewed.
