On Thursday, 14 August 2014 at 00:56:47 UTC, Jonathan M Davis
wrote:
You forgot the !, making the predicate a function argument. It
Great!
My solution:
auto dropWhile(R, E)(R range, E element) if (isInputRange!R
is(ElementType!R ==
E))
{
The default size of the runtime stack for a Fiber is 4*PAGESIZE
which is very small, and a quick test shows that a Fiber suffers
a stack overflow that doesn't lead to a clean termination when
this limit is exceeded.
This makes it difficult to simulate deterministic alternation
where the
Using __traits (identifier, ...) and a template alias seems to work for me:
import std.stdio;
/// Two kinds of enums:
/// A named enum.
enum VmParams {
OBJ_MIN_CAP,
PROTO_SLOT_IDX,
FPTR_SLOT_IDX,
}
/// An anonymous one.
enum {
ATTR_CONFIGURABLE = 3,
ATTR_WRITABLE,
On Wednesday, 13 August 2014 at 19:30:53 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
On Wed, Aug 13, 2014 at 07:23:30PM +, via
Digitalmars-d-learn wrote:
On Wednesday, 13 August 2014 at 18:58:59 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
On Wed, Aug 13, 2014 at 06:31:32PM +, Gary
On Tuesday, 12 August 2014 at 07:16:50 UTC, Jeremy DeHaan wrote:
I recently got this error messege when building my library:
dmd: cppmangle.c:154: void
CppMangleVisitor::cpp_mangle_name(Dsymbol*): Assertion `0'
failed.
I have no idea what it means and haven't found much information
about
I have just checked it and yes, it works with a constant that is not an
enum: `const int FOO` defined in the module namespace or `static int
BAR` defined in the dummy Vm class.
On 08/14/2014 02:08 PM, Maxime Chevalier-Boisvert wrote:
Thanks. Does it also work with a constant that's not an
TJB:
I am trying to find the max and min values in an associative
array. Say I have:
double[char] bids;
bid['A'] = 37.50;
bid['B'] = 38.11;
bid['C'] = 36.12;
How can I find the max and min values. I am thinking that I
need to use max and min functions from std.algorithm, but not
sure how
Théo Bueno:
Same issue here with dsfml-audio, this is really annoying :/
Have you filed the issue?
Bye,
bearophile
On Thursday, 14 August 2014 at 13:28:03 UTC, bearophile wrote:
Théo Bueno:
Same issue here with dsfml-audio, this is really annoying :/
Have you filed the issue?
Bye,
bearophile
Jebbs filed an issue on his bugtracker :
https://github.com/Jebbs/DSFML/issues/125
... and he seems to have a
On Thursday, 14 August 2014 at 13:10:58 UTC, bearophile wrote:
Marc Schütz:
Isn't SuperFastHash vulnerable to collision attacks?
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
What's the preferrred way to check if a string starts with
another string if the string is a
1. string (utf-8) BiDir
2. wstring (utf-16) BiDir
3. dstring (utf-32) Random
On Thu, 14 Aug 2014 17:17:11 +, Nordlöw wrote:
What's the preferrred way to check if a string starts with another
string if the string is a
1. string (utf-8) BiDir 2. wstring (utf-16) BiDir 3. dstring (utf-32)
Random
std.algorithm.startsWith? Should auto-decode, so it'll do a utf-32
On Thursday, 14 August 2014 at 17:41:08 UTC, Nordlöw wrote:
On Thursday, 14 August 2014 at 17:33:41 UTC, Justin Whear wrote:
std.algorithm.startsWith? Should auto-decode, so it'll do a
What about
https://github.com/D-Programming-Language/phobos/pull/2043
Auto-decoding should be avoided
On Thursday, 14 August 2014 at 17:16:42 UTC, Philippe Sigaud
wrote:
From time to time, I try to speed up some array-heavy code by
using std.array.Appender, reserving some capacity and so on.
It never works. Never. It gives me executables that are maybe
30-50% slower than bog-standard array
On 64 bit, reserve a huge chunk of memory, set a SEGV handler and
commit more as needed. Basically how kernel thread stacks work.
I've been meaning to do this but haven't gotten around to it yet.
Superfast. Though Murmur has gotten good enough that I'm tempted
to switch. At the time, Murmur didn't even have a license so it
wasn't an option.
I don't know much about Phobos appender implementation details but the key
thing with reusable buffer is avoid freeing them. AFAIR Appender.clear frees
the allocated memory but `Appender.length = 0` does not, making it possible
to just overwrite stuff again and again.
I call .clear() only at
safety0ff:
Here's a candidate for
http://rosettacode.org/wiki/Extensible_prime_generator#D in
case it is preferred to the existing entry:
http://dpaste.dzfl.pl/43735da3f1d1
I was away. I have added your nice code with some small changes
as an alternative faster version. I think you have
On Thursday, 14 August 2014 at 17:16:42 UTC, Philippe Sigaud
wrote:
From time to time, I try to speed up some array-heavy code by
using std.array.Appender, reserving some capacity and so on.
It never works. Never. It gives me executables that are maybe
30-50% slower than bog-standard array
On Thursday, 14 August 2014 at 07:46:29 UTC, Carl Sturtivant
wrote:
The default size of the runtime stack for a Fiber is 4*PAGESIZE
which is very small, and a quick test shows that a Fiber
suffers a stack overflow that doesn't lead to a clean
termination when this limit is exceeded.
This
I've never really tried to benchmark it, but it was my understanding that
the idea behind Appender was to use it to create the array when you do that
via a lot of appending, and then you use it as a normal array and stop using
Appender.
That's how I use it, yes.
It sounds like you're trying
On Thursday, 14 August 2014 at 19:29:28 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
It sounds like you're trying to use it as a way to manage
reusing
the array, and I have no idea how it works for that.
There is a misunderstanding there: I'm using clear only to
flush the
state at the
On Thursday, 14 August 2014 at 19:10:18 UTC, Jonathan M Davis
wrote:
I've never really tried to benchmark it, but it was my
understanding that the idea behind Appender was to use it to
create the array when you do that via a lot of appending, and
then you use it as a normal array and stop
On Thursday, 14 August 2014 at 18:55:55 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
btw, I saw your Dconf talk yesterday, nice content! And thanks
for
talking about Pegged!
It might interest you to know that the code I'm trying to use
Appender
on is a new engine for Pegged, based on
On Thursday, 14 August 2014 at 19:29:28 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
There is a misunderstanding there: I'm using clear only to
flush the
state at the beginning of the computation. The Appender is a
class
field, used by the class methods to calculate. If I do not
clear
On Thursday, 14 August 2014 at 20:25:20 UTC, Nordlöw wrote:
Destroy!
Correction: These algorithms require ForwardRanges.
I'm currently working on implementing demangling of ELF C++
symbols according to
https://en.wikipedia.org/wiki/Name_mangling
A reoccurring pattern high-level pattern is to use the
std.algorithm: findSplit.* functions to make algorithm
single-pass when possible.
I'm however lacking a
There is a misunderstanding there: I'm using clear only to flush the
state at the beginning of the computation. The Appender is a class
field, used by the class methods to calculate. If I do not clear it at
the beginning of the methods, I keep appending new results to old
computations, which
Thanks! Repeating what I have mentioned during DConf talk - have you ever
considered proposing Pegged for Phobos inclusion? It feels like important
bit of infrastructure to me.
At the time, it was considered (rightfully) far too slow and
memory-hogging. I think having a generic lexer and a
On Thursday, 14 August 2014 at 20:28:38 UTC, Nordlöw wrote:
On Thursday, 14 August 2014 at 20:25:20 UTC, Nordlöw wrote:
Destroy!
Correction: These algorithms require ForwardRanges.
Ooops, I just realized that we can't express current Phobos
implementations using my variant. Current
On Thursday, 14 August 2014 at 20:42:08 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
You mean by using the shrinkTo method? (Appender does not have a
length, that's a bit of a bother btw).
I just did, it does not change anything. Too bad.
Heck, my code is simpler to read and use *and*
On Thursday, 14 August 2014 at 20:50:37 UTC, Dicebot wrote:
Oh crap I had std.array.Array in mind which does have `length`
exposes. And Appender seems to indeed clear / shrink data in a
horrible way:
https://github.com/D-Programming-Language/phobos/blob/master/std/array.d#L2597
On Thursday, 14 August 2014 at 20:48:42 UTC, Nordlöw wrote:
Ooops, I just realized that we can't express current Phobos
implementations using my variant. Current algorithms take
ranges not range values as a needle. My mistake. Are my
overloads still wanted?
Ok. I finally understood that a
On Thursday, 14 August 2014 at 19:47:33 UTC, Brad Anderson wrote:
On Thursday, 14 August 2014 at 19:10:18 UTC, Jonathan M Davis
wrote:
I've never really tried to benchmark it, but it was my
understanding that the idea behind Appender was to use it to
create the array when you do that via a lot
IIRC it manages the capacity information manually instead of
calling the runtime which reduces appending overhead.
On 14/08/14 19:16, Philippe Sigaud via Digitalmars-d-learn wrote:
Do people here get good results from Appender? And if yes, how are you using it?
An example where it worked for me:
http://braingam.es/2013/09/betweenness-centrality-in-dgraph/
(You will have to scroll down a bit to get to the
On Thursday, 14 August 2014 at 21:00:55 UTC, Jonathan M Davis
wrote:
On Thursday, 14 August 2014 at 19:47:33 UTC, Brad Anderson
wrote:
On Thursday, 14 August 2014 at 19:10:18 UTC, Jonathan M Davis
wrote:
I've never really tried to benchmark it, but it was my
understanding that the idea behind
On Thursday, 14 August 2014 at 21:11:51 UTC, safety0ff wrote:
IIRC it manages the capacity information manually instead of
calling the runtime which reduces appending overhead.
That would make some sense, though it must be completely avoiding
~= then and probably is even GC-mallocing the
On 14/08/14 23:33, Joseph Rushton Wakeling via Digitalmars-d-learn wrote:
An example where it worked for me:
http://braingam.es/2013/09/betweenness-centrality-in-dgraph/
I should add that I don't think I ever explored the case of just using a regular
array with assumeSafeAppend. Now that
On Thursday, 14 August 2014 at 21:04:06 UTC, Nordlöw wrote:
Should this go into Phobos?
My variants can be found at the bottom of
https://github.com/nordlow/justd/blob/master/algorithm_ex.d
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 Thursday, 14 August 2014 at 21:34:04 UTC, Jonathan M Davis
wrote:
On Thursday, 14 August 2014 at 21:11:51 UTC, safety0ff wrote:
IIRC it manages the capacity information manually instead of
calling the runtime which reduces appending overhead.
That would make some sense, though it must be
On Thursday, 14 August 2014 at 18:52:00 UTC, Sean Kelly wrote:
On 64 bit, reserve a huge chunk of memory, set a SEGV handler
and commit more as needed. Basically how kernel thread stacks
work. I've been meaning to do this but haven't gotten around to
it yet.
I think using some sort of
On Thursday, 14 August 2014 at 21:34:04 UTC, Jonathan M Davis
wrote:
On Thursday, 14 August 2014 at 21:11:51 UTC, safety0ff wrote:
IIRC it manages the capacity information manually instead of
calling the runtime which reduces appending overhead.
That would make some sense, though it must be
On Thursday, 14 August 2014 at 13:47:58 UTC, Théo Bueno wrote:
On Thursday, 14 August 2014 at 13:28:03 UTC, bearophile wrote:
Théo Bueno:
Same issue here with dsfml-audio, this is really annoying :/
Have you filed the issue?
Bye,
bearophile
Jebbs filed an issue on his bugtracker :
I'm looking into making a binding for the C++ API called Botan, and the
constructors in it take a std::function. I'm wondering if there's a D
equivalent for this binding to work out, or if I have to make a C++
wrapper as well?
On Thursday, 14 August 2014 at 17:16:42 UTC, Philippe Sigaud
wrote:
From time to time, I try to speed up some array-heavy code by
using std.array.Appender, reserving some capacity and so on.
It never works. Never. It gives me executables that are maybe
30-50% slower than bog-standard array
47 matches
Mail list logo
