Re: Blog post on hidden treasure in the D standard library.
On Fri, 29 Aug 2014 17:13:23 + krzaq via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Negligence to do so is, to me, either extreme laziness or lack of respect to the reader. neither, in fact. i believe that those rules are useless and senseless now, so it's more like a one man crusade. i know that virtually nobody will join me in my fight, but it's not enough to stop me. ;-) signature.asc Description: PGP signature
Re: Dlang on Gentoo (update)
Added ebuild: * dub 0.9.21 Updated ebuilds: * GDC based on GCC 4.8.3 and DMD FE 2.065 * DMD 2.066.0 and tools I wonder if I can switch to linking with libphobos2.so now by default for dmd? Any outstanding issues/objections? -- Marco
Re: Blog post on hidden treasure in the D standard library.
On Saturday, 30 August 2014 at 06:00:31 UTC, ketmar via Digitalmars-d-announce wrote: i believe that those rules are useless and senseless now, so it's more like a one man crusade. It's not a one man's crusade, it affects legibility and creates dissonance within the text. It also appears unprofessional and uneducated. I gave up on reading the article and started skimming after the small introductory paragraph got it wrong 7 times.
Re: Blog post on hidden treasure in the D standard library.
On Saturday, 30 August 2014 at 07:55:37 UTC, safety0ff wrote: On Saturday, 30 August 2014 at 06:00:31 UTC, ketmar via Digitalmars-d-announce wrote: i believe that those rules are useless and senseless now, so it's more like a one man crusade. It's not a one man's crusade, it affects legibility and creates dissonance within the text. It also appears unprofessional and uneducated. I gave up on reading the article and started skimming after the small introductory paragraph got it wrong 7 times. Stop being such a grammar nazi. https://www.youtube.com/watch?v=Ovi7uQbtKas
Re: Blog post on hidden treasure in the D standard library.
On Sat, 30 Aug 2014 07:55:36 + safety0ff via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: It also appears unprofessional and uneducated. so i am. signature.asc Description: PGP signature
Re: core.stdcpp
On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote: On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote: On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote: On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: I'm judging by both the responses in this thread and the lack of responses in this thread that there isn't support, so I'm fine to go my own way with my ideas if that's what's preferred. Actuall, I am very much in favor of this, but I admit we are a bit in minority. I fel it is not because people ara gainst it, but because they feel is not very important. Plus, they have the impression that this will involve renaming modules and will need modifying curent source code. It is not about that. Names could remain just as they are, it is only about isolating that part of druntime that is really critical to run the language. As you defined very well, that part that corresponds to java.lang. There is one thing that bothers me, still, and I did not find the appropriate solution to it: if the language defines threads and garbage collector, I agree the mechanism for those should go in the runtime, but what to do with the function required to handle those? For example, creating a thread is done with a function (not with a keyword!) and the same goes for the GC.disable(), for example. So, this will kinda break the runtime means no imports mantra. Or, otherwise, how to do it? C++ fully accepted its dependency on stdlib when they wen with Threads, isn't? I find it uneasy that one accesses the runtime through import. Why we should need that? In C you never import/include something for the runtime, nor you have control over it from inside the program. It is through compiler params.
Re: Blog post on hidden treasure in the D standard library.
On Saturday, 30 August 2014 at 07:59:16 UTC, Gary Willoughby wrote: On Saturday, 30 August 2014 at 07:55:37 UTC, safety0ff wrote: On Saturday, 30 August 2014 at 06:00:31 UTC, ketmar via Digitalmars-d-announce wrote: i believe that those rules are useless and senseless now, so it's more like a one man crusade. It's not a one man's crusade, it affects legibility and creates dissonance within the text. It also appears unprofessional and uneducated. I gave up on reading the article and started skimming after the small introductory paragraph got it wrong 7 times. Stop being such a grammar nazi. https://www.youtube.com/watch?v=Ovi7uQbtKas Nitpick: this is about orthography, not grammar ;-)
Re: core.stdcpp
On Saturday, 30 August 2014 at 08:39:12 UTC, eles wrote: On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote: On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote: On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote: On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: I'm judging by both the responses in this thread and the lack of responses in this thread that there isn't support, so I'm fine to go my own way with my ideas if that's what's preferred. Actuall, I am very much in favor of this, but I admit we are a bit in minority. I fel it is not because people ara gainst it, but because they feel is not very important. For the record: This describes my stance, too. I acknowledge that it would be cleaner to separate the C bindings in a dedicated package outside of druntime (though druntime could then import this library instead of keeping its own copy of some bindings around). This package could then contain bindings to higher-level libraries, too. I just don't see it as a pressing issue, nor are there obvious disadvantages to the current situation, from what I can tell. Plus, they have the impression that this will involve renaming modules and will need modifying curent source code. It is not about that. Names could remain just as they are, it is only about isolating that part of druntime that is really critical to run the language. As you defined very well, that part that corresponds to java.lang. There is one thing that bothers me, still, and I did not find the appropriate solution to it: if the language defines threads and garbage collector, I agree the mechanism for those should go in the runtime, but what to do with the function required to handle those? For example, creating a thread is done with a function (not with a keyword!) and the same goes for the GC.disable(), for example. So, this will kinda break the runtime means no imports mantra. Or, otherwise, how to do it? C++ fully accepted its dependency on stdlib when they wen with Threads, isn't? I don't agree with this mantra, however. It makes sense for internally used functions like _d_throw, but it is fully acceptable IMO to treat some modules under core.* as part of the language that have to be imported when required. I find it uneasy that one accesses the runtime through import. Why we should need that? In C you never import/include something for the runtime, nor you have control over it from inside the program. It is through compiler params. There are some very low-level things for which you have to include header files. varargs for one, setjmp/longjmp, exit()... I would argue that these are parts of the language that happen to be implemented in the standard library (I don't know how exactly the specification treats them, however).
Re: COFF support for Win32 merged
On 2014-08-30 00:40, Szymon Gatner wrote: But there is still a matter of ARM/iOS runtime correct? Yes, but that is nothing I'm working on. Although other people are working on that. Those merges will go to 2.067? I have no idea. -- /Jacob Carlborg
Re: Blog post on hidden treasure in the D standard library.
On Saturday, 30 August 2014 at 07:55:37 UTC, safety0ff wrote: On Saturday, 30 August 2014 at 06:00:31 UTC, ketmar via Digitalmars-d-announce wrote: i believe that those rules are useless and senseless now, so it's more like a one man crusade. It's not a one man's crusade, it affects legibility and creates dissonance within the text. It also appears unprofessional and uneducated. I gave up on reading the article and started skimming after the small introductory paragraph got it wrong 7 times. ƃuıןןǝds-uɐɔıɹǝɯɐ-puɐ-ɥsıʇıɹq\spɹoʍ\ɯoɔ˙sǝıɹɐuoıʇɔıppɹoɟxo˙ʍʍʍ\\:dʇʇɥ :[Ɩ] uoıʇɐnʇɔund ou puɐ ʎןuo ǝsɐɔ-ɹǝʍoן uı uo ʍou ɯoɹɟ ƃuıɥʇʎɹǝʌǝ ƃuıʇıɹʍ ʇɹɐʇs ʇɥƃıɯ ı ˙ǝןdɯıs 'ǝʇıɹʍ ı ƃuıɥʇʎuɐ pɐǝɹ ʇ,uop 'ʇı ǝʞıן ʇ,uop noʎ ɟI ˙uoısıɔǝp snoıɔuoɔ ɐ ɟo ǝsnɐɔǝq op ı ʎɐʍ ǝɥʇ ǝʇıɹʍ I ˙ɹoɥʇnɐ pǝɥsıןqnd ɐ 'ןןɐ ɹǝʇɟɐ 'ɯɐ ı 'ǝɔuɐɹouƃı ɟo ʇno op ı ʎɐʍ ǝɥʇ ǝʇıɹʍ ʇ,uop I [Ɩ] ¡ƃuoɹʍ ʎןǝʇǝןdɯoɔ ʇןǝds ƃuıǝq spɹoʍ ɟo ʇunoɯɐ snoɯɹouǝ uɐ ɥʇıʍ sʇɔǝןɐıp ɥsıןƃuƎ ןןɐ ɟo ʇsɹoʍ ǝʇnןosqɐ ǝɥʇ sı ɥsıןƃuƎ uɐɔıɹǝɯ∀ ¡sɔıuoqƎ ǝʇoɹʍ puɐ ǝʞods oɥʍ ǝuoǝɯos ʇɔǝɹɹoɔ noʎ ǝǝs oʇ ǝʌoן pןnoʍ I ˙puıɥǝq ʇɟǝן ƃuıǝq ǝɹɐ sɯoıpı ןɐuoıʇıpɐɹʇ ʎuɐɯ ʇǝuɹǝʇuı ǝɥʇ ɟo ʇuǝʌpɐ ǝɥʇ ɥʇıM ˙suoıʇɐıɹɐʌ ʇuǝɹǝɟɟıp ǝʌɐɥ ɯopƃuı⋊ pǝʇıu∩ ǝɥʇ dn ǝʞɐɯ ʇɐɥʇ sǝıɹʇunoɔ ɹnoɟ ǝɥʇ uǝʌƎ ˙sʇsıxǝ ʇı ǝɹǝɥʍ ǝɹǝɥʍʎɹǝʌǝ ǝƃɐnƃuɐן ƃuıƃuɐɥɔ 'ƃuıʍoɹƃ ɐ sı ɥsıןƃuƎ puɐ 'ʇı ɟo uoısɹǝʌ ǝןʇʇıן uʍo ɹıǝɥʇ ǝʌɐɥ pןɹoʍ ǝɥʇ ɟo sʇɹɐd ʎuɐɯ ǝsnɐɔǝq sı ɥsıןƃuƎ ɹoɟ ǝǝʇʇıɯɯoɔ spɹɐpuɐʇs ou sı ǝɹǝɥʇ uosɐǝɹ ǝɥ⊥ ˙ǝƃɐnƃuɐן uʍo ɹıǝɥʇ ǝʇıɹʍ ɹo ʞɐǝds pןnoɥs ʎǝɥʇ ʍoɥ uo ǝןdoǝd ɥsıןƃuƎ ʇɔǝɹɹoɔ oʇ ƃuıʎɹʇ sʎɐʍןɐ ǝɹɐ ǝןdoǝd ɥsıןƃuƎ-uou ʇɐɥʇ snoıɹɐןıɥ ʇı puıɟ sʎɐʍןɐ I ˙ǝuo pǝʇɐɔnpǝun ǝɥʇ ǝɹɐ noʎ ʇɐɥʇ ɟo ǝsnɐɔǝq ʇı puɐʇsɹǝpun ʇ,uɐɔ noʎ ɟI ¡ʇxǝʇ ǝןoɥʍ ǝɥʇ uı s,ı ǝsɐɔ-ɹǝʍoן uǝ⊥ ˙*uǝʇ* sɐɥ ǝןɔıʇɹɐ ǝɹıʇuǝ ǝɥʇ 'uǝʌǝs ʇou 's,ı ǝsɐɔ-ɹǝʍoן *ǝʌıɟ* sɐɥ ɥdɐɹƃɐɹɐd ʎɹoʇɔnpoɹʇuı ǝɥ⊥
Re: core.stdcpp
On 2014-08-29 23:00, simendsjo wrote: It's still available at dsource: http://www.dsource.org/projects/ares I don't think he's referring to Ares, he's referring to some other D runtime. -- /Jacob Carlborg
DAuth v0.6.1 - Salted Hashed Password Library
An update to DAuth is out: https://github.com/Abscissa/DAuth Main Changes: - Add support for DMD 2.066 (Now supports v2.064.2 through v2.066.0) - Supports crypt(3)-style hash strings for MS5, SHA-256 and SHA-512. - Improved README - Improved API Reference - now uses ddox. Full ChangeLog: https://github.com/Abscissa/DAuth/blob/master/CHANGELOG.md Coming on the horizon: DAuth will be rebranded as InstaUser Basic. It will be one pillar of a broader multiple-lib project called InstaUser, which will also include optional higher-level tools InstaUser Store and InstaUser Web.
Re: DAuth v0.6.1 - Salted Hashed Password Library
On 8/30/2014 6:29 AM, Nick Sabalausky wrote: An update to DAuth is out: https://github.com/Abscissa/DAuth Main Changes: - Add support for DMD 2.066 (Now supports v2.064.2 through v2.066.0) - Supports crypt(3)-style hash strings for MS5, SHA-256 and SHA-512. Would you believe *MD5*, not MS5. Need sleep apparently... ;)
Re: Blog post on hidden treasure in the D standard library.
On Saturday, 30 August 2014 at 07:59:16 UTC, Gary Willoughby wrote: Stop being such a grammar nazi. I didn't bring it up because I felt like being pedantic, I brought it up as a suggestion to make it more pleasant to read. Since you've already been labelled as a pedant, perhaps you should learn the difference between pedantry and Nazism. On Saturday, 30 August 2014 at 09:38:29 UTC, Gary Willoughby wrote: ˙ǝuo pǝʇɐɔnpǝun ǝɥʇ ǝɹɐ noʎ ʇɐɥʇ ɟo ǝsnɐɔǝq ʇı puɐʇsɹǝpun ʇ,uɐɔ noʎ ɟI ¡ʇxǝʇ ǝןoɥʍ ǝɥʇ uı s,ı ǝsɐɔ-ɹǝʍoן uǝ⊥ ˙*uǝʇ* sɐɥ ǝןɔıʇɹɐ ǝɹıʇuǝ ǝɥʇ 'uǝʌǝs ʇou 's,ı ǝsɐɔ-ɹǝʍoן *ǝʌıɟ* sɐɥ ɥdɐɹƃɐɹɐd ʎɹoʇɔnpoɹʇuı ǝɥ⊥ Firstly: I’ve been using D for a number of years and i 1 am constantly surprised by the hidden treasure i 2 find in the standard library. I guess the reason for my surprise is that i’ve 3 never exhaustively read the entire library documentation, i 4 only skim it for what’s needed at any given time. I’ve promised myself i 5 will read it thoroughly one day but until then i’ll 6 enjoy these little discoveries. This article highlights a few of these hidden treasures which i 7 Secondly, as I've already stated, it's not a matter of it being incomprehensible. ˙ǝןdɯıs 'ǝʇıɹʍ ı ƃuıɥʇʎuɐ pɐǝɹ ʇ,uop 'ʇı ǝʞıן ʇ,uop noʎ ɟI In that case, don't complain when the opinions you've written are dismissed. uoıʇɐnʇɔund ou puɐ ʎןuo ǝsɐɔ-ɹǝʍoן uı uo ʍou ɯoɹɟ ƃuıɥʇʎɹǝʌǝ ƃuıʇıɹʍ ʇɹɐʇs ʇɥƃıɯ ı The second coming of e e cummings!
Re: Blog post on hidden treasure in the D standard library.
On Saturday, 30 August 2014 at 06:00:31 UTC, ketmar via Digitalmars-d-announce wrote: On Fri, 29 Aug 2014 17:13:23 + krzaq via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Negligence to do so is, to me, either extreme laziness or lack of respect to the reader. neither, in fact. i believe that those rules are useless and senseless now, so it's more like a one man crusade. i know that virtually nobody will join me in my fight, but it's not enough to stop me. ;-) i will join you in your fight. i do not use upper case letters when writing both in english and turkish. i find these rules utterly useless as well.
Re: Blog post on hidden treasure in the D standard library.
On 8/30/2014 5:38 AM, Gary Willoughby wrote: ˙ǝƃɐnƃuɐן uʍo ɹıǝɥʇ ǝʇıɹʍ ɹo ʞɐǝds pןnoɥs ʎǝɥʇ ʍoɥ uo ǝןdoǝd ɥsıןƃuƎ ʇɔǝɹɹoɔ oʇ ƃuıʎɹʇ sʎɐʍןɐ ǝɹɐ ǝןdoǝd ɥsıןƃuƎ-uou ʇɐɥʇ snoıɹɐןıɥ ʇı puıɟ sʎɐʍןɐ I I'm a native English speaker. Uncapitalized I makes a writer come across like a common leet-speak obsessed immature script kiddy. I know you're not one though, which makes it all the more puzzling. Defend it all you want, argue that it doesn't matter...but it still makes yourself look bad. And for what worthwhile benefit? (I think native speakers tend to gloss such things over because they've already seen it so much they've become accustomed to tuning out anyone writing in such styles.) It's not my intent to be insulting here, but the level of insistence on deliberately using and defending such a trivial, and self-defeating, rebelling is just...really??
Re: Blog post on hidden treasure in the D standard library.
On Sat, 30 Aug 2014 10:44:18 + safety0ff via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Saturday, 30 August 2014 at 07:59:16 UTC, Gary Willoughby wrote: Stop being such a grammar nazi. I didn't bring it up because I felt like being pedantic, I brought it up as a suggestion to make it more pleasant to read. Since you've already been labelled as a pedant, perhaps you should learn the difference between pedantry and Nazism. Can we please stop arguing this (and that goes for both sides of this). This discussion is not in the least bit productive. There is no question that failing to capitalize the letter i when it's used as a pronoun is bad English, and there's no way that anyone fluent enough in English to write an article like this is not going to know that. So, clearly, he's doing it on purpose. I agree that bad grammar - especially when it's so blatant like this - detracts from what's being written, and pointing out that it was a problem was fine, but continuing to argue about it serves no purpose. Clearly, he knows that what he's doing is bad grammar, but he's doing it anyway for whatever his personal reasons are. Arguing about it like this isn't helping. It's just increasing the level of contention around here. - Jonathan M Davis
Re: Blog post on hidden treasure in the D standard library.
On Saturday, 30 August 2014 at 10:49:33 UTC, Mengu wrote: i will join you in your fight. i do not use upper case letters when writing both in english and turkish. i find these rules utterly useless as well. the funny thing is that there are movements that fight for a revision of written english since it has been frozen for such a long time that the pronunciation is completely out of sync with how it is written, which is a fairly arcane mishmash. the lack of willingness to reform english creates a lot of unnecessary educational problems all over the world. meaning, people have to memorize pronunciation rather than deduce it from the spelling. i find that rather wasteful... (you know you've won a debate when people start to focus on your grammar ;-)
Re: core.stdcpp
On Friday, 29 August 2014 at 16:37:12 UTC, Sean Kelly wrote: On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote: On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. Please understand that I'm not suggesting we start refactoring druntime for 2.067. All I'm asking for is that we recognize that C/C++ library and OS bindings don't belong in druntime as public modules, and we gradually work towards migrating them to phobos or some other library in the years to come. The reason these are in Druntime at all is because code in Druntime depends on them. So if they were split into a separate library then it would be a required library. And even if we completely eliminate any dependency on standard C functions, I don't see any way to avoid depending on platform-specific calls. Now I would be fine with including just a subset of declarations in Druntime (which is really what we have right now anyway), but if the remainder were split into a standalone library then things start to get weird. Please let me know if you have a solution to this problem. I'm not suggesting we eliminate libc and platform-specific bindings, just encapsulate and isolate them. To make D work on any platform, druntime must be ported to that platform. To do the port, of course we have to make platform-specific calls. That's no problem. But they should be internally encapsulated in that port's logic, not publicly exposed. And if we implement 11666 we should isolate each port to its own folder so the abstraction between language and platform is clear. For example (what druntime may look like many years from now): If a port chooses to use libc, no problem. Just encapsulate the bindings in its own file/folder. Don't make it publicly available. If D programmers want bindings to libc in their programs, they should use std.c in phobos (or we could simply move core.stdc to phobos). This means that we may have duplicate bindings in druntime and std.c for the few features of libc that are required to implement the port. This isn't really a duplication of code as it should just be type declarations and function signatures - just information for the linker. Some time in the future, many years from now, it would be nice if gradually those C bindings were replaced with D implementations to throw out the middle-man and put the port directly on the platform. There's absolutely no hurry, and if it's never done, so be it. Now what about the stuff in core.sys.whateverOS? It's the same thing. Certainly these are needed to port druntime to a given platform, but they are an implementation detail of the port, not the language. Again they should be encapsulated and isolated. If users want to make calls to whateverOS libs, than we can either move core.sys.whateverOS to phobos, or create a new namespace std.whateverOS or whatever namespace name you want, and users can use that. Just get it out of the way of the language implementation. But NONE of this needs to be done right now, or even this year, or even next year. All I'm asking for with this thread is that instead of making it harder to move away from the current structure by adding core.stdcpp to druntime, we simply choose to put the C++ standard library bindings in std.cpp in phobos. Or you could choose to keep it as core.stdcpp, but just put it in phobos instead of druntime. The C++ standard library bindings don't exist yet. There's nothing to change. It's just a design decision. What do you want druntime to look like in 10 years? Let's make sure we're pointed in that direction with the C++ standard library bindings. Mike
Re: COFF support for Win32 merged
On 2014-08-29 15:46:32 +, Jacob Carlborg said: On 2014-08-29 16:06, Szymon Gatner wrote: If that is indeed the case then this is huge for me. I am doing 32bit Win apps and their iOS versions. The moment I will be able to use D libraries on both platforms I will totaly do it. In fact I want to be one of the very first to release paid iOS app with D code in it ;) It's your luck day (almost). I'm working on making D ABI compatible with Objective-C [1]. It's mostly done, I'm working on merging latest changes. [1] http://wiki.dlang.org/DIP43 That's cool stuff. How will Swift influence this? I'm pretty sure that Apple's strategy is to get rid of Objective-C ASAP and use Swift whereever possible. -- Robert M. Münch Saphirion AG http://www.saphirion.com smarter | better | faster
Re: Blog post on hidden treasure in the D standard library.
On Saturday, 30 August 2014 at 11:27:13 UTC, Jonathan M Davis wrote: On Sat, 30 Aug 2014 10:44:18 + safety0ff via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Saturday, 30 August 2014 at 07:59:16 UTC, Gary Willoughby wrote: There is no question that failing to capitalize the letter i when it's used as a pronoun is bad English, and there's no way that anyone fluent Actually, IIRC (not native English speaker here), it was once told me that the symbol for I (first person) is a different one, something like a half of circle, but in print we use I for convenience, as it is pronounced the same and it is the most similar too. But, that teacher of mine, in handwriting, always depicted the I like a kind of ].
Re: Blog post on hidden treasure in the D standard library.
On Saturday, 30 August 2014 at 11:19:55 UTC, Nick Sabalausky wrote: On 8/30/2014 5:38 AM, Gary Willoughby wrote: ˙ǝƃɐnƃuɐן uʍo ɹıǝɥʇ ǝʇıɹʍ ɹo ʞɐǝds pןnoɥs ʎǝɥʇ ʍoɥ uo ǝןdoǝd ɥsıןƃuƎ ʇɔǝɹɹoɔ oʇ ƃuıʎɹʇ sʎɐʍןɐ ǝɹɐ ǝןdoǝd ɥsıןƃuƎ-uou ʇɐɥʇ snoıɹɐןıɥ ʇı puıɟ sʎɐʍןɐ I I'm a native English speaker. Uncapitalized I makes a writer come across like a common leet-speak obsessed immature script kiddy. I know you're not one though, which makes it all the more puzzling. Defend it all you want, argue that it doesn't matter...but it still makes yourself look bad. And for what worthwhile benefit? (I think native speakers tend to gloss such things over because they've already seen it so much they've become accustomed to tuning out anyone writing in such styles.) It's not my intent to be insulting here, but the level of insistence on deliberately using and defending such a trivial, and self-defeating, rebelling is just...really?? While we're on the subject of capitalization styles we find distracting, I find the German Practice of capitalizing every Noun in a Sentence extremely distracting. I remember reading an older version of Gulliver's Travels that was written in this style, and it was quite annoying.
Re: Blog post on hidden treasure in the D standard library.
Just a correction: On Saturday, 30 August 2014 at 10:44:20 UTC, safety0ff wrote: Since you've already been labelled as a pedant, perhaps you should learn the difference between pedantry and Nazism. I meant: Since you've already labelled *me* Anyways.
Re: DAuth v0.6.1 - Salted Hashed Password Library
Would it be possible to support bcrypt style password hashing? The one key feature of it is that it encrypts/hashes the password many times to slow down brute force attacks. Hash algorithms are too fast to prevent this.
Re: COFF support for Win32 merged
On 2014-08-30 14:31, Robert M. Münch wrote: That's cool stuff. How will Swift influence this? I'm pretty sure that Apple's strategy is to get rid of Objective-C ASAP and use Swift whereever possible. Swift is ABI compatible with Objective-C. So anything that works across Swift and Objective-C should, in theory, work across Swift and D. -- /Jacob Carlborg
Re: Eclipse D Development Tools (DDT) plug-in version 0.10.2 released
On Thursday, 28 August 2014 at 21:20:48 UTC, Bruno Medeiros wrote: - Mouse hovering over an auto keyword will show the resolved type - How is this implemented? - Will this expand to cover any expression at the cursor in the future? This would be a super promotor for introducing D to newcomers.
Re: DAuth v0.6.1 - Salted Hashed Password Library
On 8/30/2014 10:19 AM, Casey wrote:
Would it be possible to support bcrypt style password hashing? The one
key feature of it is that it encrypts/hashes the password many times to
slow down brute force attacks. Hash algorithms are too fast to prevent
this.
DAuth is designed for everything to be overridable. So, while specific
support for that is not currently built-in (I definitely want to add it
though), you should still be able to use it.
The best way to do it:
All you need is a Phobos-compatible std.digest.digest[1]-style interface
for bcrypt. You can wrap an existing bcrypt algorithm like this:
[1] http://dlang.org/phobos/std_digest_digest.html
--
import your_ordinary_bcrypt_module;
import std.digest.digest : WrapperDigest;
// Phobos's template-style
struct BCrypt
{
// Implement Phobos digest interface:
void start();
void put(scope const(ubyte)[] data...);
ubyte[SIZE_OF_YOUR_FINAL_HASH] finish();
}
// Phobos's OO-style
alias BCryptDigest = WrapperDigest!BCrypt;
--
The easiest way (although maybe not most flexible) to handle BCrypt's
number of rounds parameter would be to make it a compile-time argument
for your struct, and then make a few convenience aliases:
--
struct BCrypt(int numRounds) {...}
alias BCrypt256 = BCrypt!256;
alias BCrypt1024 = BCrypt!1024; // Or whatever
--
Now you have a BCrypt that's fully compatible with Phobos's digest
system. If you don't care about DAuth's hash string format, then that's
all you need: Just pass the in digest to any function which takes it:
--
// Generate password hash
Hash!Bcrypt256 hash = makeHash!Bcrypt256(pass);
ubyte[] mySalt = hash.salt;
ubyte[SIZE_OF_YOUR_FINAL_HASH] myHash = hash.hash;
saveItAllToYourDB(mySalt, myHash);
// Test password against a hash
Hash!Bcrypt256 someHash;
someHash.salt = mySalt;
someHash.hash = myHash;
bool accessGranted = isSameHash!Bcrypt256(pass, someHash);
--
To fully integrate it with DAuth and be able to use DAuth's hash
strings, you can pass Hash.toString() and parseHash() with custom
callbacks for 'digestCodeOfObj' and 'digestFromDAuthCode'. Examples of
this are provided in the API reference:
http://semitwist.com/dauth/dauth/core/Hash.toString.html
http://semitwist.com/dauth/dauth/core/parseHash.html
If you don't want to create a Phobos-style digest wrapper for bcrypt,
you don't have to. You can just bypass makeHash/isSameHash entirely:
--
import dauth;
import std.digest.digest;
import your_bcrypt_lib;
auto makeBCryptHash(Password pass, int rounds)
{
// Digest is std.digest.digest.Digest, an OO interface
Digest dummyDigest;
Hash!Digest hash;
hash.salt = randomSalt();
hash.hash = do_the_bcrypt(h.salt ~ pass.data, rounds);
return hash;
}
bool isSameBCryptHash(Password pass, int rounds, Hash!Digest hash)
{
ubyte[] testHash = do_the_bcrypt(hash.salt ~ pass.data, rounds);
return lengthConstantEquals(testHash, hash.hash);
}
// Don't use Hash.toString() or parseHash() since you opted
// not to create a Phobos-style digest. Instead, just
// save/load hash.salt and hash.hash manually.
--
I really should add a tutorial page to the official docs showing all
this how to add support for another hashing algorithm.
