On Saturday, 2 December 2017 at 03:52:19 UTC, codephantom wrote:
On Saturday, 2 December 2017 at 00:41:19 UTC, Wanderer wrote:
Is there any method to cleanup on Ctrl-C?
// --
import std.stdio;
import core.thread;
extern(C) void signal(int sig, void
On Saturday, 2 December 2017 at 01:26:14 UTC, Adam D. Ruppe wrote:
On Saturday, 2 December 2017 at 00:41:19 UTC, Wanderer wrote:
I wonder why `scope(exit)` code is not executed when the
program is terminated with Ctrl-C.
It depends on what your operating system is. On win32, I
believe it
I wonder why `scope(exit)` code is not executed when the program
is terminated with Ctrl-C.
For example:
```
import std.stdio;
import core.thread;
void main()
{
scope (exit)
{
writeln("Cleanup");
}
writeln("Waiting...");
Thread.sleep(10.seconds);
writeln("Done
On Wednesday, 29 November 2017 at 17:03:42 UTC, Steven
Schveighoffer wrote:
On 11/29/17 11:13 AM, Wanderer wrote:
I'm trying to simulate a race condition in D with the
following code:
(https://run.dlang.io/is/RfOX0I)
One word of caution, I think the running of your code on
run.dlang.io is
On Wednesday, 29 November 2017 at 16:33:50 UTC, Steven
Schveighoffer wrote:
On 11/29/17 11:13 AM, Wanderer wrote:
[...]
[snip]
[...]
Using the compiler switch -vcg-ast, I see no synchronization of
these methods.
[...]
That's what I assume, I was just lucky not to see a race.
Thanks
On Wednesday, 29 November 2017 at 16:19:05 UTC, Michael wrote:
On Wednesday, 29 November 2017 at 16:13:13 UTC, Wanderer wrote:
[...]
I unfortunately cannot answer your question but I am noticing
that running the code with DMD gives you an unordered sequence
of IDs, but running with
I'm trying to simulate a race condition in D with the following
code:
(https://run.dlang.io/is/RfOX0I)
```
import std.stdio;
import core.thread;
import std.concurrency;
shared struct IdGen(T)
{
T id;
this(T start)
{
id = start;
}
T next()
{
id =
On Sunday, 6 July 2014 at 21:31:57 UTC, Dmitry Olshansky wrote:
Strawman.
...
Again your ignorance of what a struct could do shows.
...
Plain wrong. Again seeing you have strong Java background,
isn't particularly surprising.
...
Ignorance.
On Sunday, 6 July 2014 at 04:20:21 UTC, Timon Gehr
On Sunday, 6 July 2014 at 04:20:21 UTC, Timon Gehr wrote:
That's not 'merely holding a pointer' and it applies to class
references just as much.
Eh?
This is genius, you've just proven that references are as
unsafe as pointers, and people who spent much time and efforts
designing the whole
On Friday, 4 July 2014 at 12:18:54 UTC, Daniel Murphy wrote:
Yes they do.
http://en.wikipedia.org/wiki/Database_index#Clustered
You can obviously only do that for one index.
Ugh, and what happens in such hypothetical database if you update
its first row so it becomes 1 byte longer than
On Saturday, 5 July 2014 at 14:20:33 UTC, Dmitry Olshansky wrote:
Provision some extra space in each record. DBs do this all the
time, regardless of layout.
Which means waste of space you complained about just below.
Besides, you understand this is not a solution: one byte more
than that
On Saturday, 5 July 2014 at 16:03:17 UTC, Dmitry Olshansky wrote:
There are trade-offs. The world is not black and white and I
don't follow 'one rule everywhere'.
This is not a trade-off at all. You suggested to keep database
records linearly, with space gaps between records to support
tiny
On Monday, 23 June 2014 at 16:33:13 UTC, Chris Cain wrote:
It's not really about the time complexity but the absolute time
it must take. But I showed the example that shows that the fact
that any stable sort must do extra work:
[2,2,2,2,1]
An unstable sort may swap the first 2 and the 1
On Thursday, 3 July 2014 at 10:13:20 UTC, ed wrote:
What if you're sorting a large database with large records?
Databases don't sort their records physically. The main reason
for that is that each record has many columns so there are many
various possible sort orders.
Instead, databases
On Thursday, 3 July 2014 at 11:30:57 UTC, Alix Pexton wrote:
Saying that one is always more significant than the other is
far too much of an oversimplification.
I just thought, with the presence of structs in D, things are not
that simple. Structs don't use references and their contents is
On Wednesday, 2 July 2014 at 05:01:44 UTC, Russel Winder via
Digitalmars-d wrote:
– Branding is important.
...
– A new website is being proposed, it is an opportunity to
create a
brand, based on the current logo.
All this branding sounds like branding cows. ;) Not the most
pleasant
On Tuesday, 1 July 2014 at 01:13:25 UTC, Jonathan M Davis via
Digitalmars-d wrote:
The long term plan is to remove toString, opEquals, toHash, and
opCmp from
Object so that the derived classes can decide whether to make
them const or
not. Unlike Java and C#, we have proper templates, so we can
On Wednesday, 2 July 2014 at 09:24:39 UTC, Jonathan M Davis via
Digitalmars-d wrote:
The ~ operator has nothing to do with toString. Strings are
arrays, and ~
works with arrays already. ~ doesn't work with Object and will
only work with
user-defined types which define opBinary!~. The only thing
On Tuesday, 1 July 2014 at 19:36:26 UTC, Ola Fosheim Grøstad
wrote:
Besides, Java and Javascript, for example, both require IEEE
conformance.
But they aren't system level programming languages… and we
probably cannot expect future many-core processors or
transputer-like processors to waste
On Wednesday, 2 July 2014 at 17:21:36 UTC, Jonathan M Davis via
Digitalmars-d wrote:
By not putting these functions on Object, it allows them to
have whatever
attributes they need when declared in derived types. Without
that, we're stuck
That's not the problem of the Object class, that's the
On Tuesday, 1 July 2014 at 20:34:05 UTC, Shammah Chancellor wrote:
On 2014-07-01 12:45:11 +, w0rp said:
I'm also strongly in favour of Option/Maybe types in general,
as a replacement for null. null is one of my pet hates, and
things are much nicer when the lack of a value is represented
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote:
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1
The arguments against D are pretty weak if I'm honest, but I
think it's important we understand what people think of D. I
can confirm this sentiment is fairly
On Friday, 13 June 2014 at 21:13:20 UTC, bearophile wrote:
This was surely discussed in past, but I don't remember the
answer (so perhaps this is more fit in D.learn).
Dereferencing the null pointer in C is undefined behaviour, so
in most cases the program segfaults, but sometimes the
The General rule is not to compare floats for equality, (is
0.0==-0.0, etc.). Use a epsilon based comparision scheme
instead or a wrapper around it.
That's not exactly true. You cannot (and should not) compare
floating points for equality, and use epsilon-based comparison
instead, only in
void main() {
int[5] data;
foreach (const i; 0 .. 10)
data[i] = 0;
foreach (immutable i; 0 .. 10)
data[i] = 0;
int[10] big;
foreach (const i, x; big)
data[i] = x;
}
I'm not sure if bound checks should be removed here. Before
removal, this code gives
Actually such instructions exist since MMX on Intel CPUs. The
question is: Can these new SSE instructions replace integer
math seemlessly?
My opinion is no. When you increment an integer value (any
value), you at least expect its lower bit to change. All
cryptographic algorithms would crash
On Friday, 30 May 2014 at 10:45:14 UTC, Nordlöw wrote:
Existing GC code: 15700ms (average)
My GC code: 500ms (Average)
This sounds almost to good to be true!
For allocations of less than 128 bytes, each thread
is allocated memory from it's own memory pool to avoid
false sharing on the
I must note if the sequence is predictable, it's not random
anymore, it's pseudo-random at most.
Also, if anyone interested, PHP had such way to generate
predictable sequences in the past, but after it was horribly
misused by various people for crypto keys/password generation
purposes, they
It will be hard to beat Java's garbage collector. They use
generational, sequential memory approach, while D's memory
manager (correct me if I'm wrong) uses more common approach and
has to deal with possible memory fragmentation. Allocating a new
object is extremely cheap in Java, literally a
I don't see any valid alternatives. What should ideally happen if
you increment 0x..? Should the value remain the same?
That's not much better than resetting back to zero, still a
mathematical error. Throw an exception? That would kill
performance and break lots of existing code.
If
Java misses this feature badly, forcing programmers to copy-paste
bloated code (constructor A calls constructor B with fewer
arguments, constructor B calls constructor C etc, same thing with
methods). Please tell me, does D support this feature?
int myNiceFunc(double a, double b=0, int c=0)
On Wednesday, 28 May 2014 at 13:01:52 UTC, bearophile wrote:
Wanderer:
Please tell me, does D support this feature?
You can answer by yourself similar questions online here:
http://dpaste.dzfl.pl/
Bye,
bearophile
Thanks! :-)
It's very hard to keep up-to-date with all these successors to
Java. Every half a year a new language appears, and it's always
better than all previous. :-(
D's const feature is nice and clear. But what made me fall in
love with D, is 'immutable' modifier. No inner mutable pieces
possible,
On Wednesday, 28 May 2014 at 10:10:41 UTC, maarten van damme via
Digitalmars-d-learn wrote:
an anyone explain me what I'm doing wrong here :
[code]
dstring[][dstring] providor_symbol_map;
...
Sorry about typo, I meant
providor_symbol_map.sort!((x,y)={x.value.lengthy.value.length})
above.
Aha, so you want to maintain spam word - set of senders
relationship, so it's actually map of sets and your declaration
is correct. You only need to sort map's entries (key and value
pairs together).
If D supports that, it should be something like
36 matches
Mail list logo
