Re: DMD 2.066 Alpha
On Wednesday, 11 June 2014 at 04:17:04 UTC, Andrew Edwards wrote: On 6/10/14, 10:01 PM, Brian Schott wrote: Please do not tag anything until we decide if virtual is a keyword in D. See: https://github.com/D-Programming-Language/dlang.org/pull/584 The branch will not be created until 30 June. I trust that this will be sorted out by then. I'll be there to test and bug report ! Thank for being the release lieutenant.
Re: hap.random: a new random number library for D
On Tuesday, 10 June 2014 at 23:08:33 UTC, Chris Cain wrote: I had an opportunity to give the entire code a good once over read and I have a few comments. Thanks! :-) 1. Biggest thing about the new hap.random is how much nicer it is to actually READ. The first few times I went through the current std.random, I remember basically running out of breath. hap.random was almost a refreshing read, in contrast. I'm guessing it has a lot to do with breaking it down into smaller, more manageable pieces. Regardless, good work on that. I suspect it'll make it easier to contribute to in the future. That's great to hear, as it was a design goal. I think there will probably at some point be a need to separate things further (e.g. std.random.generator will probably have to be separated as will std.random.distribution) but always keeping the principle of implementing packages to make it possible to just import hap.random (or import hap.random.generator, or whatever). 2. Something I'd really like to see is for the seed-by-range functions to take the range by reference instead of by value to ensure that the seed values used are less likely to be used in another RNG inadvertently later. Basically, I envision a similar problem with seedRanges as we currently have with RNGs where we have to make sure people are careful with what they do with the ranges in the end. This should cover use cases where users do things like `blah.seed(myEntropyRange.take(3))` as well, so that might take some investigation to figure out how realistic it would be to support. Yea, that's an interesting point. I mean, you'd hope that myEntropyRange would be a reference type anyway, but every little helps :-) 3. I'd also REALLY like to see seed support ranges/values giving ANY type of integer and guarantee that few bytes are wasted (so, if it supplies 64-bit ints and the generator's internal state array only accepts 32-bit ints, it should spread the 64-bit int across two cells in the array). I have working code in another language that does this, and I wouldn't mind porting it to D for the standard library. I think this would greatly simplify the seeding process in user code (since they wouldn't have to care what the internal representation of the Random state is, then). That would be very cool. Can you point me at your code examples? 4. I'd just like to say the idea of using ranges for seeds gets me giddy because I could totally see a range that queries https://random.org for true random bits to seed with, wrapped by a range that zeroes out the memory on popFront. Convenient and safe (possibly? Needs review before I get excited, obviously) for crypto purposes! The paranoiac in me feels that anything that involves getting random data via HTTPS is probably insecure crypto-wise :-) However, I think sourcing random.org is a perfect case for an entry in hap.random.device. I think the best thing to do would probably be to offer a RandomOrgClient (which offers a very thin API around the random.org HTTP API) and then to wrap that in a range type that uses the client internally to generate random numbers with particular properties. 5. Another possible improvement would be something akin to a remix function. It should work identically to reseeding, but instead of setting the internal state to match the seed (as I see in https://github.com/WebDrake/hap/blob/master/source/hap/random/generator.d#L485), remixing should probably be XOR'd into the current state. That way if you have a state based on some real entropy, you can slowly, over time, drip in more entropy into the state. Also a very interesting suggestion. Is there a standard name for this kind of procedure? 6. I'd like to see about supporting xorshift1024 as well (described here: http://xorshift.di.unimi.it/ and it's public domain code, so very convenient to port ... I'd do it too, of course, if that seems like an okay idea). This is a really small thing because xorshift1024 isn't really much better than xorshift128 (but some people might like the idea of it having significantly longer period). Fantastic, I will see about implementing those. I wasn't previously aware of that work, but I _was_ aware that the standard Xorshift generators have some statistical flaws, so it's great to have some alternatives. It should be straightforward to implement things like XorshiftP128 or XorshiftS1024 and XorshiftS4096 (using P and S in place of + and *). With these in place we might even be able to deprecate the old Xorshift generators. Just for clarity, here's how I see things rolling out for the future: * First goal is to ensure the existing codebase plays nice with people's programs and that it works OK with dub, rdmd, etc. and doesn't have any serious architectural or other bugs. The 1.0.0 release will not have any new functionality compared to what is in place now. * Once it seems to be
Re: hap.random: a new random number library for D
On Tuesday, 10 June 2014 at 23:48:09 UTC, bearophile wrote: Please stop, I am not worth that, and I don't even know how much good that generator is. So for you it's better to focus on more important matters of the new random module. Extra generators can be added later if needed. After all the advice and help you've given me (and the rest of this community) over the course of years, it's really a pleasure to be able to offer you a small favour like this. But of course it could be fun to first run things through e.g. the TestU01 suite ... Passing several cpu words by value for each generated value seems not very efficient. But this generator is for special situations, so a certain performance loss could be acceptable. And if the compiler is able to inline the functions, the data transfer overhead is removed, and most of the performance loss is restored (but I don't know if non-templated Phobos functions get inlined). Well, I think it's worth experimenting with. For clarity, I wasn't suggesting modifying the existing Xorshift code, but creating a separate implementation in strongly pure style, and seeing how that differs performance-wise from what already exists. I guess I might also consider finally getting my head round monads, and relating that to RNG design ... :-)
Re: hap.random: a new random number library for D
On Monday, 9 June 2014 at 18:09:21 UTC, Joseph Rushton Wakeling wrote: Hello all, Incidentally, would it be a good idea to post a link to the blog post on r/programming? Haven't done so yet, as generally I prefer to leave decisions about D publicity to others, but can do so if people would like.
Re: Adam D. Ruppe's D Cookbook now available!
On 10/06/14 19:43, Adam D. Ruppe wrote: blargh, I thought it could do more. Does it at least work to pull out extern C functions from a C++ header? Hmm, I haven't tried that. You need to specified which language to use. Currently DStep has hard coded its language support, in which C++ is not included. It starts to get more complicate if it needs to support multiple languages in the same file. It should be possible, but then I think every declaration will need to be prefixed with extern (C). -- /Jacob Carlborg
Re: hap.random: a new random number library for D
On 6/10/2014 7:08 PM, Chris Cain wrote: 3. I'd also REALLY like to see seed support ranges/values giving ANY type of integer and guarantee that few bytes are wasted (so, if it supplies 64-bit ints and the generator's internal state array only accepts 32-bit ints, it should spread the 64-bit int across two cells in the array). I have working code in another language that does this, and I wouldn't mind porting it to D for the standard library. I think this would greatly simplify the seeding process in user code (since they wouldn't have to care what the internal representation of the Random state is, then). Joseph and I have recently had some discussion on the idea of random streams which could work as you describe (The full discussion was in the digitalmars.D thread titled isUniformRNG). A finalized design would be dependent on Phobos's redesign of streams. But an unofficial design does exist, as it was needed for a crypto RNG I wrote[1][2]. An RNG - RNG stream adapter could easily be written. [1] Original version: https://github.com/Abscissa/DAuth/blob/master/src/dauth/hashdrbg.d [2] Phobos submission: https://github.com/D-Programming-Language/phobos/pull/2208 4. I'd just like to say the idea of using ranges for seeds gets me giddy because I could totally see a range that queries https://random.org for true random bits to seed with, wrapped by a range that zeroes out the memory on popFront. Convenient and safe (possibly? Needs review before I get excited, obviously) for crypto purposes! Personally, I wouldn't trust an internet-hosted RNG for crypto purposes as there's too many ways it could go wrong on either end. However, *mixing* it in as an additional source of entropy (together with a local source of non-determinism and a proper crypto-grade PRNG such as Hash_DRBG) sounds promising to me. Although I'm not a cryptography expert. 5. Another possible improvement would be something akin to a remix function. It should work identically to reseeding, but instead of setting the internal state to match the seed (as I see in https://github.com/WebDrake/hap/blob/master/source/hap/random/generator.d#L485), remixing should probably be XOR'd into the current state. That way if you have a state based on some real entropy, you can slowly, over time, drip in more entropy into the state. Interesting that you mention that. Hash_DRBG does pretty much that (although it's a little more complicated than an simple XOR). While I'm not particularly familiar with any others, I'd imagine that's probably a typical behavior among cryptographic PRNGs in general.
Re: hap.random: a new random number library for D
On 6/11/2014 2:41 AM, Joseph Rushton Wakeling wrote: 5. Another possible improvement would be something akin to a remix function. It should work identically to reseeding, but instead of setting the internal state to match the seed (as I see in https://github.com/WebDrake/hap/blob/master/source/hap/random/generator.d#L485), remixing should probably be XOR'd into the current state. That way if you have a state based on some real entropy, you can slowly, over time, drip in more entropy into the state. Also a very interesting suggestion. Is there a standard name for this kind of procedure? NIST's crypto-RNG papers just refer to it as reseeding, so there might not be a standard name for it. FWIW, I've taken to calling it accumulating entropy.
Re: hap.random: a new random number library for D
On Wednesday, 11 June 2014 at 06:41:34 UTC, Joseph Rushton Wakeling wrote: That would be very cool. Can you point me at your code examples? It's written in Nimrod (in a way that someone who learned Nimrod the day before would write them, because I learned Nimrod the day before and worked on it for something like 17 hours straight to produce everything): https://github.com/Zshazz/Ramrod/blob/master/util.nim I'd like to make this concept a range in D. Not sure what exactly to call it but it's an adaptor. Honestly, I wouldn't be surprised if something like this didn't already exist in D in some form, but it didn't seem like Nimrod had anything like it. The paranoiac in me feels that anything that involves getting random data via HTTPS is probably insecure crypto-wise :-) Paranoia is good in this case. I appreciate the caution. However, I think sourcing random.org is a perfect case for an entry in hap.random.device. I think the best thing to do would probably be to offer a RandomOrgClient (which offers a very thin API around the random.org HTTP API) and then to wrap that in a range type that uses the client internally to generate random numbers with particular properties. This sounds like it would be beautiful. As a note, if we expose this via a part of the standard library, we would have to make certain that we follow the guidelines outlined on random.org (in particular, I'm concerned about having an internal locking mechanism to prevent multiple threads from asking for bits at the same time because that will cause clients to be banned ... global state, impurity, and all the nasty things will likely have to be a natural part of such a thing). Also a very interesting suggestion. Is there a standard name for this kind of procedure? I'm not really aware if there is. I remember hearing about the concept when talking with my cryptography professor awhile back (it may have even been in a lecture). IIRC, the description used was mixing in entropy, so my first thought is to call it a mix/remix function. Just for clarity, here's how I see things rolling out for the future: * First goal is to ensure the existing codebase plays nice with people's programs and that it works OK with dub, rdmd, etc. and doesn't have any serious architectural or other bugs. The 1.0.0 release will not have any new functionality compared to what is in place now. * Once it seems to be reasonably stable then work can begin on a 1.x release series that brings in successive pieces of new functionality. I like this procedure. Definitely confidence inspiring.
Re: hap.random: a new random number library for D
Have you any plan to implement CMWC? http://en.wikipedia.org/wiki/Multiply-with-carry#Complementary-multiply-with-carry_generators On Monday, 9 June 2014 at 18:09:21 UTC, Joseph Rushton Wakeling wrote: Hello all, Some of you may remember my earlier draft of a class-based std.random successor: http://forum.dlang.org/thread/cyytvhixkqlbwkmiu...@forum.dlang.org Following revisions made in response to feedback, and some further development, I decided that it would be best to release the results as a dub package with a new library name: http://code.dlang.org/packages/hap Source code and documentation is available here: https://github.com/WebDrake/hap http://code.braingam.es/hap/random/ I've also written a blog post describing new features and the motivations behind this library: http://braingam.es/2014/06/hap-random-a-new-random-number-library-for-d/ I think that hap.random fixes certain fundamental design issues with std.random. However, this needs to be put to the test in the wild, so I'd really appreciate it if as many people as possible could try it out with their code, and report on the experience: * Does it run faster, slower, etc? * Do any undesirable memory allocation issues arise? * Is the API (broadly similar but not identical to std.random) pleasant to use? If it proves to be effective for everyone, then I will begin the process of submission as a new Phobos module. Thanks in advance for all testing and feedback. Best wishes, -- Joe
Re: QtE - D small binding for Qt.
Example of D (dmd 2.065 64) with Qt 64 Windows64/Linux64. Running programs *.EXE with key --debug. http://yadi.sk/d/qLE7Kgz9SpKEX
Re: DlangUI
On Thursday, 5 June 2014 at 14:22:46 UTC, Mike James wrote: First problem: you need to add gl3n to the git clone list for developing under Visual-D. Fixed. I've removed gl3n and libpng references from project. I am having problems running (debugging) the example1 program. When loading the resources it gets to tab_up_background.9.png (line 579 in file resources.d) and then fails with an exception: Unhandled exception at 0x0044f932 in example1.exe: 0xC005: Access violation reading location 0x. Do you have any clues as to what the problem could be? Search log file examples/example1/ui.log for lines like 2014-06-11 13:21:11.070 D DrawableCache: adding path C:\projects\d\dlangui\examples\example1\Debug\..\..\..\res\ to resource dir list. 2014-06-11 13:21:11.070 D DrawableCache: adding path C:\projects\d\dlangui\examples\example1\Debug\..\..\..\res\mdpi\ to resource dir list. 2014-06-11 13:21:11.070 D DrawableCache: path C:\projects\d\dlangui\examples\example1\Debug\..\..\..\..\res\ does not exist. 2014-06-11 13:21:11.086 D DrawableCache: path C:\projects\d\dlangui\examples\example1\Debug\..\..\res\mdpi\ does not exist. In examples/example1/main.d several directories are added as resource path candidates // resource directory search paths string[] resourceDirs = [ appendPath(exePath, ../../../res/), // for Visual D and DUB builds appendPath(exePath, ../../../res/mdpi/), // for Visual D and DUB builds appendPath(exePath, ../../../../res/),// for Mono-D builds appendPath(exePath, ../../../../res/mdpi/),// for Mono-D builds appendPath(exePath, res/), // when res dir is located at the same directory as executable appendPath(exePath, ../res/), // when res dir is located at project directory appendPath(exePath, ../../res/), // when res dir is located at the same directory as executable appendPath(exePath, res/mdpi/), // when res dir is located at the same directory as executable appendPath(exePath, ../res/mdpi/), // when res dir is located at project directory appendPath(exePath, ../../res/mdpi/) // when res dir is located at the same directory as executable ]; If your executable is not located in examples/example1/Debug, probably you add path to your directory to list of resource dirs. Another possible reason - FreeImage.dll is found. Try to copy FreeImage.dll from lib directory to examples/example1/Debug
Re: hap.random: a new random number library for D
On Wednesday, 11 June 2014 at 07:42:10 UTC, Andrea Fontana wrote: Have you any plan to implement CMWC? http://en.wikipedia.org/wiki/Multiply-with-carry#Complementary-multiply-with-carry_generators I hadn't made any concrete plans about that particular family of generators (my impression was that Xorshift and its successors are superior), but I'll happily take patches or a feature request :-)
Re: DlangUI
On Thursday, 5 June 2014 at 19:58:10 UTC, Casper Færgemand wrote: On Thursday, 5 June 2014 at 16:10:00 UTC, Mike James wrote: I checked the sub-directory the loading refers to and all the pngs seems to be there. I managed to get the files from github just fine, but dub says it is unable to copy a libpng file to the example case. I'm not sure what is wrong, the instructions are three lines of code after all. =/ git clone https://github.com/buggins/dlangui.git cd dlangui dub run dlangui:example1 libpng is not needed anymore. These three lines worked ok for me some time ago. But now I'm facing with another problem while trying dub build: Building dlangui:example1 configuration application, build type debug. Compiling... Error: conflicting Ddoc and obj generation options Does anyone know how to fix it?
Re: DMD 2.066 Alpha
On 6/11/14, 2:23 AM, deadalnix wrote: I'll be there to test and bug report ! Thank for being the release lieutenant. In my world a lieutenant is absolutely useless. Given the tutelage and guidance of solid staff non-commissioned officer, some day they will become productive members of the community. If they don't find such a mentor however, they will become loose cannons: destroying all in their path. I tend to see life from a different perspective. Officers, in general, are quite useless. They are the good idea fairies who give little, if any, consideration to the ramifications of their ideas/proposals and will stop at nothing to see them come to fruition: regardless of consequences. Worse still, they are absolutely incapable of implementing the ideas/proposals they generate. I prefer a Chief and Indian analogy. The Chief knows what needs to get done and, though she may not know have the tasks required to get the job done, leverages the strengths of the Indians to do so. The Indians provide the skills and know-how, and actually does the work. This community needs far more Chiefs and Indians (arguably more Indians than Chiefs): and way less lieutenants. Oh, wow! That was a pretty long way around to say thank you for your continued support.
Re: DMD 2.066 Alpha
On 11 June 2014 14:19, Andrew Edwards via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 6/11/14, 2:23 AM, deadalnix wrote: I'll be there to test and bug report ! Thank for being the release lieutenant. In my world a lieutenant is absolutely useless. Given the tutelage and guidance of solid staff non-commissioned officer, some day they will become productive members of the community. If they don't find such a mentor however, they will become loose cannons: destroying all in their path. I tend to see life from a different perspective. Officers, in general, are quite useless. They are the good idea fairies who give little, if any, consideration to the ramifications of their ideas/proposals and will stop at nothing to see them come to fruition: regardless of consequences. Worse still, they are absolutely incapable of implementing the ideas/proposals they generate. I prefer a Chief and Indian analogy. The Chief knows what needs to get done and, though she may not know have the tasks required to get the job done, leverages the strengths of the Indians to do so. The Indians provide the skills and know-how, and actually does the work. This community needs far more Chiefs and Indians (arguably more Indians than Chiefs): and way less lieutenants. Oh, wow! That was a pretty long way around to say thank you for your continued support. Nice analogy (and outlook!) Now, as 'Chief' of GDC talking to 'Chief' or D releases, I must say that the release timings are abysmal. At least 2 months overdue. I have only just managed to catch up to 2.065, and that's not due out till the weekend. Things used to be so much easier when releases were less than 2 months apart.
Re: hap.random: a new random number library for D
On Tuesday, 10 June 2014 at 10:57:32 UTC, bearophile wrote: Kagamin: Pass it by reference, I see no reason why MT can't be pure. I meant strongly pure :-) I'm afraid, this pure rng pattern precludes all pure optimizations, so it's effectively weakly pure.
Re: hap.random: a new random number library for D
On Tuesday, 10 June 2014 at 23:08:33 UTC, Chris Cain wrote: 4. I'd just like to say the idea of using ranges for seeds gets me giddy because I could totally see a range that queries https://random.org for true random bits to seed with, wrapped by a range that zeroes out the memory on popFront. Convenient and safe (possibly? Needs review before I get excited, obviously) for crypto purposes! In some scenarios impredictability is not enough. For example, when you generate a session id, an attacker doesn't have to predict it ahead of time, he can guess it at any time later. And if they listen to radio waves - that's an open protocol, an attacker can setup antenna near their antenna and get the same readings. Cryptographic PRNG and quantum TRNG are better isolated, so it's harder to read them.
Re: DMD 2.066 Alpha
On 6/11/14, 11:24 AM, Iain Buclaw via Digitalmars-d-announce wrote: On 11 June 2014 14:19, Andrew Edwards via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 6/11/14, 2:23 AM, deadalnix wrote: I'll be there to test and bug report ! Thank for being the release lieutenant. In my world a lieutenant is absolutely useless. Given the tutelage and guidance of solid staff non-commissioned officer, some day they will become productive members of the community. If they don't find such a mentor however, they will become loose cannons: destroying all in their path. I tend to see life from a different perspective. Officers, in general, are quite useless. They are the good idea fairies who give little, if any, consideration to the ramifications of their ideas/proposals and will stop at nothing to see them come to fruition: regardless of consequences. Worse still, they are absolutely incapable of implementing the ideas/proposals they generate. I prefer a Chief and Indian analogy. The Chief knows what needs to get done and, though she may not know have the tasks required to get the job done, leverages the strengths of the Indians to do so. The Indians provide the skills and know-how, and actually does the work. This community needs far more Chiefs and Indians (arguably more Indians than Chiefs): and way less lieutenants. Oh, wow! That was a pretty long way around to say thank you for your continued support. Nice analogy (and outlook!) Now, as 'Chief' of GDC talking to 'Chief' or D releases, I must say that the release timings are abysmal. At least 2 months overdue. I have only just managed to catch up to 2.065, and that's not due out till the weekend. Things used to be so much easier when releases were less than 2 months apart. You are absolutely correct... I was asked to delay the April and, after that, my personal life took precedence. I am aiming is to get back on track with a two month release cycle. The maintenance releases will remain on a six month cycle though.
Re: DMD 2.066 Alpha
On 6/11/2014 9:19 AM, Andrew Edwards wrote: On 6/11/14, 2:23 AM, deadalnix wrote: I'll be there to test and bug report ! Thank for being the release lieutenant. In my world a lieutenant is absolutely useless. Given the tutelage and guidance of solid staff non-commissioned officer, some day they will become productive members of the community. If they don't find such a mentor however, they will become loose cannons: destroying all in their path. I tend to see life from a different perspective. Officers, in general, are quite useless. They are the good idea fairies who give little, if any, consideration to the ramifications of their ideas/proposals and will stop at nothing to see them come to fruition: regardless of consequences. Worse still, they are absolutely incapable of implementing the ideas/proposals they generate. Reminds me of both MBAs and MASH ;)
Re: DMD 2.066 Alpha
On 11 June 2014 17:56, Andrew Edwards via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 6/11/14, 11:24 AM, Iain Buclaw via Digitalmars-d-announce wrote: On 11 June 2014 14:19, Andrew Edwards via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 6/11/14, 2:23 AM, deadalnix wrote: I'll be there to test and bug report ! Thank for being the release lieutenant. In my world a lieutenant is absolutely useless. Given the tutelage and guidance of solid staff non-commissioned officer, some day they will become productive members of the community. If they don't find such a mentor however, they will become loose cannons: destroying all in their path. I tend to see life from a different perspective. Officers, in general, are quite useless. They are the good idea fairies who give little, if any, consideration to the ramifications of their ideas/proposals and will stop at nothing to see them come to fruition: regardless of consequences. Worse still, they are absolutely incapable of implementing the ideas/proposals they generate. I prefer a Chief and Indian analogy. The Chief knows what needs to get done and, though she may not know have the tasks required to get the job done, leverages the strengths of the Indians to do so. The Indians provide the skills and know-how, and actually does the work. This community needs far more Chiefs and Indians (arguably more Indians than Chiefs): and way less lieutenants. Oh, wow! That was a pretty long way around to say thank you for your continued support. Nice analogy (and outlook!) Now, as 'Chief' of GDC talking to 'Chief' or D releases, I must say that the release timings are abysmal. At least 2 months overdue. I have only just managed to catch up to 2.065, and that's not due out till the weekend. Things used to be so much easier when releases were less than 2 months apart. You are absolutely correct... I was asked to delay the April and, after that, my personal life took precedence. I am aiming is to get back on track with a two month release cycle. The maintenance releases will remain on a six month cycle though. FYI, I have actually collected some stats about DMD vs GDC supported D2 versions and their dates. It's quite interesting, and ends with a guestimation of the 2.067 release date, followed by how long till 2.066 will be merge down into GDC. :-) Maybe this should be posted somewhere, Andrei? http://gdcproject.org/data/gdc-dmd-v2release.svg
Re: hap.random: a new random number library for D
On 6/11/2014 12:35 PM, Kagamin wrote: In some scenarios impredictability is not enough. For example, when you generate a session id, an attacker doesn't have to predict it ahead of time, he can guess it at any time later. And if they listen to radio waves - that's an open protocol, an attacker can setup antenna near their antenna and get the same readings. An interesting point. Cryptographic PRNG and quantum TRNG are better isolated, so it's harder to read them. FWIW, a cryptographic PRNG isn't necessarily well-isolated. Being a PRNG, the isolation of a cryptographic PRNG is primarily limited to two main things: - The isolation of its entropy source(s) (which are not normally part of a crypto-PRNG's specification - it's just left as choose a good one), and - The patterns of how data is drawn from the PRNG. If the entropy source is poorly isolated (via poor choice of entropy source, or a failure within the entropy source), and the requests being made to the PRNG are relatively predictable or even guessable (quite likely given the nature of software), then a cryptographic PRNG won't be any better isolated than, say, the digits of PI. TL;DR: The isolation of a cryptographic PRNG is that of its external entropy source, not the cryptographic PRNG algorithm itself.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Tuesday, 10 June 2014 at 19:36:57 UTC, bearophile wrote: At about 40.42 in the Thoughts on static regex there is written even compile-time printf would be awesome. There is a patch about __ctWrite in GitHug, it should be fixed and merged. Bye, bearophile I wish I'd taken the mic at the end, and 2 days later Adam D. Ruppe said what I was thinking of saying: unit test and debug the CTFE function at runtime and then use it at compile-time when it's ready for production. Yes, Dmitry brought up compiler bugs. But if you write a compile-time UT and it fails, you'll know it wasn't because of your own code because the run-time ones still pass. Maybe there's still a place for something more than pragma msg, but I'd definitely advocate for the above at least in the beginning. If anything, easier ways to write compile-time UTs would be, to me, preferable to a compile-time printf. Atila
Re: Embarrassment of riches: another talk came online today
On Tuesday, 10 June 2014 at 16:30:31 UTC, Andrei Alexandrescu wrote: Leverage - my talk at Lang.NEXT. http://www.reddit.com/r/programming/comments/27sp6r/langnext_2014_leverage_by_andrei_alexandrescu/ https://news.ycombinator.com/newest https://twitter.com/D_Programming/status/476400279160885248 https://www.facebook.com/dlang.org/posts/863665863647096 Andrei I cannot accept 10. .iota; // The space here is unacceptable. Please have the programmer change 10. to 10.0 so that we have 10.0.iota; // Cleaner, obvious, and doesn't look like a typo. Thank you.
Re: Embarrassment of riches: another talk came online today
On Tuesday, 10 June 2014 at 16:30:31 UTC, Andrei Alexandrescu wrote: Leverage - my talk at Lang.NEXT. I think this is one of your better D talks. It's refreshing to see honest admittance of the shortcomings of D's features, although I think a little too much time was spent talking about inconsequential parsing quirks with UFCS (you can write goofy looking code in any language). The GC scan function was a really nice example: short, real, and instructive. In general, I think more example code would help -- it makes everything more concrete. Good job!
Re: Embarrassment of riches: another talk came online today
On Wednesday, 11 June 2014 at 18:06:03 UTC, justme wrote: I cannot accept 10. .iota; // The space here is unacceptable. Please have the programmer change 10. to 10.0 so that we have 10.0.iota; // Cleaner, obvious, and doesn't look like a typo. Thank you. The point wasn't about how best to fix the problem, it was about grammar parsing and what was legal/illegal. 10..iota doesn't parse 10. .ioat does 10.0.iota or 10F.iota are proper solutions for readability.
Re: hap.random: a new random number library for D
On Wednesday, 11 June 2014 at 07:24:11 UTC, Chris Cain wrote: I almost always like all the D posts I see on r/programming, but in general if any language highlighted the efforts in the RNG part of the standard library, I would like it. Too many languages get it wrong or don't care enough about it. (My most basic litmus test is to check a language's shuffle function... Too many fail, even if they claim to do the Knuth shuffle, often they make the small mistakes that matter) It definitely gets my vote for publicizing. http://www.reddit.com/r/programming/comments/27wohj/haprandom_a_new_random_number_library_for_the_d/ :-)
Re: Embarrassment of riches: another talk came online today
On 6/11/14, 11:06 AM, justme wrote: On Tuesday, 10 June 2014 at 16:30:31 UTC, Andrei Alexandrescu wrote: Leverage - my talk at Lang.NEXT. http://www.reddit.com/r/programming/comments/27sp6r/langnext_2014_leverage_by_andrei_alexandrescu/ https://news.ycombinator.com/newest https://twitter.com/D_Programming/status/476400279160885248 https://www.facebook.com/dlang.org/posts/863665863647096 Andrei I cannot accept 10. .iota; // The space here is unacceptable. That was the point made by the talk as well. -- Andrei
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Wednesday, 11 June 2014 at 18:03:06 UTC, Atila Neves wrote: I wish I'd taken the mic at the end, and 2 days later Adam D. Ruppe said what I was thinking of saying: unit test and debug the CTFE function at runtime and then use it at compile-time when it's ready for production. Aye. It wasn't long ago that this wasn't really possible because of how incomplete and buggy CTFE was, you kinda had to do it with special code, but now so much of the language works, there's a good chance if it works at runtime it will work at compile time too. I was really surprised with CTFE a few months ago when I tried to use my dom.d with it... and it actually worked. That's amazing to me. But anyway, in general, the ctfe mixin stuff could be replaced with an external code generator, so yeah that's the way I write them now - as a code generator standalone thing then go back and enum it to actually use. (BTW I also like to generate fairly pretty code, e.g. indentend properly, just because it makes it easier to read.) Yes, Dmitry brought up compiler bugs. But if you write a compile-time UT and it fails, you'll know it wasn't because of your own code because the run-time ones still pass. Yeah, good point too.
Re: John Chapman (Juno), calling for John Chapman (not spam)
I'm looking for the John Chapman who worked as a programmer at Centre-file Ltd, in Finsbury Circus London in 1971. Any leads? Karen
