www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 0.99 release

reply "Walter" <newshound digitalmars.com> writes:
Lots more bug fixes. Added special 'length' inside array [ ]'s.

http://www.digitalmars.com/d/changelog.html
Aug 19 2004
next sibling parent reply kinghajj <kinghajj_member pathlink.com> writes:
In article <cg3n60$2oap$1 digitaldaemon.com>, Walter says...
Added special 'length' inside array [ ]'s.

meaning ? ... (example please)
Aug 19 2004
next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"kinghajj" <kinghajj_member pathlink.com> escribió en el mensaje
news:cg3oju$2p20$1 digitaldaemon.com
| In article <cg3n60$2oap$1 digitaldaemon.com>, Walter says...
||
|| Added special 'length' inside array [ ]'s.
||
|
| meaning ? ... (example please)

Look for "Array Length" in arrays.html:

"Within the [ ] of a static or a dynamic array, the variable length is
implicitly declared and set to the length of the array."

-----------------------
Carlos Santander Bernal
Aug 19 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 20 Aug 2004 02:45:18 +0000 (UTC), kinghajj wrote:

 In article <cg3n60$2oap$1 digitaldaemon.com>, Walter says...
Added special 'length' inside array [ ]'s.

meaning ? ... (example please)

char[] myarray = "abcdefghij"; writef(myarray[length-3 .. length ] output ==> "hij" -- Derek Melbourne, Australia 20/Aug/04 12:47:50 PM
Aug 19 2004
parent kinghajj <kinghajj_member pathlink.com> writes:
In article <cg3or0$2p3k$1 digitaldaemon.com>, Derek Parnell says...
On Fri, 20 Aug 2004 02:45:18 +0000 (UTC), kinghajj wrote:

 In article <cg3n60$2oap$1 digitaldaemon.com>, Walter says...
Added special 'length' inside array [ ]'s.

meaning ? ... (example please)

char[] myarray = "abcdefghij"; writef(myarray[length-3 .. length ] output ==> "hij" -- Derek Melbourne, Australia 20/Aug/04 12:47:50 PM

Oh, ok, that's cool!
Aug 19 2004
prev sibling next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Walter wrote:

 Lots more bug fixes. Added special 'length' inside array [ ]'s.
 
 http://www.digitalmars.com/d/changelog.html

I don't suppose there's any way to get that sugar for things that implement opIndex, opSlice, etc. Or that that work already? I'm thinking that if x is an instance of class Foo and Foo defined opIndex and length() then x[length-1] is the same as x.opIndex(x.length-1).
Aug 19 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:cg3oug$2ond$1 digitaldaemon.com...
 Walter wrote:

 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html

I don't suppose there's any way to get that sugar for things that

 opIndex, opSlice, etc. Or that that work already? I'm thinking that if x

 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).

That does need to be done. I was thinking that an implicit 'with' statement could happen, and then all the members of the class instance would be usable.
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg3sh1$2qr1$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle4 juno.com> wrote in message
 news:cg3oug$2ond$1 digitaldaemon.com...
 Walter wrote:

 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html

I don't suppose there's any way to get that sugar for things that

 opIndex, opSlice, etc. Or that that work already? I'm thinking that if x

 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).

That does need to be done. I was thinking that an implicit 'with' statement could happen, and then all the members of the class instance would be usable.

Yikes no. Please, in the words of the expository master: "do as the ints do" and the relativistic master: "as simple as possible, but no simpler".
Aug 19 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg3v1i$2t3r$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

 "Ben Hinkle" <bhinkle4 juno.com> wrote in message
 news:cg3oug$2ond$1 digitaldaemon.com...
 Walter wrote:

 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html

I don't suppose there's any way to get that sugar for things that

 opIndex, opSlice, etc. Or that that work already? I'm thinking that if



 is
 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).

That does need to be done. I was thinking that an implicit 'with'


 could happen, and then all the members of the class instance would be
 usable.

Yikes no. Please, in the words of the expository master: "do as the ints do" and the

 but no simpler".

How else to supply the length? Just make that member visible?
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg40as$2thv$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg3v1i$2t3r$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

 "Ben Hinkle" <bhinkle4 juno.com> wrote in message
 news:cg3oug$2ond$1 digitaldaemon.com...
 Walter wrote:

 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html

I don't suppose there's any way to get that sugar for things that

 opIndex, opSlice, etc. Or that that work already? I'm thinking that if



 is
 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).

That does need to be done. I was thinking that an implicit 'with'


 could happen, and then all the members of the class instance would be
 usable.

Yikes no. Please, in the words of the expository master: "do as the ints do" and the

 but no simpler".

How else to supply the length? Just make that member visible?

I like Chris' suggestion of opLength(), but if not I'd settle for the compiler making length a special case. Of course, if it's going to be a special case, then why not an operator. And if that's the case, then what about allowing the Python like syntax int l = length(x); // Equivalent to int l = x.length; I'm not proposing this last bit, mind, just interested in hearing opinions on the matter.
Aug 19 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <cg412i$2tt9$1 digitaldaemon.com>, Matthew says...
And if that's the case, then what about allowing the Python like syntax

    int l = length(x); // Equivalent to int l = x.length;

I'm not proposing this last bit, mind, just interested in hearing opinions on
the matter.

D already supports this in reverse for arrays. ie. length(T[] x) can be called as: length(x) or x.length. Since this is the case, and assuming it hasn't already been done, it would be nice to expose the default parameters as D functions. So we could call sizeof(x), length(x), etc. By the same token, it would be nice to have this be consistent for all primitive types rather than just for array types. Sean
Aug 20 2004
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cg5e3f$iep$1 digitaldaemon.com...
 In article <cg412i$2tt9$1 digitaldaemon.com>, Matthew says...
And if that's the case, then what about allowing the Python like syntax

    int l = length(x); // Equivalent to int l = x.length;

I'm not proposing this last bit, mind, just interested in hearing opinions on
the matter.

D already supports this in reverse for arrays. ie. length(T[] x) can be called as: length(x) or x.length. Since this is the case, and assuming it hasn't already been done, it would be nice to expose the default parameters as D functions. So we could call sizeof(x), length(x), etc. By the same token, it would be nice to have this be consistent for all primitive types rather than just for array types.

