Re: Lang.NEXT panel
On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu wrote: On 6/12/14, 10:40 AM, Nick Sabalausky wrote: On 6/10/2014 12:35 PM, justme wrote: On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote: Of possible interest. http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/ Andrei IMHO, the coolest thing was when Rob Pike told about the tool they made for automatically upgrading user source code to their next language version. That should be quite easy to implement now in D, and once done, would give much needed room for breaking changes we feel should be done. Pike seemed to be extremely satisfied they did it. Personally, I wouldn't be comfortable trusting such a tool. Besides, I find that upgrading a codebase to a newer language version is one of the most trivial tasks I ever face in software development - even in D. It's a cute trick, but not a worthwhile use of development resources. I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors. I got convinced a dfix tool would be a strategic component of D's offering going forward. Andrei I am strongly in favour of a 'dfix' tool. There exist historical problems with languages, and you really must break them to make things better. Douglas Crockford was pushing for '~' for string concatenation in ECMAScript 6, making '+' do only additon. This would have been very similar to how D handles the two, in an arguably correct manner, but the commity wouldn't agree to it because it would force everyone to change their code. So in the end ES6 is full of features, some useful, most seem nonsensical to me, but it doesn't really fix any of the issues in ES5, because it's almost totally backwards compatible so old code still works. So I think having tools like gofix and deprecation warnings mitigate this issue massively, and it's especially easier when you're using an ahead-of-time compiled language like D. So we can make changes which break code, but just get rid of cruft likely to cause errors. I can't think of nearly as many examples of error-prone things in D that I can think of in ES6, though.
Re: dmd front end now switched to Boost license
On 13/06/14 02:31, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/3655 Awesome. Thanks for opening up to a less restrictive license. -- /Jacob Carlborg
Re: Lang.NEXT panel
On 12/06/14 19:40, Nick Sabalausky wrote: Personally, I wouldn't be comfortable trusting such a tool. Besides, I find that upgrading a codebase to a newer language version is one of the most trivial tasks I ever face in software development - even in D. It's a cute trick, but not a worthwhile use of development resources. I think the complete opposite. I migrated a Rails 2.3 app to Rails 3.x and from Ruby 1.8 to 1.9, it was an enormous task. Took probably six months. Also, it doesn't help to not have any tests and Ruby code in the database. -- /Jacob Carlborg
Re: Embarrassment of riches: another talk came online today
On 13/06/14 00:47, Dmitry Olshansky wrote: Seems ironic to say that D has no legacy baggage compared to C++ and then have a readily served self-defeat with the goofy 10. and .1 being supported for the sake of compatibility with C :) Is that still supported? I thought it was removed to be able to implement UFCS. -- /Jacob Carlborg
Re: dmd front end now switched to Boost license
On Friday, 13 June 2014 at 00:31:32 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/3655 Glad to hear it. Boost is such a simple license.
Re: Pushing D's mixin to the limits: Project Euler Problem 61 from Ruby to D by David Oftedal
On Thursday, 12 June 2014 at 20:35:39 UTC, Rounin wrote: Hey there! Yeah, to expect people to register on LiveJournal in this age of Facebook... Sorry about that; It must have been to deter the spammers. I don't leave comments if it is run through facebook, maybe one day. There should be settings in LJ to allow anonymous comments. Its what I've done (I also turned off approval since I've had good comments come in and no spam).
Re: Pushing D's mixin to the limits: Project Euler Problem 61 from Ruby to D by David Oftedal
On Thu, Jun 12, 2014 at 10:35 PM, Rounin via Digitalmars-d-announce
wrote:
> Hey there!
Oh cool, thanks for answering!
> Yeah, to expect people to register on LiveJournal in this age of Facebook...
> Sorry about that; It must have been to deter the spammers.
Sorry for whining about it. I'm not on Facebook either, I just find it
a bit bothersome to have to register every time I want to let a
comment. I suppose I'm too used to always commenting in the same
places and am leery to getting outside my comfort zones :-)
> Thanks for taking the time to comment! Your solution with the single call to
> mixin() is much more elegant. I made a version 2 which uses it.
>
> The reason I used a double mixin() was that the first thing I tried was
> mixin("foreach() etc. etc."), which I think may have failed due to the
> foreach, then mixin("defineMain();"); , which was interpreted as a function
> declaration, and then I went straight for the mixin("mixin()"); . If it
> ain't broke, et cetera.
>
> I still think the double mixin() can compete in terms of comedy value,
> though, don't you think?
mixin("..."); pastes the inside code where the mixin is. So there is
no real reason to mix a pure string like mixin("defineMain()"), since
you could directly write it into your code. As for foreach, I guess
it's because foreach is not a declaration and you cannot put it at the
module level:
module foo;
foreach(i; 0..10) {}
is illegal code, I suppose. Mixin or not.
In fact, you'll probably never see
mixin("some predefined code");
what is used is
mixin("some code" ~ some external value ~ "more code");
or
mixin(foo(args));
where foo returns a string.
> Also, thanks for pointing out UFCS. It seems like a very convenient, not to
> mention SANE alternative to monkey patching, and it'll make it even more
> seamless to port code that makes use of that mechanism.
Cool! Again, thanks for an interesting article.
Re: DMD 2.066 Alpha
On 6/12/14, 8:49 PM, Nick Sabalausky wrote: On 6/12/2014 11:13 PM, Andrei Alexandrescu wrote: On 6/12/14, 7:26 PM, Daniel Murphy wrote: It 1. allows escaping final, which we can't do without it or an equivalent 2. does exactly what everybody expects 3. is already implemented 4. looks much nicer than your proposal Why not just leave it in? I'm already using it, and it makes extern(C++) classes MUCH more readable (ie DDMD) Please no new keyword for what can be done already. It's not proportional response. AFAIK, escaping final *can't* be done. It can be worked around. -- Andrei
Re: DMD 2.066 Alpha
On 6/12/2014 11:13 PM, Andrei Alexandrescu wrote: On 6/12/14, 7:26 PM, Daniel Murphy wrote: It 1. allows escaping final, which we can't do without it or an equivalent 2. does exactly what everybody expects 3. is already implemented 4. looks much nicer than your proposal Why not just leave it in? I'm already using it, and it makes extern(C++) classes MUCH more readable (ie DDMD) Please no new keyword for what can be done already. It's not proportional response. AFAIK, escaping final *can't* be done.
Re: DMD 2.066 Alpha
On 6/12/14, 7:26 PM, Daniel Murphy wrote: "Andrei Alexandrescu" wrote in message news:lncrb0$31ec$1...@digitalmars.com... > It was decided and 100% certain - "virtual" is not going in. Need to > remove it from DMD before this release is out. Yes please. -- Andrei You did say that something with the same effect as 'virtual' was going in. No. It 1. allows escaping final, which we can't do without it or an equivalent 2. does exactly what everybody expects 3. is already implemented 4. looks much nicer than your proposal Why not just leave it in? I'm already using it, and it makes extern(C++) classes MUCH more readable (ie DDMD) Please no new keyword for what can be done already. It's not proportional response. Andrei
Re: DMD 2.066 Alpha
On 6/12/14, 5:50 PM, Nick Sabalausky wrote: On 6/12/2014 8:06 PM, Andrei Alexandrescu wrote: I don't think it's that important. And definitely there's no ignoring going on. There are plenty of things that are plenty more important, Wait, so now we're rejecting work that isn't at the right priority level? No. I am rejecting work I do not agree with. Some people did seem to find "final:" (and therefore "virtual") important to them, so this really seems to fly in the face of the DConf talk about D development involving people "scratching their own itches". I am sorry, this angle is completely mistaken. Andrei
Re: DMD 2.066 Alpha
"Andrei Alexandrescu" wrote in message news:lncrb0$31ec$1...@digitalmars.com... > It was decided and 100% certain - "virtual" is not going in. Need to > remove it from DMD before this release is out. Yes please. -- Andrei You did say that something with the same effect as 'virtual' was going in. It 1. allows escaping final, which we can't do without it or an equivalent 2. does exactly what everybody expects 3. is already implemented 4. looks much nicer than your proposal Why not just leave it in? I'm already using it, and it makes extern(C++) classes MUCH more readable (ie DDMD)
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Thursday, 12 June 2014 at 08:42:49 UTC, Dmitry Olshansky wrote: 11-Jun-2014 22:03, Atila Neves пишет: 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, that's a starting point - a function working at R-T. 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. It doesn't help that it's not your fault :) And with a bit of __ctfe's to workaround compiler bugs you won't be so sure of your code anymore. 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. There is nice assertCTFEable written by Kenji in Phobos. I think it's our private magic for now but I see no reason not to expose it somewhere. Atila It helps; you won't lose time looking at your code and wondering. I thought of the __cfte problem though: that would mean different code paths and what I said wouldn't be valid anymore. Atila
Re: DMD 2.066 Alpha
On 6/12/2014 8:06 PM, Andrei Alexandrescu wrote: I don't think it's that important. And definitely there's no ignoring going on. There are plenty of things that are plenty more important, Wait, so now we're rejecting work that isn't at the right priority level? Some people did seem to find "final:" (and therefore "virtual") important to them, so this really seems to fly in the face of the DConf talk about D development involving people "scratching their own itches".
Re: DMD 2.066 Alpha
On 6/12/2014 8:06 PM, Andrei Alexandrescu wrote: and final/virtual functions can already be done easily. But "final:" can't.
dmd front end now switched to Boost license
https://github.com/D-Programming-Language/dmd/pull/3655
Re: DMD 2.066 Alpha
On 6/12/14, 3:25 PM, Kapps wrote: On Thursday, 12 June 2014 at 18:25:36 UTC, Andrei Alexandrescu wrote: On 6/12/14, 6:34 AM, Dicebot wrote: On Wednesday, 11 June 2014 at 02:01:24 UTC, 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 It was decided and 100% certain - "virtual" is not going in. Need to remove it from DMD before this release is out. Yes please. -- Andrei That's pretty disappointing. Something similar to virtual is necessary, and that something should be actually clean, readable, and obvious. The proposed final(false), while it is generic, is long and ugly, a double negative (not not overridable), and not nicely readable / obvious. Best of all, it's simply another important thing that continues to never see any progress as it gets further ignored. I don't think it's that important. And definitely there's no ignoring going on. There are plenty of things that are plenty more important, and final/virtual functions can already be done easily. Andrei
Re: hap.random: a new random number library for D
On Thursday, 12 June 2014 at 21:51:28 UTC, Joseph Rushton Wakeling wrote: A few things I'd really like to hear back on, if anyone can give them a go: ... obviously I have tested the above myself, but "Works for me" is not a valid quality control strategy ;-) The other thing I'd really like to know about is how the effectiveness of stuff like sample and cover is affected by the transition to classes. For RNGs I doubt it will be much, because one tends to allocate and initialize the RNG quite high-up in the application and then pass it to the internals. By contrast something like sample() might well be called extensively in various inner loops of the program, and the fact that each call involves a class being allocated could be problematic in terms of triggering the GC.
Re: Embarrassment of riches: another talk came online today
10-Jun-2014 20:30, Andrei Alexandrescu пишет: "Leverage" - my talk at Lang.NEXT. Loved the title at first site and indeed the talk was great. It's definitely something I'd show people to get them into D, honest and intriguing. Seems ironic to say that D has no legacy baggage compared to C++ and then have a readily served self-defeat with the goofy 10. and .1 being supported for the sake of compatibility with C :) -- Dmitry Olshansky
Re: Lang.NEXT panel
On Thursday, 12 June 2014 at 20:48:10 UTC, Dicebot wrote: On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu wrote: I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors. I got convinced a dfix tool would be a strategic component of D's offering going forward. It essentially comes down to persistent compiler-as-a-library issue :( Tools like dscanner can help with some of more simple transition cases but anything more complicated is likely to require full semantic analysis. If only we had such a tool !
Re: DMD 2.066 Alpha
On Thursday, 12 June 2014 at 18:25:36 UTC, Andrei Alexandrescu wrote: On 6/12/14, 6:34 AM, Dicebot wrote: On Wednesday, 11 June 2014 at 02:01:24 UTC, 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 It was decided and 100% certain - "virtual" is not going in. Need to remove it from DMD before this release is out. Yes please. -- Andrei That's pretty disappointing. Something similar to virtual is necessary, and that something should be actually clean, readable, and obvious. The proposed final(false), while it is generic, is long and ugly, a double negative (not not overridable), and not nicely readable / obvious. Best of all, it's simply another important thing that continues to never see any progress as it gets further ignored. The actual pull to add virtual had multiple pings, but the only response after being told that it was coming (along with final-by-default), was that it wouldn't be in 2.065 because that was a bug fix release. Three months later (after 2.065 came out) it actually got pulled, but this was only because someone else pulled it, at which point you expressed your disappointment at it being pulled. Then the issue again continued to be ignored for another 3.5 months after that while the keyword remained in git master the entire time. There's always talk of making things actually happen and that the community needing to step up to make them happen, yet people *have* stepped up to do all of this and been continually ignored. Even after being told final-by-default would not happen, it was (I believe?) said that a way of going virtual -> final would be added, allowing people to actually use 'final:'. But again, nothing came from that. We went from agreeing on final by default, to *possibly* getting an ugly way of going from final: -> virtual, provided that something is actually done about it instead of it being ignored further. It's been over a year since the original discussion of final by default, and agreement that *something* should be done, but in the past year absolutely nothing has happened related to it and no signs exist of anything happening in the next year either.
Re: Lang.NEXT panel
On Tuesday, 10 June 2014 at 16:35:23 UTC, justme wrote: That should be quite easy to implement now in D What makes you say this?
Re: hap.random: a new random number library for D
On Monday, 9 June 2014 at 18:09:21 UTC, Joseph Rushton Wakeling wrote: 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: A few things I'd really like to hear back on, if anyone can give them a go: * try using hap.random via rdmd -- does it work? * try making a dub package dependent on hap.random -- does it work? * try importing only some, not all, of the hap.random modules (e.g. import hap.random.generator) -- does this still work? * how does it work for people on non-Linux OS's? Thanks! -- Joe
Re: Lang.NEXT panel
On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu wrote: I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors. I got convinced a dfix tool would be a strategic component of D's offering going forward. It essentially comes down to persistent compiler-as-a-library issue :( Tools like dscanner can help with some of more simple transition cases but anything more complicated is likely to require full semantic analysis.
Re: Lang.NEXT panel
Yes! That is only one of the reasons to have that ability. Almost more important is automated reasoning about very large codebases. What are the global properties? Where are the "antipatterns" of use and can we fix them? Can we "lint" away large classes of defects? Even Stroustrup believes such tools would be useful for C++. On Fri, Jun 13, 2014 at 5:53 AM, Andrei Alexandrescu via Digitalmars-d-announce wrote: > On 6/12/14, 10:40 AM, Nick Sabalausky wrote: > >> On 6/10/2014 12:35 PM, justme wrote: >> >>> On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote: >>> Of possible interest. http://www.reddit.com/r/programming/comments/278twt/ panel_systems_programming_in_2014_and_beyond/ Andrei >>> >>> IMHO, the coolest thing was when Rob Pike told about the tool they made >>> for automatically upgrading user source code to their next language >>> version. >>> >>> That should be quite easy to implement now in D, and once done, would >>> give much needed room for breaking changes we feel should be done. Pike >>> seemed to be extremely satisfied they did it. >>> >> >> Personally, I wouldn't be comfortable trusting such a tool. Besides, I >> find that upgrading a codebase to a newer language version is one of the >> most trivial tasks I ever face in software development - even in D. >> >> It's a cute trick, but not a worthwhile use of development resources. >> > > I very much think the opposite, drawing from many years of hacking into > large codebases. I'm completely with Rob here. On a large codebase, even > the slightest manual or semi-manual change is painstaking to plan and > execute, and almost always suffers of human errors. > > I got convinced a dfix tool would be a strategic component of D's offering > going forward. > > > Andrei > > -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. --
Re: Pushing D's mixin to the limits: Project Euler Problem 61 from Ruby to D by David Oftedal
On Thursday, 12 June 2014 at 20:35:39 UTC, Rounin wrote: I still think the double mixin() can compete in terms of comedy value, though, don't you think? That was actually my initial guess when having a quick look trough the code samples :) "true D programmers mixin their mixins"
Re: Pushing D's mixin to the limits: Project Euler Problem 61 from Ruby to D by David Oftedal
Hey there!
Yeah, to expect people to register on LiveJournal in this age of
Facebook... Sorry about that; It must have been to deter the
spammers.
Thanks for taking the time to comment! Your solution with the
single call to mixin() is much more elegant. I made a version 2
which uses it.
The reason I used a double mixin() was that the first thing I
tried was mixin("foreach() etc. etc."), which I think may have
failed due to the foreach, then mixin("defineMain();"); , which
was interpreted as a function declaration, and then I went
straight for the mixin("mixin()"); . If it ain't broke, et cetera.
I still think the double mixin() can compete in terms of comedy
value, though, don't you think?
Also, thanks for pointing out UFCS. It seems like a very
convenient, not to mention SANE alternative to monkey patching,
and it'll make it even more seamless to port code that makes use
of that mechanism.
Re: DConf 2014 Day 1 Talk 5: Experience Report: Using D at Facebook and Beyond by Adam Simpkins
http://youtu.be/1JZNvKhA3mA
Re: Pushing D's mixin to the limits: Project Euler Problem 61 from Ruby to D by David Oftedal
Drat, I need a livejournal account to post comments? Well, I can at
least create a reddit account, I guess...
"In the Ruby version, I was able to add the methods directly to the
Integer class, using what's known as monkey patching, allowing me to
make calls like3.pentagonal. In D, the methods are global instead, so
the call would be pentagonal(3)."
Hmm, 3.pentagonal is valid D code. If that makes it more palatable to
Rubyists, that's good news.
There is something I don't get:
"The doublemixins with the method calls also took a while to figure
out, after the convenience of eval"
That is:
mixin("mixin(defineMain());");
I don't understand why he's doing that. AFAICT, simply using
mixin(defineMain());
would work perfectly, no? (defineMain and his other functions return strings).
Pushing D's mixin to the limits: Project Euler Problem 61 from Ruby to D by David Oftedal
http://rounin.livejournal.com/24639.html http://www.reddit.com/r/programming/comments/27zjd5/pushing_ds_mixin_to_the_limits_project_euler/ https://www.facebook.com/dlang.org/posts/864930913520591 https://twitter.com/D_Programming/status/477162603140374528 Andrei
Re: DMD 2.066 Alpha
On 6/12/14, 6:34 AM, Dicebot wrote: On Wednesday, 11 June 2014 at 02:01:24 UTC, 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 It was decided and 100% certain - "virtual" is not going in. Need to remove it from DMD before this release is out. Yes please. -- Andrei
Re: hap.random: a new random number library for D
On Thursday, 12 June 2014 at 17:35:39 UTC, Nick Sabalausky wrote: Naturally, it doesn't yet exist in hap.random because, as Joseph said, hap.random's "step one" is to match the current std.random as closely as possible. I'd be happy to put together a PR to adapt my RNG stuff above to hap.random whenever it would be desired. Wow! Looks great :) Thanks for all the work on that.
Re: Lang.NEXT panel
On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu wrote: On 6/12/14, 10:40 AM, Nick Sabalausky wrote: On 6/10/2014 12:35 PM, justme wrote: On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote: Of possible interest. http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/ Andrei IMHO, the coolest thing was when Rob Pike told about the tool they made for automatically upgrading user source code to their next language version. That should be quite easy to implement now in D, and once done, would give much needed room for breaking changes we feel should be done. Pike seemed to be extremely satisfied they did it. Personally, I wouldn't be comfortable trusting such a tool. Besides, I find that upgrading a codebase to a newer language version is one of the most trivial tasks I ever face in software development - even in D. It's a cute trick, but not a worthwhile use of development resources. I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors. I got convinced a dfix tool would be a strategic component of D's offering going forward. Andrei I thought the same. I was considering writing it, actually. Imagine how having the tool would have influenced the "final by default" discussion. Amongst others, of course. Atila
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On 6/12/14, 4:04 AM, dennis luehring wrote: you should write a big top post about your CTFE experience/problems - it is important enough yes please
Re: Lang.NEXT panel
On 6/12/14, 10:40 AM, Nick Sabalausky wrote: On 6/10/2014 12:35 PM, justme wrote: On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote: Of possible interest. http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/ Andrei IMHO, the coolest thing was when Rob Pike told about the tool they made for automatically upgrading user source code to their next language version. That should be quite easy to implement now in D, and once done, would give much needed room for breaking changes we feel should be done. Pike seemed to be extremely satisfied they did it. Personally, I wouldn't be comfortable trusting such a tool. Besides, I find that upgrading a codebase to a newer language version is one of the most trivial tasks I ever face in software development - even in D. It's a cute trick, but not a worthwhile use of development resources. I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors. I got convinced a dfix tool would be a strategic component of D's offering going forward. Andrei
Re: Lang.NEXT panel
On 6/10/2014 12:35 PM, justme wrote: On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote: Of possible interest. http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/ Andrei IMHO, the coolest thing was when Rob Pike told about the tool they made for automatically upgrading user source code to their next language version. That should be quite easy to implement now in D, and once done, would give much needed room for breaking changes we feel should be done. Pike seemed to be extremely satisfied they did it. Personally, I wouldn't be comfortable trusting such a tool. Besides, I find that upgrading a codebase to a newer language version is one of the most trivial tasks I ever face in software development - even in D. It's a cute trick, but not a worthwhile use of development resources.
Re: hap.random: a new random number library for D
On 6/12/2014 4:49 AM, Chris Cain wrote: Also, it has suggestions for entropy on Windows (CryptGenRandom) which is something that will be necessary as well. It should be RtlGenRandom: It's used by CryptGenRandom, it loads/requires/involves far less unnecessary cruft, and it's well-established as *not* being something MS even *could* change/remove even if they wanted to (due to some of they ways MS themselves already rely on it): http://blogs.msdn.com/b/michael_howard/archive/2005/01/14/353379.aspx But this updated system entropy generator you suggest already exists: https://github.com/D-Programming-Language/phobos/pull/2208/files#diff-713ce153554afc99a07767cc8ba940aeR1189 https://github.com/D-Programming-Language/phobos/pull/2208/files#diff-713ce153554afc99a07767cc8ba940aeR1106 It's also ready-to-use as part of DAuth (which I admit might need a new name to avoid confusion with the totally unrelated OAuth): https://github.com/Abscissa/DAuth/blob/master/src/dauth/hashdrbg.d#L51 https://github.com/Abscissa/DAuth/blob/master/src/dauth/hashdrbg.d#L201 Naturally, it doesn't yet exist in hap.random because, as Joseph said, hap.random's "step one" is to match the current std.random as closely as possible. I'd be happy to put together a PR to adapt my RNG stuff above to hap.random whenever it would be desired.
DConf 2014 Day 1 Talk 5: Experience Report: Using D at Facebook and Beyond by Adam Simpkins
https://news.ycombinator.com/newest (please upvote, things get buried there quickly) https://twitter.com/D_Programming/status/477139782334963712 https://www.facebook.com/dlang.org/posts/864887076858308 http://www.reddit.com/r/programming/comments/27za5z/dconf_2014_day_1_talk_5_experience_report_using_d/ Yet another great talk. Enjoy! Andrei
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
12-Jun-2014 16:25, Dicebot пишет: On Thursday, 12 June 2014 at 09:17:45 UTC, Dmitry Olshansky wrote: This one thing I'm loosing sleep over - what precisely is so good in CTFE code generation in _practical_ context (DSL that is quite stable, not just tiny helpers)? By the end of day it's just about having to write a trivial line in your favorite build system (NOT make) vs having to wait for a couple of minutes each build hoping the compiler won't hit your system's memory limits. Oh, this is a very good question :) There are two unrelated concerns here: It's always nice to ask something on D NG, so many good answers I can hardly choose whom to reply ;) So this is kind of broadcast. Yes, the answer seems spot on - reflection! But allow me to retort. I'm not talking about completely stand-alone generator. Just as well generator tool could be written in D using the same exact sources as your D program does. Including the static introspection and type-awareness. Then generator itself is a library + "an invocation script" in D. The Q is specifically of CTFE in this scenario, including not only obvious shortcomings of design, but fundamental ones of compilation inside of compilation. Unlike proper compilation is has nothing persistent to back it up. It feels backwards, a bit like C++ TMP but, of course, much-much better. 1) Reflection. It is less of an issue for pure DSL solutions because those don't provide any good reflection capabilities anyway, but other code generation approaches have very similar problems. By doing all code generation in separate build step you potentially lose many of guarantees of keeping various parts of your application in sync. Use the same sources for the generator. In essence all is the same, just relying on separate runs and linkage, not mixin. Necessary "hooks" to link to later could indeed be generated with a tiny bit of CTFE. Yes, deeply embedded stuff might not be that easy. The scope and damage is smaller though. 2) Moving forward. You use traditional reasoning of DSL generally being something rare and normally stable. This fits most common DSL usage but tight in-language integration D makes possible brings new opportunities of using DSL and code generation casually all other your program. Well, I'm biased by heavy-handed ones. Say I have a (no longer) secret plan of doing a next-gen parser generator in D. Needless to say swaths of non-trivial code generation. I'm all for embedding nicely but I see very little _practical_ gains in CTFE+mixin here EVEN if CTFE wouldn't suck. See the point above about using the same metadata and types as the user application would. I totally expect programming culture to evolve to the point where something like 90% of all application code is being generated in typical project. D has good base for promoting such paradigm switch and reducing any unnecessary mental context switches is very important here. This was pretty much the point I was trying to make with my DConf talk ( and have probably failed :) ) I liked the talk, but you know ... 4th or 5th talk with CTFE/mixin I think I might have been distracted :) More specifically this bright future of 90%+ concise DSL driven programs is undermined by the simple truth - no amount of improvement in CTFE would make generators run faster then optimized standalone tool invocation. The tool (library written in D) may read D metadata just fine. I heard D builds times are important part of its adoption so... And these couple of minutes are more like 30 minutes at a times. Worse yet unlike proper build system it doesn't keep track of actual changes (same regex patterns get recompiled over and over), at this point seamless integration into the language starts felling like a joke. And speaking of seamless integration: just generate a symbol name out of pattern at CTFE to link to later, at least this much can be done relatively fast. And voila even the clunky run-time generation is not half-bad at integration. Unless things improve dramatically CTFE code generation + mixin is just our funny painful toy. Unfortunately current implementation of frontend falls behind language capabilities a lot. There are no fundamental reasons why it can't work with better compiler. It might solve most of _current_ problems, but I foresee fundamental issues of "no global state" in CTFE that in say 10 years from now would look a lot like `#include` in C++. A major one is there is no way for compiler to not recompile generated code as it has no knowledge of how it might have changed from the previous run. In fact, deadlnix has made a very good case for SDC taking over as next D frontend exactly because of things like CTFE JIT. Yeah, we ought to help him! -- Dmitry Olshansky
Re: Soon be using D with Google App Engine via Managed VMs
I didn't see anything in the article, but can you still use CloudSQL and similar from inside of one of those containers without using Java/Go/whatever else is supported by App Engine?
Re: QtE - D small binding for Qt.
On Wednesday, 11 June 2014 at 10:20:39 UTC, MGW wrote: Example of D (dmd 2.065 64) with Qt 64 Windows64/Linux64. Running programs *.EXE with key "--debug". http://yadi.sk/d/qLE7Kgz9SpKEX This looks pretty good. How much of Qt is usable through this? E.g. I assume nothing templated is usable?
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Thursday, 12 June 2014 at 09:17:45 UTC, Dmitry Olshansky wrote: This one thing I'm loosing sleep over - what precisely is so good in CTFE code generation in _practical_ context (DSL that is quite stable, not just tiny helpers)? I've asked this same question before and my answer is mostly the same as dicebot: I think reflection is the important bit. Of course, even there it is sometimes useful to break it into two steps (one just prints the data out kinda like dmd -X then a regular program reads it and generates the code), but I find it really useful to read D code and generate stuff based on that. By the end of day it's just about having to write a trivial line in your favorite build system (NOT make) it is actually pretty trivial in make too...
Re: hap.random: a new random number library for D
On Thursday, 12 June 2014 at 08:49:45 UTC, Chris Cain wrote: Well, the ultimate conclusion of the conversation with the guy is that: 1. ISAAC probably isn't cryptographically secure. Despite not having found any attacks, it just isn't proof of security. It's not been looked at enough to really approve of its usage for that purpose (I'm kind of agreeing with this) 2. ISAAC in his opinion probably isn't appropriate for non secure uses for much the same reason. I don't agree with that because everything I've seen for ISAAC shows that it has some really good statistical properties. Even if it's not cryptographically secure, it appears to produce "better" pseudorandom numbers to me than something like MT19937 or Well* (and ISAAC is really fast after the initial cost has been paid back) This comes back to another necessary project -- there needs to be a decent suite of tests of randomness for D. I think in this case it's probably best to try and wrap TestU01 etc. In the circumstances, it sounds like ISAAC would be better placed in hap.random.generator than hap.random.crypto, though. Ultimately, I think ISAAC (and ISAAC-64) _will_ get more scrutiny in the future as it's a PRNG used in Rust, for instance. I would not suggest it for default purposes, but I think having it as a non-crypto RNG in D wouldn't be a bad idea for those who want to choose to use it. Yea, this would be great. 3. Better ideas for crypto PRNGs are AES-CTR or Salsa20. I agree with this approach for the crypto section of std.random. I'd also suggest Blum Blum Shub as another thing to add. It's awfully slow, but it's probably one of the few PRNGs that is "provably strong" (that is, it's been reduced to a known hard problem). Sounds good. Also, he suggested me to refer to a presentation he made last year: http://aumasson.jp/data/talks/randomness_hackepfl13.pdf I'll give this a glance when I get home -- one thing I should probably do is collate a reference list for future hap.random development. I've gone through it and it looks like excellent reference material. Note slide 76 saying: "Don't use RaaS (things like random.org) -> random bits may be shared or reused". Also, it has suggestions for entropy on Windows (CryptGenRandom) which is something that will be necessary as well. Sounds excellent. I agree entirely about random.org, although I still think we should provide access to it via hap.random.device -- we should just surround it with necessary caveats. Overall, very enlightening. Thanks for the research! :-)
Re: DMD 2.066 Alpha
On Wednesday, 11 June 2014 at 02:01:24 UTC, 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 It was decided and 100% certain - "virtual" is not going in. Need to remove it from DMD before this release is out.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Thursday, 12 June 2014 at 12:49:23 UTC, Timon Gehr wrote: On 06/12/2014 02:31 PM, Dicebot wrote: Compiler can cache return value of function that get called from inside mixin statement (for a given argument set). As CTFE is implicitly pure (no global state at compile-time) later generated code can be simply re-used for same argument set. > Re-using it between compiler invocations is more tricky because it is only legal if generator function and all stuff they indirectly use have not changed too. Ignoring this requirement can result in nasty build issues that are only fixed by clean build. Too harmful in my opinion. Clearly, nirvana is continuous compilation, where the compiler performs explicit dependency management at the level of nodes in the syntax tree. Yeah I was wondering if we can merge some of rdmd functionality into compiler to speed up rebuilds and do better dependency tracking. But I am not sure it can fit nicely into current frontend architecture.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On 06/12/2014 02:31 PM, Dicebot wrote: Compiler can cache return value of function that get called from inside mixin statement (for a given argument set). As CTFE is implicitly pure (no global state at compile-time) later generated code can be simply re-used for same argument set. > Re-using it between compiler invocations is more tricky because it is only legal if generator function and all stuff they indirectly use have not changed too. Ignoring this requirement can result in nasty build issues that are only fixed by clean build. Too harmful in my opinion. Clearly, nirvana is continuous compilation, where the compiler performs explicit dependency management at the level of nodes in the syntax tree.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Thursday, 12 June 2014 at 12:31:09 UTC, Dicebot wrote: On Thursday, 12 June 2014 at 10:40:56 UTC, Colin wrote: Maybe a change to the compiler to write any mixin'd string out to a temporary file (along with some identifier information and the line of code that generated it) and at the next compilation time try reading it back from that file iff the line of code that generated it hasnt changed? Then, there'd be no heavy work for the compiler to do, apart from read that file in to a string. Compiler can cache return value of function that get called from inside mixin statement (for a given argument set). As CTFE is implicitly pure (no global state at compile-time) later generated code can be simply re-used for same argument set. Re-using it between compiler invocations is more tricky because it is only legal if generator function and all stuff they indirectly use have not changed too. Ignoring this requirement can result in nasty build issues that are only fixed by clean build. Too harmful in my opinion. Yeah, it quite dangerous I agree. I was only thinking of a solution to the problem above where a ctRegex is compiled every time, whether it was changed or not. I'm sure theres some way of keeping track of all dependent D modules filename, and if any of them have been changed in the chain, recalculate the string mixin. Only trouble with that is, there'd be a good chunk of checking for every mixin, and would slow the compiler down in normal use cases.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Thursday, 12 June 2014 at 10:40:56 UTC, Colin wrote: Maybe a change to the compiler to write any mixin'd string out to a temporary file (along with some identifier information and the line of code that generated it) and at the next compilation time try reading it back from that file iff the line of code that generated it hasnt changed? Then, there'd be no heavy work for the compiler to do, apart from read that file in to a string. Compiler can cache return value of function that get called from inside mixin statement (for a given argument set). As CTFE is implicitly pure (no global state at compile-time) later generated code can be simply re-used for same argument set. Re-using it between compiler invocations is more tricky because it is only legal if generator function and all stuff they indirectly use have not changed too. Ignoring this requirement can result in nasty build issues that are only fixed by clean build. Too harmful in my opinion.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Thursday, 12 June 2014 at 09:17:45 UTC, Dmitry Olshansky wrote: This one thing I'm loosing sleep over - what precisely is so good in CTFE code generation in _practical_ context (DSL that is quite stable, not just tiny helpers)? By the end of day it's just about having to write a trivial line in your favorite build system (NOT make) vs having to wait for a couple of minutes each build hoping the compiler won't hit your system's memory limits. Oh, this is a very good question :) There are two unrelated concerns here: 1) Reflection. It is less of an issue for pure DSL solutions because those don't provide any good reflection capabilities anyway, but other code generation approaches have very similar problems. By doing all code generation in separate build step you potentially lose many of guarantees of keeping various parts of your application in sync. 2) Moving forward. You use traditional reasoning of DSL generally being something rare and normally stable. This fits most common DSL usage but tight in-language integration D makes possible brings new opportunities of using DSL and code generation casually all other your program. I totally expect programming culture to evolve to the point where something like 90% of all application code is being generated in typical project. D has good base for promoting such paradigm switch and reducing any unnecessary mental context switches is very important here. This was pretty much the point I was trying to make with my DConf talk ( and have probably failed :) ) And these couple of minutes are more like 30 minutes at a times. Worse yet unlike proper build system it doesn't keep track of actual changes (same regex patterns get recompiled over and over), at this point seamless integration into the language starts felling like a joke. And speaking of seamless integration: just generate a symbol name out of pattern at CTFE to link to later, at least this much can be done relatively fast. And voila even the clunky run-time generation is not half-bad at integration. Unless things improve dramatically CTFE code generation + mixin is just our funny painful toy. Unfortunately current implementation of frontend falls behind language capabilities a lot. There are no fundamental reasons why it can't work with better compiler. In fact, deadlnix has made a very good case for SDC taking over as next D frontend exactly because of things like CTFE JIT.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On 06/12/14 11:17, Dmitry Olshansky via Digitalmars-d-announce wrote: > This one thing I'm loosing sleep over - what precisely is so good in CTFE > code generation in _practical_ context (DSL that is quite stable, not just > tiny helpers)? Language integration; direct access to meta data (such as types, but also constants). > By the end of day it's just about having to write a trivial line in your > favorite build system (NOT make) vs having to wait for a couple of minutes > each build hoping the compiler won't hit your system's memory limits. If it really was only about an extra makefile rule then CTFE wouldn't make much difference; it would just be an explicitly-requested smarter version of constant folding. But that is not the case. Simple example: create a function that implements an algorithm which is derived from some type given to it as input. /Derived/ does not mean that it only contains some conditionally executed code that depends on some property of that type; it means that the algorithm itself is determined from the type. With the external-generator solution you can emit a templated function, but what you can *not* do is emit code based on meta-data or CT introspection - because the necessary data simply isn't available when the external generator runs. With CTFE you have direct access to all the data and generating the code becomes almost trivial. It makes a night-and-day type of difference. While you could implement a sufficiently-smart-generator that could handle some subset of the functionality of CTFE, it would be prohibitively expensive to do so, wouldn't scale and would often be pointless, if you had to resort to generating code containing mixin expressions anyway. There's a reason why this isn't done in other languages that don't have CTFE. > Unless things improve dramatically CTFE code generation + mixin is just our > funny painful toy. The code snippets posted here are of course just toy programs. This does not mean that CTFE and mixins are merely toys, they enable writing code in ways that just isn't practically possible in other languages. The fact that there isn't much such publicly available code is just a function of D's microscopic user base. Real Programmers write mixins that write mixins. artur
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Tuesday, 10 June 2014 at 17:19:42 UTC, Dicebot wrote: On Tuesday, 10 June 2014 at 15:37:11 UTC, Andrei Alexandrescu wrote: Watch, discuss, upvote! https://news.ycombinator.com/newest https://twitter.com/D_Programming/status/476386465166135296 https://www.facebook.com/dlang.org/posts/863635576983458 http://www.reddit.com/r/programming/comments/27sjxf/dconf_2014_day_1_talk_4_inside_the_regular/ Andrei http://youtu.be/hkaOciiP11c Great talk, just finished watching the youtube upload. I zoned out during the livestream, as it was late over here and I was falling asleep during this fairly technical talk, but now that I'm awake, enjoyed going through it. Never knew how regular expression engines are implemented, good introduction to the topic and how D made your approach easier or harder. A model talk for DConf, particularly given the great results on the regex-dna benchmark.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
Am 12.06.2014 11:17, schrieb Dmitry Olshansky: This one thing I'm loosing sleep over - what precisely is so good in CTFE code generation in_practical_ context (DSL that is quite stable, not just tiny helpers)? By the end of day it's just about having to write a trivial line in your favorite build system (NOT make) vs having to wait for a couple of minutes each build hoping the compiler won't hit your system's memory limits. And these couple of minutes are more like 30 minutes at a times. Worse yet unlike proper build system it doesn't keep track of actual changes (same regex patterns get recompiled over and over), at this point seamless integration into the language starts felling like a joke. And speaking of seamless integration: just generate a symbol name out of pattern at CTFE to link to later, at least this much can be done relatively fast. And voila even the clunky run-time generation is not half-bad at integration. Unless things improve dramatically CTFE code generation + mixin is just our funny painful toy. you should write a big top post about your CTFE experience/problems - it is important enough
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Thursday, 12 June 2014 at 09:17:45 UTC, Dmitry Olshansky wrote: 12-Jun-2014 03:29, Adam D. Ruppe пишет: 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.) And these couple of minutes are more like 30 minutes at a times. Worse yet unlike proper build system it doesn't keep track of actual changes (same regex patterns get recompiled over and over), at this point seamless integration into the language starts felling like a joke. Maybe a change to the compiler to write any mixin'd string out to a temporary file (along with some identifier information and the line of code that generated it) and at the next compilation time try reading it back from that file iff the line of code that generated it hasnt changed? Then, there'd be no heavy work for the compiler to do, apart from read that file in to a string.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
Dmitry Olshansky: Unless things improve dramatically CTFE code generation + An alternative and much faster JITter for LLVM, something like this could make CTFE on LDC2 very quick: http://llvm.org/devmtg/2014-04/PDFs/LightningTalks/fast-jit-code-generation.pdf Bye, bearophile
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
12-Jun-2014 03:29, Adam D. Ruppe пишет: 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.) This one thing I'm loosing sleep over - what precisely is so good in CTFE code generation in _practical_ context (DSL that is quite stable, not just tiny helpers)? By the end of day it's just about having to write a trivial line in your favorite build system (NOT make) vs having to wait for a couple of minutes each build hoping the compiler won't hit your system's memory limits. And these couple of minutes are more like 30 minutes at a times. Worse yet unlike proper build system it doesn't keep track of actual changes (same regex patterns get recompiled over and over), at this point seamless integration into the language starts felling like a joke. And speaking of seamless integration: just generate a symbol name out of pattern at CTFE to link to later, at least this much can be done relatively fast. And voila even the clunky run-time generation is not half-bad at integration. Unless things improve dramatically CTFE code generation + mixin is just our funny painful toy. -- Dmitry Olshansky
Re: hap.random: a new random number library for D
On Wednesday, 11 June 2014 at 06:41:34 UTC, Joseph Rushton Wakeling wrote: Done :) ... if I get a response, I'll make sure to incorporate everything said. Great, let me know how that goes. :-) Well, the ultimate conclusion of the conversation with the guy is that: 1. ISAAC probably isn't cryptographically secure. Despite not having found any attacks, it just isn't proof of security. It's not been looked at enough to really approve of its usage for that purpose (I'm kind of agreeing with this) 2. ISAAC in his opinion probably isn't appropriate for non secure uses for much the same reason. I don't agree with that because everything I've seen for ISAAC shows that it has some really good statistical properties. Even if it's not cryptographically secure, it appears to produce "better" pseudorandom numbers to me than something like MT19937 or Well* (and ISAAC is really fast after the initial cost has been paid back) Ultimately, I think ISAAC (and ISAAC-64) _will_ get more scrutiny in the future as it's a PRNG used in Rust, for instance. I would not suggest it for default purposes, but I think having it as a non-crypto RNG in D wouldn't be a bad idea for those who want to choose to use it. 3. Better ideas for crypto PRNGs are AES-CTR or Salsa20. I agree with this approach for the crypto section of std.random. I'd also suggest Blum Blum Shub as another thing to add. It's awfully slow, but it's probably one of the few PRNGs that is "provably strong" (that is, it's been reduced to a known hard problem). Also, he suggested me to refer to a presentation he made last year: http://aumasson.jp/data/talks/randomness_hackepfl13.pdf I've gone through it and it looks like excellent reference material. Note slide 76 saying: "Don't use RaaS (things like random.org) -> random bits may be shared or reused". Also, it has suggestions for entropy on Windows (CryptGenRandom) which is something that will be necessary as well. Overall, very enlightening.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
11-Jun-2014 22:03, Atila Neves пишет: 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, that's a starting point - a function working at R-T. 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. It doesn't help that it's not your fault :) And with a bit of __ctfe's to workaround compiler bugs you won't be so sure of your code anymore. 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. There is nice assertCTFEable written by Kenji in Phobos. I think it's our private magic for now but I see no reason not to expose it somewhere. Atila -- Dmitry Olshansky
Soon be using D with Google App Engine via Managed VMs
Can use D (esp. with Vibe.d) with the auto scaling of app engine. http://googlecloudplatform.blogspot.com/2014/06/an-update-on-container-support-on-google-cloud-platform.html
Re: hap.random: a new random number library for D
On Wednesday, 11 June 2014 at 16:35:31 UTC, 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. Cryptographic PRNG and quantum TRNG are better isolated, so it's harder to read them. That's an interesting thought on a potential attack. I wouldn't say "same readings" but similar readings is possible and might make attacks easier. It might not be a bad idea as part of a solution though, since it can be used to supplement other sources of local-machine crypto-grade entropy (since often such sources are exhaustible). But yes, just straight up using it alone appears to have a few critical problems.
