Forgetting to do
import std.functional: binaryFun;
before trying to compile
bool skipOverSafe(alias pred = "a == b", R1, R2)(ref R1 r1, R2 r2)
@safe pure if (is(typeof(binaryFun!pred(r1.front, r2.front
{
return r1.length >= r2.length && skipOver!pred(r1, r2); //
TODO: Can we prev
Are there some nice traits or internals to query the current call
stack for address or perhaps even their (mangled) names. I'm
mostly interested in using this to detect infinite recursions in
my recursive descent parser. This provided that my parser slice
hasn't changed since last call to the s
On Monday, 1 September 2014 at 17:24:10 UTC, rcor wrote:
Just wanted to point out that there are also D bindings for
Allegro5 (https://github.com/SiegeLord/DAllegro5). Allegro is a
bit like SDL or SFML, but personally I find it a bit more
intuitive. I've been using the D bindings for about a mo
On 09/01/2014 11:23 AM, nikki wrote:
ah so much cleaner then the mess I was almost into ;)
thanks
In case they are useful to you or somebody else, the following chapters
are relevant.
Value Types and Reference Types:
http://ddili.org/ders/d.en/value_vs_reference.html
Pointers:
http:/
ah so much cleaner then the mess I was almost into ;)
thanks
On Monday, 1 September 2014 at 18:08:48 UTC, nikki wrote:
so I am still very new to structs and & and * adress and
pointer stuff, I have this basic code :
struct S {
int value = 0;
}
void func(S thing){
writeln(&thing); //BFC52B44
thing.value = 100;
}
sorry could have quicker just googled it thanks!
so I am still very new to structs and & and * adress and pointer
stuff, I have this basic code :
struct S {
int value = 0;
}
void func(S thing){
writeln(&thing); //BFC52B44
thing.value = 100;
}
S guy = {value:200};
writeln(&guy); //BFC52CCC
f
Also, regarding comments about Garbage Collection -- yes, it
could be an issue, but its not a showstopper. C# (which has a GC)
was widely used to create PC and 360 games with the XNA library
(which lives on as MonoGame). If you have a real time game that
manages many objects at once, you may ha
Just wanted to point out that there are also D bindings for
Allegro5 (https://github.com/SiegeLord/DAllegro5). Allegro is a
bit like SDL or SFML, but personally I find it a bit more
intuitive. I've been using the D bindings for about a month and
they seem to work fine. Most Allegro tutorials ar
On Sunday, 31 August 2014 at 03:06:48 UTC, Dicebot wrote:
My guess is that it hasn't been ported to the D1 compiler yet.
Dicebot or any other people who work for Sociomantic should be
most helpful. At this point, I recommend that you ask on the
main D forum.
Ali
I have not encountered such
On Monday, 1 September 2014 at 13:31:32 UTC, Matt wrote:
If I were to use Runtime.loadLibrary(), it claims to merge any
D GC in the shared lib with the current process' GC.
Do I need to version away symbol loading code for each platform?
Or is there already code in Phobos that allows us to do t
If I were to use Runtime.loadLibrary(), it claims to merge any D
GC in the shared lib with the current process' GC.
Do I need to version away symbol loading code for each platform?
Or is there already code in Phobos that allows us to do this
independent of platform?
On Mon, 01 Sep 2014 11:56:33 +
evilrat via Digitalmars-d-learn
wrote:
> and D states "intuitive is the way", yeah...
it's still way better than C++. ;-)
signature.asc
Description: PGP signature
On Mon, 01 Sep 2014 09:16:04 +
bearophile via Digitalmars-d-learn
wrote:
> https://issues.dlang.org/show_bug.cgi?id=13410
ah, silly me. i should stop publish patches until i rewrote 'em at
least three times.
we have a winner now: new patch should not hurt AA performance in
normal use cases y
On Monday, 1 September 2014 at 11:23:37 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 01 Sep 2014 10:57:41 +
evilrat via Digitalmars-d-learn
wrote:
p.s. you should really read about D mixins and templates. they
aren't
such intuitive sometimes, has their set of funny restrictions,
a
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 Mon, 01 Sep 2014 09:16:04 +
bearophile via Digitalmars-d-learn
wrote:
> https://issues.dlang.org/show_bug.cgi?id=13410
added another version of the patch. it doesn't significantly improves
your original code execution time, but makes syntetic tests runs with
the same speed.
aa.remove() is
On Mon, 01 Sep 2014 10:57:41 +
evilrat via Digitalmars-d-learn
wrote:
p.s. you should really read about D mixins and templates. they aren't
such intuitive sometimes, has their set of funny restrictions, and it
may be hard to 'guess the right way' sometimes.
but to be honest, i wasn't read an
On Mon, 01 Sep 2014 10:57:41 +
evilrat via Digitalmars-d-learn
wrote:
and to check that ugly hackery:
mixin template makeAlias(string aliasName, string Name, alias
Replace) {
static if ( __traits(compiles, (mixin(Name~`.sizeof`))) )
mixin(`alias `~aliasName~` = ` ~ Name
On Mon, 01 Sep 2014 10:57:41 +
evilrat via Digitalmars-d-learn
wrote:
here's some more ugly hackery for you:
string makeAlias(string aliasName, string Name, alias Replace) ()
{
static if ( __traits(compiles, (mixin(Name~`.sizeof`))) )
return `alias `~aliasName~` = ` ~ N
On Mon, 1 Sep 2014 12:51:58 +0200
Daniel Kozak via Digitalmars-d-learn
wrote:
> The problem is with searching first element
yes. AAs aren't very good in "give me some so-called 'first' element",
especially current druntime AAs. i'm not sure it worth heavy-fixing
though. i sped it up a little (see
On Sunday, 31 August 2014 at 12:01:43 UTC, evilrat wrote:
On Sunday, 31 August 2014 at 11:43:03 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sun, 31 Aug 2014 11:26:47 +
evilrat via Digitalmars-d-learn
wrote:
alias myint = mixin("int"); // <- basic type expected blah
blah
mixin("alias
V Mon, 1 Sep 2014 12:38:52 +0300
ketmar via Digitalmars-d-learn
napsáno:
> On Mon, 01 Sep 2014 09:22:50 +
> bearophile via Digitalmars-d-learn
> wrote:
>
> > In theory the best solution is to improve the performance of the
> > "byKey.front" and "byValue.front" idioms.
> i found that slowdo
On Mon, 01 Sep 2014 09:16:04 +
bearophile via Digitalmars-d-learn
wrote:
> https://issues.dlang.org/show_bug.cgi?id=13410
i added 'quick-hack-patch' to your report which halves execution time
without significantly hurting performance in other AA uses.
now there is no difference between `long
On Mon, 1 Sep 2014 12:38:52 +0300
ketmar via Digitalmars-d-learn
wrote:
> i found that slowdown is from _aaRange()
and i'm wrong again. adding `_aaFrontKey()` and `_aaFrontValue()` makes
no difference at all.
that's 'cause both hooks need to go thru bucket array to find first
entry. unless we ad
Thanks for the answers!
On Mon, 01 Sep 2014 09:22:50 +
bearophile via Digitalmars-d-learn
wrote:
> In theory the best solution is to improve the performance of the
> "byKey.front" and "byValue.front" idioms.
i found that slowdown is from _aaRange(), not from delegates.
the following code is slow even w/o delegate c
ketmar:
But I think the "j = x.byKey.front; p = x.byValue.front;"
code looks sufficiently idiomatic, and its performance is
terrible.
that's why i suggest to extend AA API, adding x.firstKey and
x.firstValue functions. i'll try to make the patch soon.
In theory the best solution is to impr
It seems fit for a performance bug report. I have to create a
synthetic benchmark that shows just the problem.
https://issues.dlang.org/show_bug.cgi?id=13410
(Perhaps I have credited the wrong person there, sorry, I will
fix).
Bye,
bearophile
On Mon, 01 Sep 2014 08:53:45 +
bearophile via Digitalmars-d-learn
wrote:
> This is a little cleaner:
yes, i just did a 'quickhack' without even analyzing what the code
does. ;-)
signature.asc
Description: PGP signature
On Mon, 01 Sep 2014 08:53:45 +
bearophile via Digitalmars-d-learn
wrote:
> ketmar:
> Thank you for your analysis and code.
actually, it's based on Daniel Kozak's observation, so credit him
instead. ;-)
> But I think the "j = x.byKey.front; p = x.byValue.front;" code
> looks sufficiently id
ketmar:
Thank you for your analysis and code.
while (x.length) {
foreach (key; x.keys) {
auto pp = key in x;
if (pp is null) continue;
j = key;
p = *pp;
x.remove(j);
This is a little cleaner:
while (x.lengt
On Mon, 1 Sep 2014 09:21:03 +0200
Daniel Kozak via Digitalmars-d-learn
wrote:
and this version executes in 0.2 seconds:
import core.stdc.stdio;
immutable H = 9, W = 12;
immutable uint[3][6] g = [
[7, 0, H - 3],
[1 + (1 << H) + (1 << (2 * H)), 0, H - 1],
[3 + (1 <<
On Mon, 1 Sep 2014 09:21:03 +0200
Daniel Kozak via Digitalmars-d-learn
wrote:
> I think main problem is in calling delegates (x.byKey.front and
> x.byValue.front;). If I change x.byValue.front with x[j], It makes
> program a lot faster
yes. replacing `p = x.byValue.front;` by `p = x[j];` cutted
d
Charles:
My solution I came up with (and works locally) is:
import std.stdio;
void main() {
int height=1,t=1,oldN=0,n;
readf(" %d\n", &t);
foreach (i;0 .. t) {
readf(" %d\n", &n);
foreach (j; oldN .. n)
I suggest to add a blank line after the import, to move t
V Sun, 31 Aug 2014 10:55:31 +
bearophile via Digitalmars-d-learn
napsáno:
> This is C++ code that solves one Euler problem:
>
> --
> #include
> #include
>
> const unsigned int H = 9, W = 12;
>
> const int g[6][3] = {{7, 0, H - 3},
> {1 + (1 << H) + (1 <<
37 matches
Mail list logo