Certainly, one the main points is to keep handling of all types consistent. And, yes, I like the application the principle of sizeof() also.
Aug 20 2004
prev sibling parent "Thomas Kuehne" <eisvogel users.sourceforge.net> writes:
Sean Kelly schrieb in <cg5e3f$iep$1 digitaldaemon.com>:
 D already supports this in reverse for arrays.  ie. length(T[] x) can be
 called as: length(x) or x.length.  Since this is the case, and assuming it
 hasn't already been done, it would be nice to expose the default
 parameters as D functions.  So we could call sizeof(x), length(x), etc.
 By the same token, it would be nice to have this be consistent for all
 primitive types rather than just for array types.

I strongly opose this. This will break lots of existing length() etc. functions. If ever enable this only when a special pragma switch is included in the sources. Thomas
Aug 20 2004
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:cg3oug$2ond$1 digitaldaemon.com...
 Walter wrote:

 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html

I don't suppose there's any way to get that sugar for things that implement opIndex, opSlice, etc. Or that that work already? I'm thinking that if x is an instance of class Foo and Foo defined opIndex and length() then x[length-1] is the same as x.opIndex(x.length-1).

I never considered that that was _not_ the case. Please say that is indeed how it works, big-W. If not, count this a loud vote for that consistency. :)
Aug 19 2004
parent "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg3uu9$2t1b$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle4 juno.com> wrote in message

 Walter wrote:

 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html

I don't suppose there's any way to get that sugar for things that


 opIndex, opSlice, etc. Or that that work already? I'm thinking that if x


 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).

I never considered that that was _not_ the case. Please say that is indeed

 If not, count this a loud vote for that consistency. :)

Right now it only works for arrays.
Aug 19 2004
prev sibling next sibling parent reply "Vathix" <vathixSpamFix dprogramming.com> writes:
 Added special 'length' inside array [ ]'s.

I think it's pretty cool, but might cause logic bugs. I'm just glad I've been lazy in naming my variables len instead of length. Perhaps it should be illegal to name something length, and just allow classes/structs/unions to have an opLength() ? It would also be helpful for people porting from another language. length is a pretty popular name.
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Vathix" <vathixSpamFix dprogramming.com> wrote in message
news:cg3trp$2s1u$1 digitaldaemon.com...
 Added special 'length' inside array [ ]'s.

I think it's pretty cool, but might cause logic bugs. I'm just glad I've been lazy in naming my variables len instead of length. Perhaps it should be illegal to name something length, and just allow classes/structs/unions to have an opLength() ? It would also be helpful for people porting from another language. length is a pretty popular name.

At first I thought yuck. But mere seconds later, I think Yes! Please add me onto this soon-to-huge list of Yeah-sayers
Aug 19 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg3v1j$2t3r$2 digitaldaemon.com...
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message

 Added special 'length' inside array [ ]'s.

I think it's pretty cool, but might cause logic bugs. I'm just glad I've been lazy in naming my variables len instead of length. Perhaps it


 illegal to name something length, and just allow classes/structs/unions


 have an opLength() ? It would also be helpful for people porting from
 another language. length is a pretty popular name.

At first I thought yuck. But mere seconds later, I think Yes!

Most of the proposals involved things like using a special token like $, but I thought we're already using length, so why not just continue that direction?
Aug 19 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg40at$2thv$3 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg3v1j$2t3r$2 digitaldaemon.com...
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message

 Added special 'length' inside array [ ]'s.

I think it's pretty cool, but might cause logic bugs. I'm just glad I've been lazy in naming my variables len instead of length. Perhaps it


 illegal to name something length, and just allow classes/structs/unions


 have an opLength() ? It would also be helpful for people porting from
 another language. length is a pretty popular name.

At first I thought yuck. But mere seconds later, I think Yes!

Most of the proposals involved things like using a special token like $, but I thought we're already using length, so why not just continue that direction?

Oh sure, we agree on the syntax. Just that the special symbol for the length operator should be, er, "length". :-)
Aug 19 2004
prev sibling parent Daniel Horn <hellcatv hotmail.com> writes:
awesome idea :-)
Matthew wrote:
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message
news:cg3trp$2s1u$1 digitaldaemon.com...
 
Added special 'length' inside array [ ]'s.

I think it's pretty cool, but might cause logic bugs. I'm just glad I've been lazy in naming my variables len instead of length. Perhaps it should be illegal to name something length, and just allow classes/structs/unions to have an opLength() ? It would also be helpful for people porting from another language. length is a pretty popular name.

At first I thought yuck. But mere seconds later, I think Yes! Please add me onto this soon-to-huge list of Yeah-sayers

Aug 20 2004
prev sibling next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
Added special 'length' inside array [ ]'s.

Excellent. I really can't imagine this causing more than a very few faltering steps for each developer, and a considerable, albiet sugary, syntactic simplification. Now, how do I go about raising the issue of D providing thread-agnostic implicit reg-exp, a la Perl and Ruby? (I'm not kidding!)
Aug 19 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg3usm$2t04$1 digitaldaemon.com...
Added special 'length' inside array [ ]'s.

