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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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
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
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
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
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.
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
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
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
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
http://youtu.be/1JZNvKhA3mA
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
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.
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
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,
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
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?
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:
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
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++
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
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/dmd/pull/3655
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
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
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.
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
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
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
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
On Thu, Jun 12, 2014 at 10:35 PM, Rounin via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com 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.
50 matches
Mail list logo
