Re: More fun with autodecoding
On 8/8/2018 2:01 PM, Steven Schveighoffer wrote: Here's where I'm struggling -- because a string provides indexing, slicing, length, etc. but Phobos ignores that. I can't make a new type that does the same thing. Not only that, but I'm finding the specializations of algorithms only work on the type "string", and nothing else. One of the worst things about autodecoding is it is special, it *only* steps in for strings. Fortunately, however, that specialness enabled us to save things with byCodePoint and byCodeUnit.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
I would like to point out that C++ does this with attributes instead[0]. If this was an attribute instead (like `@noreturn`), it would simplify interfacing with C++. It would also avoid the breaking change. [0]: eel.is/c++draft/DCL.attral.noreturn
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": https://github.com/dlang/DIPs/blob/8274b0f600075e4553b41c31f4b77be2d917bb40/DIPs/DIP1017.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 24, or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the Final Review and Formal Assessment by the language maintainers. Please familiarize yourself with the documentation for the Community Review before participating. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review Thanks in advance to all who participate. All of my points made in the draft review still stand, i.e. that this should be an attribute or pragma. Note that this feature is already supported by LDC as an attribute. The benefit that this DIP provides are: "documentation" (rationale point 2) and optimisation (rationale points 1 & 4). The claim made by Point 3 is dubious and unsubstantiated at best. Rationale point 2 comes in the form of rendered documentation and the source code. Rendered documentation, regardless of the form used should be able to convey that a function does not return. Reading the source it should be easily determinable that a function does not return, use of an suitably named attribute or pragma (i.e. pragma (noreturn) or @noreturn) makes it immediately obvious. Returning a type named "Tbottom" absolutely does not, "never_t" as suggested in the draft review is better but is not strictly better than an attribute or pragma but, IMO is still worse. The optimisation benefits provided by dead code elimination may be significant, but again this information is equally well conveyed to the compiler by an attribute or pragma. The hardcoded list of symbols, will provide the vast majority of those gains so extending this to user code will provide very marginal benefit, especially with a aggressively optimising compiler (e.g. LDC, GDC) that will propagate that information anyway. The downsides of this DIP are the breaking changes and unneeded complexity. Generic code that checks `is(T==void)` or `is(ReturnType!F == void)` will break, as will code that uses the return value of a function that happens to be inferred to return no type, use of the ternary ?: will now no longer always be the common type of the second and third operands. The complexity will manifest itself as making error messages more confusing, making the learning curve steeper than it needs to be and the implementation. The DIP makes the claim that: * "[@noreturn] has the awkward result of a function specifying it has a return type T, but never returns that type". When it is deliberate (such as annotating a fatal error function) the is almost exclusively `void` (I know of no examples to the contrary). * "[With @noreturn] other potential uses of a bottom type will not be expressible". What other? Documentation and optimisation definitely can be, the are in LDC since a long time, there are no other substantiated benefits listed in the DIP. If this DIP were to make the claim that type inference and propagation would catch bugs, then perhaps it would make more sense than an attribute or pragma, but it would have to be convincing that resulting code breakage would be worth it.
DIP 1017--Add Bottom Type--Community Review Round 1
This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": https://github.com/dlang/DIPs/blob/8274b0f600075e4553b41c31f4b77be2d917bb40/DIPs/DIP1017.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 24, or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the Final Review and Formal Assessment by the language maintainers. Please familiarize yourself with the documentation for the Community Review before participating. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review Thanks in advance to all who participate.
Re: More fun with autodecoding
On 8/8/18 4:13 PM, Walter Bright wrote: On 8/6/2018 6:57 AM, Steven Schveighoffer wrote: But I'm not sure if the performance is going to be the same, since now it will likely FORCE autodecoding on the algorithms that have specialized versions to AVOID autodecoding (I think). Autodecoding is expensive which is why the algorithms defeat it. Nearly none actually need it. You can get decoding if needed by using .byDchar or .by!dchar (forgot which it was). There is byCodePoint and byCodeUnit, whereas byCodePoint forces auto decoding. The problem is, I want to use this wrapper just like it was a string in all respects (including the performance gains had by ignoring auto-decoding). Not trying to give too much away about the library I'm writing, but the problem I'm trying to solve is parsing out tokens from a buffer. I want to delineate the whole, as well as the parts, but it's difficult to get back to the original buffer once you split and slice up the buffer using phobos functions. Consider that you are searching for something in a buffer. Phobos provides all you need to narrow down your range to the thing you are looking for. But it doesn't give you a way to figure out where you are in the whole buffer. Up till now, I've done it by weird length math, but it gets tiring (see for instance: https://github.com/schveiguy/fastaq/blob/master/source/fasta/fasta.d#L125). I just want to know where the darned thing I've narrowed down is in the original range! So this wrapper I thought would be a way to use things like you always do, but at any point, you just extract a piece of information (a buffer reference) that shows where it is in the original buffer. It's quite easy to do that part, the problem is getting it to be a drop-in replacement for the original type. Here's where I'm struggling -- because a string provides indexing, slicing, length, etc. but Phobos ignores that. I can't make a new type that does the same thing. Not only that, but I'm finding the specializations of algorithms only work on the type "string", and nothing else. I'll try using byCodeUnit and see how it fares. -Steve
Re: Give DLS a try
On Wednesday, 8 August 2018 at 07:57:49 UTC, Laurent Tréguier wrote: On Wednesday, 8 August 2018 at 07:25:57 UTC, Tab wrote: I find DLS to be very stable Ironically, as the developer of DLS, I'm not sure if it should be considered as stable. I've had quite a number of crashes myself, sometimes even seemingly right at startup :/ Although the latest version does fix a crash that was happening during garbage collection, so now it might be more stable. (Fun fact: since garbage collection always happens at least when the program exits, it was technically crashing 100% of the time before) I created a long list of features I'd like to see in D IDE. Hopefully some of them is being worked on. I have some things to fix first, but they will be worked on at some point; finding all references to a symbol especially is something that interests me. Code-d overcomplicates things I find though. I can't even build it, there's so many dependencies attached to it that it isn't worth looking through to even find which one is causing the build issue. Let alone there's a restriction that it can only build 32-bit. Also can't be built with LDC2 cause of the dependencies is trying to build a 64-bit binary even though the arch is set to 32-bit. It's a mess. DLS took no time at all to build, nice and simple. Just one thing is installing the extension didn't create that symbolic link for me. And the plugin just silently passes an empty path if it can't find DLS. https://github.com/LaurentTreguier/vscode-dls/blob/master/src/extension.ts#L20
Re: More fun with autodecoding
On 8/6/2018 6:57 AM, Steven Schveighoffer wrote: But I'm not sure if the performance is going to be the same, since now it will likely FORCE autodecoding on the algorithms that have specialized versions to AVOID autodecoding (I think). Autodecoding is expensive which is why the algorithms defeat it. Nearly none actually need it. You can get decoding if needed by using .byDchar or .by!dchar (forgot which it was).
Re: Automate the collection and publishing of data for monitoring D's progress as a software development project
On Wednesday, 8 August 2018 at 07:24:26 UTC, Joakim wrote: On Tuesday, 7 August 2018 at 17:47:45 UTC, Venu Vardhan Reddy Tekula wrote: [...] Yes, everything _could_ be done in Python or other languages, but SAoC is being run by the D foundation and a company using D, which is why the first question in the FAQ says, [...] Okay, D is actually pretty cool. I want to experiment with new things too. Though it is a bit challenging, but I am interested in this project. [...] [...] Sure, thank you. :) Venu
Re: Automate the collection and publishing of data for monitoring D's progress as a software development project
On Tuesday, 7 August 2018 at 23:59:55 UTC, Mike Franklin wrote: On Tuesday, 7 August 2018 at 17:47:45 UTC, Venu Vardhan Reddy Tekula wrote: [...] Thanks for you interest and welcome to the D community. Your skills will be valuable here if are willing to volunteer them to the D effort. It would be my pleasure to work with the D community. I am a member of the student club here in my university, called FOSS@Amrita (https://amfoss.in/) which actually encourages students to contribute to Open Source projects. I have been into Open Source for a considerable amount of time. [...] While I'm not one of the people who will be judging the merits of such a project, I believe there is a high preference for at least the backend to be written in D. There has been some progress with WebAssembly in D (https://forum.dlang.org/post/dzqvahqyohmjcustv...@forum.dlang.org), but it's highly experimental right now, so it might be best to write the frontend in the typical HTML/CSS/Javascript, or some framework built of those technologies like Angular, Vue, etc... Sure, I will move on with these things for the frontend. [...] My recommendations for getting started: * Learn D. Start here (http://ddili.org/ders/d.en/index.html), then look here (https://wiki.dlang.org/Books) Ask questions on the Learn forum, IRC, or even StackOverflow. * Lean web programming in D. Start with https://www.amazon.com/gp/product/178528889X/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=178528889X&linkCode=as2&tag=dlang-20&linkId=DR64TRTOQS2GVORZ Again, ask questions on the Learn forum , IRC, or even StackOverflow. Thank you for the suggestions. I started learning D, btw. :D If you have questions about the project, please ask away. Specific questions are likely to get answers quickly; broad questions less so. The description of the project is intentionally left vague in order to not constrain the participant's creativity. What metrics do you think would be valuable to the D effort that you feel confident you can succeed with in the time constraints of the Autumn of Code event? After the event, it would be super awesome if you could continue maintaining project and add to it. Sure, it is a super cool project and I am really excited to be a part of it. If you have questions, ask away, but feel free to take the general idea and run with it. Acceptance will likely be judged based on the merits of your proposal; not the idea from which it was formulated. Also, the ideas on the Wiki are just ideas to plant a few seeds of creativity; you are also welcome use your own unique idea as the basis of your proposal. Mike Sure. I will make sure that I will give my best in giving the ideas and also work accordingly for implementing them too. Venu
Re: Is this a bug ? (variable _param_0 cannot be read at compile time)
On Wednesday, 8 August 2018 at 13:10:58 UTC, learnfirst1 wrote: https://run.dlang.io/is/blpkb6 There is no reason the code just work without template, but try put the it into template the variable become into not readable ? Please don't post your issues in multiple forums. This is exactly what the learn forum is for, and you've already received an answer there. -- Simen
Is this a bug ? (variable _param_0 cannot be read at compile time)
https://run.dlang.io/is/blpkb6 There is no reason the code just work without template, but try put the it into template the variable become into not readable ?
Re: More fun with autodecoding
On Monday, 6 August 2018 at 13:57:10 UTC, Steven Schveighoffer wrote: I'm very tempted to start writing my own parsing utilities and avoid using Phobos algorithms... -Steve Oh yes; the good old autodecoding.
Re: Give DLS a try
On Wednesday, 8 August 2018 at 07:25:57 UTC, Tab wrote: I find DLS to be very stable Ironically, as the developer of DLS, I'm not sure if it should be considered as stable. I've had quite a number of crashes myself, sometimes even seemingly right at startup :/ Although the latest version does fix a crash that was happening during garbage collection, so now it might be more stable. (Fun fact: since garbage collection always happens at least when the program exits, it was technically crashing 100% of the time before) I created a long list of features I'd like to see in D IDE. Hopefully some of them is being worked on. I have some things to fix first, but they will be worked on at some point; finding all references to a symbol especially is something that interests me.
Give DLS a try
I find DLS [1] to be very stable, updated more often [2], and it just works without issues (vs. Code-d) ~~ at least for me. I think we should give it a chance. I created a long list of features [3] I'd like to see in D IDE. Hopefully some of them is being worked on. [1]: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.vscode-dls [2]: https://github.com/LaurentTreguier/dls/blob/master/CHANGELOG.md [3]: https://github.com/dlang-vscode/dlang-vscode/issues/53
Re: Automate the collection and publishing of data for monitoring D's progress as a software development project
On Tuesday, 7 August 2018 at 17:47:45 UTC, Venu Vardhan Reddy Tekula wrote: Hello everyone, as I said before here, https://forum.dlang.org/post/dbmottqhsyxdizfkg...@forum.dlang.org, I am interested in "Automate the collection and publishing of data for monitoring D's progress as a software development project" which is part of SAOC. I have been into Web Development and worked on few projects. Now I am actually learning data science as I am quite interested in the field. I want to apply for this project as it covers both of my interests, Web Development and Data Science. The main crux of this project lies in scraping the data using the required API's and generating a web app, which can actually show a clear graph of what all things are happening to everyone. The graph thing can be done using some libraries in python. The web app can also be made using Python and Django. Yes, everything _could_ be done in Python or other languages, but SAoC is being run by the D foundation and a company using D, which is why the first question in the FAQ says, "Q: Can I use other languages alongside the D Language in my project? A: Yes. Make sure that the focus is the D Language. We are likely to select applicants that prioritize the D Language." If you don't want to participate in SAoC, but simply want to volunteer to do this because you're interested in data science, you are free to use any language you want. I had some questions regarding the project and also needed some pointers to get started with the project. Also, more it would be great if more description of the project statement can be provided. This is not a "project," it is merely an idea to spur SAoC proposals, apparently added by Mike: https://wiki.dlang.org/?title=SAOC_2018_ideas&type=revision&diff=9293&oldid=9292 The ideas are intended to provide a base upon which you build a full proposal. If you'd like to know more about what Mike had in mind, you can ask him more questions here, as he just responded to you, or over private email, which you can probably get from his github profile or commits: https://github.com/JinShil