Excellent. I really can't imagine this causing more than a very few

 considerable, albiet sugary, syntactic simplification.

 Now, how do I go about raising the issue of D providing thread-agnostic

 (I'm not kidding!)

2.0. BTW, are you following Andrei A's thread on adding lock-free concurrent containers to C++? It's a great read in comp.lang.c++.moderated under the thread "Multithreaded programming: is the C++ standardization committee listening?"
Aug 19 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg40au$2thv$4 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg3usm$2t04$1 digitaldaemon.com...
Added special 'length' inside array [ ]'s.

Excellent. I really can't imagine this causing more than a very few

 considerable, albiet sugary, syntactic simplification.

 Now, how do I go about raising the issue of D providing thread-agnostic

 (I'm not kidding!)

2.0. BTW, are you following Andrei A's thread on adding lock-free concurrent containers to C++? It's a great read in comp.lang.c++.moderated under the thread "Multithreaded programming: is the C++ standardization committee listening?"

No. Checking out ... Sounds like Andrei's demanding for C++ what I've said to you several times that we _could_ achieve for D (given that I share the view with some of the respondents that it's not possible/practicable for C++). Atomic ops, lock-free containers, etc. etc. We can do it. (But maybe this has to be 2.0 stuff.) I'm interested right now in whether reading that thread's made you more or less interested in native threading support for D than you were the last time we discussed it? (btw, if doing this made D lose some of the odd little platforms it might conceivably be ported to, I believe that would be a worthy pact, since this would be one area in which D would be manifestly superior to C++. Has that got your juices flowing ???)
Aug 19 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg412k$2tt9$3 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

 2.0. BTW, are you following Andrei A's thread on adding lock-free


 containers to C++? It's a great read in comp.lang.c++.moderated under


 thread "Multithreaded programming: is the C++ standardization committee
 listening?"

No. Checking out ... Sounds like Andrei's demanding for C++ what I've said to you several times

 share the view with some of the respondents that it's not

 Atomic ops, lock-free containers, etc. etc. We can do it. (But maybe this

 I'm interested right now in whether reading that thread's made you more or

 for D than you were the last time we discussed it?

I've always been interested in support for threading, that's why the synchronize primitives are there, as well as the volatile statement. I'm not sure what else needs to happen in the core language, isn't the rest mostly a library issue?
 (btw, if doing this made D lose some of the odd little platforms it might

 be a worthy pact, since this would be one area in which D would be

 flowing ???)

I don't see a problem there, platforms that don't support multithreading will just have noops for the sync primitives.
Aug 20 2004
parent Sean Kelly <sean f4.ca> writes:
In article <cg4802$30v7$1 digitaldaemon.com>, Walter says...
I've always been interested in support for threading, that's why the
synchronize primitives are there, as well as the volatile statement. I'm not
sure what else needs to happen in the core language, isn't the rest mostly a
library issue?

Probably. Though it might be nice to formalize hooks for library writers to manipulate the built-in synchronization blocks. Also, there may be some advantage to having language support for condvars, though I haven't thought enough about this to know whether merely adding a new attribute would be sufficient. Sean
Aug 20 2004
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <cg412k$2tt9$3 digitaldaemon.com>, Matthew says...
"Walter" <newshound digitalmars.com> wrote in message
news:cg40au$2thv$4 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg3usm$2t04$1 digitaldaemon.com...
Added special 'length' inside array [ ]'s.

Excellent. I really can't imagine this causing more than a very few

 considerable, albiet sugary, syntactic simplification.

 Now, how do I go about raising the issue of D providing thread-agnostic

 (I'm not kidding!)

2.0. BTW, are you following Andrei A's thread on adding lock-free concurrent containers to C++? It's a great read in comp.lang.c++.moderated under the thread "Multithreaded programming: is the C++ standardization committee listening?"

No. Checking out ... Sounds like Andrei's demanding for C++ what I've said to you several times that we _could_ achieve for D (given that I share the view with some of the respondents that it's not possible/practicable for C++). Atomic ops, lock-free containers, etc. etc. We can do it. (But maybe this has to be 2.0 stuff.)

It's been a while since I checked that thread--thanks for the reminder, Walter. I think D already has laid some decent groundwork for this with the revised volatile semantics, etc. It would be logical to extend this to support the things that Andrei mentions, though I expect that much of this might not make it in until 2.0.
(btw, if doing this made D lose some of the odd little platforms it might
conceivably be ported to, I believe that would
be a worthy pact, since this would be one area in which D would be manifestly
superior to C++. Has that got your juices
flowing ???)

Heck yes. It remains to be seen how much of Boost.Threads makes it into C++ 0x, but even that is just a collection of library routines rather than native language support. Between Unicode support and multithreading, D has a lot going for it over C++. Sean
Aug 20 2004
prev sibling next sibling parent reply "antiAlias" <fu bar.com> writes:
Walter" <newshound digitalmars.com> wrote in message
 2.0. BTW, are you following Andrei A's thread on adding lock-free

 containers to C++? It's a great read in comp.lang.c++.moderated under the
 thread "Multithreaded programming: is the C++ standardization committee
 listening?"

About time too! On that note, mango.cache has a port of Doug Lea's latest-and-greatest concurrent HashMap. Nice,clean, concise bit of code, configurable (contention-level) and very efficient: no read-locks at all. Also has foreach() support. I suggest this migrate into one of the container libs rather than slumbering quietly within Mango.
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"antiAlias" <fu bar.com> wrote in message
news:cg41s8$2u61$1 digitaldaemon.com...
 Walter" <newshound digitalmars.com> wrote in message
 2.0. BTW, are you following Andrei A's thread on adding lock-free

 containers to C++? It's a great read in comp.lang.c++.moderated under the
 thread "Multithreaded programming: is the C++ standardization committee
 listening?"

About time too! On that note, mango.cache has a port of Doug Lea's latest-and-greatest concurrent HashMap. Nice,clean, concise bit of code, configurable (contention-level) and very efficient: no read-locks at all. Also has foreach() support. I suggest this migrate into one of the container libs rather than slumbering quietly within Mango.

We'll get that one into DTL, if you don't mind. :)
Aug 19 2004
parent reply "antiAlias" <fu bar.com> writes:
No problem. Just pull it out of the (browser enabled) dsource.org
repository. The documentation needs a wee bit of attention :~)

Let's share updates (on that module) until we get some resolution on how to
easily resolve multiple interdependent libraries ...


"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg42kq$2ubh$1 digitaldaemon.com...
 "antiAlias" <fu bar.com> wrote in message

 Walter" <newshound digitalmars.com> wrote in message
 2.0. BTW, are you following Andrei A's thread on adding lock-free

 containers to C++? It's a great read in comp.lang.c++.moderated under



 thread "Multithreaded programming: is the C++ standardization



 listening?"

About time too! On that note, mango.cache has a port of Doug Lea's latest-and-greatest concurrent HashMap. Nice,clean, concise bit of code, configurable (contention-level) and very efficient: no read-locks at


 Also has foreach() support. I suggest this migrate into one of the


 libs rather than slumbering quietly within Mango.

We'll get that one into DTL, if you don't mind. :)

Aug 20 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
[I'm cross posting to dtl group. Can you *only* answer in that group, and then
we've move it over nicely. :)]

Done.

I like the look of it so far.

I don't think we're going to be able to keep it in the same format for DTL,
though. If you don't mind, I'd rather keep
the container implementations as consistent as possible, in terms of layout,
etc., so I'd be looking to reformat it
considerably.

Obviously there'll be deeper changes as well, such as templatisation, and
incorporation of the composable range
transformations/filters.

Question: what's the purpose of using "volatile" in various places. Since,
AFAIK, D's volatile speaks to intra-thread
memory coherence, and do not cross-thread contention, aren't these superfluous?
Or have you come across some secret
wisdom? (If so, send it to me quickly, via the secret T1!)

Matthew

"antiAlias" <fu bar.com> wrote in message news:cg48q9$ma$1 digitaldaemon.com...
 No problem. Just pull it out of the (browser enabled) dsource.org
 repository. The documentation needs a wee bit of attention :~)

 Let's share updates (on that module) until we get some resolution on how to
 easily resolve multiple interdependent libraries ...


 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg42kq$2ubh$1 digitaldaemon.com...
 "antiAlias" <fu bar.com> wrote in message

 Walter" <newshound digitalmars.com> wrote in message
 2.0. BTW, are you following Andrei A's thread on adding lock-free

 containers to C++? It's a great read in comp.lang.c++.moderated under



 thread "Multithreaded programming: is the C++ standardization



 listening?"

About time too! On that note, mango.cache has a port of Doug Lea's latest-and-greatest concurrent HashMap. Nice,clean, concise bit of code, configurable (contention-level) and very efficient: no read-locks at


 Also has foreach() support. I suggest this migrate into one of the


 libs rather than slumbering quietly within Mango.

We'll get that one into DTL, if you don't mind. :)


Aug 20 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg4b8t$1pd$2 digitaldaemon.com...
 Question: what's the purpose of using "volatile" in various places. Since,

 memory coherence, and do not cross-thread contention, aren't these

 wisdom? (If so, send it to me quickly, via the secret T1!)

D's volatile has essentially nothing in common with C's, and everything to do with helping with writing multithreaded apps. I learned about it from Scott Meyer's talk on multithreading. As I recall, it was about preventing the compiler from moving loads and stores across locks. C++ has no such guarantee, although C++ optimizers in reality respect the locks. This is the modern understanding of volatile, and both Java and C# have altered their definitions of volatile to suit as well.
Aug 20 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <cg59uu$gfi$1 digitaldaemon.com>, Walter says...
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg4b8t$1pd$2 digitaldaemon.com...
 Question: what's the purpose of using "volatile" in various places. Since,

 memory coherence, and do not cross-thread contention, aren't these

 wisdom? (If so, send it to me quickly, via the secret T1!)

D's volatile has essentially nothing in common with C's, and everything to do with helping with writing multithreaded apps. I learned about it from Scott Meyer's talk on multithreading. As I recall, it was about preventing the compiler from moving loads and stores across locks. C++ has no such guarantee, although C++ optimizers in reality respect the locks. This is the modern understanding of volatile, and both Java and C# have altered their definitions of volatile to suit as well.

Yup. Andrei and Scott co-wrote articles in the July and August editions of DDJ about this ("C++ and the Perils of Double-Checked Locking"). There was also a thread about it in comp.std.c++. It all boils down to the evil of the "as-if" rule. Sean
Aug 20 2004
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg59uu$gfi$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg4b8t$1pd$2 digitaldaemon.com...
 Question: what's the purpose of using "volatile" in various places. Since,

 memory coherence, and do not cross-thread contention, aren't these

 wisdom? (If so, send it to me quickly, via the secret T1!)

D's volatile has essentially nothing in common with C's, and everything to do with helping with writing multithreaded apps. I learned about it from Scott Meyer's talk on multithreading. As I recall, it was about preventing the compiler from moving loads and stores across locks. C++ has no such guarantee, although C++ optimizers in reality respect the locks. This is the modern understanding of volatile, and both Java and C# have altered their definitions of volatile to suit as well.

Ok. But I'll need you to fine-grain some examples for me before that coallesces into a genuine understanding. Maybe we can do this in written form somewhere soon? ;)
Aug 20 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg5tjc$sdr$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message

 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg4b8t$1pd$2 digitaldaemon.com...
 Question: what's the purpose of using "volatile" in various places.



 AFAIK, D's volatile speaks to intra-thread
 memory coherence, and do not cross-thread contention, aren't these

 wisdom? (If so, send it to me quickly, via the secret T1!)

D's volatile has essentially nothing in common with C's, and everything


 do with helping with writing multithreaded apps. I learned about it from
 Scott Meyer's talk on multithreading. As I recall, it was about


 the compiler from moving loads and stores across locks. C++ has no such
 guarantee, although C++ optimizers in reality respect the locks. This is


 modern understanding of volatile, and both Java and C# have altered


 definitions of volatile to suit as well.

Ok. But I'll need you to fine-grain some examples for me before that

 Maybe we can do this in written form somewhere soon? ;)

See the July and August DDJ's by Andrei and Scott. They understand the issues far better than I, and my brain hurts every time I try to figure it out again.
Aug 21 2004
parent Sean Kelly <sean f4.ca> writes:
In article <cg7361$1mmk$1 digitaldaemon.com>, Walter says...
See the July and August DDJ's by Andrei and Scott. They understand the
issues far better than I, and my brain hurts every time I try to figure it
out again.

The discussions on threading in comp.std.c++ are getting pretty involved, so any of those would be a good resource. And lurking on comp.lang.threads is always helpful, though it can take some searching to catch up on the lingo. It seems there's a pretty big movement towards lockless thread synchronization, and D is already in a better position than most other languages to take advantage of this. I know that Ben was working on some lockless containers... I'll have to find some time to check them out. Sean
Aug 27 2004
prev sibling parent reply "antiAlias" <fu bar.com> writes:
"Matthew"  wrote ...
 I don't think we're going to be able to keep it in the same format for

 the container implementations as consistent as possible, in terms of

 considerably.

 Obviously there'll be deeper changes as well, such as templatisation, and

 transformations/filters.

Sure ... edit with aplomb <g>
 Question: what's the purpose of using "volatile" in various places. Since,

 memory coherence, and do not cross-thread contention, aren't these

 wisdom? (If so, send it to me quickly, via the secret T1!)

That's the difference between the Java/C++ and D implementation. The former tag the variable itself, while D tags the usage. I think the D approach to the "memory-barrier" thing is the 'correct' one, but it may lead to obtuse and hard-to-find bugs. For instance, you have to manually and carefully add the volatile tag to each usage, rather than the compiler doing it for you (in the Java/C++ case). D, however, gives you more flexibility and control over how/where the barrier is applied. I think that's accurate ... someone please correct me if I'm wrong.
 Matthew

 "antiAlias" <fu bar.com> wrote in message

 No problem. Just pull it out of the (browser enabled) dsource.org
 repository. The documentation needs a wee bit of attention :~)

 Let's share updates (on that module) until we get some resolution on how


 easily resolve multiple interdependent libraries ...


 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg42kq$2ubh$1 digitaldaemon.com...
 "antiAlias" <fu bar.com> wrote in message

 Walter" <newshound digitalmars.com> wrote in message
 2.0. BTW, are you following Andrei A's thread on adding lock-free

 containers to C++? It's a great read in comp.lang.c++.moderated





 the
 thread "Multithreaded programming: is the C++ standardization



 listening?"

