Re: Blog article on new import changes
On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote: I anticipate 2.071.0 is going to cause a lot of deprecation messages and strange errors to occur, due to the fixes of very long-standing import bugs. I wrote a blog post (actually my first ever) on this, let me know what you think (and please, any clarifications/errors, let me know): http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ 1. In addition, importing a module using static, renamed, or selective imports, then the module was imported publicly, even though it was supposed to be private. Not an English speaker, but this doesn't sound right (at least stylistically). Reread it several times, but I couldn't get the meaning of the sentence, until opened bug report. 2. With 2.070.2 and prior versions, compiling this works just fine. With 2.071.0 and above, you will get either a deprecation warning, or an error. With 2.070.2, this compiled just fine. [...] With 2.071.0 and above, this will trigger a deprecation warning. In the future, the code will trigger an error. In 2.070.2, this produces no warning or error. In 2.071.0 and beyond, this will produce a deprecation warning, and eventually an error. Not sure if it's worth it to repeat after each example. Feels redundant. 3. I think it's OK to write just major compiler versions, no need for patch version: 2.070 and 2.071
Re: Blog article on new import changes
On 3/29/16 2:02 PM, Sebastiaan Koppe wrote: On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote: I anticipate 2.071.0 is going to cause a lot of deprecation messages and strange errors to occur, due to the fixes of very long-standing import bugs. I wrote a blog post (actually my first ever) on this, let me know what you think (and please, any clarifications/errors, let me know): http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ I would avoid 'generated' names like ex1_a and ex1_b, and go for something concrete. E.g. module car; import tire; Yeah, I probably could. I wanted all my code in one gist, so I tried to come up with examples I could compile all at once. Worked great like dmd ex1*.d :) I'll see if I can change it, I agree it would sound better. Besided that, great and clear article. Thanks -Steve
Re: Blog article on new import changes
On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote: I anticipate 2.071.0 is going to cause a lot of deprecation messages and strange errors to occur, due to the fixes of very long-standing import bugs. I wrote a blog post (actually my first ever) on this, let me know what you think (and please, any clarifications/errors, let me know): http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ I would avoid 'generated' names like ex1_a and ex1_b, and go for something concrete. E.g. module car; import tire; Or whatever. Besided that, great and clear article.
Re: Blog article on new import changes
On 3/29/16 1:01 PM, Dicebot wrote: On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote: I anticipate 2.071.0 is going to cause a lot of deprecation messages and strange errors to occur, due to the fixes of very long-standing import bugs. I wrote a blog post (actually my first ever) on this, let me know what you think (and please, any clarifications/errors, let me know): http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ Worth mentioning that -transition=checkimports may slow down compilation notably which is why it isn't the default. Thanks, added a note. -Steve
Re: Blog article on new import changes
On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote: I anticipate 2.071.0 is going to cause a lot of deprecation messages and strange errors to occur, due to the fixes of very long-standing import bugs. I wrote a blog post (actually my first ever) on this, let me know what you think (and please, any clarifications/errors, let me know): http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ Worth mentioning that -transition=checkimports may slow down compilation notably which is why it isn't the default.
Re: Blog article on new import changes
On 3/29/16 11:49 AM, Jack Stouffer wrote: Here are some notes I jotted down when reading it Thanks, all fixed. Note, the "upcoming" note was added hastily before publishing because I realized 2.071 hasn't been released. Now reads: "In the upcoming version of D, several changes have been made to the import system"
Re: Blog article on new import changes
On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote: I anticipate 2.071.0 is going to cause a lot of deprecation messages and strange errors to occur, due to the fixes of very long-standing import bugs. I wrote a blog post (actually my first ever) on this, let me know what you think (and please, any clarifications/errors, let me know): http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ This is an informative article, good job. Here are some notes I jotted down when reading it In the newest version of D upcoming, several changes have been made to the import system, including fixes for 2 of the oldest bugs in D history. Grammatically, it's redundant to put "upcoming" where it is; numbers under 20 are typically written with their name. However, until the fix was rendered, these module symbols were imported as if they were marked public. This sentence is redundant. This determines where the problem lies. This sentence is also redundant.
Blog article on new import changes
I anticipate 2.071.0 is going to cause a lot of deprecation messages and strange errors to occur, due to the fixes of very long-standing import bugs. I wrote a blog post (actually my first ever) on this, let me know what you think (and please, any clarifications/errors, let me know): http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/
Re: mir.combinatorics: reviewers and ideas are wanted
On Monday, 28 March 2016 at 15:30:56 UTC, Timon Gehr wrote: Regarding ideas: For each range, there should probably be a numeric function computing the length of that range. (e.g. here, binomial corresponds to combinations, there should be factorial corresponding to permutations etc.) This table might provide some inspiration: Thanks a lot for your input and ideas - I will work on it ;-)
Re: Article on Introspective programming
On Monday, 28 March 2016 at 12:47:02 UTC, Nicholas Wilson wrote: http://thewilsonator.github.io/update/2016/03/28/better-vulkan-bindings.html I would like some feedback before this is posted to reddit. Come to think of it, putting the project on github would be a good idea, but unfortunately I won't have the time for at least a week. Oh well. Comments and suggestions appreciated. Nic https://www.reddit.com/r/programming/comments/4cezy8/generating_better_vulkan_bindings_an_adventure_in/
Re: libotr native D port
On 2016-03-28 08:53:24 +, ketmar said: subj. here[1]. not heavily tested, but it doesn't really matter, as nobody will use it anyway. 1. http://repo.or.cz/libotrd.git Off-the-Record (OTR) Messaging is a cryptographic protocol used in well-known instant messaging clients such as Pidgin, ChatSecure, Adium and others. It is designed to work on top of existing protocols and used worldwide to provide secure communication in insecure environments. OTR is regarded as highly secure and according to documents revealed by Edward Snowden one of the protocols that the NSA is not able to decrypt via cryptanalysis. The most commonly used implementation of OTR is "libotr" which is a pure C code implementation of the OTR protocol. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
