On Tuesday, 29 May 2012 at 18:46:21 UTC, Ali Çehreli wrote:
Unfortunately, that does not compile with dmd 2.059 and I think
that I understand why. Would that be possible for you to make
it clear under what conditions the return value can be
converted to immutable.
Okay, thanks for the
On 29/05/12 19:35, David Nadlinger wrote:
On Tuesday, 29 May 2012 at 12:08:08 UTC, Don Clugston wrote:
And to set the record straight -- the relaxed purity ideas were not my
idea.
I forget who first said them, but it wasn't me. I just championed them.
Unfortunately, I don't quite remember
On 18/05/2012 17:54, Russel Winder wrote:
On Fri, 2012-05-18 at 09:23 -0700, Adam Wilson wrote:
On Fri, 18 May 2012 08:49:40 -0700, Bruno Medeiros
brunodomedeiros+...@gmail.com wrote:
DDT 0.6.0 is out. It's been almost a year since last release,
unfortunately I haven't been able to work on
On 27 May 2012 21:56, David Nadlinger s...@klickverbot.at wrote:
Some of you might remember that I have been meaning to write a comprehensive
introduction to design and use of purity for quite some while now – I
finally got around to do so:
http://klickverbot.at/blog/2012/05/purity-in-d/
On Wed, 30 May 2012 08:18:11 -0700, Bruno Medeiros
brunodomedeiros+...@gmail.com wrote:
On 18/05/2012 17:54, Russel Winder wrote:
On Fri, 2012-05-18 at 09:23 -0700, Adam Wilson wrote:
On Fri, 18 May 2012 08:49:40 -0700, Bruno Medeiros
brunodomedeiros+...@gmail.com wrote:
DDT 0.6.0 is
On 30.05.2012 3:02, Andrei Alexandrescu wrote:
On 5/29/12 3:06 PM, Dmitry Olshansky wrote:
Again strictly speaking I'm of an opinion that having mutex together
with object guarded by it is at least better then 2 separate entities
bound together by virtue of code comments :)
Absolutely. I hope
On May 29, 2012, at 4:07 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/29/12 3:58 PM, Alex Rønne Petersen wrote:
On 30-05-2012 00:45, Andrei Alexandrescu wrote:
On 5/29/12 2:57 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:33, Andrei Alexandrescu wrote:
On 5/29/12 1:37
On 30.05.2012 3:04, Andrei Alexandrescu wrote:
On 5/29/12 3:56 PM, Alex Rønne Petersen wrote:
A mutex can be stored privately.
It can, but that doesn't mean it will.
Any object can be locked on, meaning no
lock is effectively protected or private or... anything.
To paraphrase you, An
On Friday, May 25, 2012 15:04:16 Alex Rønne Petersen wrote:
So I was writing a container class and in some test code, I called
container.clear(). Reasonable enough, right? Hell, it even compiled!
Turns out, my program completely broke at runtime. Apparently, I'd
forgotten to implement
On 29/05/12 16:20, Michel Fortin wrote:
On 2012-05-29 13:29:35 +, Don Clugston d...@nospam.com said:
On 27/05/12 02:45, Walter Bright wrote:
You could implement it as simply comparing the addresses - you'd be no
worse off than C is, and you would get the correct answer for pointers
both
On Wednesday, 30 May 2012 at 06:31:32 UTC, Dmitry Olshansky wrote:
I'll intervene. Following famous nerd motto talk is cheap,
show me the code I strongly suggest discussing concrete
scenarios. All prone to deadlock sentiment is trivia as in
buyer beware.
That being said:
class iMutexed
Le 24/05/2012 12:27, Denis Shelomovskij a écrit :
Let's talk about an abstract situation without caring about breaking
existing code, current docs, implementation etc.
Definitions:
* an Exception is something that tigers scope guards and executes
catch/finally blocks if thrown;
* an Error is
Le 24/05/2012 20:39, Steven Schveighoffer a écrit :
I'd argue this is unrecoverable. Access Violation results from
corruption, and the damage has already been done. Even a null pointer
access can be the cause of previous corruption. There is no recovery
from memory corruption. There is no way to
Le 24/05/2012 21:33, Sean Kelly a écrit :
On May 24, 2012, at 11:39 AM, Steven Schveighoffer wrote:
On Thu, 24 May 2012 06:27:12 -0400, Denis
Shelomovskijverylonglogin@gmail.com wrote:
Let's talk about an abstract situation without caring about breaking existing
code, current docs,
Le 29/05/2012 18:53, Sean Kelly a écrit :
On May 24, 2012, at 11:50 PM, Jacob Carlborg wrote:
On 2012-05-24 21:33, Sean Kelly wrote:
This is a good point. OutOfMemory conditions aside, the only time I'd want to
recover from an Error condition was at the point the event occurred, not
On 30.05.2012 12:17, Thiez wrote:
On Wednesday, 30 May 2012 at 06:31:32 UTC, Dmitry Olshansky wrote:
I'll intervene. Following famous nerd motto talk is cheap, show me
the code I strongly suggest discussing concrete scenarios. All prone
to deadlock sentiment is trivia as in buyer beware.
That
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're generally supposed to be), then
what does it matter? Something fatal occured in your program, so it
terminates. Because it's
Le 29/05/2012 23:53, Walter Bright a écrit :
On 5/29/2012 8:06 AM, Manu wrote:
On 29 May 2012 15:52, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
On 29/05/12 12:25, Manu wrote:
Is there any way to improve it?
Oh yeah. Orders of magnitude, easily. The slowness is not in any way
On 30.05.2012 12:33, Dmitry Olshansky wrote:
On 30.05.2012 12:17, Thiez wrote:
On Wednesday, 30 May 2012 at 06:31:32 UTC, Dmitry Olshansky wrote:
I'll intervene. Following famous nerd motto talk is cheap, show me
the code I strongly suggest discussing concrete scenarios. All prone
to deadlock
On 30.05.2012 12:33, deadalnix wrote:
Le 24/05/2012 21:33, Sean Kelly a écrit :
On May 24, 2012, at 11:39 AM, Steven Schveighoffer wrote:
On Thu, 24 May 2012 06:27:12 -0400, Denis
Shelomovskijverylonglogin@gmail.com wrote:
Let's talk about an abstract situation without caring about
On 29/05/12 23:23, Philippe Sigaud wrote:
On Tue, May 29, 2012 at 2:52 PM, Don Clugstond...@nospam.com wrote:
Is there any way to improve it?
Oh yeah. Orders of magnitude, easily.
!
The slowness is not in any way
inherent to CTFE. The experience will be completely different, once I
struct ValueImpl
{
static immutable(int) getValue()
{
return 42;
}
}
struct ValueUser
{
ValueImpl m_valueImpl;
alias m_valueImpl this;
}
void main(string[] args)
{
static assert(ValueImpl.getValue() == 42);
static assert(ValueUser.getValue() == 42); // (1)
}
Le 29/05/2012 23:54, Andrei Alexandrescu a écrit :
On 5/29/12 2:49 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:32, Andrei Alexandrescu wrote:
On 5/29/12 1:35 AM, deadalnix wrote:
Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
I should probably add that Java learned it long ago, and
On 2012-05-29 23:48, Andrei Alexandrescu wrote:
Don't be hatin'. You'd appreciate the matter considerably more after you
defined your own language and had its users yell at you for changing
even a small detail.
The situation is at it is, and there's no need to get agitated. We're
all on the
Le 30/05/2012 01:25, Alex Rønne Petersen a écrit :
On 30-05-2012 01:22, Andrei Alexandrescu wrote:
On 5/29/12 4:17 PM, Alex Rønne Petersen wrote:
On 30-05-2012 01:10, Andrei Alexandrescu wrote:
On 5/29/12 4:06 PM, Alex Rønne Petersen wrote:
Synchronized blocks are good because they
operate
Le 30/05/2012 00:53, Andrei Alexandrescu a écrit :
On 5/29/12 3:01 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:54, Andrei Alexandrescu wrote:
On 5/29/12 2:49 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:32, Andrei Alexandrescu wrote:
On 5/29/12 1:35 AM, deadalnix wrote:
Le 29/05/2012
On 2012-05-30 00:06, Dmitry Olshansky wrote:
*I like the one in Smalltalk or Obj-C. Also I think exposing type-tag as
ordinal (index inside one global master v-table) instead of pointless
_hidden_ v-table pointer could be interesting in certain designs.
Another idea is to try tackling
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're generally supposed to be), then
what does it matter? Something fatal occured in
Le 29/05/2012 23:33, Andrei Alexandrescu a écrit :
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
process, is the way to go.
So what should we use for mutex-based synchronization if we deprecate
synchronized classes?
Andrei
I think
Le 30/05/2012 08:23, Sean Kelly a écrit :
On May 29, 2012, at 4:07 PM, Andrei Alexandrescuseewebsiteforem...@erdani.org
wrote:
On 5/29/12 3:58 PM, Alex Rønne Petersen wrote:
On 30-05-2012 00:45, Andrei Alexandrescu wrote:
On 5/29/12 2:57 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:33,
Le 30/05/2012 00:50, Andrei Alexandrescu a écrit :
On 5/29/12 2:59 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:31, Andrei Alexandrescu wrote:
On 5/29/12 1:32 AM, deadalnix wrote:
I already did some comment about this.
Making any object synchronization is a very bad design decision. It is
On 30.05.2012 13:28, Jacob Carlborg wrote:
On 2012-05-30 00:06, Dmitry Olshansky wrote:
*I like the one in Smalltalk or Obj-C. Also I think exposing type-tag as
ordinal (index inside one global master v-table) instead of pointless
_hidden_ v-table pointer could be interesting in certain
On 30/05/12 01:47, Mehrdad wrote:
Just a general note: going the make a special case for two comparisons
route won't work if, for example, someone decides to use a lambda for
comparing pointers.
You mean effectively like:
bool cmp(void *x, void *y)
{
return x y:
}
assert ( cmp(x, y)
On 30.05.2012 2:27, Dmitry Olshansky wrote:
I just wish it was different. To set things straight I still believe
that OOP part of language is not what I want it to be, and thus I just
don't use it. Like in the old saying: there is always a choice.
Minor correction, when I first come to try D
On Wednesday, May 30, 2012 11:32:00 Don Clugston wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're generally supposed
On Saturday, 26 May 2012 at 08:52:07 UTC, bioinfornatics wrote:
Le mercredi 23 mai 2012 à 16:14 -0700, Walter Bright a écrit :
Currently, getting D code from github is a multistep process,
that isn't always obvious. I propose the creation of a dget
program, which will:
dget
Le 30/05/2012 10:58, Tommi a écrit :
struct ValueImpl
{
static immutable(int) getValue()
{
return 42;
}
}
struct ValueUser
{
ValueImpl m_valueImpl;
alias m_valueImpl this;
}
void main(string[] args)
{
static assert(ValueImpl.getValue() == 42);
static assert(ValueUser.getValue() == 42); // (1)
On 30-05-2012 07:47, Katayama Hirofumi MZ wrote:
Look this source:
http://codepad.org/QXAeG2aJ
The content of RbArray won't be released at the moment of deleting an
RbArray.
Why? Is it a bug?
Just use GC.collect() from core.memory when cleaning up internals of
extremely large objects is too
On 30-05-2012 08:43, Jonathan M Davis wrote:
On Friday, May 25, 2012 15:04:16 Alex Rønne Petersen wrote:
So I was writing a container class and in some test code, I called
container.clear(). Reasonable enough, right? Hell, it even compiled!
Turns out, my program completely broke at runtime.
On 30-05-2012 11:15, deadalnix wrote:
Le 30/05/2012 01:25, Alex Rønne Petersen a écrit :
On 30-05-2012 01:22, Andrei Alexandrescu wrote:
On 5/29/12 4:17 PM, Alex Rønne Petersen wrote:
On 30-05-2012 01:10, Andrei Alexandrescu wrote:
On 5/29/12 4:06 PM, Alex Rønne Petersen wrote:
Synchronized
On 30-05-2012 08:23, Sean Kelly wrote:
On May 29, 2012, at 4:07 PM, Andrei Alexandrescuseewebsiteforem...@erdani.org
wrote:
On 5/29/12 3:58 PM, Alex Rønne Petersen wrote:
On 30-05-2012 00:45, Andrei Alexandrescu wrote:
On 5/29/12 2:57 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:33,
On Sat, 26 May 2012 02:31:46 -0400, Ary Manzana a...@esperanto.org.ar
wrote:
On 5/25/12 22:42 , Steven Schveighoffer wrote:
Finalize isn't right, and neither is dispose...
In Java it's finalize:
http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#finalize()
No, this is
Like I said it doesn't compile because it can't do CTFE. But
remove static in front of the second assert and it compiles (and
works also during runtime):
assert(ValueUser.getValue() == 42);
On Wed, 30 May 2012 10:21:00 +0100, deadalnix deadal...@gmail.com wrote:
Le 30/05/2012 00:53, Andrei Alexandrescu a écrit :
On 5/29/12 3:01 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:54, Andrei Alexandrescu wrote:
On 5/29/12 2:49 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:32,
Le 30/05/2012 14:32, Regan Heath a écrit :
On Wed, 30 May 2012 10:21:00 +0100, deadalnix deadal...@gmail.com wrote:
Le 30/05/2012 00:53, Andrei Alexandrescu a écrit :
On 5/29/12 3:01 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:54, Andrei Alexandrescu wrote:
On 5/29/12 2:49 PM, Alex
On Wed, 30 May 2012 00:10:19 +0100, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Wednesday, May 30, 2012 01:02:53 Alex Rønne Petersen wrote:
But mutexes allow proper encapsulation by hiding the mutex resource. As
I've proven in the very OP of this thread, both druntime and phobos
suffer
...and that's what I would expect, if the purpose of alias this
is to bring all the functionality from one type to another. Just
like inheritance, but not quite.
On Wed, 30 May 2012 14:38:50 +0200, d coder dlang.co...@gmail.com wrote:
Greetings
What would be the form of is expression to match with a Variadic
Template
Class?
I am pasting a simple example below to clarify my need. I need an is
expression to match with the Bar(T...) type in the code
On Wednesday, 30 May 2012 at 12:43:15 UTC, deadalnix wrote:
It doesn't address most of the drawback cited. Notably the fact
that every object have a monitor field, but most of them will
not use it.
That could be solved without abandoning object locks. If locking
on all objects is allowed,
On 30.05.2012 16:43, Regan Heath wrote:
On Wed, 30 May 2012 00:10:19 +0100, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Wednesday, May 30, 2012 01:02:53 Alex Rønne Petersen wrote:
But mutexes allow proper encapsulation by hiding the mutex resource. As
I've proven in the very OP of this
Le 30/05/2012 14:43, Tommi a écrit :
...and that's what I would expect, if the purpose of alias this is to
bring all the functionality from one type to another. Just like
inheritance, but not quite.
Except your are not aliasing the type but an instance.
On Wed, 30 May 2012 13:43:14 +0100, deadalnix deadal...@gmail.com wrote:
Le 30/05/2012 14:32, Regan Heath a écrit :
1. Prevent locking on any/every object. People would have to create a
separate mutex object for locking. This is a little tedious, but it does
make people think about the scope of
On 30-05-2012 14:54, Thiez wrote:
On Wednesday, 30 May 2012 at 12:43:15 UTC, deadalnix wrote:
It doesn't address most of the drawback cited. Notably the fact that
every object have a monitor field, but most of them will not use it.
That could be solved without abandoning object locks. If
On Wed, 30 May 2012 13:55:10 +0100, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
On 30.05.2012 16:43, Regan Heath wrote:
On Wed, 30 May 2012 00:10:19 +0100, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Wednesday, May 30, 2012 01:02:53 Alex Rønne Petersen wrote:
But mutexes allow proper
On 30.05.2012 17:14, Regan Heath wrote:
synchronized class Container
{
void applyLocked(scope delegate void(Container _this));
...
}
Neat :)
Rewritten and almost complete:
synchronized class Locked!(C)
{
void applyLocked(scope delegate void(C _this) dg)
{//should have
On 2012-05-30 12:59, Jonathan M Davis wrote:
Yes, which is why it's better to have an Error thrown rather than a halt
instruction be executed. But that doesn't mean that any attempt at cleanup is
any more valid.
If you're not supposed to be able to catch Errors then what's the
difference?
On 30.05.2012 17:28, Jacob Carlborg wrote:
On 2012-05-30 12:59, Jonathan M Davis wrote:
Yes, which is why it's better to have an Error thrown rather than a halt
instruction be executed. But that doesn't mean that any attempt at
cleanup is
any more valid.
If you're not supposed to be able to
Le 30/05/2012 14:55, Dmitry Olshansky a écrit :
On 30.05.2012 16:43, Regan Heath wrote:
On Wed, 30 May 2012 00:10:19 +0100, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Wednesday, May 30, 2012 01:02:53 Alex Rønne Petersen wrote:
But mutexes allow proper encapsulation by hiding the mutex
Le 30/05/2012 14:43, Regan Heath a écrit :
On Wed, 30 May 2012 00:10:19 +0100, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Wednesday, May 30, 2012 01:02:53 Alex Rønne Petersen wrote:
But mutexes allow proper encapsulation by hiding the mutex resource. As
I've proven in the very OP of this
Le 30/05/2012 15:10, Regan Heath a écrit :
IMO, the wasted space used by the monitor isn't ideal, but it's not a
problem for the general case. It is a problem for people with limited
memory environments but that's another topic. Talking about both is only
clouding the discussional waters so to
On 2012-05-30 12:21, Dmitry Olshansky wrote:
Yup. Even Java has Class as object. If D copied most of OOP from Java it
seems strange that it was replaced by halfhearted factory method in
object.di
kind of saying you have RTTI but it's crippled just in case if it is of
no use.
I would not
On 30.05.2012 17:58, Jacob Carlborg wrote:
On 2012-05-30 12:21, Dmitry Olshansky wrote:
Yup. Even Java has Class as object. If D copied most of OOP from Java it
seems strange that it was replaced by halfhearted factory method in
object.di
kind of saying you have RTTI but it's crippled just in
Le 30/05/2012 11:32, Don Clugston a écrit :
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're generally supposed to
be), then
Le 30/05/2012 12:59, Jonathan M Davis a écrit :
And it's very valuable to log it properly.
Yes, which is why it's better to have an Error thrown rather than a halt
instruction be executed. But that doesn't mean that any attempt at cleanup is
any more valid.
Sorry but that is bullshit. What
On May 30, 2012, at 7:21 AM, deadalnix deadal...@gmail.com wrote:
Le 30/05/2012 12:59, Jonathan M Davis a écrit :
And it's very valuable to log it properly.
Yes, which is why it's better to have an Error thrown rather than a halt
instruction be executed. But that doesn't mean that any
On Tue, 29 May 2012 13:35:12 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2012-05-29 15:09:00 +, Artur Skawina art.08...@gmail.com said:
int a[1024];
int[] da = a[0..1024];
if (whatever)
da = da[3..14];
if (something_else)
da = [42] ~ da;
// etc
On 19/05/2012 02:33, Jesse Phillips wrote:
On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:
So just starting up the IDE is more important than actually writing
code or fixing bugs?...
I'd like to see you do those things without starting your IDE.
Oh yeah, I'd like to see you do
2012/5/30 Tommi tommitiss...@hotmail.com:
struct ValueImpl
{
static immutable(int) getValue()
{
return 42;
}
}
struct ValueUser
{
ValueImpl m_valueImpl;
alias m_valueImpl this;
}
void main(string[] args)
{
static assert(ValueImpl.getValue() == 42);
On Wed, 30 May 2012 05:32:00 -0400, Don Clugston d...@nospam.com wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're
On 18/05/2012 09:38, Ary Manzana wrote:
Are you happy with Windows? :-P
No, not at all!
... but I am definitely less unhappy with it than with Linux or MacOS!...
--
Bruno Medeiros - Software Engineer
On May 30, 2012, at 8:05 AM, Steven Schveighoffer schvei...@yahoo.com wrote:
On Wed, 30 May 2012 05:32:00 -0400, Don Clugston d...@nospam.com wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and
On 05/30/12 10:17, Thiez wrote:
On Wednesday, 30 May 2012 at 06:31:32 UTC, Dmitry Olshansky wrote:
I'll intervene. Following famous nerd motto talk is cheap, show me the
code I strongly suggest discussing concrete scenarios. All prone to
deadlock sentiment is trivia as in buyer beware.
On 20/05/2012 15:19, Timon Gehr wrote:
No, you misunderstand.
- Time spent starting up the IDE is lost time that could be spent doing
something productive instead. Hardware is fast. There is simply no
excuse for poor start up times/poor responsiveness.
I am not misunderstanding. No one is
On 30/05/12 12:59, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 11:32:00 Don Clugston wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly
On 2012-05-30 14:44:37 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Tue, 29 May 2012 13:35:12 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Personally, I think it'd be much cleaner to go with some kind of magic
function than trying to match the condition against a
Steven Schveighoffer wrote:
On Wed, 30 May 2012 05:32:00 -0400, Don Clugston d...@nospam.com wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly
On 5/30/12 2:14 AM, Jacob Carlborg wrote:
On 2012-05-29 23:48, Andrei Alexandrescu wrote:
Don't be hatin'. You'd appreciate the matter considerably more after you
defined your own language and had its users yell at you for changing
even a small detail.
The situation is at it is, and there's
On 5/30/12 2:34 AM, deadalnix wrote:
Le 29/05/2012 23:33, Andrei Alexandrescu a écrit :
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
process, is the way to go.
So what should we use for mutex-based synchronization if we deprecate
On 30-05-2012 17:30, Bruno Medeiros wrote:
On 20/05/2012 15:19, Timon Gehr wrote:
No, you misunderstand.
- Time spent starting up the IDE is lost time that could be spent doing
something productive instead. Hardware is fast. There is simply no
excuse for poor start up times/poor
On Mon, 28 May 2012 18:36:13 -0400, Alex Rønne Petersen a...@lycus.org
wrote:
Hi,
I've seen several occurrences of synchronized (this) and synchronized
(this.classinfo) in both druntime and phobos by now. I propose that we
officially ban these patterns with extreme prejudice.
1)
On 5/30/12 2:40 AM, deadalnix wrote:
Le 30/05/2012 00:50, Andrei Alexandrescu a écrit :
On 5/29/12 2:59 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:31, Andrei Alexandrescu wrote:
On 5/29/12 1:32 AM, deadalnix wrote:
I already did some comment about this.
Making any object
On 30.05.2012 19:05, Steven Schveighoffer wrote:
On Wed, 30 May 2012 05:32:00 -0400, Don Clugston d...@nospam.com wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If
On Fri, 11 May 2012 16:51:59 -0500, SomeDude lovelyd...@mailmetrash.com
wrote:
On Tuesday, 8 May 2012 at 08:23:38 UTC, Denis Shelomovskij wrote:
08.05.2012 3:50, Walter Bright написал:
http://www.reddit.com/r/cpp/comments/tbouj/zerobugs_modular_debugger_for_ccd_including_gui/
Poor
On Wed, 30 May 2012 11:47:34 -0400, Jens Mueller jens.k.muel...@gmx.de
wrote:
Steven Schveighoffer wrote:
case 2:
int main(string[] args)
{
writeln(invert(to!double(args[1])); // clearly a catchable error
}
This should be
int main(string[] args)
{
auto arg = to!double(args[1]);
On 5/30/12 5:43 AM, deadalnix wrote:
It doesn't address most of the drawback cited. Notably the fact that
every object have a monitor field, but most of them will not use it.
Once the TDPL design is implemented, we could look into eliminating that
field for all but synchronized class. In the
On 5/30/12 5:32 AM, Regan Heath wrote:
On Wed, 30 May 2012 10:21:00 +0100, deadalnix deadal...@gmail.com wrote:
You don't want to synchronize on ANY object. You want to synchronize
on explicit mutexes.
+1 .. this is the key point/issue.
TDPL's design only allows for entire synchronized
On Wed, 30 May 2012 11:33:54 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2012-05-30 14:44:37 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Tue, 29 May 2012 13:35:12 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Personally, I think it'd be much cleaner
On 5/30/12 5:43 AM, Regan Heath wrote:
Not in all cases. If you have a synchronized class, say a thread-safe
container, which has a synchronized lookup and synchronized insert
function, code like..
if (!o.lookup(...))
o.insert(...)
obtains and releases the mutex twice each, and in between
On Wed, 30 May 2012 16:46:54 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/30/12 2:34 AM, deadalnix wrote:
Le 29/05/2012 23:33, Andrei Alexandrescu a écrit :
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
On 30-05-2012 15:10, Regan Heath wrote:
On Wed, 30 May 2012 13:43:14 +0100, deadalnix deadal...@gmail.com wrote:
Le 30/05/2012 14:32, Regan Heath a écrit :
1. Prevent locking on any/every object. People would have to create a
separate mutex object for locking. This is a little tedious, but it
On 5/30/12 6:39 AM, deadalnix wrote:
Le 30/05/2012 14:43, Regan Heath a écrit :
Not in all cases. If you have a synchronized class, say a thread-safe
container, which has a synchronized lookup and synchronized insert
function, code like..
if (!o.lookup(...))
o.insert(...)
The correct
On 5/30/12 6:10 AM, Regan Heath wrote:
Ultimately the problem that needs solving is the fact that
synchronized classes/methods use a public mutex and this exposure makes
deadlocks more likely. I was hoping that by giving some examples in
code, it would become clearer to the people who don't see
On Wednesday, 30 May 2012 at 15:04:40 UTC, kenji hara wrote:
Looks like a bug.
ValueUser.getValue() is translated to
ValueUser.m_valueImpl.getValue()
with alias this resolution. In here:
1. ValueUser.m_valueImpl is a valid expression. It means just a
symbol
of variable which declared in
On 5/30/12 9:03 AM, Regan Heath wrote:
On Wed, 30 May 2012 16:46:54 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/30/12 2:34 AM, deadalnix wrote:
Le 29/05/2012 23:33, Andrei Alexandrescu a écrit :
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things
On 30-05-2012 18:03, Regan Heath wrote:
On Wed, 30 May 2012 16:46:54 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/30/12 2:34 AM, deadalnix wrote:
Le 29/05/2012 23:33, Andrei Alexandrescu a écrit :
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things
On 30-05-2012 18:14, Andrei Alexandrescu wrote:
On 5/30/12 9:03 AM, Regan Heath wrote:
On Wed, 30 May 2012 16:46:54 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/30/12 2:34 AM, deadalnix wrote:
Le 29/05/2012 23:33, Andrei Alexandrescu a écrit :
On 5/29/12 1:37 AM,
Steven Schveighoffer wrote:
On Wed, 30 May 2012 11:47:34 -0400, Jens Mueller
jens.k.muel...@gmx.de wrote:
Steven Schveighoffer wrote:
case 2:
int main(string[] args)
{
writeln(invert(to!double(args[1])); // clearly a catchable error
}
This should be
int main(string[] args)
{
On 30 May 2012 17:23, Alex Rønne Petersen a...@lycus.org wrote:
On 30-05-2012 18:14, Andrei Alexandrescu wrote:
On 5/30/12 9:03 AM, Regan Heath wrote:
On Wed, 30 May 2012 16:46:54 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/30/12 2:34 AM, deadalnix wrote:
Le
2012/5/31 Tommi tommitiss...@hotmail.com:
On Wednesday, 30 May 2012 at 15:04:40 UTC, kenji hara wrote:
Looks like a bug.
ValueUser.getValue() is translated to ValueUser.m_valueImpl.getValue()
with alias this resolution. In here:
1. ValueUser.m_valueImpl is a valid expression. It means just
On Wed, 30 May 2012 17:00:43 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/30/12 5:32 AM, Regan Heath wrote:
On Wed, 30 May 2012 10:21:00 +0100, deadalnix deadal...@gmail.com
wrote:
You don't want to synchronize on ANY object. You want to synchronize
on explicit
1 - 100 of 267 matches
Mail list logo