About time too! On that note, mango.cache has a port of Doug Lea's latest-and-greatest concurrent HashMap. Nice,clean, concise bit of




 configurable (contention-level) and very efficient: no read-locks at


 Also has foreach() support. I suggest this migrate into one of the


 libs rather than slumbering quietly within Mango.

We'll get that one into DTL, if you don't mind. :)



Aug 20 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"antiAlias" <fu bar.com> wrote in message
news:cg5i6n$l3k$1 digitaldaemon.com...
 That's the difference between the Java/C++ and D implementation. The

 tag the variable itself, while D tags the usage. I think the D approach to
 the "memory-barrier" thing is the 'correct' one, but it may lead to obtuse
 and hard-to-find bugs. For instance, you have to manually and carefully

 the volatile tag to each usage, rather than the compiler doing it for you
 (in the Java/C++ case). D, however, gives you more flexibility and control
 over how/where the barrier is applied. I think that's accurate ... someone
 please correct me if I'm wrong.

I think you've got it right.
Aug 20 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <cg5jfh$lr9$1 digitaldaemon.com>, Walter says...
"antiAlias" <fu bar.com> wrote in message
news:cg5i6n$l3k$1 digitaldaemon.com...
 That's the difference between the Java/C++ and D implementation. The

 tag the variable itself, while D tags the usage. I think the D approach to
 the "memory-barrier" thing is the 'correct' one, but it may lead to obtuse
 and hard-to-find bugs. For instance, you have to manually and carefully

 the volatile tag to each usage, rather than the compiler doing it for you
 (in the Java/C++ case). D, however, gives you more flexibility and control
 over how/where the barrier is applied. I think that's accurate ... someone
 please correct me if I'm wrong.

