23-May-2013 01:23, Idan Arye пишет:
On Tuesday, 21 May 2013 at 17:40:02 UTC, Idan Arye wrote:
On Tuesday, 21 May 2013 at 14:58:16 UTC, Idan Arye wrote:
At any rate, I am forced to admit I made a mistake about
`hasIntance()` not needing synchronization. I neglected the
possibility that the
On Friday, May 24, 2013 17:42:59 Dmitry Olshansky wrote:
There was a pull that allowed to separate qualifier of instance from
reference (handle) looking like this:
ref const(Object) refToConst;
ref Object mutableTlsRef;
Object mutableTlsRef; //same as above
ref const Object
24-May-2013 22:13, Jonathan M Davis пишет:
On Friday, May 24, 2013 17:42:59 Dmitry Olshansky wrote:
There was a pull that allowed to separate qualifier of instance from
reference (handle) looking like this:
ref const(Object) refToConst;
ref Object mutableTlsRef;
Object mutableTlsRef; //same
On Friday, 24 May 2013 at 13:43:02 UTC, Dmitry Olshansky wrote:
I've found github pages to be just fine.
Then GitHub pages it is -
http://someboddy.github.io/phobos/ddocs/for-idioms/idioms.html
I've also added this link to the pull request and to the review
queue.
Turns out that doing
And here is the Phobos solution:
http://d.puremagic.com/issues/show_bug.cgi?id=10165
https://github.com/D-Programming-Language/phobos/pull/1302
On Saturday, May 25, 2013 00:08:37 Dmitry Olshansky wrote:
24-May-2013 22:13, Jonathan M Davis пишет:
Lacking a proper language solution, we could create something similar to
Rebindable but for shared.
Then in my vision built-in OOP has failed if we need at least 2 wrapper
types
On Tuesday, 21 May 2013 at 14:58:16 UTC, Idan Arye wrote:
At any rate, I am forced to admit I made a mistake about
`hasIntance()` not needing synchronization. I neglected the
possibility that the constructor(or anything else used for
initialization) can throw!
The compiler might decide that
On Tuesday, 21 May 2013 at 17:40:02 UTC, Idan Arye wrote:
On Tuesday, 21 May 2013 at 14:58:16 UTC, Idan Arye wrote:
At any rate, I am forced to admit I made a mistake about
`hasIntance()` not needing synchronization. I neglected the
possibility that the constructor(or anything else used for
21-May-2013 02:02, Idan Arye пишет:
On Monday, 20 May 2013 at 19:15:34 UTC, Dmitry Olshansky wrote:
If you need synchronization and coordination based on what the
reference happens to be right now then there are tools far better fit
for the job - mutexes, semaphore, condition vars etc.
On Tuesday, 21 May 2013 at 06:44:02 UTC, Dmitry Olshansky wrote:
A-ha. That's it and it's totally wrong. Exposing as much
interface as possible is a disaster. Libraries (esp standard)
take great deal of deliberation in picking what to expose.
Exposing less is a common theme in interfaces.
At any rate, I am forced to admit I made a mistake about
`hasIntance()` not needing synchronization. I neglected the
possibility that the constructor(or anything else used for
initialization) can throw!
The compiler might decide that it's better to write the global
reference first, and if
On Monday, 20 May 2013 at 05:39:42 UTC, Diggory wrote:
In your logic you're assuming that the order of operations is
maintained - without the correct memory barriers or
synchronisation both the compiler and CPU are free to
completely reorder any operations you do. That's why it's
always a bug
On Monday, 20 May 2013 at 06:53:34 UTC, Idan Arye wrote:
On Monday, 20 May 2013 at 05:39:42 UTC, Diggory wrote:
In your logic you're assuming that the order of operations is
maintained - without the correct memory barriers or
synchronisation both the compiler and CPU are free to
completely
On Monday, 20 May 2013 at 11:19:44 UTC, Diggory wrote:
Of course it's possible, for example the code may produce the
expected result if some invariant holds which does in fact hold
if there was a single thread running, but with multiple threads
the invariant is broken. Or more simply - the
20-May-2013 19:28, Idan Arye пишет:
On Monday, 20 May 2013 at 11:19:44 UTC, Diggory wrote:
Of course it's possible, for example the code may produce the expected
result if some invariant holds which does in fact hold if there was a
single thread running, but with multiple threads the invariant
On Monday, 20 May 2013 at 16:40:27 UTC, Dmitry Olshansky wrote:
Long story short - re-read the discussion in the Low-lock
thread again:
http://forum.dlang.org/thread/pelhvaxwjzhehdjtp...@forum.dlang.org
To sum up the discussion, there are three problems with
unsynchronized access to the
20-May-2013 22:14, Idan Arye пишет:
On Monday, 20 May 2013 at 16:40:27 UTC, Dmitry Olshansky wrote:
Long story short - re-read the discussion in the Low-lock thread again:
http://forum.dlang.org/thread/pelhvaxwjzhehdjtp...@forum.dlang.org
To sum up the discussion, there are three problems
On Saturday, 18 May 2013 at 16:58:19 UTC, Idan Arye wrote:
OK, I implemented everything and made a pull request:
https://github.com/D-Programming-Language/phobos/pull/1294
I've added this to the review queue.
The module is in need of documentation (publishing not required)
before it can be
On Monday, 20 May 2013 at 21:01:36 UTC, Jesse Phillips wrote:
On Saturday, 18 May 2013 at 16:58:19 UTC, Idan Arye wrote:
OK, I implemented everything and made a pull request:
https://github.com/D-Programming-Language/phobos/pull/1294
I've added this to the review queue.
The module is in need
On Monday, 20 May 2013 at 19:15:34 UTC, Dmitry Olshansky wrote:
20-May-2013 22:14, Idan Arye пишет:
1) It doesn't matter if the object is not ready, because when
you want
to actually access the object, you need to use `instance()`
which has
synchronization.
Then where you see hasInstance to
On Monday, 20 May 2013 at 21:08:36 UTC, Jesse Phillips wrote:
On Monday, 20 May 2013 at 21:01:36 UTC, Jesse Phillips wrote:
On Saturday, 18 May 2013 at 16:58:19 UTC, Idan Arye wrote:
OK, I implemented everything and made a pull request:
On Monday, 20 May 2013 at 22:02:57 UTC, Idan Arye wrote:
On Monday, 20 May 2013 at 19:15:34 UTC, Dmitry Olshansky wrote:
20-May-2013 22:14, Idan Arye пишет:
1) It doesn't matter if the object is not ready, because when
you want
to actually access the object, you need to use `instance()`
which
On Monday, 20 May 2013 at 23:18:59 UTC, Diggory wrote:
On Monday, 20 May 2013 at 22:02:57 UTC, Idan Arye wrote:
If `hasInstance()` returns `true`, you can assume that there
is an instance for you to access, because even if the instance
is not ready yet, some other thread has entered the
On Saturday, 18 May 2013 at 16:58:19 UTC, Idan Arye wrote:
OK, I implemented everything and made a pull request:
https://github.com/D-Programming-Language/phobos/pull/1294
Nice, but the singleton implementation seems somewhat
over-complicated, and the low-lock singleton is broken, possibly
On Sunday, 19 May 2013 at 08:36:24 UTC, Diggory wrote:
On Saturday, 18 May 2013 at 16:58:19 UTC, Idan Arye wrote:
OK, I implemented everything and made a pull request:
https://github.com/D-Programming-Language/phobos/pull/1294
Nice, but the singleton implementation seems somewhat
There is no point in saving a thread local reference to the
global instance. The `__gshared` instance is never changed once
initialized, so if we saved a thread local reference, it would
*always* be either null or the same as the `__gshared` one -
which means that if the local reference is
On Sunday, 19 May 2013 at 20:35:06 UTC, Diggory wrote:
There is no point in saving a thread local reference to the
global instance. The `__gshared` instance is never changed
once initialized, so if we saved a thread local reference, it
would *always* be either null or the same as the
On Sunday, 19 May 2013 at 20:35:06 UTC, Diggory wrote:
It's also less efficient as you have to read both the
thread-local boolean and the __gshared instance. Since the
thread-local boolean is likely going to use a word anyway you
may as well store the instance in there instead.
This is a
In your logic you're assuming that the order of operations is
maintained - without the correct memory barriers or
synchronisation both the compiler and CPU are free to completely
reorder any operations you do. That's why it's always a bug to
access mutable shared data without synchronisation -
OK, I implemented everything and made a pull request:
https://github.com/D-Programming-Language/phobos/pull/1294
On Friday, 10 May 2013 at 21:04:32 UTC, Idan Arye wrote:
On Wednesday, 8 May 2013 at 20:11:34 UTC, Idan Arye wrote:
OK, so I'm gonna go ahead and implement it, so I can show by
example that the string solution can be typesafe, scalable and
elegant.
OK, this is a basic implementation:
In article pgasgjrfryfbwkebb...@forum.dlang.org, generic...@gmail.com says...
On Wednesday, 8 May 2013 at 20:11:34 UTC, Idan Arye wrote:
Aryan?? White premisey your message?
Wait, Ary lye-in-dyke won the indie 4500, is he gay? OMG, DYKES are the issue!
How many dykes have driven race cars?
On Wednesday, 8 May 2013 at 20:11:34 UTC, Idan Arye wrote:
OK, so I'm gonna go ahead and implement it, so I can show by
example that the string solution can be typesafe, scalable and
elegant.
OK, this is a basic implementation:
https://gist.github.com/someboddy/5557358
Before I can make the
On Friday, 10 May 2013 at 21:04:32 UTC, Idan Arye wrote:
On Wednesday, 8 May 2013 at 20:11:34 UTC, Idan Arye wrote:
OK, so I'm gonna go ahead and implement it, so I can show by
example that the string solution can be typesafe, scalable and
elegant.
OK, this is a basic implementation:
OK, so I'm gonna go ahead and implement it, so I can show by
example that the string solution can be typesafe, scalable and
elegant.
On 2013-05-07 01:20, Idan Arye wrote:
However, your idea of having a single mixin handle all the
class\struct's properties gave me another idea - to use a single mixin,
but instead of having it analyze the owner class to find the fields we
want to make properties, we simply give them to it with
I really think that UDA annotations + single mixin like this:
class Test
{
private:
// annotated stuff
public:
mixin implementAnnotations!Test;
}
is a most type-safe approach which scales.
On Tuesday, 7 May 2013 at 08:58:47 UTC, Dicebot wrote:
I really think that UDA annotations + single mixin like this:
class Test
{
private:
// annotated stuff
public:
mixin implementAnnotations!Test;
}
is a most type-safe approach which scales.
I think any method will
On Tuesday, 7 May 2013 at 19:10:23 UTC, Idan Arye wrote:
So, we have to change it:
class Test
{
private:
@Property int m_foo;
public:
mixin implementAnnotations!Test;
}
and inside `implementAnnotations` we would have to strip
`m_foo` out of
On Tuesday, 7 May 2013 at 19:10:23 UTC, Idan Arye wrote:
Anyways, a small enhancement to dmd can help solve both
problems easily - a mixin template that has an identifier and
does not leak to the surrounding scope.
Actually, forget about that enhancement - I can use aliases, CTFE
and a mixin
Template mixins can be used to implement some common programming
idioms(and design patterns). I have already implemented two of
them for my own project - and I want to make them into a Phobos
module - maybe `std.mixins`. The wiki at
http://wiki.dlang.org/Review/Process says that before I start
It's a nice idea but personally I don't like the syntax much, for
example it's completely non-obvious what true does when passed
to the singleton mixin, or that the parameters to the property
mixin are type, name, condition, initial value.
I suppose you could do something like this:
mixin
On 5/6/13 3:14 PM, Idan Arye wrote:
Template mixins can be used to implement some common programming
idioms(and design patterns). I have already implemented two of them for
my own project - and I want to make them into a Phobos module - maybe
`std.mixins`.
Nice idea, but at the first level of
On Monday, 6 May 2013 at 19:57:27 UTC, Andrei Alexandrescu wrote:
On 5/6/13 3:14 PM, Idan Arye wrote:
Template mixins can be used to implement some common
programming
idioms(and design patterns). I have already implemented two of
them for
my own project - and I want to make them into a Phobos
On 5/6/13 4:03 PM, Robert Rouse wrote:
On Monday, 6 May 2013 at 19:57:27 UTC, Andrei Alexandrescu wrote:
On 5/6/13 3:14 PM, Idan Arye wrote:
Template mixins can be used to implement some common programming
idioms(and design patterns). I have already implemented two of them for
my own project -
On Monday, 6 May 2013 at 20:10:59 UTC, Andrei Alexandrescu wrote:
On 5/6/13 4:03 PM, Robert Rouse wrote:
On Monday, 6 May 2013 at 19:57:27 UTC, Andrei Alexandrescu
wrote:
On 5/6/13 3:14 PM, Idan Arye wrote:
Template mixins can be used to implement some common
programming
idioms(and design
On Monday, 6 May 2013 at 19:47:33 UTC, Diggory wrote:
It's a nice idea but personally I don't like the syntax much,
for example it's completely non-obvious what true does when
passed to the singleton mixin, or that the parameters to the
property mixin are type, name, condition, initial value.
On Monday, 6 May 2013 at 21:18:56 UTC, Idan Arye wrote:
Anyways, I'll have to add a new trait template to extract the
name from the declaration(Compile time regex are too slow)
You know what? I take that back. I can probably pull this off
with an anonymous struct to get better compilation
On Mon, 06 May 2013 17:13:00 -0400, Idan Arye generic...@gmail.com wrote:
On Monday, 6 May 2013 at 19:47:33 UTC, Diggory wrote:
It's a nice idea but personally I don't like the syntax much, for
example it's completely non-obvious what true does when passed to the
singleton mixin, or that
On Monday, 6 May 2013 at 21:58:08 UTC, Steven Schveighoffer wrote:
On Mon, 06 May 2013 17:13:00 -0400, Idan Arye
generic...@gmail.com wrote:
On Monday, 6 May 2013 at 19:47:33 UTC, Diggory wrote:
It's a nice idea but personally I don't like the syntax much,
for example it's completely
50 matches
Mail list logo
