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 but not for
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.
On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote:
Thank you for your responses. I am partly enlightened. :p
I know you're a knowledgeable person in the D community, I may
have stated many things you already knew, but I tried to answer
the questions as-is.
On 06/27/2014 12:34
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 the
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
48 matches
Mail list logo