I think you've got it right.

It might be nice to also offer a way to separate acquire/release semantics for folks who care. I can't think of a clean way to do this offhand, but perhaps: volatile(acquire) volatile(release) Sean
Aug 20 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cg5ran$qvc$1 digitaldaemon.com...
 In article <cg5jfh$lr9$1 digitaldaemon.com>, Walter says...
"antiAlias" <fu bar.com> wrote in message
news:cg5i6n$l3k$1 digitaldaemon.com...
 That's the difference between the Java/C++ and D implementation. The

 tag the variable itself, while D tags the usage. I think the D approach to
 the "memory-barrier" thing is the 'correct' one, but it may lead to obtuse
 and hard-to-find bugs. For instance, you have to manually and carefully

 the volatile tag to each usage, rather than the compiler doing it for you
 (in the Java/C++ case). D, however, gives you more flexibility and control
 over how/where the barrier is applied. I think that's accurate ... someone
 please correct me if I'm wrong.

I think you've got it right.

It might be nice to also offer a way to separate acquire/release semantics for folks who care. I can't think of a clean way to do this offhand, but perhaps: volatile(acquire) volatile(release)

Can we do block volatile, as in: volatile { ... } Is that even meaningful?
Aug 20 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <cg5tje$sdr$3 digitaldaemon.com>, Matthew says...
"Sean Kelly" <sean f4.ca> wrote in message
news:cg5ran$qvc$1 digitaldaemon.com...
 In article <cg5jfh$lr9$1 digitaldaemon.com>, Walter says...
"antiAlias" <fu bar.com> wrote in message
news:cg5i6n$l3k$1 digitaldaemon.com...
 That's the difference between the Java/C++ and D implementation. The

 tag the variable itself, while D tags the usage. I think the D approach to
 the "memory-barrier" thing is the 'correct' one, but it may lead to obtuse
 and hard-to-find bugs. For instance, you have to manually and carefully

 the volatile tag to each usage, rather than the compiler doing it for you
 (in the Java/C++ case). D, however, gives you more flexibility and control
 over how/where the barrier is applied. I think that's accurate ... someone
 please correct me if I'm wrong.

I think you've got it right.

It might be nice to also offer a way to separate acquire/release semantics for folks who care. I can't think of a clean way to do this offhand, but perhaps: volatile(acquire) volatile(release)

Can we do block volatile, as in: volatile { ... } Is that even meaningful?

