On Wednesday, 25 October 2017 at 01:26:10 UTC, Brian Schott wrote:
I've been reading the Fiber code and (so far) that seems seems
to be reasonable. Can anybody think of a reason that this would
be a bad idea? I'd rather not create a pull request for a
design that's not going to work because
On Friday, 22 September 2017 at 21:29:10 UTC, Steven
Schveighoffer wrote:
GC.addRange has this signature:
static nothrow @nogc void addRange(in void* p, size_t sz, const
TypeInfo ti = null);
I see a large problem with this. Let's say you malloc an array
of struct pointers:
struct Foo {
On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote:
http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
"But the main unanswered question is why? Why an extra pass?"
It's likely to pave over the many pitfalls of D finalizers.
E.g. finalizers corrupting data:
class
On Monday, 19 June 2017 at 23:39:54 UTC, H. S. Teoh wrote:
On Mon, Jun 19, 2017 at 10:50:05PM +, Adam D. Ruppe via
Digitalmars-d wrote:
What is it about Windows that makes you call it a distant
possibility? Is it just that you are unfamiliar with it or is
there some specific OS level
On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote:
My take on D's GC problem, also spoiler - I'm going to build a
new one soonish.
http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
---
Dmitry Olshansky
Good overview, however:
the binary search pool lookup is
On Tuesday, 10 January 2017 at 05:48:10 UTC, Ignacious wrote:
It would be nice, also, if when we click on a link in the forum
that it takes us to the last page/message(Scrolls down to it)
rather than forcing us to do this.
You can click on the time of the last post (on the right side) to
go
While trying to make a few minor contributions during the
holidays, it seemed like every other PR was hitting a "random"
unit test failure.
So I solved the few that I noticed [1-3] (the last is still
waiting review / merge.)
However finding failures that have gone unnoticed or unreported
On Thursday, 29 December 2016 at 22:54:35 UTC, Ali Çehreli wrote:
Can you explain that behavior?
What about: http://dlang.org/spec/const3.html#implicit_conversions
"An expression may be converted from mutable or shared to
immutable if the expression is unique and all expressions it
On Tuesday, 27 December 2016 at 04:36:54 UTC, Martin Nowak wrote:
This version resolves a number of regressions and bugs in the
2.072.1 release.
I thought https://github.com/dlang/druntime/pull/1707 was in
stable and slated for this point release.
I see at the bottom of:
On Saturday, 24 December 2016 at 06:08:49 UTC, Saurabh Das wrote:
Feedback:
1. It will be aesthetically better if the edit/run buttons are
inside the code box, say just inside the right top corner.
I agree the button placement should be improved, I think they
should be immediately to the
On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright wrote:
For this D code:
enum SIZE = 1;
void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}
Is subtraction of pointers which do not
On Friday, 23 December 2016 at 16:15:44 UTC, Andrei Alexandrescu
wrote:
An interesting problem to look at:
The foreach macro (src/tk/vec.h#L62) looks like low hanging fruit
for optimization as well.
Looks like classic ABA to me.*
See my comment here:
https://issues.dlang.org/show_bug.cgi?id=16352#c6
I'm posting here because it should be addressed sooner rather
than later due to pull requests going red randomly and wasting
people's time.
*Disclaimer, it's very late.
On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote:
Yup looks like that was the cause. Removed some of the
functions that did a "foreach()" over some large tuples. Down
to 26 seconds with that removed.
Also: https://issues.dlang.org/show_bug.cgi?id=2396
On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei
Alexandrescu wrote:
Must be a pathological case we should fix anyway. -- Andrei
Likely related bug has been open 5 years minus 1 day:
https://issues.dlang.org/show_bug.cgi?id=7157
On Sunday, 18 December 2016 at 18:02:58 UTC, Ilya Yaroshenko
wrote:
Thank you for the answer (it is hard to understand me because
English and other reasons),
Ilya
It was difficult to understand your vision until this post, now I
think I grasp it.
Let me try to summarize what I've
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu
wrote:
But of course there are many situations out there.
Wouldn't it break chained assertion errors?
On Sunday, 11 December 2016 at 19:00:23 UTC, Stefan Koch wrote:
Just use this little program to simulate the process.
That's not really useful for understanding and making progress on
the issue.
I had a patch with improved hash functions which I stashed away
since it seemed the mangle
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, 11 December 2016 at 17:20:24 UTC, Stefan Koch wrote:
That means you have to compute the mangled name which is crazy
expensive.
And you can't cache the parent part of mangle because it all
freshly generated by the template.
How often would the mangle be needed regardless later on
On Sunday, 11 December 2016 at 16:26:29 UTC, Ethan Watson wrote:
At the very least, I now have an idea of which parts of the
compiler I'm taxing and can attempt to write around that. But
I'm also tempted to go in and optimise those parts of the
compiler.
Have a look at this issue:
On Tuesday, 29 November 2016 at 22:20:06 UTC, Walter Bright wrote:
And I do have a local copy of it. But to just see the hex code
for an instruction, the clickable reference is much handier
than navigating 3600 pages.
Other links in the same vein:
http://ref.x86asm.net/coder64.html
On Sunday, 13 November 2016 at 16:56:30 UTC, Ilya Yaroshenko
wrote:
BTW, i have implemented sumOfLogs [1], it is more precise then
everything else.
Thanks, I was going to use 32.64 fixed point for my program but
now I think I will get better precision modifying that to use a
32 bit
On Saturday, 12 November 2016 at 15:37:29 UTC, Ilya Yaroshenko
wrote:
Hi all,
Advanced summation algorithms [3] from Mir project [1] are
ready to be merged to Phobos.
Hi,
Do you have any thoughts at to when Kahan should be used over KBN?
I was testing summation for a program (summing
On Sunday, 6 November 2016 at 03:28:20 UTC, Jon Degenhardt wrote:
On Sunday, 6 November 2016 at 02:12:12 UTC, Alexandru
Caciulescu wrote:
I see this topic started a clash of opinions regarding the
future of AAs. After Andrei suggested a free-list
implementation I had a good idea of how to
On Thursday, 3 November 2016 at 13:19:17 UTC, Steven
Schveighoffer wrote:
So technically, the freelist is still needed.
In case I wasn't clear in my previous post:
We can't use a freelist because it breaks safety.
On Wednesday, 2 November 2016 at 03:36:42 UTC, Andrei
Alexandrescu wrote:
Last time I looked our associative arrays were arrays of
singly-linked lists.
F.Y.I. It now appears to use quadratic probing since druntime PR
#1229.
Each hashtable would have its own freelist, or alternatively
On Tuesday, 25 October 2016 at 21:46:30 UTC, safety0ff wrote:
P.S. I am aware that this pessimises popFront for code which
only counts codepoints without inspecting them.
Unfortunately it also changes the API of popFront to throw on
invalid characters.
So the example would need
On Wednesday, 12 October 2016 at 13:53:03 UTC, Andrei
Alexandrescu wrote:
Now it's time to look at the end-to-end cost of autodecoding.
Some food for thought:
- front necessarily needs to compute the number of bytes to
advance.
- We can't change the API to share data between front and
On Sunday, 23 October 2016 at 13:04:30 UTC, Stefam Koch wrote:
created a version of fibbonaci which I deem to be faster then
the other ones floating around.
Rosettacode is a good place to check for "floating around"
implementations of common practice exercises e.g.:
On Saturday, 15 October 2016 at 19:00:12 UTC, Patrick Schluter
wrote:
Just a question. Do encoding errors not have to be detected or
is validity of the string guaranteed?
AFAIK they have to be detected, otherwise it would be a
regression.
On Friday, 14 October 2016 at 20:47:39 UTC, Stefan Koch wrote:
On Thursday, 13 October 2016 at 21:49:22 UTC, safety0ff wrote:
Bad benchmark! Bad! -- Andrei
Also, I suspect a benchmark with a larger loop body might not
benefit as significantly from branch hints as this one.
I disagree
On Thursday, 13 October 2016 at 01:36:44 UTC, Andrei Alexandrescu
wrote:
Oh ok, so it's that checksum in particular that got optimized.
Bad benchmark! Bad! -- Andrei
Also, I suspect a benchmark with a larger loop body might not
benefit as significantly from branch hints as this one.
On Thursday, 13 October 2016 at 14:51:50 UTC, Kagamin wrote:
On Wednesday, 12 October 2016 at 20:24:54 UTC, safety0ff wrote:
Code: http://pastebin.com/CFCpUftW
Line 25 doesn't look trusted: reads past the end of an empty
string.
Length is checked in the loop that calls this function
On Thursday, 13 October 2016 at 00:32:36 UTC, safety0ff wrote:
It made little difference: LDC compiled into AVX2 vectorized
addition (vpmovzxbq & vpaddq.)
Measurements without -mcpu=native:
overhead 0.336s
bytes0.610s
without branch hints 0.852s
code pasted 0.766s
On Wednesday, 12 October 2016 at 23:47:45 UTC, Andrei
Alexandrescu wrote:
Wait, so going through the bytes made almost no difference? Or
did you subtract the overhead already?
It made little difference: LDC compiled into AVX2 vectorized
addition (vpmovzxbq & vpaddq.)
On Wednesday, 12 October 2016 at 20:07:19 UTC, Stefan Koch wrote:
where did you apply the branch hints ?
Code: http://pastebin.com/CFCpUftW
On Wednesday, 12 October 2016 at 16:24:19 UTC, Andrei
Alexandrescu wrote:
Remember the ASCII part is the bothersome one. There's only two
comparisons, all with 100% predictability. We should be able to
arrange matters so the loss is negligible. -- Andrei
My measurements:
ldc -O3
On Wednesday, 12 October 2016 at 16:48:36 UTC, safety0ff wrote:
[Snip]
Didn't see the LUT implementation, nvm!
My current favorites:
void popFront(ref char[] s) @trusted pure nothrow {
immutable byte c = s[0];
if (c >= -2) {
s = s.ptr[1 .. s.length];
} else {
import core.bitop;
size_t i = 7u - bsr(~c);
import std.algorithm;
s = s.ptr[min(i, s.length) .. s.length];
}
}
I also
On Sunday, 9 October 2016 at 22:11:50 UTC, Andrei Alexandrescu
wrote:
I suspect there are cleverer things that can be done.
Less clever seemed to work for me:
void popFront1(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
if (c < 0x80 || c >= 0xFE) {
s = s.ptr[1 ..
On Sunday, 2 October 2016 at 03:05:37 UTC, Manu wrote:
Unsigned case is:
return (x & -x) > (x - 1);
Wouldn't this be better:
return (sz & (sz-1)) == 0;
https://forum.dlang.org/post/nfkaag$2d6u$1...@digitalmars.com
On Thursday, 8 September 2016 at 17:03:30 UTC, Stefan Koch wrote:
I thought of the same thing a while back.
However I have had the time to decipher the gprof data-format
yet.
Is there another profile-format for decent visualization tools
exist ?
I was just using that as an example of what
On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
... I have now implemented another pseudo function called
__ctfeTicksMs.
[Snip]
This does allow meaningful compiletime performance tests to be
written.
spanning both CTFE and template-incitations timeings.
Please tell me what
On Thursday, 26 May 2016 at 18:44:22 UTC, ikod wrote:
Hello,
On linux, in the code below, receive() returns -1 with
errno=EINTR if syscall is interrupted by GC (so you can see
several "insterrupted") when GC enabled, and prints nothing
(this is desired and expected behavior) when GC
On Monday, 16 May 2016 at 12:13:14 UTC, Martin Nowak wrote:
Last time people forced me to spend several hours on
reimplementing and debugging a BitArray implementation
Ouch.
src/tk/vec.(h|c) already contained an implementation.
I don't know ARM specifics, but perhaps hwloc is useful to you:
https://www.open-mpi.org/projects/hwloc/
On Monday, 2 May 2016 at 16:39:13 UTC, vino wrote:
Hi All,
I am a newbie for D programming and need some help, I am
trying to write a program using the example given in the book
The "D Programming Language" written by "Andrei Alexandrescu"
Make sure to check the errata on his site:
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.
On Saturday, 23 April 2016 at 21:04:52 UTC, Nordlöw wrote:
On Saturday, 23 April 2016 at 20:42:25 UTC, Lass Safin wrote:
CPUID: https://en.wikipedia.org/wiki/CPUID.
You can check for the presence of a lot of instructions with
this instruction.
However this will only work on x86 and only
On Thursday, 22 October 2015 at 07:13:58 UTC, KlausO wrote:
Intrusive data structures have their strengths especially when
nodes are
part of several containers.
I implemented some of the intrusive containers back in D1 times.
See
On Thursday, 22 October 2015 at 14:14:09 UTC, safety0ff wrote:
I also like having an intrusive container library in my
toolbox: they don't limit membership to one container and they
don't "bake" memory management into the container type.
Also wanted to mention that this
Thanks!
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 Sunday, 12 April 2015 at 15:21:26 UTC, Johan Engelen wrote:
Sorry for not being clear.
I should have thought about it more before answering. :)
I understand why the current bsr behaves like it does, but what
I meant is whether that is the desired behavior of bsr:
bsr( byte(-1) ) ==
On Sunday, 12 April 2015 at 11:53:41 UTC, Johan Engelen wrote
My questions:
1) Is it OK to put a more general bsf/bsr in druntime or in
Phobos? (if Phobos: in which package to put it?)
IMO I want a std.integer package for such functions.
I started writing one but I have to rewrite it.
I
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 Saturday, 21 February 2015 at 14:02:41 UTC, Daniel Murphy
wrote:
https://auto-tester.puremagic.com/?projectid=10
This is a pretty big milestone for the project. For the first
time, an unpatched dmd can build ddmd, and that ddmd can build
druntime and phobos and pass all the test suites.
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 Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei
Alexandrescu wrote:
On my reading list:
http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf
http://users.cecs.anu.edu.au/~steveb/downloads/pdf/immix-pldi-2008.pdf
(this has been mentioned before)
Andrei
These are
On Thursday, 25 December 2014 at 09:46:19 UTC, Martin Nowak wrote:
On Saturday, 20 December 2014 at 19:22:05 UTC, safety0ff wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak
wrote:
Just wondering what the general sentiment is.
Multiple alias this (DIP66 / #6083.)
It's
On Friday, 2 January 2015 at 14:34:39 UTC, Martin Nowak wrote:
Would be nice to have @noinline, @forceinline and
__builtin_expect.
It's rare to get measurable gains from __builtin_expect, and
since there is no macro preprocessor in D, it's likely less
verbose to just put the common case as
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
Multiple alias this (DIP66 / #6083.)
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 Wednesday, 5 November 2014 at 03:54:23 UTC, Craig Dillabaugh
wrote:
This is my second Call for Proposals for the 2015 Google Summer
of Code. Anyone interested in mentoring, or who has good idea's
for a project for 2015 please post here.
I think it'd be awesome to have something like
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 Saturday, 25 October 2014 at 16:14:30 UTC, Trass3r wrote:
Yes it's clearly stated on the ABI page (and sane).
Nobody ever noticed cause it's hard to spot this in assembly.
I've hit it a few times, I wasn't sure if it was me or the
compiler that was mistaken so I didn't create a report, I
On Thursday, 6 November 2014 at 01:31:40 UTC, Shammah Chancellor
wrote:
Is this fixed now?
https://issues.dlang.org/show_bug.cgi?id=7804
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
On Tuesday, 14 October 2014 at 13:29:33 UTC, Dmitry Olshansky
wrote:
Also it's universal as in any github-hosted D project, for
example here is an output for druntime:
http://wiki.dlang.org/Stuff_in_Druntime_That_Generates_Garbage
Still todo:
- a few bugs to fix in artifact labeling
One
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 06:00:31 UTC, ketmar via
Digitalmars-d-announce wrote:
i believe that those rules are useless and senseless now, so
it's more like a one man crusade.
It's not a one man's crusade, it affects legibility and creates
dissonance within the text.
It also appears
On Saturday, 30 August 2014 at 07:59:16 UTC, Gary Willoughby
wrote:
Stop being such a grammar nazi.
I didn't bring it up because I felt like being pedantic, I
brought it up as a suggestion to make it more pleasant to read.
Since you've already been labelled as a pedant, perhaps you
Just a correction:
On Saturday, 30 August 2014 at 10:44:20 UTC, safety0ff wrote:
Since you've already been labelled as a pedant, perhaps you
should learn the difference between pedantry and Nazism.
I meant:
Since you've already labelled *me*
Anyways.
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.
On Thursday, 28 August 2014 at 16:06:11 UTC, Gary Willoughby
wrote:
Direct link:
http://nomad.so/2014/08/hidden-treasure-in-the-d-standard-library/
What do you have against capitalizing 'I' ?
It's annoying / distracting to read text filled with
uncapitalised 'I's.
On Friday, 22 August 2014 at 01:54:55 UTC, Paul D Anderson wrote:
Is this expected behavior that has never been enforced before,
or is it something new?
And is anyone else having the same problem?
Paul
Looks like a regression, I've filed it here:
On Monday, 18 August 2014 at 23:18:46 UTC, Vladimir Panteleev
wrote:
On Monday, 18 August 2014 at 23:14:45 UTC, Dicebot wrote:
I also propose to start 2.067 beta branch right now and
declare it yet another bug-fixing release.
Isn't this what point-releases are for, though?
I agree, I think
On Wednesday, 20 August 2014 at 00:14:59 UTC, Andrew Edwards
wrote:
On 8/20/14, 8:38 AM, safety0ff wrote:
I agree, I think 2.066.next should be the focus considering
the known
issues of 2.066.
Fear not, point releases will address known deficiencies.
Btw, thank you for the good work
On Tuesday, 19 August 2014 at 17:39:13 UTC, Ivan Kazmenko wrote:
It looks like I want to have most of my data under something
like GC.BlkAttr.NO_SCAN. But I don't yet see a clean way to
introduce something like that in the code.
GC.BlkAttr.NO_INTERIOR can also be useful for eliminating
On Saturday, 16 August 2014 at 17:55:28 UTC, Gary Willoughby
wrote:
Funnily enough i've been toying with linked lists using the
same kind of nodes here:
https://github.com/nomad-software/etcetera/blob/master/source/etcetera/collection/linkedlist.d
Might be of use to you?
Why did you put
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 Friday, 8 August 2014 at 12:01:43 UTC, Andrew Edwards wrote:
DMD v2.066.0-rc2 binaries are available for testing:
http://wiki.dlang.org/Beta_Testing
Probably too late but
https://github.com/D-Programming-Language/dmd/pull/3826 is an ICE
wrong-code fix which requires review (green
On Sunday, 10 August 2014 at 08:34:40 UTC, Era Scarecrow wrote:
Depends on how many pesky extra braces you want to avoid...
enum Flags {a,b,c,readonly,write,etc}
void func(Flags f){
switch(f) {
with(Flags): //or put this outside the switch...
For that specific case, put it outside
On Friday, 8 August 2014 at 22:28:56 UTC, Era Scarecrow wrote:
On Friday, 8 August 2014 at 21:35:59 UTC, Dmitry Olshansky
wrote:
FYI
https://github.com/D-Programming-Language/phobos/pull/2248
https://github.com/D-Programming-Language/phobos/pull/2249
These were mostly bugfixes not trying to
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 Thursday, 31 July 2014 at 22:45:44 UTC, Timon Gehr wrote:
For example, because it might actually be random on the first
invocation and cached later. :-)
This is interesting.
Some hash functions in druntime might break in an environment
with a precise moving GC.
1 - 100 of 236 matches
Mail list logo
