Re: DIP 1034--Add a Bottom Type (reboot)--Formal Assessment Concluded
On Tuesday, 16 February 2021 at 07:07:09 UTC, Mike Parker wrote: When I emailed Walter and Atila to officially launch the Formal Assessment of DIP 1034, "Add a Bottom Type (reboot)", I expected it would be three or four weeks before I received their final decision. So I was surprised when Walter replied two days later with the following response: "Accepted with pleasure and enthusiasm. This is what DIPs should be like. I intuitively felt that a bottom type was right for D, but failed to express it in DIP1017. Dennis has done it right." Atila was on vacation at the time, but as soon as he got back he responded: "Seconded." Congratulations to Dennis Korpel for a job well done, and thanks to everyone who provided feedback on this DIP from the Draft Review through to the Final Review. I had been hoping for this so much! Very happy that it got accepted! Congratulations Dennis, you did a great Job with the DIP. Thanks once again for taking that up!
Re: Github Actions now support D out of the box!
Am 21.08.20 um 04:03 schrieb Mathias LANG: > [...] Thanks a lot for this! I just switched to using this instead of Travis CI in one of my projects. Works great!
Re: From the D Blog: A Pattern for Head-mutable Structures
On Friday, 26 June 2020 at 09:30:47 UTC, aberba wrote: On Friday, 26 June 2020 at 07:35:17 UTC, JN wrote: [...] For a while I thought it was just me but the D blog posts addressing D specific nifty tricks mostly don't interest me. Benchmarks, const, etc... :(. Probably it's just because of my area of interest or how they're articulated. But stuff about a companies using D for this and that or a community member sharing their thing comes out very interesting. I myself will be interested in doing some less technical but more practical posts. Probably comparing and contrasting packages, tools, community and stuff. I'm curious what's happening in those D meetups. Are they still happening (online)? The Munich D meetup has been quite inactive during recent times. The last event was on 16.07.2019, almost a year ago. To be honest, I think the problem is that it’s a bit difficult to find topics that we have presenters for and that enough people are interested in.
Re: DIP 1028 "Make @safe the Default" is dead
Am 29.05.20 um 06:53 schrieb Walter Bright: > The subject says it all. > > If you care about memory safety, I recommending adding `safe:` as the > first line in all your project modules, and annotate individual > functions otherwise as necessary. For modules with C declarations, do as > you think best. > > For everyone else, carry on as before. Thank you, Walter. I understand that this comes with a lot of frustration (and maybe bitterness and resignation). But I really appreciate your decision to respect the community's opinion. It is the right thing to do. You have my biggest respect.
Re: DIP1028 - Rationale for accepting as is
Am 27.05.20 um 12:40 schrieb Walter Bright: > > Indeed it is, and that's the whole point to @safe. My motivation here is > make suspicious code stand out. @trusted code does not stand out so > much, because it is required to exist. By that logic, wouldn't it also make more sense to implicitly default to @trusted instead of @safe for any unannotated D code? Following that logic, if @safe is the default and somebody writes non-@safe code without annotating it, it won't compile they might just slap @trusted on it without actually checking it. By that they make it harder for the QA department to spot. If @trusted was the default, it would compile, there would be no annotation on it an the QA department would see it is a red flag. What's the difference here?
Re: DIP1028 - Rationale for accepting as is
Am 27.05.20 um 11:50 schrieb Walter Bright: > > It is a fair point. > By the way, thank you for acknowledging that. I appreciate it.
Re: DIP1028 - Rationale for accepting as is
Am 27.05.20 um 11:25 schrieb Walter Bright: > On 5/24/2020 3:40 AM, Stefan Koch wrote: >> The distinction is that you can find a slapped on trusted with a grep. > > It's just as easy to use grep to *not* find @trusted. But that's not enough. You need a regexp that searches for extern (C(++)) declarations that do not have any of @safe, @trusted, @system. The attributes can also be either before the return type + name + parameters or after it. They can also be mixed with any other attributes. Sure, you can probably write a regex that matches all of this but it is a _lot_ more complicated than simply searching for @trusted.
Re: DIP1028 - Rationale for accepting as is
Am 27.05.20 um 11:50 schrieb Walter Bright: > It is a fair point. But I am looking a bit farther than that - the team > that is responsible for QAing software (sometimes it is a separate > team). The QA team cannot tell the difference between correctly > annotated @trusted code and greenwashed code. > > But they can tell when code is not annotated (no, it is not harder to > do, the annotations are designed to not be hidden - annotations cannot > be hidden by the preprocessor nor are they propagated from imports. They > have to be there, and if grep doesn't find them, they are not there. > I've never had any difficulty finding the annotations belonging to a > declaration). > > Un-annotated C declarations should be a red flag to any competent QA > team. Recognizing a false @trusted is a whole lot harder. This is a very specific situation. There are a lot of teams / developers that do not work in this manner. I don't know the numbers so I will make no statement about what is more common but my personal experience is a different one. Also what is the difference between your QA department telling you to correctly annotate C declarations and the compiler telling you that? If you expect people to ignore what the compiler is telling them, why do you expect them to listen to the QA department? In my opinion, the compiler actually _is_ one of the best QA departments. Also in my opinion, a competent QA department should carefully look at any @trusted code /declarations. Maybe it is not a "red flag" but it is definitely something that needs to be checked with extra care.
Re: DIP1028 - Rationale for accepting as is
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.
Re: DIP1028 - Rationale for accepting as is
Am 26.05.20 um 14:20 schrieb Johannes T: > Thank you very much for your patience with all the negative feedback. I > get your decision to not annotate extern C with @system by default. As much as i disagree with the decision, I am still very glad that we are at least having a discussion. I also want to thank Walter for participating here. I understand this can be difficult but it is the right thing to do. > The biggest issue with extern @system is that @trusted would become less > useful when dealing with declarations and bindings. @trusted would > appear more frequently. We wouldn't be able to assume that the author > put in effort in assessing the trustworthiness of a declaration. More > greenwashing, less safety. Those are severe drawbacks, I agree. > However, as Andrei pointed out, PR is a huge problem. We need to be able > to sell it with a straight face. > I think this might be done by formally redefining the meaning of safety > attributes when applied to extern: > The safety of extern can't be assessed by the compiler. Implicit "@safe" > extern within @safe code is accepted for the convenience of the average > user. Explicit @system or @trusted can be added for desired behavior. > I think this can be explained. Well, the spec actually already mentions that: > Safe External Functions > > External functions don't have a function body visible to the compiler: > > @safe extern (C) void play(); > > and so safety cannot be verified automatically. > Best Practices: Explicitly set an attribute for external functions rather than relying on default settings. I still don't think this is the correct thing to do. Instead, annotating external (at least extern(C)) functions with @safe (implicitly as the default or explicitly) should be a compile error in my opinion. > It's not an acceptable solution for people who require correctness. > ZombineDev can't tell an auditor that he relies on D-Scanner to find the > problematic spots. I believe it's unavoidable to provide an option to > change the default. It could make extern @system or refuse to compile > safe code calling @safe extern. 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.
Re: DIP1028 - Rationale for accepting as is
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote: He can look at unattributed declarations. The issue is, you have to know about that beforehand. In the other situation, you explicitly get warned by the compiler (by the compile error) that that something dangerous is going on. Also, this means, there are now 2 different things to look for: @trusted function declarations and unannotated extern(C) declarations. The latter is much harder to search for (as Andrei also noted in his reply) and it's just much simpler to only have one escape hatch to look out for. It is also a very weird special case. @safe means no memory corruption is possible except for any @trusted declarations and any unannotated extern(C) declarations, wrongfully @safe extern(C) declarations and wrongfully @trusted extern(C) declarations. This just doesn’t sound right. The whole debate boils down to "is greenwashing better, more honest, more debuggable than leaving things unattributed?" No on all three accounts. The question should be rephrased: „Is explicit greenwashing by the developer better, more honest, more debuggable than implicit greenwashing by the compiler?“ Yes for better and more debuggable for the reasons that have already been mentioned so many times. Regarding honesty: In your variant, the compiler is dishonest, in the other variant, the developer is dishonest. Just think about what the developer's reaction would be in the situation I described in my last post, when he actually finds the issue. In your variant, the developer will be questioning why the compiler did not help him at all with realizing that there might be a problem. It is very likely that he blames the issue on the compiler. In the other variant, he will realize that this something he had been warned about by the compiler and that he made a careless wrong decision and that it is his own fault. In the future he will be likely more careful when it comes to annotating stuff with @trusted. So this even has an educational effect.
Re: DIP1028 - Rationale for accepting as is
On Tuesday, 26 May 2020 at 01:16:49 UTC, Walter Bright wrote: On 5/24/2020 5:56 PM, Timon Gehr wrote: It's only greenwashing if it's misleading. Putting @safe is a lie, putting @trusted is honest. It is not honest unless the programmer actually carefully examined the interface and the documentation to determine if it is a safe interface or not. For example, labeling memcpy() with @trusted is not honest. Forcing people to add uncheckable annotations is a path to convenience, not honesty. This has already been repeated over and over again but I'll do it once more: If people cannot check the code (or get enough confidence in another way), they really shouldn’t annotate it with @trusted but with @system instead. If they annotate it with @trusted anyways, it is their own fault. And at least in that case they are lying and not the compiler. Also if something bad actually happens, they can at least search for „high risk areas“ (@trusted declarations). Just consider the following situation: A (maybe inexperienced) programmer needs to call an existing C function from D code. Because no bindings exist yet, he creates them himself. He does not add any annotations regarding safety. Now he uses this function in @safe code and he uses it in a way that actually creates a memory corruption (the function is not safe, but the developer does not know about that). Now let's compare the two different options: 1. With DIP1028 in its current form, the code will compile and a memory corruption will actually happen. The problem might be extremely difficult to track down for the developer because he has no clues whatsoever where to start looking. 2. With one of the solutions that were presented, the code will not compile as it is. According to your argument of „convenience“, the developer will probably just mark the function incorrectly as @trusted which makes the code compile. The memory corruption will happen. However, even if the developer did not think much about potential safety issues when adding @trusted to the function, he now still remembers that he did that (it was a conscious decision, even if it was a careless and lazy one). He has a clear point to start looking for the reason of the memory corruption. Do you honestly think option 1 is better?
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 11:40:46 UTC, Johannes T wrote: On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote: [..] But with the DIP in its current form, we make @safe lose its meaning and power, which is much worse in my opinion. [..] The alternative, not making extern @safe, would result in more untrustworthy @trusted code we have to worry about. It's a vicious circle. I try to relax my view on extern annotations. They are @system. We *should* go ahead and diligently mark with @trusted. From experience, it doesn't normally happen. I don't like @safe extern, but it seems like the lesser evil. Walter got a lot of flak. I tried to retrace his thoughts and see the merits. From my perspective it is really simple: Either we have a strict @safety system (with exactly one escape hatch) or we don't. At the moment we don't because you can have @safe extern(C) declarations but with this DIP it becomes even worse as it is more likely that @safe promises are broken without anybody noticing. If you and more importantly Walter and Atila really think this is the lesser evil and that it is worth dropping the strict @safety system with exactly one controlled escape hatch for this, then we also need to clarify what @safe means after that. We can definitely not claim that it means machine verified except for @trusted because extern(C) functions are another escape hatch. The question has been asked in this thread a few times already: What does @safe actually mean? How to „sell“ / „advertise“ it?
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 09:25:52 UTC, Johannes T wrote: On Monday, 25 May 2020 at 00:56:04 UTC, Timon Gehr wrote: [..] After thinking about it, Walter ultimately made the right decision, leading to overall higher safety and code quality. We all agree that making extern C @safe is incorrect. It's also meaningless. Even if you were to verify the safety of a specific version of your binding, it can't be known what's loaded at runtime. It's not the compiler's concern. @safe extern shall be an error. We might additionally make an exception and make all extern C @system. It would be correct for the declarations, but inconsistent in regard to default safety. It doesn't affect the outcome. Let's say we'll go with @system, it gives us a bit more freedom. We hit compile, our now safe wrappers are errors. We are most likely to do one of two things, depending on the module failing to compile. If it mostly wrappers, we slap @trusted: at the top. If there are just a few functions calling C, we only annotate those with @trusted. Let's be real, we probably won't begin checking and annotating the trustworthiness of the C functions. An individual programmer might, but not on average. We are formally correct, but @trusted can't be trusted at this point. It has lost its meaning. We now have to check all foreign @trusted code, which we probably won't. We could have moved the problem one level down and slapped @trusted: on top of the @system declarations. Now there is a bunch of safe code using them. It doesn't change much. @trusted: is easier to grep, but we won't put everything down and begin trustworthily annotate extern C. So yeah, I do believe Walter was right. @safe on extern is formally incorrect but leads to safer code because @trusted still has its power. So basically you are saying we should do it the way it is described in the DIP because otherwise it will lead developers to incorrect usage of @trusted (just slapping it on declarations whiteout actually checking the implementation) thus making it loose its „power“ which leads to less safe code. But with the DIP in its current form, we make @safe lose its meaning and power, which is much worse in my opinion. It makes the statement „@safe code cannot create memory corruptions except for @trusted code“ wrong (it already is wrong now but it really shouldn’t be!). What you are describing is really just an admit of defeat. Then why still bother with @safe at all if it doesn't give us any meaningful guarantees? I don't think we are at that point (yet).
Re: DIP1028 - Rationale for accepting as is
On Sunday, 24 May 2020 at 12:14:13 UTC, aliak wrote: On Sunday, 24 May 2020 at 11:30:53 UTC, Johannes Loher wrote: On Sunday, 24 May 2020 at 11:25:06 UTC, aliak wrote: On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote: does not work). But I admit that it is still a bit weird to have 2 different defaults. Is that any more or less weirder than having functions inferred with different attributes based on context? What exactly are you referring to? Attribute inference by D, specifically template functions. The attributes are inferred based on context (I don't know the exact algorithm). So a function f(T)(T) when called can maybe be pure, maybe safe, maybe not? From what I understand, it does not depend on the context but on the template parameters you pass to the template. I agree that it might be a bit confusing at first, but it makes sense if you realize that templates themselves are not functions but something that can generate functions (and other constructs) from compile time parameters. Why shouldn't the attributes of a generated function be able to depend on the parameters being passed to the template? Basically everything else can depend on them, too. Automatically inferring the attributes is just a very convenient way to do that. But yeah, it's not 100% consistent that they are not also inferred for regular functions (some people have been arguing for that). However, at least for templates, there is a very good reason for the difference (or at least the fact that attributes are inferred for templates): if that was not the case, it would basically be impossible to write generic code that works with all the attribute combinations. However, the very purpose of templates is to enable writing generic code. They wouldn't make that much sense if that capability was strongly limited. On the other hand, having different @safety defaults for bodiless function declarations and regular faction declarations does not have such a big benefit, especially when considering the fact, that we can have the same defaults but make @safe (default or explicit) bodiless function declarations a compiler error. If we ignore that option for some reason, it would only be dort of a necessity in order to prevent people from shooting them selves in the foot without even noticing. But there is no inherent value in the difference, it doesn't enable anything. That said, I'd still prefer this variant over what DIP1028 does currently. It's just that I think the other option is even better because it is more consistent.
Re: DIP1028 - Rationale for accepting as is
On Sunday, 24 May 2020 at 11:25:06 UTC, aliak wrote: On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote: does not work). But I admit that it is still a bit weird to have 2 different defaults. Is that any more or less weirder than having functions inferred with different attributes based on context? What exactly are you referring to?
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. From my perspective, there is a clear difference in meaning between them: @safe means verified by the compiler (which as you mentioned can never be true for declarations where the code is not available, hence it always is a lie in that case) and @trusted means verified by the developer. Whenever @trusted is slapped on _anything_, it is clear that extra caution is needed (in codereviews etc.) and as others have mentioned, it is easily searchable. When I put @safe on a piece of code, my expectation is that it is actually verified by the compiler. If that is not possible, it should not compile. The same reasoning also applies to the case where the annotations are not added by the developer explicitly and the defaults are used instead: If the default is @safe and the code for an unannotated declaration is not available, it should not compile. Making @trusted the default is not an option because as mentioned earlier, one of the points of @trusted is for it to be actually seen, which is not the case if it is the default, so I will not elaborate on that. If @sytem is the default, there is no issue but of course the whole point of this DIP is to move away from that. I understand that today it is possible to slap @safe on declarations without code without the compiler complaining but it really _should_ be an error in order to have a consistent meaning of @safe, @trusted and @system (@safe = compiler verified, @trusted = user verified, @system = not verified) also in the case of declarations where no code is available. Let's assume this is indeed the way to go, then there are 2 possible solutions for this DIP regarding how to handle this: 1. Make declarations without code default to @system instead of @safe. This is what many here have been arguing for but as you mentioned several times, it has the drawback of adding special cases to the language. As a user, it does not seem that problematic though because the compiler can easily tell you what is going on when there is an issue (i.e. calling an unannotated declaration without code from a @safe function could result in compiler error message that explains why this does not work). But I admit that it is still a bit weird to have 2 different defaults. Additionally, explicitly annotating such declarations with @safe should be a compile error. 2. Make @safe the default for _all_ declarations but still make @safe on declarations without code a compile error (because the compiler cannot verify it). This means that annotating function declarations without code with @system or @trusted is now mandatory. This is what Timon has been arguing for if I understood him correctly. 3. There may be a third option if we introduce something like conditional safety but I do not completely understand that yet. This is what H.S. Theo has been suggesting. Option 1 and 2 both have the „issue“ that people might „greenwash“ things by simply slapping @trusted: at the top of a file. But that can always be done anyways and at least it is explicit and searchable. As mentioned, using @trusted now has the meaning that it is user verified so it always needs extra caution. Personally I prefer option 2 because it is a lot more consistent: There are no special cases. Until now, I did not discuss whether or not all of this should apply only to extern(C) function declarations without code or all function declarations without code. This is because it is a separate point. Both are possible and have pros and cons: If it applies to extern(C) function declarations without code only, then we can still have @safe extern(D) declarations. They are not verified by the compiler but you get linker errors instead because @safe is part of the mangling. The benefit is that you get more @safe code by default, the drawback is that it relies on linker errors instead of compiler errors and that it introduces a special case. If it applies to all function declarations without code, also extern(D) function declarations without bodies need to be annotated with @trusted explicitly if they are @safe or @trusted. If they are @system, we still get linker errors due to name mangling. The benefit is that it is a very consistent solution, no special cases are needed. The drawback is that it requires more manual effort to add the additional annotations (but then, don't we want to encourage
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote: On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote: Although it seems an improvement has been made to how he needs to respond to the DIP assessment. It should also include a statement from Atila as well given his position. One thing that need to be clear and for I read it was not remotely answered from Walter is why this DIP process and discussion exists if in the end like it or not it will be incorporated. As an end user, I'd like to know if this language will be guided by community or one person, because it seems the "democracy" is very shallow right now. And again why waste time with this process plus 2 rounds of discussion? I mean just do it and tell in this announcement section about the feature. Matheus. There is no democracy. The decisions are simply made by Walter and Atila. From my understanding, the purpose of the DIP process is to improve DIPs and find any potential flaws before a final decision ist made by the two language maintainers. However, how much of the review the maintainers take into account is their own decision. In theory, this results in much higher quality DIPs and the chance of a DIP that actually makes it to the formal assessment stage to be accepted is a lot higher. It also seems to work quite well when the DIP author is not one of the language maintainers. From my experience, the quality of those DIPs really has gone up by a lot. There is also a lively discussion about each DIP and the authors are actively participating. It is in their own interest to do so because getting feedback and addressing it increases the quality of the proposal which in turn increases the chance of the DIP being accepted. If the author is one the language maintainers, this doesn't seem to work that well though. There is simply less motivation for them to do all of that because in the end, they can make the decision by themselves anyways. I am not saying that the language maintainers do this on purpose, it is simply a psychological effect. And the result can be seen very clearly when comparing review threads for DIPs from the language authors with review threads for DIPs from others. In defense of the language authors, it has to be stated that the situation has improved quite a bit over time. Examples of this are how DIP1017 was handled or the fact that Walter now gave a reasoning for his decision regarding DIP1028 (even if only after being asked to do so). But unfortunately, sometimes it still really feels like DIPs from the language maintainers and DIPs from others are handled quite differently by the maintainers.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md As others have mentioned, this really is a farce. I understand that not everybody will be happy with every decision but the fact that there is not even a comment is just disrespectful towards all the people that put in a lot of effort to review the DIP. How can you seriously expect them to continue to do that if you treat them like this? Don't you think their work is valuable? If not, why bother with the DIP process at all? It just seems like a total waste of everybody’s time. I am really disappointed about this...
Re: D Forum Mobile Version - Beta
On Thursday, 28 November 2019 at 04:23:21 UTC, Nick Sabalausky (Abscissa) wrote: 1. I find the text size to be exactly what I wish most sites would use. Most sites just assume everyone's on some kind of "Apple iSuperMini for Oompa-Loompas With The Fingers of Five-Year-Olds" and crank up the font size to absurd levels to compensate. The result is not merely an enormously waste of screen real-estate on a form factor notorious for every last millimeter being crucial, but the fonts themselves actually manage to be uncomfortably large to read in the first place. The problem you describe my be a real one, but the solution presented by this version of the forum is not any better because it makes the text very hard to read on devices with high pixel density. It is possible to have the fontsize depend on the devices pixel density, which would be a much better solution. 2. The only reason extra margins would be needed on the actual post-viewing pages would be as a workaround for those goofy phones with the nonsensical misfeature of "edge-to-edge" screens the manufacturers have been trying to push (just because they can, and because they figure its harder for their competitors to copy). Handheld touchscreens obviously need borders (that's just basic HCI common-sense), and requests for applications/websites to add them back in just proves its nothing more than a glaring flaw of the phone itself. People with better practicality-oriented phones shouldn't have to sacrifice their own perfectly usable real estate just because of some *other* phones' MBA-driven lunacy. That is missing the point in my opinion. Margins are important for visual separation and to create focus. My iPhone 8 has borders around the screen, but having text stick directly to this border makes it very hard to read. Having an additional white border is much more comfortable. This is also something that has been established for a very long time. There is a reason that basically every medium in existence uses margins like that (e.g. books, newspapers, etc.)
Re: D Forum Mobile Version - Beta
To begin with: Sorry if my last post came across a bit harsh. That was not my intention. I thought you were looking for feedback and I wanted to be honest regarding that. If you are simply doing it for yourself and others, who also like it, that is of course perfectly fine. But personally I would not want it under an official domain in the current state because it simply looks a bit unprofessional in my opinion (which is fine for personal use, but would reflect on D‘s image if made official). On Wednesday, 27 November 2019 at 23:54:19 UTC, matheus wrote: On Wednesday, 27 November 2019 at 21:32:06 UTC, Johannes Loher wrote: ... What are your concerns with the regular forum on mobile devices? Look at the first post, I showed the diffs between both versions: https://i.imgur.com/wfmm035.png <- For "me" the new is cleaner. That’s personal preference, which is fine. Your version is more minimal, and actually does have one major benefit: You can read the whole topic names. On the other hand, your version is missing some things which I like very much, e.g. the breadcrumbs (Index » Learn » Topic name) which I regularly use to quickly navigate between different forums. https://i.imgur.com/LzvhrdQ.png <- I can read more. Which is achieved mainly by removing the margins and decreasing font size. Depending on your device, this might actually work out, but it does not on my iPhone 8. There is a reason why every major website uses margins around the content. You might also want to take a look at what the „Reader Modes“ of some browsers look like. They reduce the style of pages to a minimum (only black text on white background), but they still keep the fontsize quite a bit bigger than what you are using and they also use margins. Space is also gained because you remove some small parts. While I already mentioned that I personally would want the breadcrumbs to stay, there is a point to removing the „Log in, Settings, Help“ section, if this is really only for reading. Others who actually use this part of the website might disagree of course. https://i.imgur.com/BM13xTw.png <- At the bottom there is a shortcut to change pages on a topic. While I personally hate absolutely positioned navigation bars (they just look weird to me), this is actually helpful because you do not have to scroll down all the way to navigate. What I‘d personally prefer though would be to have a navigation at both the top and the bottom, but that‘s just personal preference. Well I'll not enter in a battle which design is better, all I know is the current design doesn't works for me on my old LG K4. * Weird spacing in general. As mentioned before, there is missing space to the screen border, but in other places, there is disturbingly much space, e.g. between the different forum „groups“ (new users, ecosystem etc.) Let's see this closely and compare these 2 versions: 1) https://i.imgur.com/n2N7Tfx.png <- In the original you need to scroll down first to see the topics. Agreed, there is a lot of info in the original version that regular users probably don’t need to see all the time. Removing this is actually good (at least for my usage, the missing introduction might be bad for new forum users). 2) After scrolling down you will see this: https://i.imgur.com/tijpNip.png So between the 2 versions, the new version is only missing one topic (LDC). And this is mostly because the spacing between the different forum groups is quite big (too big in my opinion). I already mentioned that your version has one major benefit here: you can read complete titles. But this comes at the cost of the „Last Post“ link, a feature I use on a daily basis, which I would not want to miss. It basically brings me to the latest post which I have not read yet, so it allows me to quickly find all the new information which has been posted since my last visit. This is an extremely important feature to me because it basically defines how I use the forums. I‘m sure, I could mention a lot more, but these are the major points I immediately noticed. I‘m looking at it in an iPhone 8. I'd like to see screenshots running on your iPhone 8. https://ibb.co/qgYhvZm https://ibb.co/HxBBFDS https://ibb.co/jZD89Fq ...you mentioned that is intended as readonly. a readonly Forum Is basically useless imo. Also if it is readonly, why are there reply and create thread buttons? Again look my first post where I said: I use to access this Forum mainly through the WEB version, and so far It never bothered me when reading on my PC. But on my phone (An old LG K4) with tiny screen it's not very pleasant, I use this phone when I'm on the road, I lately I gave up to read this Forum through it. So I use this mobile version only when I am on the road, to see what's happening here, if you ask the mods, all my posts came from the same IP (Desktop), this mobile version was intended only to read on my tiny and old
Re: D Forum Mobile Version - Beta
On Wednesday, 27 November 2019 at 15:17:15 UTC, matheus wrote: On Wednesday, 27 November 2019 at 10:58:17 UTC, Bastiaan Veelo wrote: I’d recommend contacting Vladimir directly, like bachmeier said... OK I'll try that. However, I tried your version and it didn’t work well for me; I’m on an iPhone 6. I prefer the current version in the threaded mode. Could you please explain more about this or take a screenshot? Because so far 4 friends (3 on Android e 1 on iPhone 8 ~ 9 I think) said it works better than the actual version on mobile, their main complain is about the speed and that's because my hosting is slow. I'm using JavaScript to handle some features and hid some elements and for this I set an interval because the some features of this Forum uses JS too. By the way I made this version for "viewing" only. I don’t know how you implemented your version, but if you can make it configurable as one of the current supported view modes, I guess the chances of getting it accepted are higher. It can be set, I'm current using CURL to get the page and setting the style over it. If it was totally 100% static it would be easier and clean, but there are some JS that it was needed to take care of. Thanks, Matheus. I have to agree that I prefer the regular version by a lot. Some concerns that I can immediately identify with your version are: * no space around the content. I don‘t want the letters to stick directly to the border of my phone‘s screen. * small font size. It‘s just to small to readable comfortably. * Painfully slow (that could be fixable by better hosting) * Weirdly styled „Create Thread“ Button. * Weird spacing in general. As mentioned before, there is missing space to the screen border, but in other places, there is disturbingly much space, e.g. between the different forum „groups“ (new users, ecosystem etc.) * icons next to some links (e.g. permalink, reply) are broken * you mentioned that is intended as readonly. a readonly Forum Is basically useless imo. Also if it is readonly, why are there reply and create thread buttons? I‘m sure, I could mention a lot more, but these are the major points I immediately noticed. I‘m looking at it in an iPhone 8. That said, I don‘t really see what is wrong with the mobile version of the regular forum. Sure, there are some things which could be improved a bit, but in contrast to your suggestion it at least gets spacing and fontsize right. What are your concerns with the regular forum on mobile devices?
Re: Redis client hunt-redis RC1 released
Am 27.07.19 um 16:00 schrieb zoujiaqing: > On Saturday, 27 July 2019 at 09:07:13 UTC, Eugene Wissner wrote: >> On Saturday, 27 July 2019 at 06:08:34 UTC, zoujiaqing wrote: >>> On Thursday, 25 July 2019 at 20:19:53 UTC, ag0aep6g wrote: [...] >>> >>> Thanks. >>> But we use other language to implementation. >> >> It doesn't matter. It is all about intellectual property, algorithms >> and the structure. The language is the least important factor. > > 这不是问题，问题是我们想保留他的版权，我愿意告诉大家我们是翻译的jedis， > 因为我想大家更了解一个项目。 However, you do not seem to keep his copy right. In the whole project, there is not a single mention of Jedis or its author "Jonathan Leibiusky". The MIT license, under which Jedis is licensed, explicitly requires you to keep the original copyright notice: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." By not by not keeping the notice, you are actually performing copy right infringement. I think it is very honorable of you to contribute to the D community by porting a lot of stuff and thereby improving the ecosystem. I thank you for that. But you can only do this within the boundaries that the licenses of the software you port allows. I mean come on, it's not that difficult, right? Simply keep the original copy right notice, that is all that is reuired... For the sake of your own company, please take more care and properly address these licensing issues. Otherwise people might actually try to sue you for it... On a side note: I'm not sure if this has ever been made official, but it is common practice to write in English on this mailing list. Please stick to that. It is simply the best common ground that we have and it also makes a lot of sense: Would you want to have to put almost every message here into google translator because they are in German, Polish, Swedish, Spanish, etc.? Thanks :)
Re: Beta 2.087.0
Am 17.06.19 um 00:47 schrieb Martin Nowak: > Glad to announce the first beta for the 2.087.0 release, ♥ to the 66 > contributors. > > http://dlang.org/download.html#dmd_beta > http://dlang.org/changelog/2.087.0.html > > As usual please report any bugs at > https://issues.dlang.org > > -Martin > Thanks to evrybody who helped making this possible. This is a really exciting release. Personally, I'm very much looking forward to - "Local templates can now receive local symbols." - "Template alias parameters now match basic types as a conversion." - "Phobos is now compiled with -preview=dip1000" The first 2 fix huge annoyances which I have run into several times already. And phobos being compile with DIP1000 is a major milestone towards a safer D. Thanks again to everybody involved!
Re: Static Webpages of Forum Threads
Am 13.05.19 um 09:45 schrieb Walter Bright: > A request for this was made at DConf (I think by Nicholas) and we're > already doing it: > > https://www.digitalmars.com/NewsGroup.html > > Just click on the items under the "Archive" column. It's all there, back > to the first post. It's organized as one page per thread. > > The web pages are created by this rather hackish and wretched program: > > https://github.com/DigitalMars/ngArchiver > > I run it manually whenever I think of it, which is erratically, because > I've tried repeatedly to set up a cron job to do it, but somehow it > never runs. Bah. Thanks for the links, Walter. I still think that we should make them easily available from either the website or the forums. I believe Mike already mentioned that during the AGM. Is there anybody already working on that? Is there any way in which we can help you in automating the process of archiving? Your time seems to be much too valuable to be taken up by things like this...
Re: DConf 2019 Day 2 Livestream
On Thursday, 9 May 2019 at 07:45:41 UTC, Andrei Alexandrescu wrote: Just checked, it works: https://youtu.be/Vj6jNAlv03o Great to know! Thanks for fixing this for today!
Re: DConf 2019 Livestream
On Wednesday, 8 May 2019 at 08:33:52 UTC, Laeeth Isharc wrote: On Wednesday, 8 May 2019 at 08:04:08 UTC, Mike Parker wrote: On Wednesday, 8 May 2019 at 08:00:15 UTC, Andrej Mitrovic wrote: On Wednesday, 8 May 2019 at 07:57:40 UTC, Mike Parker wrote: The venue uses WebEx for livestreaming. All the information is available in this PDF: https://drive.google.com/open?id=1yekllbfOmxHqJNuuWIVeP9vNeROmfp1I "When joining: Please connect using Internet Explorer, not Google Chrome or another web browser." You guys can't be serious, you're using WebEx? Not us. The venue. Sorry about that. It was supposed to be streaming to YouTube, but it fell through the cracks. We are looking into it now. Laeeth Any news on that? I've received feedback from several people already that they are not able to to watch the stream because of google docs / webex (e.g. at the workplace of a friend of mine, these things are simply not permitted)...
Re: DIP 1017--Add Bottom Type--Formal Assessment
Am 30.01.19 um 15:05 schrieb Mike Parker: > Given the nature of the feedback in both review rounds this DIP has gone > through, Walter has decided to reject his own DIP. He still believes > there is a benefit to adding a bottom type to the language, but this > proposal is not the way to go about it. He hopes to revisit the issue in > the future. > > Thanks to everyone who provided feedback. I believe this is a good decision and the proper way forward. I also think that there is indeed a benefit in adding a bootom type to the language so I'd be happy to help with a new attempt as much my limited knowledge of type theroy permits.
Re: New Fundraiser: D Forums Server
Am 29.01.19 um 01:58 schrieb Mike Parker: > On Monday, 28 January 2019 at 20:00:53 UTC, Johannes Loher wrote: > >> I would like to donate for this, but flipcause does not seem to work >> for me at all: >> >> I tried to make the donation several times, but after entering all the >> details and payment details and clicking on "Finish", I either got a >> message saying something like "Sorry, your session expired. >> Redirecting you to 'Home'" or i was simply redirected to 'Home' >> without any message. >> >> Considering the other comments in this thread, it seems like I am not >> the only one who has issues like that. Maybe you should get in touch >> with flipcause in order to try to resolve these issues. > > > Ah, so it's happening at payment time. No wonder I couldn't reproduce > it. I'll look into it. Did you have the same error with the Flipcause > order form for your DConf registration before you went to PayPal? After having problems with the donation, I did not try Flipcause for pyaing for the DConf ticket. I directly went for PayPal instead, so I can't really comment on that.
Re: Hunt framework 2.0.0 released
Am 29.01.19 um 11:00 schrieb zoujiaqing: > [...] It's really great to see your continued efforts. Keep up the good work!
Re: GtkD Blog Now Up and Running
Am 29.01.19 um 22:47 schrieb Ron Tarrant: > And this goes in the same folder as the code file. And then... what? I > type: dub? The code file should be in a subfolder called "source". This is customizable, but this is the default. So the folder structure should look something like this: ├── dub.sdl └── source └── app.d By default, if there is a source file called "app.d" or "main.d", dub will assume that your application is an exectuable and build it accordingly (if targetType is not explicitly set to something else in your dub.json or dub.sdl file). If you don't want to have a source file named like that, you will need to tell dub explicitly to build an executable (if that is what you want) by adding the line ``` targetType "executable" ``` to your dub.sdl. The easiest way to actually see how the basic folder structure should look like is to simply call `dub init` in an empty folder. This will interactively set up a basic project in that directory. During the interactive process, you can set some properties for your project, e.g. if you want to use a dub.sdl or dub.json file, add dependencies, choose the name of the project etc. It really works in a straightforward way. To actually build the project, simply run `dub build` from the project's root folder. this will create a binary in the projects root folder with the name specified in the dub.sdl file. You can also run the project directly after compiling by running `dub run` (or simply just `dub`, which does the same thing) from the projects root folder. All of this assumes that dub is actually installed and available on your PATH.
Re: New Fundraiser: D Forums Server
Am 25.01.19 um 18:01 schrieb Mike Parker: > One of the options we were considering for a new fundraising campaign > was raising money for Vladimir's continuing efforts on the forums. He's > been maintaining them, and covering the server, without any compensation > since the beginning. The recent thread about forum outages pushed all > other considerations aside: it's time to support Vladimir. > > However, being the awesome guy he is, he insisted we only help out in > covering the server costs. So that's what we're setting out to do with > the new campaign. > > He has a list of options to improve the forum performance, one of which > he recently implemented (moving the database to a new partition). A new > server with more resources and an SSD should show an even bigger win. > Then he can take the time to do his other optimizations at his leisure. > > We're asking the community to contribute $2000 to cover the new server > for one year, with a little bit extra for any incidentals that arise. > This is a campaign we want to make an annual event so that Vladimir > never has to pay out of pocket for the server again. > > The campaign is available from the menu on the Donate page, but you can > go straight to it here: > > https://www.flipcause.com/secure/cause_pdetails/NDkzNjc= > > And if you also want to support Vladimir in the broader work he does on > all the open source software he puts out, he has a Patreon page that is > looking pretty empty right now: > > https://www.patreon.com/cybershadow > > Next month, I'll be launching Round 2 of the PR Manager campaign for > another three months of PR trimming goodness. We pulled in $3,124 from > Round 1, so the extra $124 will be used for a head start on Round 2. > > I'll put all of this in a blog post in the next few days, along with > some other info. I would like to donate for this, but flipcause does not seem to work for me at all: I tried to make the donation several times, but after entering all the details and payment details and clicking on "Finish", I either got a message saying something like "Sorry, your session expired. Redirecting you to 'Home'" or i was simply redirected to 'Home' without any message. Considering the other comments in this thread, it seems like I am not the only one who has issues like that. Maybe you should get in touch with flipcause in order to try to resolve these issues.
Re: DConf 2019 Early-Bird Registration Now Open
Am 28.01.19 um 15:07 schrieb Mike Parker: > I've published a post on the blog with updates about DConf 2019 > registrations, the invited keynote speaker, the Symmetry Autumn of Code > finalist, and the previously announced fundraiser for a new forum server. > > Early-bird registrations are $340 again this year and will remain > available until March 17, 24:00 AOE. This time around, we have to factor > in a 20% VAT for all registrations, so the actual price will be $408. > > Read the blog post for more info: > > https://dlang.org/blog/2019/01/28/dconf-2019-early-bird-registration-opens-and-other-news/ > > > I've also shared it to /r/programming: > > https://www.reddit.com/r/programming/comments/aknnxo/dconf_2019_earlybird_registration_now_open/ > Great news! I just registered and after the registration was completed, the website said "Thanks! Your request was processed successfully. We look forward to seeing you in Munich!". This should probably be updated to "London".
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
Am 17.01.19 um 23:20 schrieb Stefan Koch: > For 2 years I have pondered this problem, and I did come up with a > solution. > It's actually not that hard to have CTFE interact with type-tuples. > You can pass them as function parameters, or return them if you wish. > Of course a type-tuple returning ctfe function, is compile-time only. > This solved one more problem that ctfe has: > helper functions required for ctfe can only be omitted from the binary, > if you use the trick of putting them into a module which is the import > path but never explicitly given on the command line. > newCTFE has the facility to be extended for this, and implementing > type-functions is at least on my personal roadmap. > > At Dconf 2018 Andrei and Walter said, a DIP which is substantiated > enough might make it. > However due to lack of time, (and productivity-reducing internal > changes) it will take some time until I can get started on this. > > Also I plan for newCTFE to be in shape before I add type-manipulation > abilities. > > Cheers, > > Stefan > > P.S. There is one caveat: because of how type-functions work they > cannot, you cannot create a non-anonymous symbol inside a type-function, > because there is no way to infer a mangle. > You can however create an anonymous symbol and alias it inside a > template body, which gives it a mangle and it can behave like a regular > symbol. > > This is one of the most exciting things i have read in recent times!
Re: hunt library 1.0.0 released!
On Tuesday, 15 January 2019 at 14:58:01 UTC, Brian wrote: [...] Thanks for the great work! I had already been planning on playing around with hunt for a bit. What has been holding me back until now is the fact that part of the documentation still is only available in Chinese, which I unfortunately am not able to read. Are there any plans on translating the remaining parts of the documentation?
Re: DCD, D-Scanner and DFMT : new year edition
On Monday, 31 December 2018 at 12:25:08 UTC, WebFreak001 wrote: IMPORTANT: if you have downloaded the v0.10.2 DCD binaries before 2018-12-31T12:30:00Z, please delete those and redownload because the binaries were broken; they reported version v0.1 instead of v0.10.2 and this could mess with your IDE if you use one for DCD! Unfortunately this also applies to the precompiled binaries used when installing DCD on OS X via HomeBrew: Currently when running `brew install dcd`, you will get binaries which report version v0.1. This can be worked around by building DCD from source: `brew install --build-from-source dcd`. Does anybody know who is maintaining the DCD HomeBrew formula? That person should probably trigger a rebuild of the precompiled binaries.
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 16:57:10 UTC, Joakim wrote:
As I recall, you largely agreed with me:
That is true, and I still do regarding many points (though not
all). But this is not the point I wanted to make. I don't
consider my opinion that important. I simply wanted to point out
why the D team probably decided against your suggestion.
I'm not trying to discuss it with you or the community. I'm
asking the D team who're making this decision why it's being
made, despite all the reasoning in that thread, and reiterating
that it's a bad move. I suspect they're not thinking this
through, but they can speak for themselves.
I do understand your wish for them to explain the reasons for
their decision. And in my opinion the reasoning so far has indeed
been a bit poor ("your arguments were not convincing"). Maybe The
D team can give some more details about why they value the
traditional conference format more than your suggestion.
By the way, if you are still interested in implementing your
suggested conference format (I'm getting the feeling that you are
getting a bit frustrated :(), it might be more promising to not
replace DConf with it, but instead make it an additional event
(maybe in autumn). If you are interested in discussing more ideas
about this, I'd gladly participate.
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 15:11:10 UTC, Joakim wrote: On Saturday, 22 December 2018 at 14:26:29 UTC, Atila Neves wrote: On Saturday, 22 December 2018 at 13:46:39 UTC, Joakim wrote: On Saturday, 22 December 2018 at 12:18:25 UTC, Mike Parker wrote: The egregious waste of time and resources of this DConf format strongly signals that D is not a serious effort to build a used language, It's the same signal being emitted by all of these "failures" as well: Go: https://twitter.com/dgryski/status/1034939523736600576 Rust: https://rustconf.com/ Clojure: https://clojure.org/community/events Haskell: https://wiki.haskell.org/Conferences C++: https://cppcon.org/ https://cpponsea.uk/ http://cppnow.org/ https://meetingcpp.com/ etc. To me it's obvious from that short list that took me less than 5min to come up with that conferences aren't a dying format. I gave up on C++ conferences after the 4th link, there are just too many. The fact that a short list of conferences still exists at all somehow makes it "obvious" to you that they're not dying? Did you even look at my second link that actually tallies some numbers for a particular tech market? It is true that a few conferences are still being done, even my second link above never said they're _all_ gone. But simply saying some are still following this outdated ritual is not an argument for continuing it, nor does it contradict anything I said about the number of conferences going down. If you don't like conferences you don't have to go. This has nothing do me: I've never been to DConf or most any other tech conference and likely never will. This is about whether the D team should be wasting time with this dying format. I for one am excited about being in London in May. Please don't sour it for other who think/feel like I do. Heh, so that's your two big arguments for why the conference format should continue: other languages are doing it and you want to visit London in May? You are exemplifying the mindset that I'm pointing out with these flimsy arguments, everything that is wrong with D and DConf. We talked a great deal about this in your thread (https://forum.dlang.org/thread/ogrdeyojqzosvjnth...@forum.dlang.org). I believe the main takeaway from that discussion was that many of us disagree with your opinion to at least some degree. I know that you are very convinced about your idea of how we should do DConf being superior and that is OK. Maybe you are just ahead of time in this case, I don't know. But it is also a fact that many people stated that they actually enjoy the current DConf format very much and believe it is not a waste of time and money at all. So to me, it is no surprise at all that it was decided to to stick with the current format. Also I don't think this is the right place for this discussion. If you feel that we indeed need to rediscuss this issue, I think it should be done in a separate thread.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 16:39:47 UTC, Mike Parker wrote: Walter and Andrei take the position that this is incorrect the wrong way to view a bool. Unfortunately you did not include their justification for this position (if any). To me it would be interesting to know about the reasoning that is behind this position.
Re: Copy Constructor DIP and implementation
On Monday, 17 September 2018 at 19:10:27 UTC, Jonathan M Davis wrote: On Monday, September 17, 2018 8:27:16 AM MDT Meta via Digitalmars-d-announce wrote: [...] Honestly, I don't think that using a pragma instead of an attribute fixes much, and it goes against the idea of what pragmas are supposed to be for in that pragmas are supposed to be compiler-specific, not really part of the language. [...] I totally agree with this.
Re: I have a plan.. I really DO
Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
>
> Add a 10-liner "Hello World" web server example on the main page and
> that's it.
There already is one in the examples:
#!/usr/bin/env dub
/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
void main()
{
import vibe.d;
listenHTTP(":8080", (req, res) {
res.writeBody("Hello, World: " ~ req.path);
});
runApplication();
}
Re: unit-threaded v0.7.45 - now with more fluency
On Monday, 7 May 2018 at 09:19:31 UTC, Dechcaudron wrote: On Saturday, 5 May 2018 at 15:51:11 UTC, Johannes Loher wrote: Personally, I don't like that kind of "abuse" of operators at all. I think it looks really unusual and it kind of breaks your "flow" when reading the code. Additionally, people, who don't know about the special behaviour the operators have in this case, might get really confused. I would much prefer it, if you used a more common fluent style (like 1.0.should.be.approximately(1.0001);). Anyways, thanks for working on this awesome project! I think I'm siding with Johannes here. Much as the overloads look nice, I don't really see the advantage over `shouldEqual`. Also, what's with `all.these.identifiers`? Any particular reason why you are more fond of them rather than of good ol' pascalCase? Fluent assertions have one major advantage over using pascalCase assertions: There is no ambiuguity about the order of arguments. When using e.g. assertEquals, how do you know wheter is is supposed to be assertEquals(actual, expected), or assertEquals(expected, actual)? The first one is the only one that makes sense wirh UFCS, but it is not clear directly from the API. On top of that, some popular Frameworks (I‘m looking at you, JUnit...) do it exactly the other way round. With fluent assertions, you don‘t have this Problem, it is much more clear that it should be actual.should.equal(expected) and not expected.should.equal(actual), because it fits naturally in the chain of ufcs calls.
Re: unit-threaded v0.7.45 - now with more fluency
On Saturday, 5 May 2018 at 13:28:41 UTC, Atila Neves wrote: For those not in the know, unit-threaded is an advanced testing library for D that runs tests in threads by default. It has a lot of features: http://code.dlang.org/packages/unit-threaded New: * Bug fixes * Better integration testing * unitThreadedLight mode also runs tests in threads * More DDoc documentation (peer pressure from Adam's site) * Sorta kinda fluent-like asserts On the new asserts (should and should.be are interchangeable): 1.should == 1 1.should.not == 2 1.should.be in [1, 2, 3] 4.should.not.be in [1, 2, 3] More controversially (due to a lack of available operators to overload): // same as .shouldApproxEqual 1.0.should ~ 1.0001; 1.0.should.not ~ 2.0; // same as .shouldBeSameSetAs [1, 2, 3].should ~ [3, 2, 1]; [1, 2, 3].should.not ~ [1, 2, 2]; I also considered adding `.should ~=`. I think it even reads better, but apparently some people don't. Let me know? The operator overloads are completely optional. Atila Personally, I don't like that kind of "abuse" of operators at all. I think it looks really unusual and it kind of breaks your "flow" when reading the code. Additionally, people, who don't know about the special behaviour the operators have in this case, might get really confused. I would much prefer it, if you used a more common fluent style (like 1.0.should.be.approximately(1.0001);). Anyways, thanks for working on this awesome project!
Re: mysql-native v2.2.2: Minor updates
On Friday, 4 May 2018 at 02:59:10 UTC, Nick Sabalausky (Abscissa) wrote: An all-D MySQL/MariaDB client library: https://github.com/mysql-d/mysql-native == Tagged release, 'v2.2.2'. Sorry, no "zero date" fix just yet, but I think we're getting close (#65). In this version: - Fixed #177: Update unit-threaded, and don't lock mysql-native to a specific version of unit-threaded. (@ghost91) - Fixed #178, #179: Fix deprecation message in DMD v2.080.0: Replace enforceEx by enforce (@ghost91) Full changelog: https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md Thanks for merging and releasing this so quickly, it helps me a lot!
Re: code-d 0.17.0 + serve-d 0.1.2
Am 10.04.2018 um 14:27 schrieb WebFreak001: > On Monday, 9 April 2018 at 21:45:57 UTC, Johannes Loher wrote: >> Am 04.04.2018 um 20:34 schrieb greatsam4sure: >>> [...] >> I just tried to get this to work, too, but I was not able to get it to >> work correctly. It seems that running dub fails somehow: >> >> [...] > > hm before it would have completely crashed workspace-d/serve-d to a > point where nothing would work, now you basically only get stdlib and a > guess of further import paths. Can you make a minimal test case where > this happens? It is probably due to some dub.json settings. But as I use > dub as a library it should work the same as just calling `dub build` You are right, it indeed seems to be a dub problem. Running `dub build` gives me "Could not resolv configuration for package vibe-d". The strange thing is, it workls correctly on Linux / OS X with the same dub/dmd versions... I tried it with another project with a more simple dub.json and it works fine out of the box. Very nice job!
Re: code-d 0.17.0 + serve-d 0.1.2
Am 04.04.2018 um 20:34 schrieb greatsam4sure:
> On Tuesday, 3 April 2018 at 23:02:42 UTC, WebFreak001 wrote:
>> new code-d (D extension for vscode) and serve-d (Language Server
>> Protocol server for it) release
>>
>> See the CHANGELOG in vscode, or on
>> https://github.com/Pure-D/code-d/blob/master/CHANGELOG.md
>>
>> Today massive improvements towards windows installation have been made
>> and it should be a lot more painless now.
>>
>> Big thanks to Mike Franklin for helping me debug the windows
>> installation, making this available very quickly and to p0nce for
>> compiling the windows release because my VM wasn't working for this
>> anymore.
>>
>> As now the extension is in stable and no longer requires the beta
>> branch a lot of issues have been fixed and old ones which are probably
>> no longer valid closed. If you find any issue please create a new one
>> or reopen if you have an old issue.
>>
>> Here are some of my personal highlights:
>>
>> https://wfr.moe/fmEfTw.png - documentation inside autocompletion
>> https://wfr.moe/fmq4Da.png - import timing
>> https://wfr.moe/fmqCNt.png https://wfr.moe/fmqh3H.png - simple
>> implement interface action
>> n/a - everything compiles and installs without reloads or cumbersome
>> dialogs, just install from marketplace, wait for the installation
>> which should be very quick, especially with prebuilt binaries and
>> start coding without any distractions!
>> https://wfr.moe/fmzcS8.png - dub dependency browser
>> n/a - automatic insertion of a module statement on rename and file
>> creation
>>
>> code-d beta and code-d are therefore on the same release right now,
>> but code-d beta will still be continuing to get features early.
>>
>> eager to hear your feedback, though gonna go to sleep for now.
>>
>> Planned for next release is internationalizing the final few messages
>> which are in the code-d part, all serve-d parts have already been
>> translated to German and Japanese and are determined by vscode language.
>
> Thanks a lot! It works fine for me now in windows 10
>
> steps
>
> * I delete C:\Users\Greatsam\AppData\Roaming\code-d folder
> **Restart visual studio code at least twice with internet connect on to
> enable code-d serve-d to download DCD
> It shows dcd successfully installed with many deprecation message
> ***I used sdl in my dub project with the flags: dflags
> "-transition=intpromote" platform="dmd"
>
> I don't know if this have any effect. This help me to avoid some errors
> from the compilers
>
>
>
> Thanks all who make this a success on windows. It is a great achievement
> in moving D forward.
I just tried to get this to work, too, but I was not able to get it to
work correctly. It seems that running dub fails somehow:
2018-04-09T23:40:19.281:source\app.d:main:196 Setting language to de
2018-04-09T23:40:19.281:source\app.d:main:205 Features fulfilled
2018-04-09T23:40:19.283:source\app.d:main:211 Started reading from stdin
2018-04-09T23:40:19.283:source\app.d:main:215 RPC started
2018-04-09T23:40:19.294:source\app.d:main:226 Has Message
2018-04-09T23:40:19.294:source\app.d:main:228 Message: RequestMessage(0,
"initialize",
{"capabilities":{"textDocument":{"codeAction":{"dynamicRegistration":true},"codeLens":{"dynamicRegistration":true},"completion":{"completionItem":{"commitCharactersSupport":true,"snippetSupport":true},"dynamicRegistration":true},"definition":{"dynamicRegistration":true},"documentHighlight":{"dynamicRegistration":true},"documentLink":{"dynamicRegistration":true},"documentSymbol":{"dynamicRegistration":true},"formatting":{"dynamicRegistration":true},"hover":{"dynamicRegistration":true},"onTypeFormatting":{"dynamicRegistration":true},"rangeFormatting":{"dynamicRegistration":true},"references":{"dynamicRegistration":true},"rename":{"dynamicRegistration":true},"signatureHelp":{"dynamicRegistration":true},"synchronization":{"didSave":true,"dynamicRegistration":true,"willSave":true,"willSaveWaitUntil":true}},"workspace":{"applyEdit":true,"didChangeConfiguration":{"dynamicRegistration":true},"didChangeWatchedFiles":{"dynamicRegistration":true},"executeCommand":{"dynamicRegistration":true},"symbol":{"dynamicRegistration":true}}},"processId":7464,"rootPath":"c:\\Users\\Johannes
Loher\\Development\\fsical-management","rootUri":"file:\/\/\/c%3A\/Users\/Johannes%20Loher\/Development\/fsical-management","trace":"off"})
2018-04-09T23:40:19.306:source\app.d:__lambda10:234 Processing as request
2018-04-09T23:40:19.306:source\app.d:processRequest:50 Initializing
2018-04-09T23:40:19.306:source\served\extension.d:initialize:143
Initializing serve-d for c:\Users\Johannes
Loher\Development\fsical-management
2018-04-09T23:40:19.306:source\served\extension.d:initialize:156
Starting dub...
2018-04-09T23:42:07.144:source\served\extension.d:safe:52
object.Exception@..\..\AppData\Local\dub\packages\dub-1.8.0\dub\source\dub\project.d(600):
Could not resolve configuration for package fsical-management
0x015C51EF
0x015C4FA2
Re: State of D 2018 Survey
Am 28.02.2018 um 14:41 schrieb Mike Parker: > About a month ago, Sebastian Wilzbach sent an email out to a few of the > core D folks asking for feedback on a survey he had put together. He > thought it would be useful for the Foundation to use in order to make > decisions about where to expend development efforts. Eventually Andrei > gave his stamp of approval, the survey questions were tweaked, and then > it was ready to roll. > > Of course I would love for you to read my blog post announcing it, but > if you want to skip the prose and go straight to the good stuff, here's > the survey link: > > https://seb134.typeform.com/to/H1GTak > > The blog: > https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/ > > Reddit: > https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/ > Is there a way to directly view the results without taking the survey again?
Re: LDC 1.8.0
On Monday, 5 March 2018 at 12:14:52 UTC, kinke wrote: On Monday, 5 March 2018 at 07:45:04 UTC, Johannes Loher wrote: Will there also be a armhf Release? Yep; it'll most likely be up this evening (CET). I just saw that it is up now, thats awesome, thank you very much for your efforts!
Re: LDC 1.8.0
On Sunday, 4 March 2018 at 22:37:21 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce LDC 1.8. The highlights of this version in a nutshell: * Based on D 2.078.3. * New switch `-link-defaultlib-shared` to link against shared druntime/Phobos. * Plugins support, compatible with existing Clang plugins. * Support for LLVM IR-based PGO as alternative to existing (AST-based) PGO. * Basic support for LLVM XRay instrumentation. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.8.0 Thanks to all contributors! Thank you very much for your efforts! Will there also be a armhf Release?
Re: dxml 0.2.0 released
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis wrote: dxml 0.2.0 has now been released. [...] Thank you very much for your efforts, I really appreciate it, as I have been looking for a decent xml library for quite some time. Whethr or not this is a candidate for inclusion into phobos is certainly up for debate, but as you already mentioned several times, this thread is hardly the right place for that. So instead I'd like to emphasize how much I appreciate you working on this and I am sure I am not the only one. This absence of a usable high quality xml library is/was a big problem for d in my opinion and it is great to see that this is finally being worked on :)
Re: LDC 1.7.0
On Sunday, 21 January 2018 at 12:00:32 UTC, kinke wrote: [...] Please note that building a release package isn't identical to just build from source; there are subtle diffs and additional steps to be undertaken. I hope we get an ARM CI box soon and can automate the armhf package generation as well. In the meantime, I started an LLVM 5.0.1 build in my qemu emulator 12 hours ago; one third has been compiled so far, so you may expect the armhf package to be available tomorrow or the day after that. That is great news to me, thank you very much for your effort!
Re: LDC 1.7.0
On Saturday, 6 January 2018 at 01:19:14 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce LDC 1.7. The highlights of this version in a nutshell: * Based on D 2.077.1. * Catching C++ exceptions supported on Linux and Windows. * LLVM for prebuilt packages upgraded to v5.0.1. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.7.0 Thanks to all contributors! Hey, thanks for your great work! Would it be possible to add a armhf build to the release? If you can not do it yourself, could you please point me to some resources where I can find out about how to create such a release build myself? Thank you!
dub zsh completion
I created a zsh completion script for dub. It is not perfect, but it does many things well already. You can find it here: https://github.com/ghost91-/dub-zsh-completion. I have seen that bash and fish completion scripts are included in the dub github repo. If people are interested in this, I could create a pull request to also add the zsh completion script. I hope this helps some people :)
Re: Second release candidate 0.8.1-rc.2
On Saturday, 12 August 2017 at 12:43:14 UTC, Sönke Ludwig wrote: v0.8.1-rc.2 now supports setting a version "VibeUseOpenSSL11" in the package recipe to compile against the OpenSSL 1.1.0 API on systems that don't have 1.0.1 anymore. This is great, Thank you!
