On Wednesday, 8 March 2017 at 22:13:26 UTC, XavierAP wrote:
On Wednesday, 8 March 2017 at 20:00:54 UTC, aberba wrote:
(To make my problem clear, how is D's current state not going
to allow / make it so difficult for developers (who know what
they are doing) to write say Photoshop-scale softw
On Thu, Mar 09, 2017 at 12:21:48AM +, Adam D. Ruppe via Digitalmars-d wrote:
> On Wednesday, 8 March 2017 at 21:34:19 UTC, H. S. Teoh wrote:
> > So I came up with an idea to abstract file contents as a
> > random-access range of ubyte with lazy loading, so that I can
> > rewrite file parsing co
On Wednesday, 8 March 2017 at 21:34:19 UTC, H. S. Teoh wrote:
So I came up with an idea to abstract file contents as a
random-access range of ubyte with lazy loading, so that I can
rewrite file parsing code in the nice
Sounds like what the kernel does when you memory-map a file...
On Wed, Mar 08, 2017 at 10:38:24PM +, XavierAP via Digitalmars-d wrote:
[...]
> Also at least as of 2010 Andrei's book stated that "At the time of
> this writing, SafeD is of alpha quality -- meaning that there may be
> unsafe programs [@safe code blocks] that pass compilation, and safe
> progr
On Wednesday, 8 March 2017 at 22:38:24 UTC, XavierAP wrote:
On Wednesday, 8 March 2017 at 21:02:23 UTC, Moritz Maxeiner
wrote:
[...]
The operating word here being "can". The above is semantically
equivalent (assuming the delegate gets optimized out) to an
unsafe block inside a Rust function.
PSA: please don't feed the trolls.
On Wed, Mar 08, 2017 at 10:03:28PM +, XavierAP via Digitalmars-d wrote:
> On Wednesday, 8 March 2017 at 21:34:19 UTC, H. S. Teoh wrote:
> > While writing a tool for dissecting various file formats, I found a
> > useful coding pattern that helps your D code be cleaner, more
> > modular, and more
On Wednesday, 8 March 2017 at 22:43:49 UTC, XavierAP wrote:
On Wednesday, 8 March 2017 at 21:25:41 UTC, Jack Stouffer wrote:
On Wednesday, 8 March 2017 at 20:21:24 UTC, deadalnix wrote:
https://www.youtube.com/watch?v=dIageYT0Vgg
If anyone wanted a manual on "How to Build an Echo-Chamber", I
On Wednesday, 8 March 2017 at 21:25:41 UTC, Jack Stouffer wrote:
On Wednesday, 8 March 2017 at 20:21:24 UTC, deadalnix wrote:
https://www.youtube.com/watch?v=dIageYT0Vgg
If anyone wanted a manual on "How to Build an Echo-Chamber", I
would advise you to watch this video starting at about the 7
On Wednesday, 8 March 2017 at 21:02:23 UTC, Moritz Maxeiner wrote:
On Wednesday, 8 March 2017 at 17:40:29 UTC, Brad Roberts wrote:
[...]
You can hide unsafe code in D by annotating a function with
@trusted the same way you can hide unsafe code in Rust with
unsafe blocks.
Clearly marked is
On Wednesday, 8 March 2017 at 21:25:41 UTC, Jack Stouffer wrote:
On Wednesday, 8 March 2017 at 20:21:24 UTC, deadalnix wrote:
Oh, you and I travel in the same circles (*those* subreddits),
I think I can id PC when I see it ;).
https://www.youtube.com/watch?v=dIageYT0Vgg
If anyone wanted a
On Wednesday, 8 March 2017 at 20:00:54 UTC, aberba wrote:
(To make my problem clear, how is D's current state not going
to allow / make it so difficult for developers (who know what
they are doing) to write say Photoshop-scale software:
This is probably a common question, and it would be ea
On Wednesday, 8 March 2017 at 21:34:19 UTC, H. S. Teoh wrote:
While writing a tool for dissecting various file formats, I
found a useful coding pattern that helps your D code be
cleaner, more modular, and more easily unittestable.
https://en.wikipedia.org/wiki/Dependency_inversion_principle
"
On Tuesday, 7 March 2017 at 19:07:29 UTC, Jack Stouffer wrote:
On Tuesday, 7 March 2017 at 03:04:05 UTC, Joakim wrote:
https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hello-d/
This reenforces my estimation that the most persuasive feature
of any language is the ability to get shit do
On Wednesday, 8 March 2017 at 21:34:19 UTC, H. S. Teoh wrote:
[...]
tl;dr: Whenever you have a data structure or a function that
depends on a concrete type like File that introduces a
dependency between modules, templatize it! In fact, templatize
your code whenever possible -- the more the b
On Wednesday, 8 March 2017 at 04:56:55 UTC, thedeemon wrote:
On Tuesday, 7 March 2017 at 19:09:11 UTC, bachmeier wrote:
Yep. If you want to give someone enough rope to get maximum
performance, you have to give them enough rope to shoot
themselves in the foot. Once you've moved into this territ
While writing a tool for dissecting various file formats, I found a
useful coding pattern that helps your D code be cleaner, more modular,
and more easily unittestable.
Initially, I wrote a parser module that directly accessed std.stdio.File
to parse file contents. Pretty standard approach, but i
On Wednesday, 8 March 2017 at 20:21:24 UTC, deadalnix wrote:
Lot of good stuff in there, but, if you know how to read
between the lines, all you need to know about the
PC/politicking as well.
Oh, you and I travel in the same circles (*those* subreddits), I
think I can id PC when I see it ;).
On Tuesday, 7 March 2017 at 20:15:56 UTC, Nick Sabalausky
(Abscissa) wrote:
On 03/07/2017 05:18 AM, Seb wrote:
[...]
Ooh, that's great to know! (Kinda sad that it seems necessary,
given the "unix filesystem and unix design" ideals, but oh
well, realities are realities.)
Is there a "proper"
On Wednesday, 8 March 2017 at 17:40:29 UTC, Brad Roberts wrote:
[...]
You can hide unsafe code in D by annotating a function with
@trusted the same way you can hide unsafe code in Rust with
unsafe blocks.
Clearly marked is an interesting definition of hidden.
---
module mymemorysafexyzlib
On Wednesday, 8 March 2017 at 20:00:54 UTC, aberba wrote:
I don't really have much experience with large code base, so
spare me.
From a technical and experience point of view (those with
experience in large D code-base), how is only D's GC & optional
MMM a significant production-use blocker?
On Tuesday, 7 March 2017 at 19:07:29 UTC, Jack Stouffer wrote:
I've seen this mentioned serval times now by people coming from
Rust.
Rust users: Is the PC/politicking really that pervasive in
their community?
https://www.youtube.com/watch?v=dIageYT0Vgg
Lot of good stuff in there, but, if yo
On Wednesday, 8 March 2017 at 17:16:58 UTC, Johan Engelen wrote:
Does LLVM trunk automatically build an LLD LTO plugin on
Windows? If not, we should ask about it on the LLVM mailing
list.
Er... stop me before doing something stupid :)
LTO is of course a native feature of LLD.
I don't really have much experience with large code base, so
spare me.
From a technical and experience point of view (those with
experience in large D code-base), how is only D's GC & optional
MMM a significant production-use blocker?
(To make my problem clear, how is D's current state not
On Wednesday, 8 March 2017 at 19:21:58 UTC, Dukc wrote:
On Wednesday, 8 March 2017 at 15:48:47 UTC, Timon Gehr wrote:
On 07.03.2017 16:48, Kagamin wrote:
[snip]
Sorry, accidently accounted that quote to a wrong person.
On Wednesday, 8 March 2017 at 15:48:47 UTC, Timon Gehr wrote:
On 07.03.2017 16:48, Kagamin wrote:
I might need to point out that -release does not disable bounds
checking in @safe code while it has been stated that -release
introduces UB for assertion failures in @safe code.
There is no flag
On 3/8/2017 5:56 AM, Moritz Maxeiner via Digitalmars-d wrote:
On Wednesday, 8 March 2017 at 13:30:42 UTC, XavierAP wrote:
On Wednesday, 8 March 2017 at 12:42:37 UTC, Moritz Maxeiner wrote:
Doing anything else is reckless endangerment since it gives you the
feeling of being safe without actually
On Tuesday, 7 March 2017 at 22:38:33 UTC, kinke wrote:
Yep, I gave LLD 3.9 a try on Win64 some weeks ago. Works out of
the box as drop-in replacement for Microsoft's link.exe, incl.
usage of environment variables.
Niiice. Awesome indeed!
Does LLVM trunk automatically build an LLD LTO plugin
On 07.03.2017 16:48, Kagamin wrote:
On Monday, 6 March 2017 at 21:05:13 UTC, Timon Gehr wrote:
Not every program with a wrong assertion in it exceeds array bounds.
Until it does.
Not necessarily so. With -release, it will be able to both exceed and
not exceed array bounds at the same time i
On Wednesday, 8 March 2017 at 14:50:18 UTC, XavierAP wrote:
On Wednesday, 8 March 2017 at 14:02:40 UTC, Moritz Maxeiner
wrote:
[...]
This is true for controlled experiments like the one I pointed
to and this model works fine for those sciences where
controlled experiments are applicable (e.g.
On Wednesday, 8 March 2017 at 14:02:40 UTC, Moritz Maxeiner wrote:
On Wednesday, 8 March 2017 at 13:14:19 UTC, XavierAP wrote:
On Wednesday, 8 March 2017 at 12:42:37 UTC, Moritz Maxeiner
wrote:
On Tuesday, 7 March 2017 at 22:07:51 UTC, XavierAP wrote:
Plus statistics can prove nothing -- this l
On Wednesday, 8 March 2017 at 13:50:28 UTC, Paulo Pinto wrote:
[...]
I will just leave this here.
https://muen.codelabs.ch/
This seems really cool, but I though seL4[1] were the first in
the field.
Guess I'll have some more research to do :p
[1] https://sel4.systems/
On Wednesday, 8 March 2017 at 13:14:19 UTC, XavierAP wrote:
On Wednesday, 8 March 2017 at 12:42:37 UTC, Moritz Maxeiner
wrote:
On Tuesday, 7 March 2017 at 22:07:51 UTC, XavierAP wrote:
Plus statistics can prove nothing -- this logical truth
cannot be overstated.
It's called empirical evidence
On Wednesday, 8 March 2017 at 13:30:42 UTC, XavierAP wrote:
On Wednesday, 8 March 2017 at 12:42:37 UTC, Moritz Maxeiner
wrote:
Doing anything else is reckless endangerment since it gives
you the feeling of being safe without actually being safe.
Like using @safe in D, or Rust, and being unaware
On Wednesday, 8 March 2017 at 13:12:12 UTC, Minty Fresh wrote:
On Sunday, 5 March 2017 at 11:48:23 UTC, Jacob Carlborg wrote:
On 2017-03-03 16:23, Moritz Maxeiner wrote:
That would be a good next step from an engineering
standpoint, I agree,
to proceed to minimize the amount of trust in people
On Wednesday, 8 March 2017 at 12:42:37 UTC, Moritz Maxeiner wrote:
Doing anything else is reckless endangerment since it gives you
the feeling of being safe without actually being safe. Like
using @safe in D, or Rust, and being unaware of unsafe code
hidden from you behind "safe" facades.
Saf
On Wednesday, 8 March 2017 at 12:42:37 UTC, Moritz Maxeiner wrote:
On Tuesday, 7 March 2017 at 22:07:51 UTC, XavierAP wrote:
Plus statistics can prove nothing -- this logical truth cannot
be overstated.
It's called empirical evidence and it's one of the most
important techniques in science[2]
On Sunday, 5 March 2017 at 11:48:23 UTC, Jacob Carlborg wrote:
On 2017-03-03 16:23, Moritz Maxeiner wrote:
That would be a good next step from an engineering standpoint,
I agree,
to proceed to minimize the amount of trust in people you need
to have vs
verifiable safety.
I have considered port
On Tuesday, 7 March 2017 at 16:18:15 UTC, Wyatt wrote:
On Tuesday, 7 March 2017 at 03:04:05 UTC, Joakim wrote:
https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hello-d/
I like the bit in the comments where he says this:
"It doesn’t have to be idiomatic to work just fine, which is
rel
On Tuesday, 7 March 2017 at 22:07:51 UTC, XavierAP wrote:
On Tuesday, 7 March 2017 at 21:24:43 UTC, Moritz Maxeiner wrote:
[...]
D does not claim to be memory-safe always.It does afaik do so
within @safe environments (barring internal runtime or compiler
bugs of course). Even C# has the same
On 2017-03-07 21:15, Nick Sabalausky (Abscissa) wrote:
And anyone know about OSX? Would OSX use the getentropy the article you
linked to mentions for OpenBSD?
As far as I can see, there's no "getentropy" on macOS. I see references
to it online, but I cannot find it in any header files.
Or
41 matches
Mail list logo
