On Tuesday, 24 May 2016 at 17:14:24 UTC, Andrei Alexandrescu
wrote:
On 05/24/2016 10:39 AM, Gary Willoughby wrote:
On Monday, 23 May 2016 at 16:04:14 UTC, Andrei Alexandrescu
wrote:
Found this on reddit:
http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.
I found it
On Thursday, 28 April 2016 at 18:49:54 UTC, Steven Schveighoffer
wrote:
var i = i (which you may think causes i to now be mutable, but
in actuality declares a NEW variable to shadow the old).
So how would you tell the difference, and why would you care?
Swift uses LLVM, so everything gets
On Thursday, 21 April 2016 at 13:42:50 UTC, Era Scarecrow wrote:
On Thursday, 21 April 2016 at 09:15:05 UTC, Thiez wrote:
On Thursday, 21 April 2016 at 04:07:52 UTC, Era Scarecrow
wrote:
I'd say either you specify the amount of retries, or give
some amount that would be acceptable for some
On Thursday, 21 April 2016 at 04:07:52 UTC, Era Scarecrow wrote:
I'd say either you specify the amount of retries, or give some
amount that would be acceptable for some background program to
retry for. Say, 30 seconds.
Would that actually be more helpful than simply printing an OOM
message
On Thursday, 10 March 2016 at 23:47:55 UTC, Andrew wrote:
One of awful things about programming in many languages is that
there's a gazillion tools you need to tack-on before you can do
any engineering. In C++ that includes Doxygen for
documentation, C++Unit for unit tests, gprof, gcov,
On Thursday, 10 March 2016 at 21:54:33 UTC, Andrew wrote:
Don't forget to mention all the "software engineering"
principles that can be taught using D too including:
Design by Contract
Literate programming (embedded documentation)
and to tool that come "standard" in the language such as
On Friday, 19 February 2016 at 12:28:14 UTC, Nemanja Boric wrote:
What Rust is doing:
```
let foo: Option = bar();
let new_stuff = match foo {
Some(x) => x,
None => 0
}
```
(or similar, I don't have compiler handy).
I think most would write that as:
let new_stuf =
On Thursday, 28 January 2016 at 22:59:58 UTC, cym13 wrote:
On Thursday, 28 January 2016 at 11:53:48 UTC, Russel Winder
wrote:
It should be pointed out that anyone using the synchronized
keyword anywhere in Java code is doing concurrent and parallel
programming wrong. If they are using
On Thursday, 26 November 2015 at 06:14:47 UTC, Joakim wrote:
I don't consider Java and C# real competitors to Swift or D, as
they're much older and won't attract the same users. Certainly
not Java, with how verbose it is, haven't looked at C# too
much. But for those with legacy codebases,
On Wednesday, 18 November 2015 at 23:14:48 UTC, deadalnix wrote:
On Wednesday, 18 November 2015 at 22:33:09 UTC, jmh530 wrote:
On Wednesday, 18 November 2015 at 06:43:22 UTC, deadalnix
wrote:
http://blog.pnkfx.org/blog/2015/10/27/gc-and-rust-part-0-how-does-gc-work/
On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:
One big difference between the D community and other languages'
communities is is that D people keep criticizing the language
and see every little flaw in every little corner, which is good
and which is why D is the way it is.
Or
With regard to the whole self-hosting thing, perhaps it is worth
copying the way Rust handles this:
https://github.com/rust-lang/rust/wiki/Note-compiler-snapshots
So in order to build one would usually download a binary compiler
and use it to bootstrap, but in theory one can take the last
On Friday, 21 February 2014 at 14:27:48 UTC, Paulo Pinto wrote:
On Friday, 21 February 2014 at 13:08:37 UTC, Francesco
Cattoglio wrote:
On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote:
That is easy to answer, I doubt they could with their rule of
not having more than 5
On Monday, 6 January 2014 at 00:20:59 UTC, deadalnix wrote:
void foo(int* ptr) {
*ptr;
if (ptr is null) {
// do stuff
}
// do stuff.
}
The code look stupid, but this is quite common after a first
pass of optimization/inlining, do end up with something like
that when a
On Saturday, 4 January 2014 at 04:20:30 UTC, David Nadlinger
wrote:
This is not true. While it _is_ possible to get null pointers
in @safe code, they are not a safety problem, as the first page
is never mapped in any D processes (yes, I'm aware of the
subtle issues w.r.t. object size here,
On Friday, 20 September 2013 at 10:41:39 UTC, Bruno Medeiros
wrote:
Even without seeing that article, I can well believe it. It
seems they shun away completely from compile-time
optimizations, and not much reasoning is given to that. It
seems almost a purely political/marketing move: like if
You may wish to take a look at Rust for inspiration. Rust has
unique (~) pointers and has made some interesting choices there.
Their ~pointers imply ownership. I'm not sure this could be
(efficiently) duplicated in a library for D (Rust has significant
compiler support for its pointer types)
On Tuesday, 29 January 2013 at 14:22:06 UTC, Don wrote:
The key phrase is *undefined behaviors*. Remember that C does
not require twos-complement arithmetic. D does, so it doesn't
have those problems in the first place.
It must have been a dozen times by now that you have posted the
same
On Tuesday, 22 January 2013 at 16:31:20 UTC, Era Scarecrow wrote:
I really wouldn't want to have to use BigInt for everything
that can't overflow and then check to make sure I can fit it in
my smaller variables afterwards along with the extra move. I
wouldn't want to use BigInts everywhere,
Nick, Teoh, what exactly do you guys hope to accomplish with your
current discussion? What if someone who comes from a dynamically
typed language wants to check out D and reads that vitriolic crap
the two of you are spewing? I'm sure they'll feel very welcome
knowing that what appears to be
On Thursday, 3 January 2013 at 10:17:19 UTC, deadalnix wrote:
Generational seems completely unrealistic.
Why?
On Wednesday, 2 January 2013 at 12:32:01 UTC, deadalnix wrote:
Most GC language lack proper memory management, and sometime
have design choice that are a nightmare for the GC (java have
no value type for instance).
Surely Java's primitive types (byte, short, int, long, float,
double,
On Wednesday, 2 January 2013 at 22:53:04 UTC, Jonathan M Davis
wrote:
Then we're going to have to disagree, and I believe that Walter
and Andrei are
completely with me on this one. If all of the constructs that
you use are
@safe, then it should be _guaranteed_ that your program is
memory-safe.
On Saturday, 8 December 2012 at 21:47:32 UTC, Dan wrote:
My approach is to have a general dup function. I call it gdup,
for global dup so the name does not conflict with the existing
dup. It dup's fields recursively. Feel free to have a look and
any suggestions appreciated. Would greatly
On Monday, 10 December 2012 at 12:45:16 UTC, Dan wrote:
That would be an infinite loop. If you have a compile time
cycle you would likely need your own custom dups anyway, as you
are doing low level and heap allocating already. But for the
simpler cases without cycles, if dup encounters a
On Saturday, 10 November 2012 at 22:52:56 UTC, Nick Sabalausky
wrote:
On Sat, 10 Nov 2012 23:17:41 +0100
eskimo jfanati...@gmx.at wrote:
Hey party people!
What is the current state? Is it enough to store a pointer in a
ptrdiff_t variable instead of a pointer for the GC to ignore
it or is
my
On Sunday, 7 October 2012 at 12:39:35 UTC, Piotr Szturmaj wrote:
In my prostgres client one may specify field types at compile
time. If I had divided the client into two separate layers it
would return a Variant[] at first layer, then convert it to
user specified tuple at the second. For
On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander
wrote:
So, with this in mind, do you think these hypothetical people
are all justified?
(a) [Go programmer]: D is rubbish because it doesn't have
channels.
(b) [Lisp programmer]: D is rubbish because it doesn't have
On Tuesday, 18 September 2012 at 22:01:30 UTC, Andrei
Alexandrescu wrote:
After extensive tests with a variety of aggregate functions, I
can say firmly that taking the minimum time is by far the best
when it comes to assessing the speed of a function.
What if one tries to benchmark a
On Sunday, 19 August 2012 at 09:28:49 UTC, Paulo Pinto wrote:
Oh, and forgot to mention that structs wouldn't be allocated in
stack anyway, even with a JVM's implementation for safe D, thus
breaking language's semantics.
The reference page on structs http://dlang.org/struct.html does
not
On Thursday, 16 August 2012 at 00:48:44 UTC, Alexey Egorov wrote:
I think there is no problems to make, for example, compiler for
Java Virtual Machine.
Think again. Like Java, the JVM does not have pointer arithmetic,
which means there is no straightforward way to write a
D-to-JVM-bytecode
On Thursday, 16 August 2012 at 11:47:56 UTC, Paulo Pinto wrote:
On Thursday, 16 August 2012 at 09:23:18 UTC, Thiez wrote:
On Thursday, 16 August 2012 at 00:48:44 UTC, Alexey Egorov
wrote:
I think there is no problems to make, for example, compiler
for Java Virtual Machine.
Think again. Like
On Sunday, 12 August 2012 at 08:43:53 UTC, Alex Rønne Petersen
wrote:
On 11-08-2012 20:54, Thiez wrote:
On Saturday, 11 August 2012 at 17:15:21 UTC, Norbert Nemec
wrote:
On 11.08.2012 18:13, bearophile wrote:
David:
Thanks! I thought modulo should alawys yield the same ...
seems like I
On Sunday, 12 August 2012 at 13:11:36 UTC, David wrote:
My implementation of py_mod:
int py_mod(int a, int b) {
return cast(uint)a % b;
}
So a simple cast from signed to unsigned does exactly what I
need (Prf_Jakob showed me that in IRC)
It seems to work when b is a power of 2, but not
On Saturday, 11 August 2012 at 17:15:21 UTC, Norbert Nemec wrote:
On 11.08.2012 18:13, bearophile wrote:
David:
Thanks! I thought modulo should alawys yield the same ...
seems like I
was wrong ;)
It's C design that's wrong.
And it's the processor design that makes it inefficient to
Have you considered adding operator overloading using UFCS while
you're at it?
On Thursday, 12 July 2012 at 12:43:24 UTC, Tommi wrote:
On Thursday, 12 July 2012 at 10:05:16 UTC, Thiez wrote:
Have you considered adding operator overloading using UFCS
while you're at it?
I assumed it's already possible to add operators
non-intrusively, because operators are just
On Tuesday, 5 June 2012 at 22:17:57 UTC, bearophile wrote:
Or you can add an assert/enforce, or you can create a small
struct that represent safely assignable uints, etc. No solution
is good.
Bye,
bearophile
Surely structs could work?
struct safeType(T) {
T value;
}
Define all
On Wednesday, 30 May 2012 at 06:31:32 UTC, Dmitry Olshansky wrote:
I'll intervene. Following famous nerd motto talk is cheap,
show me the code I strongly suggest discussing concrete
scenarios. All prone to deadlock sentiment is trivia as in
buyer beware.
That being said:
class iMutexed
On Wednesday, 30 May 2012 at 12:43:15 UTC, deadalnix wrote:
It doesn't address most of the drawback cited. Notably the fact
that every object have a monitor field, but most of them will
not use it.
That could be solved without abandoning object locks. If locking
on all objects is allowed,
40 matches
Mail list logo
