Am 13.11.2012 00:46, schrieb Walter Bright:
> On 11/9/2012 5:53 AM, Sönke Ludwig wrote:
>> Independent of this article I think D is currently missing out a lot by
>> omitting a proper unique type (a _proper_ library solution would be a
>> start, but I'm not sure if that can handle all details). It
On Monday, 12 November 2012 at 08:37:20 UTC, Tommi wrote:
This whole mess makes me wish that D was designed so that all
types had value semantics (by convention, since it's probably
not possible to enforce by the language).
"..so that all types had value semantics". That's a bit too
harsh. Ra
On Monday, 12 November 2012 at 08:39:50 UTC, Johannes Pfau wrote:
Am Mon, 12 Nov 2012 06:21:30 +0100
schrieb "adi" :
Hi there!!,
can any one help me with these errors, what do they mean
and how
do i resolve them
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010
On 11/12/12 6:29 PM, deadalnix wrote:
Le 13/11/2012 03:01, Andrei Alexandrescu a écrit :
On 11/12/12 5:40 PM, deadalnix wrote:
I never used moveFront and alike.
They're used by algorithms that you might be using.
Andrei
I'm not saying they are useless, or that I never used them under the h
Le 13/11/2012 03:01, Andrei Alexandrescu a écrit :
On 11/12/12 5:40 PM, deadalnix wrote:
I never used moveFront and alike.
They're used by algorithms that you might be using.
Andrei
I'm not saying they are useless, or that I never used them under the hood.
On 11/12/12 5:40 PM, deadalnix wrote:
I never used moveFront and alike.
They're used by algorithms that you might be using.
Andrei
Le 13/11/2012 01:57, Jonathan M Davis a écrit :
On Monday, November 12, 2012 15:57:42 Andrei Alexandrescu wrote:
Here are two thoughts:
1. The notion of "this is an input range that is not a forward range,
AND the element type has mutable indirections so it's not a proper value
type" is a very
On Monday, 12 November 2012 at 20:54:39 UTC, Jonathan M Davis
wrote:
On Monday, November 12, 2012 21:24:06 Rob T wrote:
Long discussion on const ref,
http://forum.dlang.org/thread/yhnbcocwxnbutylfe...@forum.dlang.org
here's the summary thread
http://forum.dlang.org/thread/zteryxwxyngvyqvuk...@f
On Monday, 12 November 2012 at 23:38:43 UTC, luka8088 wrote:
What about making this a default behavior and introducing a new
keyword if the function wants to modify the argument but it is
not ref (pass by value) ? The reason I think that this should
be a default behavior because not many functi
Update - we've crossed $20K! At this point we're one major backer away
from achieving the goal, and we're looking at a number of options.
Please share with your friends and coworkers, and bring the discussion
up with your employer's managers and recruiters. It should be an easier
case to make n
On Monday, November 12, 2012 15:57:42 Andrei Alexandrescu wrote:
> Here are two thoughts:
>
> 1. The notion of "this is an input range that is not a forward range,
> AND the element type has mutable indirections so it's not a proper value
> type" is a very close approximation of transiency. We cou
On 11/12/2012 3:52 PM, deadalnix wrote:
As much as I like the unique proposal, I don't think it is a good idea to
integrate at this point.
Neither do I. But it's good to think about it.
Le 13/11/2012 00:57, Andrei Alexandrescu a écrit :
On 11/12/12 3:14 PM, Jonathan M Davis wrote:
On Monday, November 12, 2012 12:28:14 Andrei Alexandrescu wrote:
Topic on range transience probably, as it is
almost concluded.
I'm leaning toward doing nothing about this.
As it stands, most eve
On 11/12/12 3:14 PM, Jonathan M Davis wrote:
On Monday, November 12, 2012 12:28:14 Andrei Alexandrescu wrote:
Topic on range transience probably, as it is
almost concluded.
I'm leaning toward doing nothing about this.
As it stands, most everything assumes that front is not transient. But the
On Monday, 12 November 2012 at 22:44:22 UTC, Jonathan M Davis
wrote:
On Monday, November 12, 2012 23:01:22 Tommi wrote:
NOTE: All of the above assumes that D were designed so that all
types had value semantics.
Which will never happen. So, any discussion based on that
premise is pretty pointl
Le 13/11/2012 00:46, Walter Bright a écrit :
On 11/9/2012 5:53 AM, Sönke Ludwig wrote:
Independent of this article I think D is currently missing out a lot by
omitting a proper unique type (a _proper_ library solution would be a
start, but I'm not sure if that can handle all details). It would m
Walter Bright:
Unique as a type qualifier comes with all kinds of subtle
problems. For one thing, unique is more of a property of an
expression rather than a property of the type.
Unfortunately I am not able to fully understand the paper linked
by Sönke Ludwig in this thread, but maybe you a
On 11/9/2012 5:53 AM, Sönke Ludwig wrote:
Independent of this article I think D is currently missing out a lot by
omitting a proper unique type (a _proper_ library solution would be a
start, but I'm not sure if that can handle all details). It would make a
lot of the cases work that are currently
What about making this a default behavior and introducing a new keyword
if the function wants to modify the argument but it is not ref (pass by
value) ? The reason I think that this should be a default behavior
because not many functions actually modify their arguments and so it
leaves a lot of
Here i as wild idea:
//
void main () {
mutex x;
// mutex is not a type but rather a keyword
// x is a symbol in order to allow
// different x in different scopes
shared(x) int i;
// ... or maybe use UDA ?
// mutex x must be locked
// in order to change i
synchronized
On Monday, November 12, 2012 12:28:14 Andrei Alexandrescu wrote:
> > Topic on range transience probably, as it is
> > almost concluded.
>
> I'm leaning toward doing nothing about this.
As it stands, most everything assumes that front is not transient. But then we
have ByLine and ByChunk. So, the
On Mon, Nov 12, 2012 at 12:28:14PM -0800, Andrei Alexandrescu wrote:
> On 11/12/12 11:45 AM, deadalnix wrote:
[...]
> >Topic on range transience probably, as it is almost concluded.
>
> I'm leaning toward doing nothing about this.
[...]
Please don't. This is an issue that *needs* to be addressed,
On Monday, November 12, 2012 23:01:22 Tommi wrote:
> On Monday, 12 November 2012 at 20:52:07 UTC, Jonathan M Davis
>
> wrote:
> > That wouldn't work. It's the complete opposite of what a
> > generative range would require if it generates the return value
> > in front. Narrow strings in particularl
On 11/12/12 12:50 PM, Jacob Carlborg wrote:
What's also being discussed in addition to your points are:
* Should built in types be allowed as attributes
* Should only types explicitly marked as an attribute (somehow) be
allowed as attributes
Saw that too. I don't have an opinion about such, th
On 11/12/12, Andrej Mitrovic wrote:
> Otherwise people use workarounds like "alias
> void[0][string] StringSet", and wrap such a type in a struct with
> operator overloads to emulate the built-in hash syntax.
Unfortunately this is also problematic with libraries which don't
handle this type. For
On Mon, Nov 12, 2012 at 2:28 PM, Andrei Alexandrescu
wrote:
>
> * The execution of that feature (merging in the trunk along with a bunch of
> unrelated work) was extremely poor. We need to acquire a sense of urgency
> about fixing our process, lest this mom-and-pop-shop style of getting work
> don
On Monday, 12 November 2012 at 20:52:07 UTC, Jonathan M Davis
wrote:
That wouldn't work. It's the complete opposite of what a
generative range would require if it generates the return value
in front. Narrow strings in particularly would be screwed by
it, because their front is calculated, and
Dne 11.11.2012 21:41, Regan Heath napsal(a):
On Sun, 11 Nov 2012 08:03:40 -, creatio wrote:
I'm not sure if this is the correct forum. But It looks like I'm one
of the few people that ran into this. I've recently upgraded to 2.60
and been getting this error when compiling:
Error: undefin
On 2012-11-12 21:28, Andrei Alexandrescu wrote:
* I saw very little focus for attribute testing, i.e. "does symbol xyz
have attribute abc"? I don't think we should relegate that to a __traits.
The current implementation only has __traits(getAttributes), which will
basically return a tuple of
On Monday, November 12, 2012 21:24:06 Rob T wrote:
> Long discussion on const ref,
> http://forum.dlang.org/thread/yhnbcocwxnbutylfe...@forum.dlang.org
>
> here's the summary thread
> http://forum.dlang.org/thread/zteryxwxyngvyqvuk...@forum.dlang.org
Yeah. You have some very strong views and that
On Monday, November 12, 2012 20:51:53 Tommi wrote:
> Then you'd solve this issue by specifying range concept so that
> front should return by value if it's transient, and front should
> return by reference or const reference if it's persistent.
That wouldn't work. It's the complete opposite of wha
Don't think that would be the case for you. It works just fine, just
make sure you are using the correct configure --target flag.
On my third time running through the instructions I felt like I was on
the right track until I got to the part about running
./setup-gcc.sh $HOME/gcc-4.7-4.7.1
On 11/12/12 11:45 AM, deadalnix wrote:
Le 12/11/2012 20:42, Andrei Alexandrescu a écrit :
Hi all,
I'm back from a few long trips during which I got behind reading this
group. I decided to mark everything as read and restart anew. If there
are any topics that you believe have "extinguished" but
On Monday, 12 November 2012 at 19:42:14 UTC, Andrei Alexandrescu
wrote:
Hi all,
I'm back from a few long trips during which I got behind
reading this group. I decided to mark everything as read and
restart anew. If there are any topics that you believe have
"extinguished" but need my attenti
On Monday, 12 November 2012 at 08:37:20 UTC, Tommi wrote:
This whole mess makes me wish that D was designed so that all
types had value semantics (by convention, since it's probably
not possible to enforce by the language).
That would mean:
1) No classes. Just duck-typing based polymorphism à
Le 12/11/2012 20:42, Andrei Alexandrescu a écrit :
Hi all,
I'm back from a few long trips during which I got behind reading this
group. I decided to mark everything as read and restart anew. If there
are any topics that you believe have "extinguished" but need my
attention, I'd be indebted if y
On Monday, November 12, 2012 11:36:38 H. S. Teoh wrote:
> I contend that the problem with built-in AA's is their implementation,
> not the fact that they're built-in.
Oh, I agree, but we, as a group, have obviously failed to handle the
implementation of the built-in AAs properly, and I think that
Hi all,
I'm back from a few long trips during which I got behind reading this
group. I decided to mark everything as read and restart anew. If there
are any topics that you believe have "extinguished" but need my
attention, I'd be indebted if you mentioned them to me via private email
or by
On 12-11-2012 20:42, Andrei Alexandrescu wrote:
Hi all,
I'm back from a few long trips during which I got behind reading this
group. I decided to mark everything as read and restart anew. If there
are any topics that you believe have "extinguished" but need my
attention, I'd be indebted if you
On Mon, Nov 12, 2012 at 08:07:08PM +0100, Jonathan M Davis wrote:
> On Monday, November 12, 2012 15:43:57 monarch_dodra wrote:
> > Thoughts?
>
> For now, if you need a set, then use RedBlackTree. Long term, a hash
> set should be added to std.container. As cool as it is to have AAs
> built into th
Am 12.11.2012 16:27, schrieb Sönke Ludwig:
> I generated some quick documentation with examples here:
>
> http://vibed.org/temp/d-isolated-test/stdx/typecons/lock.html
> http://vibed.org/temp/d-isolated-test/stdx/typecons/makeIsolated.html
> http://vibed.org/temp/d-isolated-test/stdx/typecons/make
On 2012-11-12 16:10, Andrej Mitrovic wrote:
On 11/12/12, monarch_dodra wrote:
But of course, a library solution would be good too.
dcollections has sets http://www.dsource.org/projects/dcollections
(not sure if it still compiles though)
And Tango:
https://github.com/SiegeLord/Tango-D2
htt
On 2012-11-12 17:57, Simen Kjaeraas wrote:
Until someone writes a proper DIP on them, macros can write entire software
packages, download Hitler, turn D into lisp, and bake bread. Can we please
stop with the 'macros could do that' until there's any sort of consensus as
to what macros *could* do?
On Monday, November 12, 2012 15:43:57 monarch_dodra wrote:
> Thoughts?
For now, if you need a set, then use RedBlackTree. Long term, a hash set
should be added to std.container. As cool as it is to have AAs built into the
language, they have been a disaster on a number of levels, and they buy yo
On Mon, Nov 12, 2012 at 09:58:14PM +0400, Dmitry Olshansky wrote:
> 11/12/2012 9:44 PM, H. S. Teoh пишет:
[...]
> >For storing integer types, you could optimize for space by dividing
> >your key space into blocks of, say, 32 entries each. Then your hash
> >function will hash only the upper (n-5) bi
On Monday, November 12, 2012 12:09:34 monarch_dodra wrote:
> IMO, there *NEEDS* to be some way of saying
> - "this _will_ be deprecated soon (marked for deprecation), you
> should consider migrating to something else. here is you warning."
> and
> - "This is already deprecated. Here is your error.
OK, as this problem seems to not be of any priority, let me state things
here.
I'm working on a program in D that is ~20 000 LOC. This is a non trivial
program, but really an huge one.
Compiling it trigger the error mentioned above. To have real data to
show, I did some test, right now, and
Le 12/11/2012 19:02, deadalnix a écrit :
OK, as this problem seems to not be of any priority, let me state things
here.
I'm working on a program in D that is ~20 000 LOC. This is a non trivial
program, but really an huge one.
Compiling it trigger the error mentioned above. To have real data to
On 12 November 2012 04:30, Walter Bright wrote:
> On 11/11/2012 10:46 AM, Alex Rønne Petersen wrote:
>
>> It's starting to get outright embarrassing to talk to newcomers about D's
>> concurrency support because the most fundamental part of it -- the shared
>> type
>> qualifier -- does not have we
On Monday, 12 November 2012 at 11:19:57 UTC, Walter Bright wrote:
On 11/12/2012 2:57 AM, Johannes Pfau wrote:
But there are also shared member functions and they're kind of
annoying
right now:
* You can't call shared methods from non-shared methods or
vice versa.
This leads to code duplicat
11/12/2012 9:44 PM, H. S. Teoh пишет:
On Mon, Nov 12, 2012 at 05:52:32PM +0100, Joseph Rushton Wakeling wrote:
On 11/12/2012 05:27 PM, Dmitry Olshansky wrote:
The current "workaround" is to just dummy it.
alias bool Dummy;
Dummy[string] names;
names["Paul"] = true; //Ew.
Make a wrapper?
The
Am 12.11.2012 07:50, schrieb Walter Bright:
On 11/11/2012 10:05 PM, Benjamin Thaut wrote:
The only problem beeing that you can not really have user defined
shared (value)
types:
http://d.puremagic.com/issues/show_bug.cgi?id=8295
If you include an object designed to work only in a single threa
On Mon, Nov 12, 2012 at 05:52:32PM +0100, Joseph Rushton Wakeling wrote:
> On 11/12/2012 05:27 PM, Dmitry Olshansky wrote:
> >>The current "workaround" is to just dummy it.
> >>alias bool Dummy;
> >>Dummy[string] names;
> >>names["Paul"] = true; //Ew.
> >
> >Make a wrapper?
>
> The problem with wr
11/12/2012 8:52 PM, Joseph Rushton Wakeling пишет:
On 11/12/2012 05:27 PM, Dmitry Olshansky wrote:
The current "workaround" is to just dummy it.
alias bool Dummy;
Dummy[string] names;
names["Paul"] = true; //Ew.
Make a wrapper?
The problem with wrapped versions of associative arrays is that
On 2012-11-12, 15:11, Jacob Carlborg wrote:
On 2012-11-12 12:55, Regan Heath wrote:
On Mon, 12 Nov 2012 02:30:17 -, Walter Bright
wrote:
To make a shared type work in an algorithm, you have to:
1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the dat
On 11/12/2012 05:27 PM, Dmitry Olshansky wrote:
The current "workaround" is to just dummy it.
alias bool Dummy;
Dummy[string] names;
names["Paul"] = true; //Ew.
Make a wrapper?
The problem with wrapped versions of associative arrays is that they just don't
scale with number of keys. If I wa
On Mon, Nov 12, 2012 at 08:27:51PM +0400, Dmitry Olshansky wrote:
> 11/12/2012 6:43 PM, monarch_dodra пишет:
> >D has a built in hashed associative container, which is great.
> >
>
>
> No. The literals are nice though.
>
> >I've noticed though it has no built-in "hashed container" for when
> >yo
On Monday, 12 November 2012 at 16:27:58 UTC, Dmitry Olshansky
wrote:
11/12/2012 6:43 PM, monarch_dodra пишет:
[SNIP]
Yeah... I'm implementing my lightweight wrapper now.
11/12/2012 6:43 PM, monarch_dodra пишет:
D has a built in hashed associative container, which is great.
No. The literals are nice though.
I've noticed though it has no built-in "hashed container" for when you
just need to store unique elements, but without any specific data
associated (list
On Mon, Nov 12, 2012 at 04:38:59PM +0100, monarch_dodra wrote:
> On Monday, 12 November 2012 at 15:22:00 UTC, bearophile wrote:
> >The situation is not fully symmetrical: associative arrays fully
> >defined in Phobos have bad literals.
> >
> >Bye,
> >bearophile
>
> Related: what is the hook for im
On Mon, Nov 12, 2012 at 03:43:57PM +0100, monarch_dodra wrote:
> D has a built in hashed associative container, which is great.
>
> I've noticed though it has no built-in "hashed container" for when
> you just need to store unique elements, but without any specific
> data associated (lists of name
Le 12/11/2012 16:00, luka8088 a écrit :
If I understood correctly there is no reason why this should not compile ?
import core.sync.mutex;
class MyClass {
void method () {}
}
void main () {
auto myObject = new shared(MyClass);
synchronized (myObject) {
myObject.method();
}
}
D has no owners
On 11/12/12, Joseph Rushton Wakeling wrote:
> Can you give a bit more explanation of how that workaround would work? I
> can't
> see how you would insert entries in that case ...
>
> StringSet s;
>
> s["one"] = ?
>
s["one"] = [];
On 11/12/2012 04:49 PM, monarch_dodra wrote:
Wait. That doesn't work actually. This does.
auto add(T value)
{
return _data[value] = cast(void[0]) null;
}
Only with DMD. GDC and LDC both reject this formulation -- it seems better to
use byte instead of void[0].
The pr
monarch_dodra:
Related: what is the hook for implementing "in"?
"in" is supported:
http://dlang.org/operatoroverloading.html#Binary
Bye,
bearophile
On Monday, 12 November 2012 at 15:36:29 UTC, monarch_dodra wrote:
As for the implementation, this seems to work:
StringSet(T)
{
private void[0][T] _data;
void add(T value)
{
_data.get(value, cast(void[0]) null);
}
}
Wait. That doesn't work actually. This does.
auto
On Monday, 12 November 2012 at 15:32:24 UTC, Joseph Rushton
Wakeling wrote:
On 11/12/2012 03:53 PM, Andrej Mitrovic wrote:
You probably mean a Set? I think we could really use some
syntax
support for sets. Otherwise people use workarounds like "alias
void[0][string] StringSet"
Can you give a
On Monday, 12 November 2012 at 15:22:00 UTC, bearophile wrote:
The situation is not fully symmetrical: associative arrays
fully defined in Phobos have bad literals.
Bye,
bearophile
Related: what is the hook for implementing "in"?
On Monday, 12 November 2012 at 15:22:00 UTC, bearophile wrote:
The situation is not fully symmetrical: associative arrays
fully defined in Phobos have bad literals.
I apologize, I'm not sure what you mean.
On 11/12/2012 03:53 PM, Andrej Mitrovic wrote:
You probably mean a Set? I think we could really use some syntax
support for sets. Otherwise people use workarounds like "alias
void[0][string] StringSet"
Can you give a bit more explanation of how that workaround would work? I can't
see how you
I generated some quick documentation with examples here:
http://vibed.org/temp/d-isolated-test/stdx/typecons/lock.html
http://vibed.org/temp/d-isolated-test/stdx/typecons/makeIsolated.html
http://vibed.org/temp/d-isolated-test/stdx/typecons/makeIsolatedArray.html
It does offer some nice improveme
monarch_dodra:
Well, I don't see why AA would be built-in, but not set.
It's generally wise to minimize the amount of stuff you put in
the D front end or in the D runtime.
so if we take the time to implement AA, why not hashed sets?
The advantage of having it built-in would mean more con
On 11/12/12, monarch_dodra wrote:
> But of course, a library solution would be good too.
dcollections has sets http://www.dsource.org/projects/dcollections
(not sure if it still compiles though)
On Monday, 12 November 2012 at 14:53:19 UTC, Andrej Mitrovic
wrote:
On 11/12/12, monarch_dodra wrote:
I've noticed though it has no built-in "hashed container" for
when you just need to store unique elements, but without any
specific data associated (lists of names, for example).
You probably
On Monday, 12 November 2012 at 14:50:48 UTC, bearophile wrote:
monarch_dodra:
I've noticed though it has no built-in "hashed container" for
when you just need to store unique elements, but without any
specific data associated (lists of names, for example).
They are often named "hash sets". I
Andrej Mitrovic:
I think we could really use some syntax support for sets.<
I don't agree. I think in D there is no real need for built-in
support for sets, despite built-ins are handy. It's better to
leave the compiler changes to things that can't be implemented in
library code, like a goo
If I understood correctly there is no reason why this should not compile ?
import core.sync.mutex;
class MyClass {
void method () {}
}
void main () {
auto myObject = new shared(MyClass);
synchronized (myObject) {
myObject.method();
}
}
On 12.11.2012 12:19, Walter Bright wrote:
On
monarch_dodra:
I've noticed though it has no built-in "hashed container" for
when you just need to store unique elements, but without any
specific data associated (lists of names, for example).
They are often named "hash sets". In Python this is a built-in
type. But in D I think it's better
On 11/12/12, monarch_dodra wrote:
> I've noticed though it has no built-in "hashed container" for
> when you just need to store unique elements, but without any
> specific data associated (lists of names, for example).
You probably mean a Set? I think we could really use some syntax
support for s
D has a built in hashed associative container, which is great.
I've noticed though it has no built-in "hashed container" for
when you just need to store unique elements, but without any
specific data associated (lists of names, for example).
Has anybody requested this before? Would there be a
On 2012-11-12 12:55, Regan Heath wrote:
On Mon, 12 Nov 2012 02:30:17 -, Walter Bright
wrote:
To make a shared type work in an algorithm, you have to:
1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex
Flamaros wrote:
> How many years it will take to be able to do a search on D that
> isn't linked to the code? Like a job search, or anything else?
I've done a little bit in the area of search engines. With todays algorithms
it's no problem to search for a language with a single letter "D". Modern
Le 12/11/2012 14:23, Sönke Ludwig a écrit :
Am 12.11.2012 14:00, schrieb deadalnix:
With some kind of ownership in the type system, it can me made automagic
that shared is casted away on synchronized object.
Yes and I would love to have that, but I fear that we then basically get
where Bartos
Am 12.11.2012 14:00, schrieb deadalnix:
>
> With some kind of ownership in the type system, it can me made automagic
> that shared is casted away on synchronized object.
Yes and I would love to have that, but I fear that we then basically get
where Bartosz Milewski was at the end of his research.
Am 12.11.2012 13:33, schrieb Regan Heath:
> On Mon, 12 Nov 2012 11:41:00 -, Sönke Ludwig
> wrote:
>
>> Am 11.11.2012 19:46, schrieb Alex Rønne Petersen:
>>> Something needs to be done about shared. I don't know what, but the
>>> current situation is -- and I'm really not exaggerating here --
On Mon, 12 Nov 2012 08:46:42 + (UTC)
Manfred Nowak wrote:
> Nick Sabalausky wrote:
>
> > tell the user he's using an impractical approach
>
> ... it is ncurrently ot the duty of the compiler to decide what
> a practical approach might be. Therefore the coder has to notify
> this to the co
Le 12/11/2012 02:29, Walter Bright a écrit :
On 11/11/2012 10:59 AM, Sönke Ludwig wrote:
However, I have to admit that without actually trying it and seeing how
usable it is first hand, it's difficult to tell how usable it is in
practice (e.g. because D functions have to be explicitly tagged 'pu
Le 12/11/2012 13:25, Regan Heath a écrit :
First off, IIRC object contains a mutex/monitor/critical section, which
means all objects contain one. The last discussion saw many people
wanting this removed for efficiency. I propose we do this. Then, if a
class or struct is declared as "shared" or a
Le 12/11/2012 12:41, Sönke Ludwig a écrit :
Am 11.11.2012 19:46, schrieb Alex Rønne Petersen:
Something needs to be done about shared. I don't know what, but the
current situation is -- and I'm really not exaggerating here --
laughable. I think we either need to just make it perfectly clear that
Le 12/11/2012 03:30, Walter Bright a écrit :
On 11/11/2012 10:46 AM, Alex Rønne Petersen wrote:
It's starting to get outright embarrassing to talk to newcomers about D's
concurrency support because the most fundamental part of it -- the
shared type
qualifier -- does not have well-defined semanti
On Mon, 12 Nov 2012 11:41:00 -, Sönke Ludwig
wrote:
Am 11.11.2012 19:46, schrieb Alex Rønne Petersen:
Something needs to be done about shared. I don't know what, but the
current situation is -- and I'm really not exaggerating here --
laughable. I think we either need to just make it perf
On Mon, 12 Nov 2012 11:55:51 -, Regan Heath
wrote:
On Mon, 12 Nov 2012 02:30:17 -, Walter Bright
wrote:
To make a shared type work in an algorithm, you have to:
1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5.
Ok, i was trying out D and wanted to see if i could create
something that behaves like a property but adds a change
notification signal. Doing this, I encountered a hangup which
might be a bug. So far I have the following:
---
import std
On Mon, 12 Nov 2012 02:30:17 -, Walter Bright
wrote:
To make a shared type work in an algorithm, you have to:
1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex
So what we actually want, in order to
On Sat, 10 Nov 2012 09:06:38 -, Marco Leise wrote:
DPL -> has no sound to it
I read DPL as "dee-pee-el" which sounds cool to me. :p
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Am 11.11.2012 19:46, schrieb Alex Rønne Petersen:
> Something needs to be done about shared. I don't know what, but the
> current situation is -- and I'm really not exaggerating here --
> laughable. I think we either need to just make it perfectly clear that
> shared is for documentation purposes a
On 11/12/2012 2:57 AM, Johannes Pfau wrote:
But there are also shared member functions and they're kind of annoying
right now:
* You can't call shared methods from non-shared methods or vice versa.
This leads to code duplication, you basically have to implement
everything twice:
You can'
On Sunday, 11 November 2012 at 21:14:10 UTC, Jonathan M Davis
wrote:
Agreed. Otherwise, you can't deprecate something without
immediately breaking
code, which means that if you're trying to never immediately
break people's
code when making a change (which is the position that Phobos is
in), the
Am Sun, 11 Nov 2012 18:30:17 -0800
schrieb Walter Bright :
>
> To make a shared type work in an algorithm, you have to:
>
> 1. ensure single threaded access by aquiring a mutex
> 2. cast away shared
> 3. operate on the data
> 4. cast back to shared
> 5. release the mutex
>
> Also, all op= need
Am 12.11.2012 04:06, schrieb Jonathan M Davis:
> On Sunday, November 11, 2012 17:29:02 Walter Bright wrote:
>> I'm not convinced that adding a "unique" qualifier is strictly necessary.
>
> Where it would be particularly valuable would be passing stuff across threads
> with std.concurrency. We don
1 - 100 of 104 matches
Mail list logo
