Re: The Thermopylae excerpt of TDPL available online
Andrei Alexandrescu wrote
> Saaa wrote:
>> Andrei Alexandrescu wrote:
>>> Andrei Alexandrescu wrote:
Saaa wrote:
> Could anybody clear these up for me?
>
>> p16. Is there anything other than the random values, unsafe about
>> void assignment?
I'd put your feedback on my pile of things to do, but now that you ask,
I made this change to the incriminated paragraph:
===
Such uninitialized arrays are particularly useful for large arrays
that serve as temporary buffers. An uninitialized integral may not
cause too much harm, but uninitialized values of types with
indirections (such as arrays themselves) are unsafe.
===
>> p18. What is unsafe about implicit conversion of static to dynamic
>> array?
>>Meaning getting a dynamic array pointing to a stack allocated
>> array.
>>Any operation changing its size could copy the array to the
>> heap. What am I missing
T[] fun() { T[10] a; return a; }
...
auto x = fun(); // gained access to recycled stack memory
There's no change in size there.
>> p20. 10 int take up 40 words?
The example given has a per-row payload of 10 ints, i.e. 40 words.
>>> It's bytes actually. So finally I rewrote those last words as:
>>>
>>> "... small per-row payload of~10 @i...@s (40 bytes)."
>>>
>>>
>>> Andrei
>>
>> Thanks !
>>
>> Out of interest, do you keep a list of common error or something alike
>> that helps you keep errors at a minimum?
>
> I got as sophisticated as having an email folder dedicated to TDPL.
>
>> Also, do you have automated example checking?
>
> Yes. If you look at the document very closely, you'll see that some
> snippets have a thin line above and below them. Those are automatically
> checked every time I save the document. (There are 1-2 examples that
> aren't checked in the Thermopylae excerpt because I switched editing to a
> 64-bit machine that can't build D programs (I'll post a question later
> today). But in the meantime I fixed those.)
>
> Very short snippets do not have a thin line above and below them. Those
> are not checked because they are short enough to warrant that I know what
> I'm doing.
:)
>
> Some checked snippets wouldn't compile without being in a function, for
> example:
>
> enum size_t columns = 128;
> // Allocate a matrix with 64 rows and 128 columns
> auto matrix = new double[columns][64];
> // No need to allocate each row - they already exist in-situ
> foreach (ref row; matrix) {
>... // use row of type double[columns]
> }
>
> These are automatically entered inside a unittest. Also, my code
> extraction script (written in D!) automatically eliminates unneeded
I Wouldn't accept it being written in C++ !! :D
> "...", so the code as seen by the compiler is:
>
> unittest {
> enum size_t columns = 128;
> // Allocate a matrix with 64 rows and 128 columns
> auto matrix = new double[columns][64];
> // No need to allocate each row - they already exist in-situ
> foreach (ref row; matrix) {
> // use row of type double[columns]
> }
> }
>
> which passes compilation.
>
> Some other examples need "invisible" support:
>
> writeln("hey");
>
> For those I have a special mechanism to insert invisible code, so my text
> for the above actually looks like this:
>
> \begin{D-invisible}
> import std.stdio;
> \end{D-invisible}
> \begin{D-snippet}
> writeln("hey");
> \end{D-snippet}
>
> What the compiler sees is a file importing std.stdio and including the
> writeln inside a unittest.
nice
>
> I wouldn't know how to pull this off reasonably with e.g. Word, but I'm
> sure it now has mechanisms or extensions that allow that kind of thing.
> One thing I don't need to worry about with LaTeX is that it's text-based
> so I can process it easily myself.
Somehow I only associate LaTeX with b/w scientific articles :)
>
>> Or, more general, I would be interested in a small article explaining how
>> a book like this is written.
>>
>> Maybe After the book is finished :)
>
> I think the topic is well worth an article indeed. I continuously
> streamline the process of building the book, and it's gotten pretty
> sophisticated but very helpful as well. Index building is also an
> interesting subtopic.
>
>
> Andrei
Thanks, looking forward to the article ( and the tools used :P )
Re: The Thermopylae excerpt of TDPL available online
"Robert Clipsham" wrote in message
news:hcg0qr$fc...@digitalmars.com...
> Don wrote:
>> I'm starting to think we need a
>>> separate namespace for the CT stuff.
>>>
>>> D.compiles(XXX)
>>> D.typeof(foo)
>>> D.stringof(T)
>>> D.allMembers(T)
>>
>> That's not bad. Can't be 'D', though, has to look like a keyword. Maybe
>> something like 'traits' instead. In exchange, get rid of the '__traits'
>> and 'typeid' keywords. Not sure about typeof, though.
>>
>> traits.compiles(XXX)
>> traits.typeid(TTT)
>> traits.stringof(T)
>> traits.allMembers(T)
>> traits.error("message");
>>
>> IMHO this looks better than __traits(compiles, XXX) but it actually has
>> the same flexibility, and it's a straightforward transformation inside
>> the compiler.
>> For bonus points, allow 'with(traits)':
>>
>> with(traits) {
>> if (compiles(XXX)) return stringof(T);
>> else error("Can't use " ~ stringof(T) ~ " in a transmogrifier.");
>> }
>>
>
> This could even be implemented in phobos (or object.d to avoid an import
> when you want to use it), using something like:
>
> pragma(traits) struct traits
> {
> // Members automatically added by the compiler, or maybe just their
> // declarations eg:
> static T delegate()[] allMembers(T)(T type);
> }
>
> This way there's no need to force a certain name, as it can be chosen by
> the developer (by either using renaming imports or just giving the struct
> a different name eg pragma(traits) struct meta {}).
I'm not sure I see the value in being able to rename that. That's like
making sure people can rename "for".
Re: TDPL reaches Thermopylae level
Justin Johansson wrote: Andrei Alexandrescu Wrote: Lars T. Kyllingstad wrote: Nick Sabalausky wrote: "Chris Nicholson-Sauls" wrote in message news:hcctuf$140...@digitalmars.com... Granted LTR is common enough to be expectable and acceptable. To be perfectly honest, I don't believe I have *ever* even used wchar/wstring. Char/string gosh yes; dchar/dstring quite a bit as well, where I need the simplicity; but I've yet to feel much need for the "weirdo" middle child of UTF. Given that just about anything outside of D (at least as far as I've seen) that attempts to use unicode does so with UTF-16 (or just uses UCS-2 and pretends that's UTF-16...), wchar and wstring are great for dealing with that. For instance, my Goldie engine for GOLD currently uses wchar in a number of places because GOLD's .cfg format stores text in...well, presumably UTF-16 (I haven't tested to see if it's really UCS-2). But yea, as long as you're not dealing with anything that's already in UTF-16 or that expects it, then it does seem to be somewhat questionable. I think this says it all: http://en.wikipedia.org/wiki/Utf-16#Use_in_major_operating_systems_and_environments -Lars :) Yep, there was a frenzy when UCS-2 came about: everybody thought two bytes will be enough for everyone. So UCS-2 was widely adopted - who wouldn't love to have constant character width? Then, the UTF-16 surrogate business came about, and the only logical step they could take was to migrate to UTF-16, which was upward compatible to UCS-2. I personally think UTF-8 is a better overall design though. Andrei "I personally think UTF-8 is a better overall design though." Unicode Technical Note #12 by The Unicode Consortium apparently disagree, recommending UTF-16 for Processing. http://unicode.org/notes/tn12/ The major claim in the TN is that Unicode is optimized for UTF-16. The rest of the argument looks like a VHS (everyone is using it i.e. UTF-16) versus Beta argument. So who's right? My personal view is that whilst they are the *Unicode Consortium*, I have great difficulty in accepting UTF-16 as the one-and-holy encoding. FWIW, there was a subthread during a discussion about the ordained features of programming languages on LtU a while back. http://lambda-the-ultimate.org/node/3166#comment-46233 What Are The Resolved Debates in General Purpose Language Design? Its a long discussion so easier to search for UTF or Unicode on the page if you're interested. cheers Justin Johansson Thanks for the pointers. One of the reasons for which I like the design of UTF-8 is its generality: it's a variable-length code for any number of 31 bits. In contrast, UTF-16 is a relies on specific dead zones inside the assigned space. But the authors of the unicode.org article do make a few good points, such as there not being any invalid UTF-16 symbol. But then that actually can be seen as a strength of UTF-8 - the binary files that are actually UTF-8 files are statistically so scarce, UTF-8 has a very solid method of checking whether a file is UTF-8 or something else. Andrei
Re: Success! (Precisely)
"dsimcha" wrote in message news:hcfur2$av...@digitalmars.com... == Quote from Craig Black (craigbla...@cox.net)'s article Does the GC have knowledge of pointers on both the stack as well as the heap? Also, probably most of the problem with false pointers is on the heap anyhow. The stack is usually on the order of a few 10s of kilobytes, the static data segment maybe another few 10s of kilobytes, whereas the heap can be hundreds of megabytes. I think that, given how little progress has been made on improving the current GC implementation and how hard a problem it is, adding precise heap scanning to the current GC is a good 80/20 solution until D becomes popular enough to earn hordes of money for research into improving its GC. Yeah, that would be great. Maybe some day. One step at a time I suppose. -Craig
Re: Success! (Precisely)
"dsimcha" wrote in message news:hcfu9t$9d...@digitalmars.com... == Quote from Craig Black (craigbla...@cox.net)'s article "dsimcha" wrote in message news:hcdsbq$4i...@digitalmars.com... > After a few evenings of serious hacking, I've integrated precise heap > scanning > into the GC. Awesome! Thank you so much for doing this. Does the GC have knowledge of pointers on both the stack as well as the heap? No. Precise stack and static data segment scanning would be an order of magnitude harder to implement because it would require going deep into compiler hacking. Precise heap scanning, to the extent that I can get the mask information to the GC somehow, can be implemented by just hacking the runtime. > 3. new only takes RTTI. It is not a template. Unless RTTI gets > bitmasks > in > the format I created (which I'll document once I clean things up and > release, > but has only deviated slightly from what I had talked about here), > stuff > allocated using it won't be able to take advantage of precise heap > scanning. > The default bitmask, if none is provided, uses good (bad) old-fashioned > conservative scanning unless the entire block has no pointers, in which > case > it isn't scanned. This means that we have all the more incentive to > replace > new with a template of some kind. I'm surprised nobody commented on this. Andrei said Walter decided that new shouldn't be a template. But it seems like a good idea to me. Templated new has received positive feedback from the community, and here is another advantage of templated new. -Craig What's the rationale for not templating new? IMHO it makes a lot of sense b/c then you have access to all the compile time features of the language while new'ing stuff, such as the ability to generate bitmasks. You would have to ask Walter. The only downside I see is the extra exclaimation point, but perhaps he has another reason. -Craig
Getting class member offsets at compile time
Is there any **good** way to iterate over the members fields of a class at
compile time via templates or CTFE? With structs you can do:
void someCtfeFunction(Struct)() {
foreach(tupleIndex, elem; Struct.init.tupleof) {
// Do stuff.
}
}
This doesn't work for classes because using .tupleof requires an instance, and
classes, being reference types that require heap allocations and stuff, can't
be initialized in CTFE or templates. In my case, I'm trying to introspect the
offsets of the fields, so I don't actually need an instance.
The way I found was:
1. Get all members using __traits(allMembers, SomeClass) This returns an
array of strings.
2. Iterate over these strings in a CTFE function and generate a bunch of code
for each one. Build a string to mix in. Put static if statements into this
string to bypass functions and other stuff that's not a field.
3. Call the CTFE function. Mix in the huge amount of code it generates.
Curse when builds for anything non-trivial require more memory than you have
address space.
Please tell me there's a better solution that I somehow didn't think of.
Re: The Thermopylae excerpt of TDPL available online
Don wrote:
I'm starting to think we need a
separate namespace for the CT stuff.
D.compiles(XXX)
D.typeof(foo)
D.stringof(T)
D.allMembers(T)
That's not bad. Can't be 'D', though, has to look like a keyword. Maybe
something like 'traits' instead. In exchange, get rid of the '__traits'
and 'typeid' keywords. Not sure about typeof, though.
traits.compiles(XXX)
traits.typeid(TTT)
traits.stringof(T)
traits.allMembers(T)
traits.error("message");
IMHO this looks better than __traits(compiles, XXX) but it actually has
the same flexibility, and it's a straightforward transformation inside
the compiler.
For bonus points, allow 'with(traits)':
with(traits) {
if (compiles(XXX)) return stringof(T);
else error("Can't use " ~ stringof(T) ~ " in a transmogrifier.");
}
This could even be implemented in phobos (or object.d to avoid an import
when you want to use it), using something like:
pragma(traits) struct traits
{
// Members automatically added by the compiler, or maybe just their
// declarations eg:
static T delegate()[] allMembers(T)(T type);
}
This way there's no need to force a certain name, as it can be chosen by
the developer (by either using renaming imports or just giving the
struct a different name eg pragma(traits) struct meta {}).
Re: Success! (Precisely)
== Quote from Craig Black (craigbla...@cox.net)'s article Does the GC have knowledge of > pointers on both the stack as well as the heap? Also, probably most of the problem with false pointers is on the heap anyhow. The stack is usually on the order of a few 10s of kilobytes, the static data segment maybe another few 10s of kilobytes, whereas the heap can be hundreds of megabytes. I think that, given how little progress has been made on improving the current GC implementation and how hard a problem it is, adding precise heap scanning to the current GC is a good 80/20 solution until D becomes popular enough to earn hordes of money for research into improving its GC.
Re: Success! (Precisely)
== Quote from Craig Black (craigbla...@cox.net)'s article > "dsimcha" wrote in message > news:hcdsbq$4i...@digitalmars.com... > > After a few evenings of serious hacking, I've integrated precise heap > > scanning > > into the GC. > Awesome! Thank you so much for doing this. Does the GC have knowledge of > pointers on both the stack as well as the heap? No. Precise stack and static data segment scanning would be an order of magnitude harder to implement because it would require going deep into compiler hacking. Precise heap scanning, to the extent that I can get the mask information to the GC somehow, can be implemented by just hacking the runtime. > > 3. new only takes RTTI. It is not a template. Unless RTTI gets bitmasks > > in > > the format I created (which I'll document once I clean things up and > > release, > > but has only deviated slightly from what I had talked about here), stuff > > allocated using it won't be able to take advantage of precise heap > > scanning. > > The default bitmask, if none is provided, uses good (bad) old-fashioned > > conservative scanning unless the entire block has no pointers, in which > > case > > it isn't scanned. This means that we have all the more incentive to > > replace > > new with a template of some kind. > I'm surprised nobody commented on this. Andrei said Walter decided that new > shouldn't be a template. But it seems like a good idea to me. Templated > new has received positive feedback from the community, and here is another > advantage of templated new. > -Craig What's the rationale for not templating new? IMHO it makes a lot of sense b/c then you have access to all the compile time features of the language while new'ing stuff, such as the ability to generate bitmasks.
Re: Success! (Precisely)
"dsimcha" wrote in message news:hcdsbq$4i...@digitalmars.com... After a few evenings of serious hacking, I've integrated precise heap scanning into the GC. Awesome! Thank you so much for doing this. Does the GC have knowledge of pointers on both the stack as well as the heap? 3. new only takes RTTI. It is not a template. Unless RTTI gets bitmasks in the format I created (which I'll document once I clean things up and release, but has only deviated slightly from what I had talked about here), stuff allocated using it won't be able to take advantage of precise heap scanning. The default bitmask, if none is provided, uses good (bad) old-fashioned conservative scanning unless the entire block has no pointers, in which case it isn't scanned. This means that we have all the more incentive to replace new with a template of some kind. I'm surprised nobody commented on this. Andrei said Walter decided that new shouldn't be a template. But it seems like a good idea to me. Templated new has received positive feedback from the community, and here is another advantage of templated new. -Craig
Re: Success! (Precisely)
Denis Koroskin Wrote: > On Fri, 30 Oct 2009 08:08:10 +0300, dsimcha wrote: > > > After a few evenings of serious hacking, I've integrated precise heap > > scanning > > into the GC. Right now, I still need to test it better and debug it, > > but it > > at least basically works. I also still need to write the templates to > > generate bit masks at compile time, but this is a simple matter of > > programming. > > > > A few things: > > > > 1. Who knows how to write some good stress tests to make sure this > > works? > > > > 2. I'm thinking about how to write the bitmask templates. In the next > > release of DMD, when static arrays are value types and returnable from > > functions, will they be returnable from functions in CTFE? > > > > 3. new only takes RTTI. It is not a template. Unless RTTI gets > > bitmasks in > > the format I created (which I'll document once I clean things up and > > release, > > but has only deviated slightly from what I had talked about here), stuff > > allocated using it won't be able to take advantage of precise heap > > scanning. > > The default bitmask, if none is provided, uses good (bad) old-fashioned > > conservative scanning unless the entire block has no pointers, in which > > case > > it isn't scanned. This means that we have all the more incentive to > > replace > > new with a template of some kind. > > > > 4. I solved the static array problem, but the solution required using > > up one > > of the high-order bits. We have at least one more to play with in my > > bitmask > > scheme, because I'm storing things by word offsets, not byte offsets, > > since > > the GC isn't supposed to work with misaligned pointers anyhow. This > > leaves > > one more bit before we start limiting T.sizeof to less than full address > > space > > (on 32-bit, where a word is 4 bytes). I think it needs to be reserved > > for > > pinning, in case a copying collector ever gets implemented. If we're > > willing > > to not let any precisely scanned object have a T.sizeof of more than > > half the > > address space (a ridiculously minor limitation; this does not limit the > > size > > of arrays, only the size of classes and the elements of an array), we > > could > > throw in a third bit for weak references. > > Blaze (http://www.dsource.org/projects/blaze) is often suggested for > stress-testing the GC. Probably, because it does huge amount of dynamic > allocations, while total amount of memory consumed is about the same. > Worth a note, it's for D1/Tango, but you said you were going to port it to > Tango, too, so it may be better to start with Tango (because there are a > lot more code written against Tango and you get instant user feedback) and > then port it to druntime. If not a performance test, it may be a good > correctness test (so that you don't collect memory which is still > referenced). Blaze is for D1, yes, but it's not only for Tango - I made the initial port for Phobos, and the author decided to keep it (all further changes were Phobos-compatiable). It's been available for both Tango and Phobos for a long while now.
Re: TDPL reaches Thermopylae level
Andrei Alexandrescu Wrote: > Lars T. Kyllingstad wrote: > > Nick Sabalausky wrote: > >> "Chris Nicholson-Sauls" wrote in message > >> news:hcctuf$140...@digitalmars.com... > >>> Granted LTR is common enough to be expectable and acceptable. To be > >>> perfectly honest, I don't believe I have *ever* even used > >>> wchar/wstring. Char/string gosh yes; dchar/dstring quite a bit as > >>> well, where I need the simplicity; but I've yet to feel much need for > >>> the "weirdo" middle child of UTF. > >>> > >> > >> Given that just about anything outside of D (at least as far as I've > >> seen) that attempts to use unicode does so with UTF-16 (or just uses > >> UCS-2 and pretends that's UTF-16...), wchar and wstring are great for > >> dealing with that. For instance, my Goldie engine for GOLD currently > >> uses wchar in a number of places because GOLD's .cfg format stores > >> text in...well, presumably UTF-16 (I haven't tested to see if it's > >> really UCS-2). But yea, as long as you're not dealing with anything > >> that's already in UTF-16 or that expects it, then it does seem to be > >> somewhat questionable. > > > > I think this says it all: > > > > http://en.wikipedia.org/wiki/Utf-16#Use_in_major_operating_systems_and_environments > > > > > > > > -Lars :) > > Yep, there was a frenzy when UCS-2 came about: everybody thought two > bytes will be enough for everyone. So UCS-2 was widely adopted - who > wouldn't love to have constant character width? Then, the UTF-16 > surrogate business came about, and the only logical step they could take > was to migrate to UTF-16, which was upward compatible to UCS-2. I > personally think UTF-8 is a better overall design though. > > Andrei "I personally think UTF-8 is a better overall design though." Unicode Technical Note #12 by The Unicode Consortium apparently disagree, recommending UTF-16 for Processing. http://unicode.org/notes/tn12/ The major claim in the TN is that Unicode is optimized for UTF-16. The rest of the argument looks like a VHS (everyone is using it i.e. UTF-16) versus Beta argument. So who's right? My personal view is that whilst they are the *Unicode Consortium*, I have great difficulty in accepting UTF-16 as the one-and-holy encoding. FWIW, there was a subthread during a discussion about the ordained features of programming languages on LtU a while back. http://lambda-the-ultimate.org/node/3166#comment-46233 What Are The Resolved Debates in General Purpose Language Design? Its a long discussion so easier to search for UTF or Unicode on the page if you're interested. cheers Justin Johansson
Re: Success! (Precisely)
On 10/30/09 14:29, dsimcha wrote: == Quote from Jacob Carlborg (d...@me.com)'s article On 10/30/09 06:08, dsimcha wrote: After a few evenings of serious hacking, I've integrated precise heap scanning into the GC. Right now, I still need to test it better and debug it, but it at least basically works. I also still need to write the templates to generate bit masks at compile time, but this is a simple matter of programming. A few things: 1. Who knows how to write some good stress tests to make sure this works? 2. I'm thinking about how to write the bitmask templates. In the next release of DMD, when static arrays are value types and returnable from functions, will they be returnable from functions in CTFE? 3. new only takes RTTI. It is not a template. Unless RTTI gets bitmasks in the format I created (which I'll document once I clean things up and release, but has only deviated slightly from what I had talked about here), stuff allocated using it won't be able to take advantage of precise heap scanning. The default bitmask, if none is provided, uses good (bad) old-fashioned conservative scanning unless the entire block has no pointers, in which case it isn't scanned. This means that we have all the more incentive to replace new with a template of some kind. 4. I solved the static array problem, but the solution required using up one of the high-order bits. We have at least one more to play with in my bitmask scheme, because I'm storing things by word offsets, not byte offsets, since the GC isn't supposed to work with misaligned pointers anyhow. This leaves one more bit before we start limiting T.sizeof to less than full address space (on 32-bit, where a word is 4 bytes). I think it needs to be reserved for pinning, in case a copying collector ever gets implemented. If we're willing to not let any precisely scanned object have a T.sizeof of more than half the address space (a ridiculously minor limitation; this does not limit the size of arrays, only the size of classes and the elements of an array), we could throw in a third bit for weak references. Would this be possible to use with D1 ? The precise heap scanning would probably work, if the bit masks were generated manually, but I don't know if D1's templates are powerful enough to generate them. I had D2 in mind as a target, but I'll document the format once everything's cleaned up, tested, etc. and if someone wants to try to make it work on D1, they can. The only thing, though, is that D1 is supposed to be stable, and adding bit masks as an argument o GC.malloc might not fly. Then again, it would only be a lib change, probably in Tango. Furthermore, I made old-fashioned conservative scanning the default (a bit mask called conservativeBitMask is stored in the static data segment and is the default argument to GC.malloc) specifically to avoid breaking any compatibility at the source level. Ok, well I didn't think phobos would change so I was think about the possibility to add this to tango. It seems it's mostly a runtime thing but I may be wrong.
Re: The Thermopylae excerpt of TDPL available online
Don Wrote: > Leandro Lucarella wrote: > > Justin Johansson, el 30 de octubre a las 08:42 me escribiste: > >>> Actually, I think I like that better than 'traits'. > >>> > >>> -Lars > >> I'm in agreement with whoever suggested 'meta' or just about anything else > >> except 'traits'. > >> 'meta', whilst perhaps an overloaded keyword, is still much more > >> user-friendly. Whenever > >> I see 'traits' I get the feeling I need a Ph.D. to understand what it's > >> about. For some reason, > >> I don't know why, 'meta' has an aire of karma about it. > > > > "compiler"? That could open the door to other types of access to compiler > > internals, AST, etc. > > Yup. I think the 'magic namespace' approach is a simple, clean way to > incorporate reflection. It could be like Object and TypeInfo, implicitly > available in every module and tightly coupled to the compiler, but can > be viewed by the user as if it were just a module. It'd be particularly > interesting if some of the functions _were_ actually implemented in > library code, when possible. What about going one step further? You could require an import statement to use traits. For example, import traits=std.traits could reproduce your earlier suggestion, but gives added flexibility to the programmer. It also eliminates a keyword.
Re: The Thermopylae excerpt of TDPL available online
Saaa wrote:
Andrei Alexandrescu wrote:
Andrei Alexandrescu wrote:
Saaa wrote:
Could anybody clear these up for me?
p16. Is there anything other than the random values, unsafe about void
assignment?
I'd put your feedback on my pile of things to do, but now that you ask, I
made this change to the incriminated paragraph:
===
Such uninitialized arrays are particularly useful for large arrays
that serve as temporary buffers. An uninitialized integral may not
cause too much harm, but uninitialized values of types with
indirections (such as arrays themselves) are unsafe.
===
p18. What is unsafe about implicit conversion of static to dynamic
array?
Meaning getting a dynamic array pointing to a stack allocated
array.
Any operation changing its size could copy the array to the
heap. What am I missing
T[] fun() { T[10] a; return a; }
...
auto x = fun(); // gained access to recycled stack memory
There's no change in size there.
p20. 10 int take up 40 words?
The example given has a per-row payload of 10 ints, i.e. 40 words.
It's bytes actually. So finally I rewrote those last words as:
"... small per-row payload of~10 @i...@s (40 bytes)."
Andrei
Thanks !
Out of interest, do you keep a list of common error or something alike that
helps you keep errors at a minimum?
I got as sophisticated as having an email folder dedicated to TDPL.
Also, do you have automated example checking?
Yes. If you look at the document very closely, you'll see that some
snippets have a thin line above and below them. Those are automatically
checked every time I save the document. (There are 1-2 examples that
aren't checked in the Thermopylae excerpt because I switched editing to
a 64-bit machine that can't build D programs (I'll post a question later
today). But in the meantime I fixed those.)
Very short snippets do not have a thin line above and below them. Those
are not checked because they are short enough to warrant that I know
what I'm doing.
Some checked snippets wouldn't compile without being in a function, for
example:
enum size_t columns = 128;
// Allocate a matrix with 64 rows and 128 columns
auto matrix = new double[columns][64];
// No need to allocate each row - they already exist in-situ
foreach (ref row; matrix) {
... // use row of type double[columns]
}
These are automatically entered inside a unittest. Also, my code
extraction script (written in D!) automatically eliminates unneeded
"...", so the code as seen by the compiler is:
unittest {
enum size_t columns = 128;
// Allocate a matrix with 64 rows and 128 columns
auto matrix = new double[columns][64];
// No need to allocate each row - they already exist in-situ
foreach (ref row; matrix) {
// use row of type double[columns]
}
}
which passes compilation.
Some other examples need "invisible" support:
writeln("hey");
For those I have a special mechanism to insert invisible code, so my
text for the above actually looks like this:
\begin{D-invisible}
import std.stdio;
\end{D-invisible}
\begin{D-snippet}
writeln("hey");
\end{D-snippet}
What the compiler sees is a file importing std.stdio and including the
writeln inside a unittest.
I wouldn't know how to pull this off reasonably with e.g. Word, but I'm
sure it now has mechanisms or extensions that allow that kind of thing.
One thing I don't need to worry about with LaTeX is that it's text-based
so I can process it easily myself.
Or, more general, I would be interested in a small article explaining how a
book like this is written.
Maybe After the book is finished :)
I think the topic is well worth an article indeed. I continuously
streamline the process of building the book, and it's gotten pretty
sophisticated but very helpful as well. Index building is also an
interesting subtopic.
Andrei
Re: The Thermopylae excerpt of TDPL available online
Andrei Alexandrescu wrote:
> Andrei Alexandrescu wrote:
>> Saaa wrote:
>>> Could anybody clear these up for me?
>>>
p16. Is there anything other than the random values, unsafe about void
assignment?
>>
>> I'd put your feedback on my pile of things to do, but now that you ask, I
>> made this change to the incriminated paragraph:
>>
>> ===
>> Such uninitialized arrays are particularly useful for large arrays
>> that serve as temporary buffers. An uninitialized integral may not
>> cause too much harm, but uninitialized values of types with
>> indirections (such as arrays themselves) are unsafe.
>> ===
>>
p18. What is unsafe about implicit conversion of static to dynamic
array?
Meaning getting a dynamic array pointing to a stack allocated
array.
Any operation changing its size could copy the array to the
heap. What am I missing
>>
>> T[] fun() { T[10] a; return a; }
>> ...
>> auto x = fun(); // gained access to recycled stack memory
>>
>> There's no change in size there.
>>
p20. 10 int take up 40 words?
>>
>> The example given has a per-row payload of 10 ints, i.e. 40 words.
>
> It's bytes actually. So finally I rewrote those last words as:
>
> "... small per-row payload of~10 @i...@s (40 bytes)."
>
>
> Andrei
Thanks !
Out of interest, do you keep a list of common error or something alike that
helps you keep errors at a minimum?
Also, do you have automated example checking?
Or, more general, I would be interested in a small article explaining how a
book like this is written.
Maybe After the book is finished :)
Re: Targeting C
On Fri, 30 Oct 2009 10:05:27 +0300, rmcguire wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
Pelle Månsson wrote:
Andrei Alexandrescu wrote:
Yigal Chripun wrote:
On 23/10/2009 13:02, bearophile wrote:
Chris Nicholson-Sauls:
I prefer this (Scala):
list = list ++ (0 to 10)
That's quite less readable. Scala sometimes has some unreadable
syntax. Python has taught me how much useful a readable syntax is
:-)
Designing languages requires to find a balance between several
different and opposed needs.
Bye,
bearophile
how about this hypothetical syntax:
list ~= [0..10];
I'm not sure what the type of "list" is supposed to be, but this
works today for arrays:
list ~= array(iota(0, 10));
Andrei
What does iota mean?
http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota
This link jumps straight to:
Take!(Sequence!("a.field[0] + n *
a.field[1]",Tuple!(CommonType!(B,E),S))) iota(B, E, S)(B begin, E end,
S
step);
Wow, please tell me this is a ddoc malfunction. I mean, that thing left
to iota is supposed to be a type?
(OK, it _is_ a malfunction, but that thing is still supposed to be... a
type?)
Well what was I supposed to do? It was either define another type Iota,
or reuse existing types. I chose to reuse.
Andrei
Hi Andrei,
Could you tell me why:
Take!(Sequence!("a.field[0] + n *
a.field[1]",Tuple!(CommonType!(B,E),S)))
Is a type and not a value?
-Rory
I guess Take!(T) is a type, returned by a take(T t, int limit) function
(it accepts a range and returns other range with a "limit" elements at
most). The naming is consistent with a function, but capitalized to
reflect that it's actually a type, not a function.
Re: Targeting C
rmcguire wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
Pelle Månsson wrote:
Andrei Alexandrescu wrote:
Yigal Chripun wrote:
On 23/10/2009 13:02, bearophile wrote:
Chris Nicholson-Sauls:
I prefer this (Scala):
list = list ++ (0 to 10)
That's quite less readable. Scala sometimes has some unreadable
syntax. Python has taught me how much useful a readable syntax is :-)
Designing languages requires to find a balance between several
different and opposed needs.
Bye,
bearophile
how about this hypothetical syntax:
list ~= [0..10];
I'm not sure what the type of "list" is supposed to be, but this
works today for arrays:
list ~= array(iota(0, 10));
Andrei
What does iota mean?
http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota
This link jumps straight to:
Take!(Sequence!("a.field[0] + n *
a.field[1]",Tuple!(CommonType!(B,E),S))) iota(B, E, S)(B begin, E end, S
step);
Wow, please tell me this is a ddoc malfunction. I mean, that thing left
to iota is supposed to be a type?
(OK, it _is_ a malfunction, but that thing is still supposed to be... a
type?)
Well what was I supposed to do? It was either define another type Iota,
or reuse existing types. I chose to reuse.
Andrei
Hi Andrei,
Could you tell me why:
Take!(Sequence!("a.field[0] + n * a.field[1]",Tuple!(CommonType!(B,E),S)))
Is a type and not a value?
-Rory
Take!(
Sequence!(
"a.field[0] + n * a.field[1]",
Tuple!(
CommonType!(B,E),
S
)
)
)
If you look here:
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/algorithm.d
and in related files, you'll see that Take is a type with one parameter.
Then Sequence is a type with two parameters. Then Tuple is a type with
any number of parameters, and so is CommonType.
So in spite of it looking complicated, it's just a usual instantiation
of a few parameterized types. (What may confuse a C++ programmer is the
presence of the string - it's just a template argument.)
Andrei
Re: Success! (Precisely)
== Quote from Denis Koroskin (2kor...@gmail.com)'s article > On Fri, 30 Oct 2009 08:08:10 +0300, dsimcha wrote: > > After a few evenings of serious hacking, I've integrated precise heap > > scanning > > into the GC. Right now, I still need to test it better and debug it, > > but it > > at least basically works. I also still need to write the templates to > > generate bit masks at compile time, but this is a simple matter of > > programming. > > > > A few things: > > > > 1. Who knows how to write some good stress tests to make sure this > > works? > > > > 2. I'm thinking about how to write the bitmask templates. In the next > > release of DMD, when static arrays are value types and returnable from > > functions, will they be returnable from functions in CTFE? > > > > 3. new only takes RTTI. It is not a template. Unless RTTI gets > > bitmasks in > > the format I created (which I'll document once I clean things up and > > release, > > but has only deviated slightly from what I had talked about here), stuff > > allocated using it won't be able to take advantage of precise heap > > scanning. > > The default bitmask, if none is provided, uses good (bad) old-fashioned > > conservative scanning unless the entire block has no pointers, in which > > case > > it isn't scanned. This means that we have all the more incentive to > > replace > > new with a template of some kind. > > > > 4. I solved the static array problem, but the solution required using > > up one > > of the high-order bits. We have at least one more to play with in my > > bitmask > > scheme, because I'm storing things by word offsets, not byte offsets, > > since > > the GC isn't supposed to work with misaligned pointers anyhow. This > > leaves > > one more bit before we start limiting T.sizeof to less than full address > > space > > (on 32-bit, where a word is 4 bytes). I think it needs to be reserved > > for > > pinning, in case a copying collector ever gets implemented. If we're > > willing > > to not let any precisely scanned object have a T.sizeof of more than > > half the > > address space (a ridiculously minor limitation; this does not limit the > > size > > of arrays, only the size of classes and the elements of an array), we > > could > > throw in a third bit for weak references. > Blaze (http://www.dsource.org/projects/blaze) is often suggested for > stress-testing the GC. Probably, because it does huge amount of dynamic > allocations, while total amount of memory consumed is about the same. > Worth a note, it's for D1/Tango, but you said you were going to port it to > Tango, too, so it may be better to start with Tango (because there are a > lot more code written against Tango and you get instant user feedback) and > then port it to druntime. If not a performance test, it may be a good > correctness test (so that you don't collect memory which is still > referenced). Clarification: I didn't say **I** was going to port this to Tango. I've been targeting D2/druntime all along. A Tango port is not out of the question if the port ends up being fairly trivial and the Tango devs are ok with breaking backwards compatibility, at least at the binary level. However, if the port is non-trivial then it's unlikely that I'll do it since I don't use D1 and, if Tango ever gets ported to D2 it will run on top of druntime. I just said that if **someone else** cares enough to port this to Tango, it shouldn't be terribly hard, since druntime is basically the Tango runtime.
Re: The demise of T[new]
I've just caught up on this thread. Built-in dynamic arrays have been one of D's major features since the early days. Now you're planning to remove this feature? http://www.digitalmars.com/d/1.0/builtin.html states that the C++ STL has many types that have been created to compensate for the limitations of the built-in array type, and the power of D's built-in arrays largely eliminates the need for these. So now you're suggesting that we do away with this power, and create these library types that the point was to avoid? Walter Bright wrote: The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[]. I thought you were already moving that functionality into T[new]. I think T[new] versus T[] is actually a good design - it makes for a form of array length constancy as well as possibly getting rid of such nasties as bug 2093. We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. I must've missed the discussion - what's wrong with fixing such expressions to work in terms of property setters/getters in the natural way? Stewart.
Re: The Thermopylae excerpt of TDPL available online
Jason House wrote: Andrei Alexandrescu Wrote: Jason House wrote: Andrei Alexandrescu Wrote: It's a rough rough draft, but one for the full chapter on arrays, associative arrays, and strings. http://erdani.com/d/thermopylae.pdf Any feedback is welcome. Thanks! I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet? Also, on page 8? a code comment says average of a and b even though the variables don't exist. Thanks, fixed. I also would like to see is expressions improved, but so far we couldn't find a good solution. There is a proposal currently in Bugzilla which may improve things. Andrei What's the bugzilla number? http://d.puremagic.com/issues/show_bug.cgi?id=1827 I can't believe I actually found it. Just got lucky - I vaguely know it was submitted by someone in Poland. I never find anything with bugzilla... Andrei
Re: Success! (Precisely)
On Fri, 30 Oct 2009 08:08:10 +0300, dsimcha wrote: After a few evenings of serious hacking, I've integrated precise heap scanning into the GC. Right now, I still need to test it better and debug it, but it at least basically works. I also still need to write the templates to generate bit masks at compile time, but this is a simple matter of programming. A few things: 1. Who knows how to write some good stress tests to make sure this works? 2. I'm thinking about how to write the bitmask templates. In the next release of DMD, when static arrays are value types and returnable from functions, will they be returnable from functions in CTFE? 3. new only takes RTTI. It is not a template. Unless RTTI gets bitmasks in the format I created (which I'll document once I clean things up and release, but has only deviated slightly from what I had talked about here), stuff allocated using it won't be able to take advantage of precise heap scanning. The default bitmask, if none is provided, uses good (bad) old-fashioned conservative scanning unless the entire block has no pointers, in which case it isn't scanned. This means that we have all the more incentive to replace new with a template of some kind. 4. I solved the static array problem, but the solution required using up one of the high-order bits. We have at least one more to play with in my bitmask scheme, because I'm storing things by word offsets, not byte offsets, since the GC isn't supposed to work with misaligned pointers anyhow. This leaves one more bit before we start limiting T.sizeof to less than full address space (on 32-bit, where a word is 4 bytes). I think it needs to be reserved for pinning, in case a copying collector ever gets implemented. If we're willing to not let any precisely scanned object have a T.sizeof of more than half the address space (a ridiculously minor limitation; this does not limit the size of arrays, only the size of classes and the elements of an array), we could throw in a third bit for weak references. Blaze (http://www.dsource.org/projects/blaze) is often suggested for stress-testing the GC. Probably, because it does huge amount of dynamic allocations, while total amount of memory consumed is about the same. Worth a note, it's for D1/Tango, but you said you were going to port it to Tango, too, so it may be better to start with Tango (because there are a lot more code written against Tango and you get instant user feedback) and then port it to druntime. If not a performance test, it may be a good correctness test (so that you don't collect memory which is still referenced).
Re: Success! (Precisely)
> Yes, I understand. What kind of code are you looking for then? You have already answered, in a way. You need complex code that runs for a lot of time, while keeping the total amount of memory used constant. You also surely need some synthetic tests, to spot eventual bugs better. I don't know if I have code for you, probably not. Indeed the Olden benchmarks stress the GC, but only its performance, not its precision... Bye, bearophile
Re: Success! (Precisely)
== Quote from bearophile (bearophileh...@lycos.com)'s article > dsimcha: > > These might be worth a try, but they're more benchmarks for performance > > than tests > > of correctness, if I understand correctly.< > Yes, I understand. What kind of code are you looking for then? > Bye, > bearophile I was just thinking maybe someone else (I mostly had Sean and Walter in mind, but would certainly accept solutions from others) had written a GC test suite and never released it. If not, I'll probably just write my own and include it with the patches.
Re: Permitted locations of a version condition
Rainer Deyke wrote: What makes this case particularly bad is that Walter deliberate chose to limit the power of the 'version' construct in order to prevent overly complex read-only code. Actually, AIUI it's just one of many things he did to eliminate the syntactic fragility that C++ has a lot of, thereby making code manipulation tools work better. http://www.digitalmars.com/d/1.0/overview.html "It's time to step back, look at what the preprocessor is used for, and design support for those capabilities directly into the language." Naturally, putting these capabilities into the language has to be done one step at a time. Stewart.
Re: Success! (Precisely)
dsimcha: > These might be worth a try, but they're more benchmarks for performance than > tests > of correctness, if I understand correctly.< Yes, I understand. What kind of code are you looking for then? Bye, bearophile
Re: Success! (Precisely)
== Quote from bearophile (bearophileh...@lycos.com)'s article > Leandro Lucarella: > > If somebody have this, I'm very interested too. > Two D translations of the Olden Benchmarks, more to come: > http://www.fantascienza.net/leonardo/js/index.html > Bye, > bearophile These might be worth a try, but they're more benchmarks for performance than tests of correctness, if I understand correctly. I was looking for the latter. The improvements I'm working on have nothing to do with speed (though I may throw in a few optimizations I found while I'm at it). They have to do with preventing the GC from retaining memory unnecessarily.
Re: Success! (Precisely)
Leandro Lucarella: > If somebody have this, I'm very interested too. Two D translations of the Olden Benchmarks, more to come: http://www.fantascienza.net/leonardo/js/index.html Bye, bearophile
Re: The Thermopylae excerpt of TDPL available online
Leandro Lucarella wrote: Justin Johansson, el 30 de octubre a las 08:42 me escribiste: Actually, I think I like that better than 'traits'. -Lars I'm in agreement with whoever suggested 'meta' or just about anything else except 'traits'. 'meta', whilst perhaps an overloaded keyword, is still much more user-friendly. Whenever I see 'traits' I get the feeling I need a Ph.D. to understand what it's about. For some reason, I don't know why, 'meta' has an aire of karma about it. "compiler"? That could open the door to other types of access to compiler internals, AST, etc. Yup. I think the 'magic namespace' approach is a simple, clean way to incorporate reflection. It could be like Object and TypeInfo, implicitly available in every module and tightly coupled to the compiler, but can be viewed by the user as if it were just a module. It'd be particularly interesting if some of the functions _were_ actually implemented in library code, when possible.
Re: The Thermopylae excerpt of TDPL available online
Andrei Alexandrescu wrote:
Saaa wrote:
Could anybody clear these up for me?
p16. Is there anything other than the random values, unsafe about
void assignment?
I'd put your feedback on my pile of things to do, but now that you ask,
I made this change to the incriminated paragraph:
===
Such uninitialized arrays are particularly useful for large arrays
that serve as temporary buffers. An uninitialized integral may not
cause too much harm, but uninitialized values of types with
indirections (such as arrays themselves) are unsafe.
===
p18. What is unsafe about implicit conversion of static to dynamic
array?
Meaning getting a dynamic array pointing to a stack allocated
array.
Any operation changing its size could copy the array to the
heap. What am I missing
T[] fun() { T[10] a; return a; }
...
auto x = fun(); // gained access to recycled stack memory
There's no change in size there.
p20. 10 int take up 40 words?
The example given has a per-row payload of 10 ints, i.e. 40 words.
It's bytes actually. So finally I rewrote those last words as:
"... small per-row payload of~10 @i...@s (40 bytes)."
Andrei
Re: The Thermopylae excerpt of TDPL available online
Saaa wrote:
Could anybody clear these up for me?
p16. Is there anything other than the random values, unsafe about void
assignment?
I'd put your feedback on my pile of things to do, but now that you ask,
I made this change to the incriminated paragraph:
===
Such uninitialized arrays are particularly useful for large arrays
that serve as temporary buffers. An uninitialized integral may not
cause too much harm, but uninitialized values of types with
indirections (such as arrays themselves) are unsafe.
===
p18. What is unsafe about implicit conversion of static to dynamic array?
Meaning getting a dynamic array pointing to a stack allocated
array.
Any operation changing its size could copy the array to the heap.
What am I missing
T[] fun() { T[10] a; return a; }
...
auto x = fun(); // gained access to recycled stack memory
There's no change in size there.
p20. 10 int take up 40 words?
The example given has a per-row payload of 10 ints, i.e. 40 words.
Andrei
Re: Success! (Precisely)
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > This is great news. Hopefully you'll be willing to integrate your code > with druntime. That was kind of the point all along. I'll file it in Bugzilla after I finish the bitmask generation, testing and debugging.
Re: Success! (Precisely)
dsimcha, el 30 de octubre a las 05:08 me escribiste: > After a few evenings of serious hacking, I've integrated precise heap scanning > into the GC. Right now, I still need to test it better and debug it, but it > at least basically works. I also still need to write the templates to > generate bit masks at compile time, but this is a simple matter of > programming. > > A few things: > > 1. Who knows how to write some good stress tests to make sure this works? If somebody have this, I'm very interested too. Being D2 it will be much harder to find programs to test. I found Dil to be a good candidate for testing, at least it failed with some bugs other smaller, simpler test didn't. But it's for D1. And congratulations! Great news. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Cada movimiento que no se hace, es un movimiento que se pierde. Y cada movimiento que se pierde, se transforma en una mochila. Y las mochilas nos alejan, de nuestros amigos y nuestras amigas. Y nuestros amigos se transforman, en enemigos y en enemigas. Cada movimiento que se hace, es una mochila que se deja.
Re: Followup Poll: Why tango trunk instead of 0.99.8?
Nick Sabalausky, el 29 de octubre a las 21:18 me escribiste: > "If you use (or admin a project that requires) Tango trunk instead of > 0.99.8: Why? (Select all that apply)" > > http://www.micropoll.com/akira/mpview/704493-212991 It's missing an answer: Tango doesn't release fast enough and doesn't maintain (do bug-fixes-releases for) released versions. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- PADRES DENUNCIAN QUE SU HIJA SE ESCAPO CON UN PARAGUAYITO -- Crónica TV
Re: TDPL reaches Thermopylae level
Lars T. Kyllingstad wrote: Nick Sabalausky wrote: "Chris Nicholson-Sauls" wrote in message news:hcctuf$140...@digitalmars.com... Granted LTR is common enough to be expectable and acceptable. To be perfectly honest, I don't believe I have *ever* even used wchar/wstring. Char/string gosh yes; dchar/dstring quite a bit as well, where I need the simplicity; but I've yet to feel much need for the "weirdo" middle child of UTF. Given that just about anything outside of D (at least as far as I've seen) that attempts to use unicode does so with UTF-16 (or just uses UCS-2 and pretends that's UTF-16...), wchar and wstring are great for dealing with that. For instance, my Goldie engine for GOLD currently uses wchar in a number of places because GOLD's .cfg format stores text in...well, presumably UTF-16 (I haven't tested to see if it's really UCS-2). But yea, as long as you're not dealing with anything that's already in UTF-16 or that expects it, then it does seem to be somewhat questionable. I think this says it all: http://en.wikipedia.org/wiki/Utf-16#Use_in_major_operating_systems_and_environments -Lars :) Yep, there was a frenzy when UCS-2 came about: everybody thought two bytes will be enough for everyone. So UCS-2 was widely adopted - who wouldn't love to have constant character width? Then, the UTF-16 surrogate business came about, and the only logical step they could take was to migrate to UTF-16, which was upward compatible to UCS-2. I personally think UTF-8 is a better overall design though. Andrei
Re: Success! (Precisely)
dsimcha wrote: After a few evenings of serious hacking, I've integrated precise heap scanning into the GC. Right now, I still need to test it better and debug it, but it at least basically works. I also still need to write the templates to generate bit masks at compile time, but this is a simple matter of programming. [snip] This is great news. Hopefully you'll be willing to integrate your code with druntime. I forwarded Sean your post to make sure your work doesn't slip unnoticed. Andrei
Re: The Thermopylae excerpt of TDPL available online
Lars T. Kyllingstad, el 30 de octubre a las 08:55 me escribiste: > Leandro Lucarella wrote: > >Walter Bright, el 29 de octubre a las 16:06 me escribiste: > >>Lars T. Kyllingstad wrote: > >>>What I cannot for the life of me understand is WHY the double > >>>underscores? What's wrong with just "traits"? > >>Because D needed the feature, and it wasn't clear what a good syntax > >>for it would be. So __traits is a "put something out there, make it > >>work, if it proves its usefulness and a good syntax for it appears, > >>then that can be adopted." > > > >And now, being moderately close to D2 stabilization, isn't a good moment > >to think about a better syntax or just live with traits() as it is (but > >without the leading __)? > > > >Same for __gshared. > > > I'm not convinced about __gshared. As far as I've understood, > __gshared is a "don't use this unless you know what you are doing" > feature. As such, it should probably be a bit ugly. D is a system programming language. I don't see why one should be over patronizing. It's enough to clarify what the keyword does in the documentation. __gshared is not *that* rare, if you are interfacing with C, every C global have to be __gshared, it just makes the code uglier for no reason. Maybe it can be renamed to cglobal? I think we need a good descriptive name so people can know what it's about, not an ugly obfuscated one to confuse and scare them. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- I can't watch TV for four minutes without thinking I have five serious diseases. Like: "Do you ever wake up tired in the mornings?" Oh my god I have this, write this down. Whatever it is, I have this.
Re: The Thermopylae excerpt of TDPL available online
Justin Johansson, el 30 de octubre a las 08:42 me escribiste: > > Actually, I think I like that better than 'traits'. > > > > -Lars > > I'm in agreement with whoever suggested 'meta' or just about anything else > except 'traits'. > 'meta', whilst perhaps an overloaded keyword, is still much more > user-friendly. Whenever > I see 'traits' I get the feeling I need a Ph.D. to understand what it's > about. For some reason, > I don't know why, 'meta' has an aire of karma about it. "compiler"? That could open the door to other types of access to compiler internals, AST, etc. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Yo soy peperino el que siempre pone el vino, yo soy aquel que come los huevos con tocino. -- Peperino Pómoro
Re: Success! (Precisely)
== Quote from Jacob Carlborg (d...@me.com)'s article > On 10/30/09 06:08, dsimcha wrote: > > After a few evenings of serious hacking, I've integrated precise heap > > scanning > > into the GC. Right now, I still need to test it better and debug it, but it > > at least basically works. I also still need to write the templates to > > generate bit masks at compile time, but this is a simple matter of > > programming. > > > > A few things: > > > > 1. Who knows how to write some good stress tests to make sure this works? > > > > 2. I'm thinking about how to write the bitmask templates. In the next > > release of DMD, when static arrays are value types and returnable from > > functions, will they be returnable from functions in CTFE? > > > > 3. new only takes RTTI. It is not a template. Unless RTTI gets bitmasks > > in > > the format I created (which I'll document once I clean things up and > > release, > > but has only deviated slightly from what I had talked about here), stuff > > allocated using it won't be able to take advantage of precise heap scanning. > > The default bitmask, if none is provided, uses good (bad) old-fashioned > > conservative scanning unless the entire block has no pointers, in which case > > it isn't scanned. This means that we have all the more incentive to replace > > new with a template of some kind. > > > > 4. I solved the static array problem, but the solution required using up > > one > > of the high-order bits. We have at least one more to play with in my > > bitmask > > scheme, because I'm storing things by word offsets, not byte offsets, since > > the GC isn't supposed to work with misaligned pointers anyhow. This leaves > > one more bit before we start limiting T.sizeof to less than full address > > space > > (on 32-bit, where a word is 4 bytes). I think it needs to be reserved for > > pinning, in case a copying collector ever gets implemented. If we're > > willing > > to not let any precisely scanned object have a T.sizeof of more than half > > the > > address space (a ridiculously minor limitation; this does not limit the size > > of arrays, only the size of classes and the elements of an array), we could > > throw in a third bit for weak references. > Would this be possible to use with D1 ? The precise heap scanning would probably work, if the bit masks were generated manually, but I don't know if D1's templates are powerful enough to generate them. I had D2 in mind as a target, but I'll document the format once everything's cleaned up, tested, etc. and if someone wants to try to make it work on D1, they can. The only thing, though, is that D1 is supposed to be stable, and adding bit masks as an argument o GC.malloc might not fly. Then again, it would only be a lib change, probably in Tango. Furthermore, I made old-fashioned conservative scanning the default (a bit mask called conservativeBitMask is stored in the static data segment and is the default argument to GC.malloc) specifically to avoid breaking any compatibility at the source level.
Re: The Thermopylae excerpt of TDPL available online
Max Samukha Wrote: > On Thu, 29 Oct 2009 13:30:35 -0500, Andrei Alexandrescu > wrote: > > >It's me as well. The decision didn't go without a fight (I had your > >viewpoint and Walter didn't). He convinced me with two arguments. One is > >that 90% of the time you actually want T[], not T[n]. > > The argument may be flawed because, out of those 90% of arrays, only > small part may be initialized from array literals. Many (most?) are > created with new or appended. I suspect dynamic arrays created from > literals are as rare as static arrays in real world code. Probably, > I'll investigate how exactly rare. Is this the same argument as Andrei's rhetorical question (in relation to proposed removal of D complex literals), "Name me five significant complex numbers" from a few weeks ago? (Sorry can't find the NG link just right now).
Re: Safe Systems from Unreliable Parts
> Clicking on the link linked by your link, I get: > > You are not authorised to view this resource. > You need to login. The same links worked 3 hours ago.
Re: The Thermopylae excerpt of TDPL available online
Could anybody clear these up for me? > p16. Is there anything other than the random values, unsafe about void > assignment? > p18. What is unsafe about implicit conversion of static to dynamic array? >Meaning getting a dynamic array pointing to a stack allocated > array. >Any operation changing its size could copy the array to the heap. > What am I missing > p20. 10 int take up 40 words? Thanks!
Re: Safe Systems from Unreliable Parts
Jason House Wrote: > Walter Bright Wrote: > > > This is an important topic for anyone who is building software systems > > that, if they fail, can cause injury or large property damage. > > > > http://www.reddit.com/r/programming/comments/9z811/safe_systems_from_unreliable_parts/ > > Downvoted for poor links :( Ditto
Re: The Thermopylae excerpt of TDPL available online
Lars T. Kyllingstad Wrote:
> Don wrote:
> > Lars T. Kyllingstad wrote:
> >> Don wrote:
> >>> Lars T. Kyllingstad wrote:
> Denis Koroskin wrote:
> > On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad
> > wrote:
> >
> >> Jason House wrote:
> >>> Andrei Alexandrescu Wrote:
> >>>
> It's a rough rough draft, but one for the full chapter on
> arrays, associative arrays, and strings.
>
> http://erdani.com/d/thermopylae.pdf
>
> Any feedback is welcome. Thanks!
> >>> I still think is expressions are a glaring problem. Somewhere in
> >>> the text, you use assert(!is(typeof(... as support for what
> >>> you're talking about. That particular construct feels more like a
> >>> hack someone stumbled into than clean, easy to read code. It's
> >>> the type of thing a programmer will get wring unless they use it
> >>> frequently. Even you've screwed it up in past Phobos releases!
> >>> IMHO all is(...) expressions should be revisited. Have you
> >>> written the section(s) on them yet?
> >>
> >> I don't think he uses is(typeof(...)) in the text. The code
> >> snippets in question are marked "Note: normally the code below
> >> would not be included...", and I suppose he's put them there as a
> >> reminder for himself and Walter on what needs to be fixed before
> >> the book comes out.
> >>
> >> I agree with you, though, is(typeof(...)) is quite often misused,
> >> or at least used in an ugly way. Why not use __traits(compiles,
> >> ...) instead?
> >>
> >> -Lars
> >
> > ... which is at least as ugly.
>
>
> I disagree. Pretend you are just learning D, and you are presented
> with the following two lines of code:
>
> static assert (is(typeof(XXX));
> static assert (__traits(compiles, XXX));
>
> Which of these would you most likely assume to be a check on whether
> XXX is compilable code?
>
> What I cannot for the life of me understand is WHY the double
> underscores? What's wrong with just "traits"?
>
> -Lars
> >>>
> >>> Also is(typeof(XXX)) *doesn't* currently check that XXX is
> >>> compilable, just that it has a type.
> >>> OTOH __traits(compiles, XXX) is ugly. traits(compiles, XXX) would be
> >>> better; but I think we need to do better than that. It's the
> >>> bread-and-butter of metaprogramming in D. Using the ugly syntax, it
> >>> has well and truly proved its value.
> >>> I've counted 20 uses in what I've seen of Andrei's book -- it appears
> >>> about as often as (say) 'delegate'!
> >>>
> >>> It does a beautiful thing, it deserves a beautiful syntax. Something
> >>> at least as good as __compiles(XXX), I reckon.
> >>
> >> Again with the double underscores. :)
> > Yes. That's why I said "at least as good".
> >
> > I'm starting to think we need a
> >> separate namespace for the CT stuff.
> >>
> >> D.compiles(XXX)
> >> D.typeof(foo)
> >> D.stringof(T)
> >> D.allMembers(T)
> >
> > That's not bad. Can't be 'D', though, has to look like a keyword. Maybe
> > something like 'traits' instead. In exchange, get rid of the '__traits'
> > and 'typeid' keywords. Not sure about typeof, though.
> >
> > traits.compiles(XXX)
> > traits.typeid(TTT)
> > traits.stringof(T)
> > traits.allMembers(T)
> > traits.error("message");
> >
> > IMHO this looks better than __traits(compiles, XXX) but it actually has
> > the same flexibility, and it's a straightforward transformation inside
> > the compiler.
> > For bonus points, allow 'with(traits)':
> >
> > with(traits) {
> > if (compiles(XXX)) return stringof(T);
> > else error("Can't use " ~ stringof(T) ~ " in a transmogrifier.");
> > }
>
> I like it. It's a clean, simple solution. The std.traits module will
> just have to be renamed to std.meta or something. Or one could possibly
> use 'meta' as the new keyword:
>
>meta.compiles(XXX)
>meta.typeid(T)
>meta.stringof(T)
>
> Actually, I think I like that better than 'traits'.
>
> -Lars
I'm in agreement with whoever suggested 'meta' or just about anything else
except 'traits'.
'meta', whilst perhaps an overloaded keyword, is still much more user-friendly.
Whenever
I see 'traits' I get the feeling I need a Ph.D. to understand what it's about.
For some reason,
I don't know why, 'meta' has an aire of karma about it.
Justin
Re: The Thermopylae excerpt of TDPL available online
Andrei Alexandrescu Wrote: > Jason House wrote: > > Andrei Alexandrescu Wrote: > > > >> It's a rough rough draft, but one for the full chapter on arrays, > >> associative arrays, and strings. > >> > >> http://erdani.com/d/thermopylae.pdf > >> > >> Any feedback is welcome. Thanks! > > > > I still think is expressions are a glaring problem. Somewhere in the > > text, you use assert(!is(typeof(... as support for what you're > > talking about. That particular construct feels more like a hack > > someone stumbled into than clean, easy to read code. It's the type of > > thing a programmer will get wring unless they use it frequently. Even > > you've screwed it up in past Phobos releases! IMHO all is(...) > > expressions should be revisited. Have you written the section(s) on > > them yet? > > > > Also, on page 8? a code comment says average of a and b even though > > the variables don't exist. > > Thanks, fixed. I also would like to see is expressions improved, but so > far we couldn't find a good solution. There is a proposal currently in > Bugzilla which may improve things. > > Andrei What's the bugzilla number?
Re: Safe Systems from Unreliable Parts
Walter Bright Wrote: > This is an important topic for anyone who is building software systems > that, if they fail, can cause injury or large property damage. > > http://www.reddit.com/r/programming/comments/9z811/safe_systems_from_unreliable_parts/ Downvoted for poor links :(
Re: The Thermopylae excerpt of TDPL available online
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
Lars T. Kyllingstad wrote:
Denis Koroskin wrote:
On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad
wrote:
Jason House wrote:
Andrei Alexandrescu Wrote:
It's a rough rough draft, but one for the full chapter on
arrays, associative arrays, and strings.
http://erdani.com/d/thermopylae.pdf
Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in
the text, you use assert(!is(typeof(... as support for what
you're talking about. That particular construct feels more like a
hack someone stumbled into than clean, easy to read code. It's
the type of thing a programmer will get wring unless they use it
frequently. Even you've screwed it up in past Phobos releases!
IMHO all is(...) expressions should be revisited. Have you
written the section(s) on them yet?
I don't think he uses is(typeof(...)) in the text. The code
snippets in question are marked "Note: normally the code below
would not be included...", and I suppose he's put them there as a
reminder for himself and Walter on what needs to be fixed before
the book comes out.
I agree with you, though, is(typeof(...)) is quite often misused,
or at least used in an ugly way. Why not use __traits(compiles,
...) instead?
-Lars
... which is at least as ugly.
I disagree. Pretend you are just learning D, and you are presented
with the following two lines of code:
static assert (is(typeof(XXX));
static assert (__traits(compiles, XXX));
Which of these would you most likely assume to be a check on whether
XXX is compilable code?
What I cannot for the life of me understand is WHY the double
underscores? What's wrong with just "traits"?
-Lars
Also is(typeof(XXX)) *doesn't* currently check that XXX is
compilable, just that it has a type.
OTOH __traits(compiles, XXX) is ugly. traits(compiles, XXX) would be
better; but I think we need to do better than that. It's the
bread-and-butter of metaprogramming in D. Using the ugly syntax, it
has well and truly proved its value.
I've counted 20 uses in what I've seen of Andrei's book -- it appears
about as often as (say) 'delegate'!
It does a beautiful thing, it deserves a beautiful syntax. Something
at least as good as __compiles(XXX), I reckon.
Again with the double underscores. :)
Yes. That's why I said "at least as good".
I'm starting to think we need a
separate namespace for the CT stuff.
D.compiles(XXX)
D.typeof(foo)
D.stringof(T)
D.allMembers(T)
That's not bad. Can't be 'D', though, has to look like a keyword. Maybe
something like 'traits' instead. In exchange, get rid of the '__traits'
and 'typeid' keywords. Not sure about typeof, though.
traits.compiles(XXX)
traits.typeid(TTT)
traits.stringof(T)
traits.allMembers(T)
traits.error("message");
IMHO this looks better than __traits(compiles, XXX) but it actually has
the same flexibility, and it's a straightforward transformation inside
the compiler.
For bonus points, allow 'with(traits)':
with(traits) {
if (compiles(XXX)) return stringof(T);
else error("Can't use " ~ stringof(T) ~ " in a transmogrifier.");
}
I like it. It's a clean, simple solution. The std.traits module will
just have to be renamed to std.meta or something. Or one could possibly
use 'meta' as the new keyword:
meta.compiles(XXX)
meta.typeid(T)
meta.stringof(T)
Actually, I think I like that better than 'traits'.
-Lars
Re: The Thermopylae excerpt of TDPL available online
bearophile wrote:
Don:
traits.compiles(XXX)
traits.typeid(TTT)
traits.stringof(T)
traits.allMembers(T)
traits.error("message");
Cute.
Simpler alternative, the dot isn't necessary:
traits_compiles(XXX)
traits_typeid(TTT)
traits_stringof(T)
traits_allmembers(T)
traits_error("message");
That is WAY more complicated! It adds a crazy number of keywords, and
isn't extensible.
Re: Success! (Precisely)
On 10/30/09 06:08, dsimcha wrote: After a few evenings of serious hacking, I've integrated precise heap scanning into the GC. Right now, I still need to test it better and debug it, but it at least basically works. I also still need to write the templates to generate bit masks at compile time, but this is a simple matter of programming. A few things: 1. Who knows how to write some good stress tests to make sure this works? 2. I'm thinking about how to write the bitmask templates. In the next release of DMD, when static arrays are value types and returnable from functions, will they be returnable from functions in CTFE? 3. new only takes RTTI. It is not a template. Unless RTTI gets bitmasks in the format I created (which I'll document once I clean things up and release, but has only deviated slightly from what I had talked about here), stuff allocated using it won't be able to take advantage of precise heap scanning. The default bitmask, if none is provided, uses good (bad) old-fashioned conservative scanning unless the entire block has no pointers, in which case it isn't scanned. This means that we have all the more incentive to replace new with a template of some kind. 4. I solved the static array problem, but the solution required using up one of the high-order bits. We have at least one more to play with in my bitmask scheme, because I'm storing things by word offsets, not byte offsets, since the GC isn't supposed to work with misaligned pointers anyhow. This leaves one more bit before we start limiting T.sizeof to less than full address space (on 32-bit, where a word is 4 bytes). I think it needs to be reserved for pinning, in case a copying collector ever gets implemented. If we're willing to not let any precisely scanned object have a T.sizeof of more than half the address space (a ridiculously minor limitation; this does not limit the size of arrays, only the size of classes and the elements of an array), we could throw in a third bit for weak references. Would this be possible to use with D1 ?
Re: Safe Systems from Unreliable Parts
grauzone wrote: Walter Bright wrote: This is an important topic for anyone who is building software systems that, if they fail, can cause injury or large property damage. http://www.reddit.com/r/programming/comments/9z811/safe_systems_from_unreliable_parts/ Clicking on the link linked by your link, I get: You are not authorised to view this resource. You need to login. Try the link in the first comment instead. -Lars
Re: Safe Systems from Unreliable Parts
On 30.10.2009 12:16, grauzone wrote: Walter Bright wrote: This is an important topic for anyone who is building software systems that, if they fail, can cause injury or large property damage. http://www.reddit.com/r/programming/comments/9z811/safe_systems_from_unreliable_parts/ Clicking on the link linked by your link, I get: You are not authorised to view this resource. You need to login. "This Account Has Been Suspended".
Re: Followup Poll: Why tango trunk instead of 0.99.8?
On 30.10.2009 12:16, grauzone wrote: The new stack tracing feature is essential. Normally you'd use a debugger, but we're talking about D here. Same goes for me. I use the oldest revision where the stack tracing works, which is 4498. Plus a patch to make it work on Vista.
Re: Followup Poll: Why tango trunk instead of 0.99.8?
Nick Sabalausky wrote: "If you use (or admin a project that requires) Tango trunk instead of 0.99.8: Why? (Select all that apply)" http://www.micropoll.com/akira/mpview/704493-212991 The new stack tracing feature is essential. Normally you'd use a debugger, but we're talking about D here.
Re: Safe Systems from Unreliable Parts
Walter Bright wrote: This is an important topic for anyone who is building software systems that, if they fail, can cause injury or large property damage. http://www.reddit.com/r/programming/comments/9z811/safe_systems_from_unreliable_parts/ Clicking on the link linked by your link, I get: You are not authorised to view this resource. You need to login.
Re: The Thermopylae excerpt of TDPL available online
Op Fri, 30 Oct 2009 11:44:08 +0100 schreef bearophile
:
Simpler alternative, the dot isn't necessary:
traits_compiles(XXX)
traits_typeid(TTT)
traits_stringof(T)
traits_allmembers(T)
traits_error("message");
Not nice. Bad.
Re: The Thermopylae excerpt of TDPL available online
Don:
> traits.compiles(XXX)
> traits.typeid(TTT)
> traits.stringof(T)
> traits.allMembers(T)
> traits.error("message");
Cute.
Simpler alternative, the dot isn't necessary:
traits_compiles(XXX)
traits_typeid(TTT)
traits_stringof(T)
traits_allmembers(T)
traits_error("message");
Or, more uniformly (all D needs more identifier style uniformity):
traits_compiles(XXX)
traits_type_id(TTT)
traits_string_of(T)
traits_all_members(T)
traits_error("message");
> For bonus points, allow 'with(traits)':
> with(traits) {
>if (compiles(XXX)) return stringof(T);
>else error("Can't use " ~ stringof(T) ~ " in a transmogrifier.");
> }
Not nice. Bad.
Bye,
bearophile
Re: Permitted locations of a version condition
Rainer Deyke Wrote: > - However, the language has other features that can be abused to > provide the functionality in a syntactically ugly way. > - D programmers use these language features to write powerful but ugly > code. There was a word that macros are not needed because string mixins are more powerful.
Re: The Thermopylae excerpt of TDPL available online
Lars T. Kyllingstad wrote:
Don wrote:
Lars T. Kyllingstad wrote:
Denis Koroskin wrote:
On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad
wrote:
Jason House wrote:
Andrei Alexandrescu Wrote:
It's a rough rough draft, but one for the full chapter on arrays,
associative arrays, and strings.
http://erdani.com/d/thermopylae.pdf
Any feedback is welcome. Thanks!
I still think is expressions are a glaring problem. Somewhere in
the text, you use assert(!is(typeof(... as support for what you're
talking about. That particular construct feels more like a hack
someone stumbled into than clean, easy to read code. It's the type
of thing a programmer will get wring unless they use it
frequently. Even you've screwed it up in past Phobos releases!
IMHO all is(...) expressions should be revisited. Have you written
the section(s) on them yet?
I don't think he uses is(typeof(...)) in the text. The code
snippets in question are marked "Note: normally the code below
would not be included...", and I suppose he's put them there as a
reminder for himself and Walter on what needs to be fixed before
the book comes out.
I agree with you, though, is(typeof(...)) is quite often misused,
or at least used in an ugly way. Why not use __traits(compiles,
...) instead?
-Lars
... which is at least as ugly.
I disagree. Pretend you are just learning D, and you are presented
with the following two lines of code:
static assert (is(typeof(XXX));
static assert (__traits(compiles, XXX));
Which of these would you most likely assume to be a check on whether
XXX is compilable code?
What I cannot for the life of me understand is WHY the double
underscores? What's wrong with just "traits"?
-Lars
Also is(typeof(XXX)) *doesn't* currently check that XXX is compilable,
just that it has a type.
OTOH __traits(compiles, XXX) is ugly. traits(compiles, XXX) would be
better; but I think we need to do better than that. It's the
bread-and-butter of metaprogramming in D. Using the ugly syntax, it
has well and truly proved its value.
I've counted 20 uses in what I've seen of Andrei's book -- it appears
about as often as (say) 'delegate'!
It does a beautiful thing, it deserves a beautiful syntax. Something
at least as good as __compiles(XXX), I reckon.
Again with the double underscores. :)
Yes. That's why I said "at least as good".
I'm starting to think we need a
separate namespace for the CT stuff.
D.compiles(XXX)
D.typeof(foo)
D.stringof(T)
D.allMembers(T)
That's not bad. Can't be 'D', though, has to look like a keyword. Maybe
something like 'traits' instead. In exchange, get rid of the '__traits'
and 'typeid' keywords. Not sure about typeof, though.
traits.compiles(XXX)
traits.typeid(TTT)
traits.stringof(T)
traits.allMembers(T)
traits.error("message");
IMHO this looks better than __traits(compiles, XXX) but it actually has
the same flexibility, and it's a straightforward transformation inside
the compiler.
For bonus points, allow 'with(traits)':
with(traits) {
if (compiles(XXX)) return stringof(T);
else error("Can't use " ~ stringof(T) ~ " in a transmogrifier.");
}
Re: Is it possible that the Karmic upgrade interferes with dmd?
Don wrote: > That's odd. Please try adding an 'L' to end of each of each constant. > [0x1.a5f1c2eb3fe4efp+73L, 0x1.A5F1C2EB3FE4EFp-1L, 74], Oh, I'm really sorry, I copied the wrong line (this was 640). Here's the guilty line (641, this time for real): [0x1.fa01712e8f0471ap-1064, 0x1.fa01712e8f0471ap-1, -1063], Adding 'L' to the first constant works: [0x1.fa01712e8f0471ap-1064L, 0x1.fa01712e8f0471ap-1, -1063], Thanks! -Mike
Re: Permitted locations of a version condition
Phil Deets wrote:
> mixin(q"ENUM
> enum Tag
> {
>A, B,
> ENUM"~(Version!("symbol")?q"ENUM
>C, D,
> ENUM":"")~q"ENUM
>E,
> }
> ENUM");
>
> That's not pretty, but it's good enough for me; so I'll probably not do
> any compiler hacking.
"Not pretty" is putting it very lightly.
What's happening in the D community is the same thing that's already
happened in the C++ community:
- The language is missing some useful features.
- The language is also missing an elegant powerful macro system that
could be used to add those features.
- However, the language has other features that can be abused to
provide the functionality in a syntactically ugly way.
- D programmers use these language features to write powerful but ugly
code.
- The language develops a reputation for being overly complex and
difficult to read.
What makes this case particularly bad is that Walter deliberate chose to
limit the power of the 'version' construct in order to prevent overly
complex read-only code.
--
Rainer Deyke - rain...@eldwood.com
Re: associative arrays: iteration is finally here
Nick Sabalausky wrote:
"Pelle Månsson" wrote in message
news:hcaaro$15e...@digitalmars.com...
I think foreach should be consistent with opIn, that is,
if (foo in aa) { //it is in the aa.
foreach (f; aa) { // loop over each item in the aa
//I expect foo to show up in here, since it is "in" the aa.
}
}
I use key iteration more than I use value iteration, and it is what I am
used to. It is, as you say, a matter of preference.
I've thought for a long while that "in" should be value-based (so you can do
things like "if(foo in [1,2,7,9])" instead of the not-as-nice
"if([1,2,7,9].contains(foo))"), and that there should be some other way to
check for the existance of a key (like "aa.hasKey(key)" or "key in aa.keys",
or something like that). I need to check for values in an array much more
often than I need to check for keys in an aa.
I, too, want opIn to work on arrays. On values. As a linear search. I do
not see why you would want to remove it on AA keys, though.
Re: The Thermopylae excerpt of TDPL available online
Don wrote: Lars T. Kyllingstad wrote: Denis Koroskin wrote: On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad wrote: Jason House wrote: Andrei Alexandrescu Wrote: It's a rough rough draft, but one for the full chapter on arrays, associative arrays, and strings. http://erdani.com/d/thermopylae.pdf Any feedback is welcome. Thanks! I still think is expressions are a glaring problem. Somewhere in the text, you use assert(!is(typeof(... as support for what you're talking about. That particular construct feels more like a hack someone stumbled into than clean, easy to read code. It's the type of thing a programmer will get wring unless they use it frequently. Even you've screwed it up in past Phobos releases! IMHO all is(...) expressions should be revisited. Have you written the section(s) on them yet? I don't think he uses is(typeof(...)) in the text. The code snippets in question are marked "Note: normally the code below would not be included...", and I suppose he's put them there as a reminder for himself and Walter on what needs to be fixed before the book comes out. I agree with you, though, is(typeof(...)) is quite often misused, or at least used in an ugly way. Why not use __traits(compiles, ...) instead? -Lars ... which is at least as ugly. I disagree. Pretend you are just learning D, and you are presented with the following two lines of code: static assert (is(typeof(XXX)); static assert (__traits(compiles, XXX)); Which of these would you most likely assume to be a check on whether XXX is compilable code? What I cannot for the life of me understand is WHY the double underscores? What's wrong with just "traits"? -Lars Also is(typeof(XXX)) *doesn't* currently check that XXX is compilable, just that it has a type. OTOH __traits(compiles, XXX) is ugly. traits(compiles, XXX) would be better; but I think we need to do better than that. It's the bread-and-butter of metaprogramming in D. Using the ugly syntax, it has well and truly proved its value. I've counted 20 uses in what I've seen of Andrei's book -- it appears about as often as (say) 'delegate'! It does a beautiful thing, it deserves a beautiful syntax. Something at least as good as __compiles(XXX), I reckon. Again with the double underscores. :) I'm starting to think we need a separate namespace for the CT stuff. D.compiles(XXX) D.typeof(foo) D.stringof(T) D.allMembers(T) etc. -Lars
Re: Is it possible that the Karmic upgrade interferes with dmd?
Michael Mittner wrote: Walter Bright wrote: It could be that the C library routine strtold(), which the lexer relies on, changed. That has nothing to do with linking. Hmm. This is where dmd struggles: 641:[0x1.a5f1c2eb3fe4efp+73, 0x1.A5F1C2EB3FE4EFp-1, 74],// normal I have no idea how the lexer works, but that sounds pretty plausible when I look at that constant in there. Anyway, after further investigation I figured out that it's a unittest, so I just commented it out and it compiles now without problems. Maybe it's just a fluke, I guess we'll see if someone else will have the same problem. I, for one, am satisfied; my code compiles, and that is all that counts. That's odd. Please try adding an 'L' to end of each of each constant. [0x1.a5f1c2eb3fe4efp+73L, 0x1.A5F1C2EB3FE4EFp-1L, 74],
Re: The Thermopylae excerpt of TDPL available online
Leandro Lucarella wrote: Walter Bright, el 29 de octubre a las 16:06 me escribiste: Lars T. Kyllingstad wrote: What I cannot for the life of me understand is WHY the double underscores? What's wrong with just "traits"? Because D needed the feature, and it wasn't clear what a good syntax for it would be. So __traits is a "put something out there, make it work, if it proves its usefulness and a good syntax for it appears, then that can be adopted." And now, being moderately close to D2 stabilization, isn't a good moment to think about a better syntax or just live with traits() as it is (but without the leading __)? Same for __gshared. I'm not convinced about __gshared. As far as I've understood, __gshared is a "don't use this unless you know what you are doing" feature. As such, it should probably be a bit ugly. __traits(), on the other hand, is more of a "hey you guys, you should try this traits thing, it's totally neat" feature. -Lars
Re: TDPL reaches Thermopylae level
Nick Sabalausky wrote: "Chris Nicholson-Sauls" wrote in message news:hcctuf$140...@digitalmars.com... Granted LTR is common enough to be expectable and acceptable. To be perfectly honest, I don't believe I have *ever* even used wchar/wstring. Char/string gosh yes; dchar/dstring quite a bit as well, where I need the simplicity; but I've yet to feel much need for the "weirdo" middle child of UTF. Given that just about anything outside of D (at least as far as I've seen) that attempts to use unicode does so with UTF-16 (or just uses UCS-2 and pretends that's UTF-16...), wchar and wstring are great for dealing with that. For instance, my Goldie engine for GOLD currently uses wchar in a number of places because GOLD's .cfg format stores text in...well, presumably UTF-16 (I haven't tested to see if it's really UCS-2). But yea, as long as you're not dealing with anything that's already in UTF-16 or that expects it, then it does seem to be somewhat questionable. I think this says it all: http://en.wikipedia.org/wiki/Utf-16#Use_in_major_operating_systems_and_environments -Lars :)
Re: Targeting C
Andrei Alexandrescu wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> Pelle Månsson wrote:
Andrei Alexandrescu wrote:
> Yigal Chripun wrote:
>> On 23/10/2009 13:02, bearophile wrote:
>>> Chris Nicholson-Sauls:
>>>
I prefer this (Scala):
list = list ++ (0 to 10)
>>>
>>> That's quite less readable. Scala sometimes has some unreadable
>>> syntax. Python has taught me how much useful a readable syntax is :-)
>>> Designing languages requires to find a balance between several
>>> different and opposed needs.
>>>
>>> Bye,
>>> bearophile
>>
>> how about this hypothetical syntax:
>>
>> list ~= [0..10];
>
> I'm not sure what the type of "list" is supposed to be, but this
> works today for arrays:
>
> list ~= array(iota(0, 10));
>
>
> Andrei
What does iota mean?
>>>
>>> http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota
>> This link jumps straight to:
>>
>> Take!(Sequence!("a.field[0] + n *
>> a.field[1]",Tuple!(CommonType!(B,E),S))) iota(B, E, S)(B begin, E end, S
>> step);
>>
>> Wow, please tell me this is a ddoc malfunction. I mean, that thing left
>> to iota is supposed to be a type?
>>
>> (OK, it _is_ a malfunction, but that thing is still supposed to be... a
>> type?)
>
> Well what was I supposed to do? It was either define another type Iota,
> or reuse existing types. I chose to reuse.
>
> Andrei
>
Hi Andrei,
Could you tell me why:
Take!(Sequence!("a.field[0] + n * a.field[1]",Tuple!(CommonType!(B,E),S)))
Is a type and not a value?
-Rory
