Since there is CTFE, I keep running into, do I really need this
as a template parameter? Why not put this in a constructor. And
so on...
On 3/24/12, H. S. Teoh wrote:
> OK, I found that your template doesn't handle the case where the key
> type is an AA.
Heh, yeah, I've never used hashes as key types before.
> However, one case remains unsolved: either I can't find the right way to
> express this, or the new AA template needs fix
On Sat, Mar 24, 2012 at 05:56:27AM +0100, Andrej Mitrovic wrote:
> On 3/24/12, H. S. Teoh wrote:
> > Cool. Should I just replace the current AA alias with Assoc? I think
> > this is far more concise, and much easier to convert to "real" AA
> > syntax when we integrate with druntime/dmd.
>
> Sure.
On 3/24/12, Andrej Mitrovic wrote:
> https://github.com/msgpack/msgpack-d
Btw, thank you very much for your hard work Masahiro Nakagawa! Your
serialization library has reduced my waiting time by over 20 seconds
(I used Json before even though I didn't need a human-readable
format).
On Sat, Mar 24, 2012 at 06:08:40AM +0100, Andrej Mitrovic wrote:
> On 3/24/12, H. S. Teoh wrote:
> > Note that if hash literals are used, then they can be inefficient
> > because of the current hack of copying from the current AA (so it
> > will involve two copies
>
> Okie. I was mostly measuring
On 3/21/12, Andrej Mitrovic wrote:
> Hi,
>
> it seems MessagePack won't compile with 2.058:
Oops sorry about that. I've used this old repository:
https://bitbucket.org/repeatedly/msgpack4d/
instead of the new one:
https://github.com/msgpack/msgpack-d
I think you should delete the old one if it'
On 3/24/12, H. S. Teoh wrote:
> Note that if hash literals are used, then they can be inefficient
> because of the current hack of copying from the current AA (so it will
> involve two copies
Okie. I was mostly measuring lookups though. I can't accurately
measure writes because I'm taking data fr
On Sat, Mar 24, 2012 at 05:47:55AM +0100, Andrej Mitrovic wrote:
[...]
> I've managed to test the hashes on a small-sized closed-source project
> (9K lines) which used hashes a lot. I've found no issues so far (no
> memory corruption or anything). Performance did drop a bit from
> 812msecs to 898ms
On 3/24/12, H. S. Teoh wrote:
> Cool. Should I just replace the current AA alias with Assoc? I think
> this is far more concise, and much easier to convert to "real" AA syntax
> when we integrate with druntime/dmd.
Sure. I kept wondering whether AA!(int, string) is a hash with an int
or a string
On 3/24/12, H. S. Teoh wrote:
> I have a much simpler version:
>
> template Assoc(T)
> {
> static if (is(T K : V[K], V))
> alias AA!(K,V) Assoc;
> else
> static assert(0);
> }
>
> :-)
Yeah but with a type st
On 3/24/12, Andrej Mitrovic wrote:
> snip
I've managed to test the hashes on a small-sized closed-source project
(9K lines) which used hashes a lot. I've found no issues so far (no
memory corruption or anything). Performance did drop a bit from
812msecs to 898msecs. I can't extensively test this
On Sat, Mar 24, 2012 at 05:12:00AM +0100, Andrej Mitrovic wrote:
> On 3/24/12, H. S. Teoh wrote:
> > Fix pushed to github. :-)
>
> Okay. Then I have some eye-candy for you:
I have a much simpler version:
template Assoc(T)
{
static if (is(T K : V[K], V))
On 3/24/12, Andrej Mitrovic wrote:
> Anyways, this doesn't seem to work.
Another bug:
struct Foo {
string s;
}
AA!(string, Foo) test;
newAA.d(378): Error: template newAA.toHash(T) if (is(T == char) ||
is(T == const(char)) || is(T == immutable(char))) toHash(T) if (is(T
== char) || is(T == c
On 3/24/12, H. S. Teoh wrote:
> Fix pushed to github. :-)
Okay. Then I have some eye-candy for you:
template Assoc(T)
if (std.traits.isAssociativeArray!T)
{
alias AA!(GetTypesTuple!T) Assoc;
}
import std.typetuple;
template GetTypesTuple(T)
if (std.traits.isAssociativeArray!T)
{
On Sat, Mar 24, 2012 at 04:21:21AM +0100, Andrej Mitrovic wrote:
> On 3/24/12, H. S. Teoh wrote:
[...]
> > Another issue:
> >
> > AA!(string,int[]) aa;
> > auto x = aa.get("abc", []);
>
> Yeah, templates are unforgiving sometimes.
Well, I wish that compiler magic that does these inferenc
On 3/24/12, H. S. Teoh wrote:
> On Sat, Mar 24, 2012 at 02:39:35AM +0100, Andrej Mitrovic wrote:
>> I thought I'd open this topic for discussion of issues with the new
>> hash implementation.
> [...]
>
> Another issue:
>
> AA!(string,int[]) aa;
> auto x = aa.get("abc", []);
Yeah, temp
On Tuesday, 20 March 2012 at 22:52:13 UTC, James Miller wrote:
A bit of a side note, but is there any way that some of this
work
could be made more standalone, even if somebody else has to
take up
the work to finish it and make it truly standalone. I
personally can't
stand fully integrated envi
On Sat, Mar 24, 2012 at 02:39:35AM +0100, Andrej Mitrovic wrote:
> I thought I'd open this topic for discussion of issues with the new
> hash implementation.
[...]
Another issue:
AA!(string,int[]) aa;
auto x = aa.get("abc", []);
This fails to compile, because the compiler deduces
On 3/24/12, Andrej Mitrovic wrote:
> Anyways, this doesn't seem to work:
>
> AA!(string,int[]) hash;
Ok it works now w/ your patch.
On Sat, Mar 24, 2012 at 03:15:49AM +0100, Andrej Mitrovic wrote:
> On 3/24/12, Andrej Mitrovic wrote:
> > Anyways, this doesn't seem to work:
> >
> > AA!(string,int[]) hash;
>
> Ok it works now w/ your patch.
You probably want to git pull, 'cos I found 2-3 other places where I
forgot about inout
On 3/24/12, Andrej Mitrovic wrote:
> Anyways, this doesn't seem to work:
>
> AA!(string,int[]) hash;
Ok it works now w/ your patch.
On Sat, Mar 24, 2012 at 03:11:32AM +0100, Andrej Mitrovic wrote:
> On 3/24/12, H. S. Teoh wrote:
> > Argh. Looks like it's caused by more const madness. :-( Try this diff:
>
> Ahaha:
> patching file newAA.d
> Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 354
> This application has
On 3/24/12, H. S. Teoh wrote:
> Argh. Looks like it's caused by more const madness. :-( Try this diff:
Ahaha:
patching file newAA.d
Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 354
This application has requested the Runtime to terminate it in an unusual way.
Please contact the ap
On Sat, Mar 24, 2012 at 02:39:35AM +0100, Andrej Mitrovic wrote:
> I thought I'd open this topic for discussion of issues with the new
> hash implementation.
>
> Anyways, this doesn't seem to work:
>
> AA!(string,int[]) hash;
[...]
Argh... in the process of trying to fix this issue, I ran into a
On Sat, Mar 24, 2012 at 02:39:35AM +0100, Andrej Mitrovic wrote:
> I thought I'd open this topic for discussion of issues with the new
> hash implementation.
Thanks for taking the time to test the code!
> Anyways, this doesn't seem to work:
>
> AA!(string,int[]) hash;
>
> D:\dev\projects\New-A
I thought I'd open this topic for discussion of issues with the new
hash implementation.
Anyways, this doesn't seem to work:
AA!(string,int[]) hash;
D:\dev\projects\New-AA-implementation>rdmd
-ID:\DMD\dmd2\src\druntime\src newAATest.d
newAA.d(581): Error: template
newAA.AA!(string,int[]).Associa
On Fri, Mar 23, 2012 at 10:53:10PM +0100, Timon Gehr wrote:
> On 03/23/2012 10:07 PM, Timon Gehr wrote:
> >
> >I see. An alternative solution (one that does not make AAs depend on
> >Phobos and is more slick) would be to use the const qualified key type
> >for lookup (that is what const is for) and
Andrej Mitrovic:
> On 3/23/12, Timon Gehr wrote:
> > Maybe you are also missing that this is valid code:
> > int[] a = [1 : 2, 3 : 4];
>
> What is this syntax for and how is it used? It creates '[0, 2, 0, 4]',
> which is puzzling to me.
See:
http://d.puremagic.com/issues/show_bug.cgi?id=4703
T
On 03/23/2012 10:07 PM, Timon Gehr wrote:
I see. An alternative solution (one that does not make AAs depend on
Phobos and is more slick) would be to use the const qualified key type
for lookup (that is what const is for) and to have immutable keys for
stores. For types that define .idup, there w
On 03/23/2012 09:43 PM, Andrei Alexandrescu wrote:
On 3/23/12 3:23 PM, Timon Gehr wrote:
On 03/23/2012 09:05 PM, Andrei Alexandrescu wrote:
On 3/23/12 2:28 PM, Timon Gehr wrote:
On 03/23/2012 08:06 PM, Andrei Alexandrescu wrote:
Casting is very different from to, and useless for your purpose
On 3/23/12, Timon Gehr wrote:
> It creates an array from key-value pairs. a[1] will be 2 and a[3] will
> be 4. Unspecified entries are default-initialized. It can be quite
> useful for building lookup tables.
Interesting. It's documented under "Static Initialization of
Statically Allocated Arrays
On 3/23/12 3:23 PM, Timon Gehr wrote:
On 03/23/2012 09:05 PM, Andrei Alexandrescu wrote:
On 3/23/12 2:28 PM, Timon Gehr wrote:
On 03/23/2012 08:06 PM, Andrei Alexandrescu wrote:
Casting is very different from to, and useless for your purposes. You
must use to.
Andrei
druntime mustn't depe
On 03/23/2012 09:05 PM, Andrei Alexandrescu wrote:
On 3/23/12 2:28 PM, Timon Gehr wrote:
On 03/23/2012 08:06 PM, Andrei Alexandrescu wrote:
Casting is very different from to, and useless for your purposes. You
must use to.
Andrei
druntime mustn't depend on Phobos, and I don't see why it is
On 03/23/2012 09:10 PM, Andrej Mitrovic wrote:
On 3/23/12, Timon Gehr wrote:
Maybe you are also missing that this is valid code:
int[] a = [1 : 2, 3 : 4];
What is this syntax for and how is it used? It creates '[0, 2, 0, 4]',
which is puzzling to me.
It creates an array from key-value pairs
On 3/23/12, Timon Gehr wrote:
> Maybe you are also missing that this is valid code:
> int[] a = [1 : 2, 3 : 4];
What is this syntax for and how is it used? It creates '[0, 2, 0, 4]',
which is puzzling to me.
On 3/23/12 2:30 PM, H. S. Teoh wrote:
Wouldn't that require moving std.conv into druntime? And std.conv does
depend on std.traits as well...
Not sure how it's best to address this.
Andrei
On 3/23/12 2:28 PM, Timon Gehr wrote:
On 03/23/2012 08:06 PM, Andrei Alexandrescu wrote:
Casting is very different from to, and useless for your purposes. You
must use to.
Andrei
druntime mustn't depend on Phobos, and I don't see why it is necessary.
What kind of functionality do you want t
On 03/23/2012 08:06 PM, Andrei Alexandrescu wrote:
Casting is very different from to, and useless for your purposes. You
must use to.
Andrei
druntime mustn't depend on Phobos, and I don't see why it is necessary.
What kind of functionality do you want to provide that depends on
std.conv.to
On Fri, Mar 23, 2012 at 02:06:15PM -0500, Andrei Alexandrescu wrote:
[...]
> A cast would be needed anyway because they have different types,
> too. Anyway upon more thinking maybe this is too restrictive a rule.
> It won't catch e.g. functions that are, in fact, identical, but come
> from distinct
Something that *might* help is to do unit tests. Yeah,
that's kinda ass, but it would catch a stray virtual early.
Do a unit test that does a traits check for virtuals:
http://dlang.org/traits.html#getVirtualFunctions
if the name isn't on a list of approved virtuals,
static assert fail.
You'd
On 3/23/12 1:48 PM, H. S. Teoh wrote:
How do we check at compile time whether the hash function resolves to
the same entity?
int fun(T)(T x) {
return 42;
}
void main() {
static assert(&fun!int != &fun!double);
}
This actually reveals a compiler bug:
Assertion failed: (d->purity != PU
On 23 March 2012 17:24, Ary Manzana wrote:
> On 3/18/12 9:23 AM, Manu wrote:
>
>> The virtual model broken. I've complained about it lots, and people
>> always say "stfu, use 'final:' at the top of your class".
>>
>> That sounds tolerable in theory, except there's no 'virtual' keyword to
>> keep
On Mar 23, 2012, at 11:17 AM, "Nathan M. Swan" wrote:
> On Friday, 23 March 2012 at 12:36:42 UTC, David Nadlinger wrote:
>> Are you trying to build std.concurrency from Git master against Phobos 2.058
>> or something like that?
>>
>> David
>
> I cloned from git://github.com/D-Programming-Langu
On Fri, Mar 23, 2012 at 01:31:28PM -0500, Andrei Alexandrescu wrote:
[...]
> Let's see what requirements need to be satisfied by []. Say k is a
> value of the key type and x is a value being looked up.
>
> First, we need to be able to evaluate k == x. So the types must be
> comparable.
>
> Second
On 23.03.2012 22:17, Nathan M. Swan wrote:
On Friday, 23 March 2012 at 12:36:42 UTC, David Nadlinger wrote:
Are you trying to build std.concurrency from Git master against Phobos
2.058 or something like that?
David
I cloned from git://github.com/D-Programming-Language/phobos.git
NMS
replac
On 3/23/12 12:54 PM, H. S. Teoh wrote:
Currently my AA implementation supports automatic key conversion (as
suggested by Andrei), for example:
AA!(string,int) aa;
char[] key = "abc".dup;
aa[key] = 1;// automatically converts char[] to
On Fri, Mar 23, 2012 at 07:18:05PM +0100, Timon Gehr wrote:
> On 03/23/2012 07:10 PM, H. S. Teoh wrote:
> >On Fri, Mar 23, 2012 at 07:01:46PM +0100, Timon Gehr wrote:
> >>Why do you not just do the conversion and then compute the hash,
> >>even if the representation is the same?
> >
> >Because Andr
On 03/23/2012 07:10 PM, H. S. Teoh wrote:
On Fri, Mar 23, 2012 at 07:01:46PM +0100, Timon Gehr wrote:
Why do you not just do the conversion and then compute the hash, even
if the representation is the same?
Because Andrei says that the .idup shouldn't be performed unless it's
necessary (e.g.,
On Friday, 23 March 2012 at 12:36:42 UTC, David Nadlinger wrote:
Are you trying to build std.concurrency from Git master against
Phobos 2.058 or something like that?
David
I cloned from git://github.com/D-Programming-Language/phobos.git
NMS
On Fri, Mar 23, 2012 at 07:01:46PM +0100, Timon Gehr wrote:
> Why do you not just do the conversion and then compute the hash, even
> if the representation is the same?
Because Andrei says that the .idup shouldn't be performed unless it's
necessary (e.g., you should be able to lookup char[] in a s
Why do you not just do the conversion and then compute the hash, even if
the representation is the same?
Currently my AA implementation supports automatic key conversion (as
suggested by Andrei), for example:
AA!(string,int) aa;
char[] key = "abc".dup;
aa[key] = 1;// automatically converts char[] to
// string via .idup
The way this
On Friday, 23 March 2012 at 04:07:53 UTC, bearophile wrote:
I suggest to compile all your D2 code with -wi (or -w) and
-property.
Already using -w, and I thought I was using -property. I am now,
thanks.
And one bug of UFCS will be probably fixed by Hara
(http://d.puremagic.com/issues/sh
On Mar 22, 2012, at 10:35 PM, Nick Sabalausky wrote:
>
> And some of that fancier template stuff (like template fibonacci) is better
> done as CTFE anyway ;)
It is, but I think it should be covered anyway because people may still
encounter this code and should be able to grasp what it's doing.
On Mar 22, 2012, at 10:31 PM, H. S. Teoh wrote:
> On Fri, Mar 23, 2012 at 01:16:13AM -0400, Nick Sabalausky wrote:
>> "Nick Sabalausky" wrote in message
>> news:jk2ro7$6dl$1...@digitalmars.com...
>>>
>>> Here's a little templates primer, I hope it helps:
>>>
>>> [...]
>>
>> I've cleaned this
On 3/18/12 9:23 AM, Manu wrote:
The virtual model broken. I've complained about it lots, and people
always say "stfu, use 'final:' at the top of your class".
That sounds tolerable in theory, except there's no 'virtual' keyword to
keep the virtual-ness of those 1-2 virtual functions I have... so
Given that the four most popular languages today (Java, C, C++,
and C#) all function this way, I'd say it's fairly accurate.
But I also didn't to say Final by default should be default in
D (though I wouldn't really disagree with that direction
either), I do think D should have a virtual keywor
On Friday, 23 March 2012 at 13:58:00 UTC, Timon Gehr wrote:
On 03/23/2012 02:47 PM, F i L wrote:
... and most programmers are already used
to fixed by default anyways.
This assertion is unjustified.
Given that the four most popular languages today (Java, C, C++,
and C#) all function this
On 03/23/2012 02:46 PM, Jay Norwood wrote:
I believe the current std.parallelism default threadpool count is number
of cpus-1, according to some documentation. When I was testing some
concurrent vs threadpool parallel implementations I was seeing
improvements on the concurrent operation up to abo
On 03/23/2012 02:47 PM, F i L wrote:
... and most programmers are already used
to fixed by default anyways.
This assertion is unjustified.
I believe the current std.parallelism default threadpool count is
number of cpus-1, according to some documentation. When I was
testing some concurrent vs threadpool parallel implementations I
was seeing improvements on the concurrent operation up to about
14 threads. I didn't try to figure
Marco Leise wrote:
"the D compiler knows all of the class hierarchy when
generating code"
This is just wrong, and if that was the base for deciding on
virtual as default, I believe it is natural to think about it
again.
Yes, further reading has led me to believe that Manu is right in
his req
On Friday, 23 March 2012 at 01:35:05 UTC, Nathan M. Swan wrote:
Used to work, and std.concurrency doesn't even use std.utf.
Not sure what's going on there.
Weird :(
Are you trying to build std.concurrency from Git master against
Phobos 2.058 or something like that?
David
On 03/23/2012 12:33 AM, F i L wrote:
Timon Gehr wrote:
We have the macro keyword. I envision something like:
macro replaceAggregate(macro newAggregate, macro loop : foreach(x;
aggr){statements}, macro x, macro aggr, macro statements) {
foreach(x; newAggregate){statements}
}
void main(){
int[]
On 03/23/2012 07:15 AM, Andrej Mitrovic wrote:
On 3/23/12, H. S. Teoh wrote:
WAT?! What on earth is "cast()" supposed to mean??
I've no idea. It's probably a front-end bug and the cast forces the
compiler to.. come to its senses?
That part is not a bug, it is specified.
http://dlang.org/ex
Am Sun, 18 Mar 2012 04:49:12 +0100
schrieb "F i L" :
> On Sunday, 18 March 2012 at 03:27:40 UTC, bearophile wrote:
> > F i L:
> >
> >> I'm a bit confused. Reading through the virtual function's
> >> docs (http://dlang.org/function.html#virtual-functions) it
> >> says:
> >>
> >> "All non-static
On Thursday, 22 March 2012 at 23:48:03 UTC, deadalnix wrote:
Inference isn't possible with an attribute system.
It isn't possible simply because it wasn't implemented yet.
nothing prevents us to add such a feature in the future. Could be
a worthwhile enhancement for D3 or D4, given we actual
"H. S. Teoh" wrote in message
news:mailman.1036.1332480215.4860.digitalmar...@puremagic.com...
> On Fri, Mar 23, 2012 at 06:11:05AM +0100, Andrej Mitrovic wrote:
> [...]
>> Btw, want to see a magic trick? Put this into your hash:
>>
>> this(AA)(AA aa)
>> if (std.traits.isAssociativeArray!AA
>
68 matches
Mail list logo