volatile is a statement specifier, so yes. Is it meaningful? I think it could be. Memory barriers are far cheaper than locks but they aren't free. I think a volatile block would basically put an acquire barrier at the beginning of the block and a release barrier at the end. This would basically say that "this block of code can not be reordered with respect to the surrounding code" though I think the code *within* the block could still be reordered. Perhaps this last bit is something Walter could answer? For the record, I *think* this is a correct implementation of the DCLP in D: # class Singleton # { # static Singleton s; # # Singleton instance() # { # volatile Singleton tmp = s; # if(!tmp) # { # synchronized # { # tmp = s; # if(!tmp) # { # volatile tmp = new Singleton(); # s = tmp; # } # } # } # return s; # } # } With the above, the block volatile might be useful if we wanted to do extra initialization of the singleton before assigning to s, thus replacing: # volatile tmp = new Singleton(); with: # volatile { # tmp = new Singleton(); # // do stuff # } Sean
Aug 20 2004
next sibling parent reply "antiAlias" <fu bar.com> writes:
You'll forgive me Sean, but the double-locking 'style' was driven out of
Java developers after it was shown to be mostly futile (I think it may have
been Doug Lea who demonstrated that). The recommended approach over there is
to construct singletons statically; which is where a 'static final'
assignment would be really useful in D:

static final Whatever singleton = new Whatever (...);

I know you've run into this need before. For those who don't know, the D
approach is thus:

static Whatever singleton;

static this()
{
    singleton = new Whatever (...);
}

Would be nice to have the former syntactic-sugar; but I imagine it would add
the same compiler complexity as static-constructors do, in terms of figuring
out the interdependencies across multiple related 'static final'
assignments.

Which leads to a question: how does the compiler deal with circular
dependencies across static-constructors? Let's try it out ...

class A
{
        static B b;

        static this()
        {
                printf ("A\n");
                b = new B;
        }
}

class B
{
        static A a;

        static this()
        {
                printf ("B\n");
                a = new A;
        }
}

Note that I wouldn't recommend this as a practice to anyone, but it may
occur accidentally where multiple modules are involved (I've done that with
Mango). No compile errors ~ emits:
A
B

In fact, the only obvious means to get the output in a different order is to
switch the class order within the file; that is, placing B above A yields:
B
A

Is there no dependency checking done for static constructors? Is this a bug?
Am I being particularly dense today?

n.b. the documentation for static constructors is apparently out-of-date.




"Sean Kelly" <sean f4.ca> wrote in message
news:cg5uva$t06$1 digitaldaemon.com...
 volatile is a statement specifier, so yes.  Is it meaningful?  I think it

 be.  Memory barriers are far cheaper than locks but they aren't free.  I

 volatile block would basically put an acquire barrier at the beginning of

 block and a release barrier at the end.  This would basically say that

 block of code can not be reordered with respect to the surrounding code"

 I think the code *within* the block could still be reordered.  Perhaps

 bit is something Walter could answer?

 For the record, I *think* this is a correct implementation of the DCLP in

 # class Singleton
 # {
 #     static Singleton s;
 #
 #     Singleton instance()
 #     {
 #         volatile Singleton tmp = s;
 #         if(!tmp)
 #         {
 #            synchronized
 #            {
 #                tmp = s;
 #                if(!tmp)
 #                {
 #                   volatile tmp = new Singleton();
 #                   s = tmp;
 #                }
 #            }
 #         }
 #         return s;
 #     }
 # }

 With the above, the block volatile might be useful if we wanted to do

 initialization of the singleton before assigning to s, thus replacing:

 # volatile tmp = new Singleton();

 with:

 # volatile {
 #    tmp = new Singleton();
 #    // do stuff
 # }


 Sean

Aug 20 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cg61nf$u96$1 digitaldaemon.com>, antiAlias says...
You'll forgive me Sean, but the double-locking 'style' was driven out of
Java developers after it was shown to be mostly futile (I think it may have
been Doug Lea who demonstrated that).

That's fine :) I mostly used it as an example beceause I had the Andrei and Scott's DDJ articles on it in front of me at the time.
The recommended approach over there is to construct singletons statically

Yup. And this would work in D just as well. Since apps all begin with only one thread, eager construction seems to make far more sense than the lazy method.
Which leads to a question: how does the compiler deal with circular
dependencies across static-constructors? Let's try it out ...

class A
{
        static B b;

        static this()
        {
                printf ("A\n");
                b = new B;
        }
}

class B
{
        static A a;

        static this()
        {
                printf ("B\n");
                a = new A;
        }
}

Note that I wouldn't recommend this as a practice to anyone, but it may
occur accidentally where multiple modules are involved (I've done that with
Mango). No compile errors ~ emits:
A
B

In fact, the only obvious means to get the output in a different order is to
switch the class order within the file; that is, placing B above A yields:
B
A

Is there no dependency checking done for static constructors? Is this a bug?
Am I being particularly dense today?

I was wondering about this. What if A and B were in separate modules? Sean
Aug 20 2004
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cg62jg$umv$1 digitaldaemon.com...
 I was wondering about this.  What if A and B were in separate modules?

You'll get an error about circular dependencies.
Aug 22 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"antiAlias" <fu bar.com> wrote in message
news:cg61nf$u96$1 digitaldaemon.com...
 You'll forgive me Sean, but the double-locking 'style' was driven out of
 Java developers after it was shown to be mostly futile (I think it may

 been Doug Lea who demonstrated that). The recommended approach over there

 to construct singletons statically; which is where a 'static final'
 assignment would be really useful in D:

 static final Whatever singleton = new Whatever (...);

 I know you've run into this need before. For those who don't know, the D
 approach is thus:

 static Whatever singleton;

 static this()
 {
     singleton = new Whatever (...);
 }

 Would be nice to have the former syntactic-sugar; but I imagine it would

 the same compiler complexity as static-constructors do, in terms of

 out the interdependencies across multiple related 'static final'
 assignments.

 Which leads to a question: how does the compiler deal with circular
 dependencies across static-constructors? Let's try it out ...

 class A
 {
         static B b;

         static this()
         {
                 printf ("A\n");
                 b = new B;
         }
 }

 class B
 {
         static A a;

         static this()
         {
                 printf ("B\n");
                 a = new A;
         }
 }

 Note that I wouldn't recommend this as a practice to anyone, but it may
 occur accidentally where multiple modules are involved (I've done that

 Mango). No compile errors ~ emits:
 A
 B

 In fact, the only obvious means to get the output in a different order is

 switch the class order within the file; that is, placing B above A yields:
 B
 A

 Is there no dependency checking done for static constructors? Is this a

 Am I being particularly dense today?

