On Sunday, 11 December 2016 at 11:58:39 UTC, ag0aep6g wrote:
Try putting an `assert(childCrossPoint !is otherCrossPoint);`
before the assignment. If it fails, the variables refer to the
same node. That would explain how otherCrossPoint.left gets set.
Furthermore, I think he is calling breed
On Sunday, 24 April 2016 at 11:03:11 UTC, Lass Safin wrote:
So the question is: Will the GC scan ptr? As you can see, it is
a write-only pointer, so reading from it will cause undefined
behavior (such as return data which looks like a pointer to
data..), and can potentially be reallly slow.
Just for fun:
// map, join, text, iota, writeln,
tuple
import std.algorithm, std.array, std.conv, std.range, std.stdio,
std.typecons;
void main()
{
iota(1,100)
.map!(a = tuple(a, a % 3 == 0 ? 0 : 4, a % 5 == 0 ? 8 : 4))
.map!(a = a[1] == a[2] ? a[0].text :
On Tuesday, 10 March 2015 at 20:41:14 UTC, Dennis Ritchie wrote:
Hi.
How to parallelize a large array to check for the presence of
an element matching the value with the data?
Here's a simple method (warning: has pitfalls):
import std.stdio;
import std.parallelism;
void main()
{
int[] a
On Tuesday, 10 March 2015 at 21:56:39 UTC, Xinok wrote:
I'm inclined to believe this is a bug.
https://issues.dlang.org/show_bug.cgi?id=11048
On Sunday, 8 March 2015 at 21:34:25 UTC, Dennis Ritchie wrote:
This is normal behavior?
Yes it is normal, there are two potential points of confusion:
- remove mutates the input range and returns a shortened slice to
the range which excludes the removed element.
- remove takes an index as
On Sunday, 8 February 2015 at 16:23:44 UTC, FG wrote:
2. auto buf = new byte[](1024*1024*100);
now the gc can't free this buf.
can i free it by manual?
Yes. import core.memory; GC.free(buf.ptr); // and don't use buf
afterwards
That won't work, see:
On Sunday, 8 February 2015 at 18:43:18 UTC, FG wrote:
On 2015-02-08 at 19:15, safety0ff wrote:
That won't work, see:
http://forum.dlang.org/thread/uankmwjejsitmlmrb...@forum.dlang.org
Perhaps it was fixed in DMD 2.066.1, because this works for me
just fine:
Here's the link I couldn't
False pointers, current GC is not precise.
On Friday, 12 December 2014 at 06:17:56 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
Is there a way to allocate GC
memory blocks in D that are guaranteed to fall on OS page
boundaries?
I don't know about guarantees, I think that in practice, if your
OS page size is 4096, any GC allocation
On Saturday, 22 November 2014 at 18:30:06 UTC, Ad wrote:
Hello, I would like to write a popcnt function. This works
fine
ulong popcnt(ulong x)
{
asm { mov RAX, x ; popcnt RAX, RAX ; }
}
However, if I add the naked keyword ( which should improve
performance? ) it doesn't work anymore and I
On Friday, 24 October 2014 at 02:51:20 UTC, tcak wrote:
I don't want to blame dmd directly because as far as I see from
the search I did with __lll_lock_wait_private, some C++
programs are having same problem with malloc operation as well.
But still, can this be because of compiler?
Looks
On Tuesday, 21 October 2014 at 08:25:07 UTC, bearophile wrote:
Minas Mina:
Aren't pure functions supposed to return the same result every
time? If yes, it is correct to not accept it.
But how can main() not be pure? Or, how can't the 'a' array be
immutable?
Bye,
bearophile
There can
On Wednesday, 22 October 2014 at 01:21:19 UTC, Freddy wrote:
Is there any advice/tips for reading medium/big D codebases?
Somewhat D specific: I would consider an IDE/editor like Eclipse
with DDT that can give an outline of the data structures
functions names in a source file to make the
The following D code runs over 2x faster than the C++ code
(comparing dmd no options to g++ no options.) Its not a fair
comparison because it changes the order of operations.
import core.stdc.stdio;
const uint H = 9, W = 12;
const uint[3][6] g = [[7, 0, H - 3],
[1 + (1
On Saturday, 30 August 2014 at 17:09:41 UTC, JD wrote:
Hi all,
I tried to write a Linux daemon in D 2.065 (by translating one
in C we use at work). My basic skeleton works well. But as soon
as I start allocating memory it crashed with several
'core.exception.InvalidMemoryOperationError's.
IIRC it manages the capacity information manually instead of
calling the runtime which reduces appending overhead.
On Thursday, 14 August 2014 at 13:10:58 UTC, bearophile wrote:
D AAs used to be not vulnerable to collision attacks because
they resolved collisions building a red-black tree for each
bucket. Later buckets became linked lists for speed,
Slight corrections:
It was a effectively a randomized
On Tuesday, 12 February 2013 at 01:07:35 UTC, bearophile wrote:
In practice at the moment I am maintaining all the D entries of
Rosettacode.
Here's a candidate for
http://rosettacode.org/wiki/Extensible_prime_generator#D in case
it is preferred to the existing entry:
On Tuesday, 5 August 2014 at 23:23:43 UTC, Jon wrote:
So that does indeed solve some of the problems. However, using
this method, when linking I get two errors, undefined reference
rt_init() and rt_term() I had just put these methods in the
header file. If I put wrappers around these
Don't forget to call rt_init:
http://dlang.org/phobos/core_runtime.html#.rt_init
On Monday, 4 August 2014 at 21:14:17 UTC, Jon wrote:
On Monday, 4 August 2014 at 21:10:46 UTC, safety0ff wrote:
Don't forget to call rt_init:
http://dlang.org/phobos/core_runtime.html#.rt_init
Where/when should I call this?
Before calling any D functions, but usually it's simplest to call
On Monday, 4 August 2014 at 21:35:21 UTC, Jon wrote:
I get Error: core.runtime.rt_init is private. And Error:
core.runtime.init is not accessible.
I would add them to the header and Haskell wrapper
(FunctionsInD.h and ToD.hs.)
The signatures are:
int rt_init();
int rt_term();
When it is
On Sunday, 3 August 2014 at 19:52:42 UTC, Philippe Sigaud wrote:
Can someone confirm the results and tell me what I'm doing
wrong?
LDC is likely optimizing the summation:
int sum = 0;
foreach(i; 0..task.goal)
sum += i;
To something like:
int sum =
On Friday, 1 August 2014 at 23:09:39 UTC, sigod wrote:
Code: http://dpaste.dzfl.pl/51bd62138854
(It was reduced by DustMite.)
Have I missed something about structs? Or this simply a bug?
Isn't this the same mistake as:
On Tuesday, 12 February 2013 at 01:07:35 UTC, bearophile wrote:
In practice at the moment I am maintaining all the D entries of
Rosettacode.
I modified the Hamming numbers code in a personal exercise.
It now uses considerably less memory but is slower.
I've posted the code here in case it
On Thursday, 24 July 2014 at 14:59:16 UTC, Darren wrote:
It does seem that's the case. Which is odd, as I thought that
DMD and LDC did TCO. Not in this case obviously.
DMD doesn't do it with the :? operator:
https://issues.dlang.org/show_bug.cgi?id=3713
On Tuesday, 15 July 2014 at 12:24:48 UTC, Alexandre wrote:
Thanks, but, when I convert I recive a 'c' in the front of my
number...
uint reverseBytes(uint val)
{
import core.bitop : bitswap;
return bitswap(val);
}
You confused bswap with bitswap.
The former reverses bytes,
On Friday, 4 July 2014 at 09:39:49 UTC, Sean Campbell wrote:
On Friday, 4 July 2014 at 08:02:59 UTC, Misu wrote:
Can you try to add DerelictGL3.reload(); after
SDL_GL_CreateContext ?
yes this solved the problem. however why? is it a problem with
the SDL binding?
No.
Everything compiles fine except for function qux2:
http://dpaste.dzfl.pl/9d9187e0b450
Is this a bug or an enhancement for CTFE?
It would be really nice to have this feature because core.simd
has functions such as: void16 __simd(XMM opcode, void16 op1,
void16 op2, ubyte imm8);
Where all the
Actually, this is an enhancement because adding:
enum b = blah
Makes them fail. :(
On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote:
Actually, this is an enhancement because adding:
enum b = blah
Makes them fail. :(
The question is now: how can the delegate be evaluated for the
return value but not for the enum?
On Thursday, 3 July 2014 at 02:02:19 UTC, safety0ff wrote:
On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote:
Actually, this is an enhancement because adding:
enum b = blah
Makes them fail. :(
The question is now: how can the delegate be evaluated for the
return value
On Friday, 27 June 2014 at 23:26:55 UTC, Ali Çehreli wrote:
I appreciated your answers, which were very helpful. What I
meant was, I was partially enlightened but still had some
questions. I am in much better shape now. :)
Yea, I understood what you meant. :)
On Friday, 27 June 2014 at 07:03:28 UTC, Ali Çehreli wrote:
1) After allocating memory by GC.calloc() to place objects on
it, what else should one do?
Use std.conv.emplace.
In what situations does one need to call addRoot() or
addRange()?
Add root creates an internal reference within the
I realize that my answer isn't completely clear in some cases, if
you still have questions, ask away.
, safety0ff wrote:
Add range is usually for cases when you use
stdc.stdlib.malloc/calloc
and place pointers to GC managed memory within that memory.
This allows
the GC to scan that memory for pointers during collection,
otherwise it
may reclaim memory which is pointed to my malloc'd memory
On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote:
So, the GC's default behavior is to scan the memory,
necessitating clearing the contents? That seems to make
GC.malloc() behave the same as GC.calloc() by default, doesn't
it?
Yes.
compare:
On Friday, 27 June 2014 at 09:20:53 UTC, safety0ff wrote:
Yes.
compare:
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L543
to:
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L419
Actually, I just realized that I was wrong in saying
On Wednesday, 11 June 2014 at 22:32:45 UTC, Taylor Hillegeist
wrote:
I have a simpleish bit of code here that always seems to give
me an error, and i can't figure out quite why.
modulo takes the sign of the dividend:
http://en.wikipedia.org/wiki/Modulo_operation#Common_pitfalls
It works with
On Friday, 30 May 2014 at 19:50:43 UTC, Philippe Sigaud wrote:
Am I misunderstanding something or is that a bug?
Try: auto foo() { return Hidden();}
On Friday, 30 May 2014 at 19:54:00 UTC, safety0ff wrote:
On Friday, 30 May 2014 at 19:50:43 UTC, Philippe Sigaud wrote:
Am I misunderstanding something or is that a bug?
Try: auto foo() { return Hidden();}
This is incorrect, please ignore.
//*** CODE **
mixin(version = foo;);
version(foo)
{
void main(){}
}
//** END CODE ***
If it's illegal in D, what is the reason where is documented?
The reason I was considering such a construct is the following:
Some C libraries have an associated config.h header that
On Thursday, 29 May 2014 at 15:02:48 UTC, Steven Schveighoffer
wrote:
Even if that is valid code, you are much better off using enums
and static if.
enum includeSomeFeature = ...
static if(includeSomeFeature)
{
...
}
These work much more like #defines, and can be seen outside the
module.
I think malloc isn't @safe and alloca doesn't work if your
function can throw.
On Wednesday, 28 May 2014 at 23:57:40 UTC, Dicebot wrote:
I believe within current language semantics even considering
`new` pure is broken, there was a very recent thread discussing
it in digitalmars.D group.
If you can be sure that your code won't break basic sanity
requirements (never
You should look into associative arrays (
http://dlang.org/hash-map .)
Example:
import std.stdio;
void main()
{
int[][string] mybobs;
mybobs[bob_1] = [-1, -1, 1, -1, -1];
mybobs[bob_2] = [-1, 1, 1, 1, -1];
mybobs[bob_3] = [-1, 1, 1, 1, -1];
On Monday, 5 May 2014 at 03:57:54 UTC, Andrey wrote:
A similar D code is, as far as I know,
type.field.offsetof
Is there an any way to make a corresponding D template?
What you've written is the specific syntax for offsetof in D.
If the intent is to create a template so that you can simply
On Sunday, 16 March 2014 at 07:59:33 UTC, Sergei Nosov wrote:
Hi!
Suppose I have a small .d script that has a main. Is there any
simple way to just run the unit tests without running main at
all?
Here's the first thing that came to mind:
If you never want to both unit tests and regular
On Saturday, 22 February 2014 at 16:21:21 UTC, Nordlöw wrote:
In the following test code given below of std.parallelism I get
some interesting results:
Don't forget that n.iota.map is returning a lazily evaluated
range.
Std.parallelism might have to convert the lazy range to a random
access
Could be related to #10351 or #5488 in bugzilla.
On Wednesday, 20 November 2013 at 08:48:33 UTC, simendsjo wrote:
But I would think this trick would break the GC, as well as
making code less portable.
Since the GC supports interior pointers, I think you can justify
using the least significant bits as long as the size and
alignment of the
On Thursday, 31 October 2013 at 09:15:53 UTC, Namespace wrote:
I'm sure we had already this conversation but I don't find the
thread.
T[] buffer = new T[N]; assumes more space than stated (in
average 2010 elements more. See:
http://dpaste.dzfl.pl/af92ad22c). It behaves exactly like
reserve
See this code: http://dpaste.dzfl.pl/b3ae1667
On DMD it gives the error message if version=bug, but not if
version=bug AND version=workaround1 (through 6).
On LDC it segfaults at run time if version=bug, but not if
version=bug AND version=workaround1 (through 6).
Workaround1 - workaround4
On Tuesday, 8 October 2013 at 10:54:08 UTC, JR wrote:
On Monday, 7 October 2013 at 21:13:53 UTC, safety0ff wrote:
I think I've found the culprit: Memory managment / GC,
disabling the GC caused the program to eat up all my memory.
I'll have to look into this later.
From what I've gathered
].)
My interpretation of these results is that std.parallelism.amap
does significant communication between threads which causes
issues with scaling.
[1] https://github.com/kid0m4n/rays
[2] https://github.com/Safety0ff/rays/tree/master/drays
Ok, well I re-wrote the parallelism amap into spawning/joining
threads and the results are similar, except notably less system
calls (specifically, less futex calls.)
I think I've found the culprit: Memory managment / GC, disabling
the GC caused the program to eat up all my memory.
I'll have to look into this later.
58 matches
Mail list logo
