Fighting with alias this: bugs or features?

2010-10-26 Thread osa
Every time I'm trying to use alias this (which looks like a nice feature, on paper), I end up with problems. This is the most recent one (dmd v2.049): -- struct Foo {} class Bar { Foo foo_; alias foo_ this; } void main() { auto a = new Bar; auto b = a; a = null; //

Re: Fighting with alias this: bugs or features?

2010-10-26 Thread osa
On 10/26/2010 03:22 PM, Jérôme M. Berger wrote: I'm not sure that the problem is on the line where the error is reported. My guess would be that the issue is with the auto a = new Bar line: I would bet that this gets interpreted as Foo a = new Bar instead of what we expect (Bar a = new

Re: Fighting with alias this: bugs or features?

2010-10-26 Thread osa
On 10/26/2010 04:46 PM, Andrei Alexandrescu wrote: In this particular case the decision goes both ways, and both have something going for them. You may want to submit a bug report at least to prompt us to change the documentation to clarify the behavior. A workaround is to define opAssign(Bar).

Re: Fighting with alias this: bugs or features?

2010-10-26 Thread osa
On 10/26/2010 05:09 PM, Andrei Alexandrescu wrote: Thanks. Defining opAssign for Bar will allow you to use the syntax bar = null and have it nullify the reference. I feel stupid, but I do not see how to nullify the Bar reference inside of opAssign. Again, my problem is that I have

Re: [std.concurrency] prioritySend is 1000 times slower than send?

2010-10-08 Thread osa
On 10/08/2010 04:29 PM, Sean Kelly wrote: I just made some functional changes to how priority messages are sent and added a few performance tweaks to messaging in general. The only visible difference should be that PriorityMessageException is no longer a template class but instead contains a

[std.concurrency] Critical bug

2010-09-30 Thread osa
I've struggled with occasional hangs in my code using std.concurrency for a while. Initially I thought it was my fault but it seems that std.concurrency has a critical bug which makes it completely unusable, at least for me. The problem is that in some situations message sent by send() is

Re: [std.concurrency] prioritySend is 1000 times slower than send?

2010-09-30 Thread osa
On 09/30/2010 01:45 PM, Sean Kelly wrote: Benchmark: 5944400 iterations in 5 seconds (1.1e+06/second) -- built without -version=priority Benchmark: 4900 iterations in 5.119 seconds (957.218/second) -- build with -version=priority before fix Benchmark: 39700 iterations in 5.001 seconds

Re: [std.concurrency] prioritySend is 1000 times slower than send?

2010-09-30 Thread osa
On 09/30/2010 03:33 PM, Sean Kelly wrote: osa Wrote: I've also thought about switching to 'send' if the receiver queue is empty, but there is no way in std.concurrency API to check for that. Is there any serious issue with adding such method? I understand that in multi-threaded environment

[std.concurrency] prioritySend is 1000 times slower than send?

2010-09-29 Thread osa
I started using std.concurrency in some projects and overall it feels like a solid (albeit minimalistic) design. However, current implementation has some issues. For example, I've noticed that using prioritySend slows everything considerably. Here is a simple benchmark to demonstrate the

Re: dmd 1.064 and 2.049 release

2010-09-17 Thread osa
After upgrading to 2.049, trying to compile this code: import std.traits; void foo() {} void main() { static assert( ! hasUnsharedAliasing!foo ); } gives this error: dmd2/linux/bin/../../src/phobos/std/traits.d(971): Error: template instance isAssociativeArray!(foo) does not match

Re: dmd 1.064 and 2.049 release

2010-09-17 Thread osa
On 09/17/2010 03:22 PM, dsimcha wrote: I agree the error message is obtuse, but I don't think this code is supposed to work because foo is not a type. This code does work: import std.traits; void foo() {} void main() { static assert( ! hasUnsharedAliasing!(typeof(foo)) ); } My bad.

Re: dmd 1.064 and 2.049 release

2010-09-17 Thread osa
On 09/17/2010 04:05 PM, dsimcha wrote: This is a real bug. Please file a bug report. I'll look into it soon. Done: http://d.puremagic.com/issues/show_bug.cgi?id=4882