Static constructors are simply executed in the lexical order in which they appear.
Aug 22 2004
prev sibling parent reply Gold Dragon <dragonwing dragonu.net> writes:
 # volatile {
 #    tmp = new Singleton();
 #    // do stuff
 # }
 
 
 Sean
 
 

What type is tmp? Wouldn't you get a compiler error if you don't put the type or will the compiler automatically know like with um, well I can't think of an example.
Aug 20 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <cg6bs8$1325$1 digitaldaemon.com>, Gold Dragon says...
 # volatile {
 #    tmp = new Singleton();
 #    // do stuff
 # }
 
 
 Sean
 
 

What type is tmp? Wouldn't you get a compiler error if you don't put the type or will the compiler automatically know like with um, well I can't think of an example.

Its type is Singleton. tmp was delcared in the first line of the function as: volatile tmp = s; Sean
Aug 20 2004
parent Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:
 In article <cg6bs8$1325$1 digitaldaemon.com>, Gold Dragon says...
 
# volatile {
#    tmp = new Singleton();
#    // do stuff
# }


Sean

What type is tmp? Wouldn't you get a compiler error if you don't put the type or will the compiler automatically know like with um, well I can't think of an example.

Its type is Singleton. tmp was delcared in the first line of the function as: volatile tmp = s;

err... I meant: volatile Singleton tmp = s; Sean
Aug 21 2004
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"antiAlias" <fu bar.com> wrote in message news:cg5i6n$l3k$1 digitaldaemon.com...
 "Matthew"  wrote ...
 I don't think we're going to be able to keep it in the same format for

 the container implementations as consistent as possible, in terms of

 considerably.

 Obviously there'll be deeper changes as well, such as templatisation, and

 transformations/filters.

Sure ... edit with aplomb <g>

Thanks, though I suspect it'll be more rotten plum than aplomb, but I'll do my best.
 Question: what's the purpose of using "volatile" in various places. Since,

 memory coherence, and do not cross-thread contention, aren't these

 wisdom? (If so, send it to me quickly, via the secret T1!)

That's the difference between the Java/C++ and D implementation. The former tag the variable itself, while D tags the usage. I think the D approach to the "memory-barrier" thing is the 'correct' one, but it may lead to obtuse and hard-to-find bugs. For instance, you have to manually and carefully add the volatile tag to each usage, rather than the compiler doing it for you (in the Java/C++ case). D, however, gives you more flexibility and control over how/where the barrier is applied. I think that's accurate ... someone please correct me if I'm wrong.

 Matthew

 "antiAlias" <fu bar.com> wrote in message

 No problem. Just pull it out of the (browser enabled) dsource.org
 repository. The documentation needs a wee bit of attention :~)

 Let's share updates (on that module) until we get some resolution on how


 easily resolve multiple interdependent libraries ...


 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg42kq$2ubh$1 digitaldaemon.com...
 "antiAlias" <fu bar.com> wrote in message

 Walter" <newshound digitalmars.com> wrote in message
 2.0. BTW, are you following Andrei A's thread on adding lock-free

 containers to C++? It's a great read in comp.lang.c++.moderated





 the
 thread "Multithreaded programming: is the C++ standardization



 listening?"

About time too! On that note, mango.cache has a port of Doug Lea's latest-and-greatest concurrent HashMap. Nice,clean, concise bit of




 configurable (contention-level) and very efficient: no read-locks at


 Also has foreach() support. I suggest this migrate into one of the


 libs rather than slumbering quietly within Mango.

We'll get that one into DTL, if you don't mind. :)




Aug 20 2004
prev sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
 2.0. BTW, are you following Andrei A's thread on adding lock-free
 concurrent containers to C++? It's a great read in comp.lang.c++.moderated
 under the thread "Multithreaded programming: is the C++ standardization
 committee listening?"

Interesting. That 64-bit CAS posting I made on digitalmars.D.bugs was in support of implementing two very cool concurrent data structures "dualqueue": http://www.cs.rochester.edu/~scott/papers/2004_DISC_dual_DS.pdf "obstruction-free circular array": http://www.cs.brown.edu/people/mph/HerlihyLM03/main.pdf coming to MinTL soon...
Aug 20 2004
parent reply pragma <EricAnderton at yahoo dot com> <pragma_member pathlink.com> writes:
In article <cg4qog$8oe$1 digitaldaemon.com>, Ben Hinkle says...
 2.0. BTW, are you following Andrei A's thread on adding lock-free
 concurrent containers to C++? It's a great read in comp.lang.c++.moderated
 under the thread "Multithreaded programming: is the C++ standardization
 committee listening?"

Interesting. That 64-bit CAS posting I made on digitalmars.D.bugs was in support of implementing two very cool concurrent data structures "dualqueue": http://www.cs.rochester.edu/~scott/papers/2004_DISC_dual_DS.pdf "obstruction-free circular array": http://www.cs.brown.edu/people/mph/HerlihyLM03/main.pdf coming to MinTL soon...

Neat stuff Ben. Here's something that'll help if you haven't done this already. (All apologies if you're already this up-to-speed with assembler) :) I read through both these papers, and all I could think was: boy does this algorithm "cheat"! It accomplishes lockless syncronization by exploiting the Compare-and-Swap atomic instruction that is present on Sparc workstations. That's great and all, but what about us guys on x86?!? Well, I did some sniffng around and dug up the "cmpxchg" ASM instruction. http://members.tripod.com/~oldboard/assembly/cmpxchg.html A concrete use of the instruction (see "compare_and_swap" function): http://www.cs.cornell.edu/courses/cs414/2001SP/minithread_md.c This should make your implementation a little easier to write. - Pragma
Aug 20 2004
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"pragma" <EricAnderton at yahoo dot compragma_member pathlink.com> wrote in
message news:cg5dhk$i4c$1 digitaldaemon.com...
 In article <cg4qog$8oe$1 digitaldaemon.com>, Ben Hinkle says...
 2.0. BTW, are you following Andrei A's thread on adding lock-free
 concurrent containers to C++? It's a great read in



 under the thread "Multithreaded programming: is the C++ standardization
 committee listening?"

Interesting. That 64-bit CAS posting I made on digitalmars.D.bugs was in support of implementing two very cool concurrent data structures "dualqueue": http://www.cs.rochester.edu/~scott/papers/2004_DISC_dual_DS.pdf "obstruction-free circular array": http://www.cs.brown.edu/people/mph/HerlihyLM03/main.pdf coming to MinTL soon...

Neat stuff Ben. Here's something that'll help if you haven't done this

 (All apologies if you're already this up-to-speed with assembler) :)

 I read through both these papers, and all I could think was: boy does this
 algorithm "cheat"!  It accomplishes lockless syncronization by exploiting

 Compare-and-Swap atomic instruction that is present on Sparc workstations.

 That's great and all, but what about us guys on x86?!?  Well, I did some

 around and dug up the "cmpxchg" ASM instruction.

 http://members.tripod.com/~oldboard/assembly/cmpxchg.html

 A concrete use of the instruction (see "compare_and_swap" function):
 http://www.cs.cornell.edu/courses/cs414/2001SP/minithread_md.c

 This should make your implementation a little easier to write.

 - Pragma

Yeah - it seems like the two work-horses of the latest concurrent research are cmpxchg and cmpxchg8b (or whatever the equivalent is on a particular processor). There are some pretty nasty hacks around memory management, though, in one of those papers. It maintains a thread-specific heap by aligning the bottom of the stack and whacking off the bottom bits of the stack pointer whenever it needs to start looking for a free node. Talk about cheating!
Aug 20 2004
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Walter wrote:
 Lots more bug fixes. Added special 'length' inside array [ ]'s.
 
 http://www.digitalmars.com/d/changelog.html
 
 

Walter, have you got std.loader compiled into phobos on linux?
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"clayasaurus" <clayasaurus gmail.com> wrote in message
news:cg3vc7$2t8d$1 digitaldaemon.com...
 Walter wrote:
 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html

Walter, have you got std.loader compiled into phobos on linux?

Good question. btw, I'm going to bite the bullet next week and revisit std.loader. I don't know whether I can resurrect it from its current ignominy, or whether a total reimplementation (keeping interface, of course, if at all poss) will be called for. I do know that it's had lots of complaints and that, even though it was born out of wedlock, I still need to take my responsibilities seriously. Colin the Code Cassanova
Aug 19 2004
next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Matthew wrote:
 "clayasaurus" <clayasaurus gmail.com> wrote in message
news:cg3vc7$2t8d$1 digitaldaemon.com...
 
Walter wrote:

Lots more bug fixes. Added special 'length' inside array [ ]'s.

http://www.digitalmars.com/d/changelog.html

Walter, have you got std.loader compiled into phobos on linux?

Good question. btw, I'm going to bite the bullet next week and revisit std.loader. I don't know whether I can resurrect it from its current ignominy, or whether a total reimplementation (keeping interface, of course, if at all poss) will be called for. I do know that it's had lots of complaints and that, even though it was born out of wedlock, I still need to take my responsibilities seriously. Colin the Code Cassanova

Hey Matthew I think std.loader is a nice piece of code and was complaining about it because I didn't know about -ldl. Oh yes and having it be compiled into phobos on linux would be nice too. *cheers*
Aug 20 2004
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Matthew wrote:
 "clayasaurus" <clayasaurus gmail.com> wrote in message
news:cg3vc7$2t8d$1 digitaldaemon.com...
 
Walter wrote:

Lots more bug fixes. Added special 'length' inside array [ ]'s.

http://www.digitalmars.com/d/changelog.html

Walter, have you got std.loader compiled into phobos on linux?

Good question. btw, I'm going to bite the bullet next week and revisit std.loader. I don't know whether I can resurrect it from its current ignominy, or whether a total reimplementation (keeping interface, of course, if at all poss) will be called for. I do know that it's had lots of complaints and that, even though it was born out of wedlock, I still need to take my responsibilities seriously. Colin the Code Cassanova

I just checked and loader.o is still missing from libphobos.a on linux. Surely it would only take a few seconds of Walter's time to add it? Just change version(Linux) to version(linux).
Aug 20 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"clayasaurus" <clayasaurus gmail.com> wrote in message
news:cg4t06$9ns$2 digitaldaemon.com...
 Matthew wrote:
 "clayasaurus" <clayasaurus gmail.com> wrote in message
news:cg3vc7$2t8d$1 digitaldaemon.com...

Walter wrote:

Lots more bug fixes. Added special 'length' inside array [ ]'s.

http://www.digitalmars.com/d/changelog.html

Walter, have you got std.loader compiled into phobos on linux?

Good question. btw, I'm going to bite the bullet next week and revisit std.loader. I don't know whether I can resurrect it from its current ignominy, or whether a total reimplementation (keeping interface, of course, if at all poss) will be called


 I do know that it's had lots of complaints and that, even though it was born
out of wedlock, I still need to take my
 responsibilities seriously.

 Colin the Code Cassanova

I just checked and loader.o is still missing from libphobos.a on linux. Surely it would only take a few seconds of Walter's time to add it? Just change version(Linux) to version(linux).

Indeed. Let's hope he does so. :-)
Aug 20 2004
prev sibling next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
Added special 'length' inside array [ ]'s.

Yay!
Aug 20 2004
prev sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <cg3n60$2oap$1 digitaldaemon.com>, Walter says...
Lots more bug fixes. Added special 'length' inside array [ ]'s.

http://www.digitalmars.com/d/changelog.html

Walter: Thxs a lot for adding in the ifind() and irfind() functions into the std.string...I'll be putting them to good use! :)) Also, will you be adding in the ireplace() and icount() as well? I wrote them up and put them in a link just below ifind() functions back in mid-june, I'm not sure if you want me to resubmit them or not. ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Aug 20 2004