## digitalmars.D - The Thermopylae excerpt of TDPL available online

• Andrei Alexandrescu (5/5) Oct 28 2009 It's a rough rough draft, but one for the full chapter on arrays,
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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!

Andrei

Oct 28 2009
=?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
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!

Andrei

Your "Hallå Värd!" should be "Hallå Värld!", to be Swedish. D:

Also, I am wondering, why is the undefined behavior of opCatAssign kept?
Couldn't every T[] know if it is the owner of the memory in question?
Sorry if I bring outdated discussions up unnecessarily.

Oct 29 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Pelle Månsson 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!

Andrei

Your "Hallå Värd!" should be "Hallå Värld!", to be Swedish. D:

Thanks! Ouch, two mistakes in one word. Also, should I put a comma in
between the words?

Also, I am wondering, why is the undefined behavior of opCatAssign kept?
Couldn't every T[] know if it is the owner of the memory in question?
Sorry if I bring outdated discussions up unnecessarily.

We don't know how to do that cheaply.

Andrei

Oct 29 2009
=?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
Andrei Alexandrescu wrote:
Pelle Månsson 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!

Andrei

Your "Hallå Värd!" should be "Hallå Värld!", to be Swedish. D:

Thanks! Ouch, two mistakes in one word. Also, should I put a comma in
between the words?

Actually, I see now that you had it as "Hallå, värd!", and it should be
"Hallå, värld!", no need to capitalize the second word.

Unless what you want to say is "Hello, host!", in which case your värd
is correct.

Also, I am wondering, why is the undefined behavior of opCatAssign
kept? Couldn't every T[] know if it is the owner of the memory in
question? Sorry if I bring outdated discussions up unnecessarily.

We don't know how to do that cheaply.

Andrei

How about doing it expensively? Maybe storing a boolean in each T[]? I
think undefined behavior is bad.

Oct 29 2009
Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
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!

Andrei

Maybe I haven't been paying attention lately, but shouldn't

assert(x == 0)

be

assert(x[] == 0)

?

Oct 29 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ellery Newcomer 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!

Andrei

Maybe I haven't been paying attention lately, but shouldn't

assert(x == 0)

be

assert(x[] == 0)

?

Where does the former occur?

Thanks,

Andrei

Oct 29 2009
Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:
Ellery Newcomer 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!

Andrei

Maybe I haven't been paying attention lately, but shouldn't

assert(x == 0)

be

assert(x[] == 0)

?

Where does the former occur?

Thanks,

Andrei

top of page 102

Oct 29 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ellery Newcomer wrote:
Andrei Alexandrescu wrote:
Ellery Newcomer 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!

Andrei

Maybe I haven't been paying attention lately, but shouldn't

assert(x == 0)

be

assert(x[] == 0)

?

Where does the former occur?

Thanks,

Andrei

top of page 102

Thanks. Notice that x is an integer because it was fetched as array[5].

Andrei

Oct 29 2009
Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:
Ellery Newcomer wrote:
Andrei Alexandrescu wrote:
Ellery Newcomer 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!

Andrei

Maybe I haven't been paying attention lately, but shouldn't

assert(x == 0)

be

assert(x[] == 0)

?

Where does the former occur?

Thanks,

Andrei

top of page 102

Thanks. Notice that x is an integer because it was fetched as array[5].

Andrei

Oh wow. I'm dyslexic.

Oct 29 2009
"Saaa" <empty needmail.com> writes:
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!

Andrei

Makes me want to read the rest!

Will we get the electronic version with the paper version?

p2. typo: eenlists
p9. Is it ok to expect the order of an array expression to be like in
foreach ?
Maybe mention a[] = b.
p11. typo: no(t) palindrome
p12. Should in a safe module "~=" always create a new array?
p14. further expansions reads as if expansions have been made
especially because the comment is maybe that obvious that I was
looking for something else to be there.
p16. Is there anything other than the random values, unsafe about void
assignment?
When you write something to be unsafe, I expect it to not be allowed
safe modules.
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. An alternative to figure 4.5 could display row/column properties.
p20. change 1,000,000 to 1_000_000 :D to me the comma is a decimal separator
anyways.
p20. 40 words? <<<<
p21. Why use enum iso immutable? Probably in the previous chapters explained
:)
p21. Second paragraph reads as a solution to the above
p22. typo: array!literal
p25. Expected to read about ref in foreach

That's all :)

Oct 29 2009
"Saaa" <empty needmail.com> writes:
Also, no mention about .dup not being a deep dup.

Oct 29 2009
"Saaa" <empty needmail.com> writes:
crp
p20. 40 words? <<<<

those <<<< where for myself, to check

Oct 29 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Saaa wrote:
Will we get the electronic version with the paper version?

I'm not exactly sure how things will roll out. Probably yes.

p2. typo: eenlists
p9. Is it ok to expect the order of an array expression to be like in
foreach ?
Maybe mention a[] = b.
p11. typo: no(t) palindrome
p12. Should in a safe module "~=" always create a new array?
p14. further expansions reads as if expansions have been made
especially because the comment is maybe that obvious that I was
looking for something else to be there.
p16. Is there anything other than the random values, unsafe about void
assignment?
When you write something to be unsafe, I expect it to not be allowed
safe modules.
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. An alternative to figure 4.5 could display row/column properties.
p20. change 1,000,000 to 1_000_000 :D to me the comma is a decimal separator
anyways.
p20. 40 words? <<<<
p21. Why use enum iso immutable? Probably in the previous chapters explained
:)
p21. Second paragraph reads as a solution to the above
p22. typo: array!literal
p25. Expected to read about ref in foreach

That's all :)

Thanks much!

Andrei

Oct 29 2009
"Saaa" <empty needmail.com> writes:
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!

Oct 30 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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

Oct 30 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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   int s (40 bytes)."

Andrei

Oct 30 2009
"Saaa" <empty needmail.com> writes:
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   int 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 :)

Oct 30 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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   int 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

Oct 30 2009
"Saaa" <empty needmail.com> writes:
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   int 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 )

Oct 30 2009
"Robert Jacques" <sandford jhu.edu> writes:
On Thu, 29 Oct 2009 00:38:33 -0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> 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!

Andrei

Still reading, but here's a quick comment. I found it odd that the syntax
for element-wise copying (4.1.7) comes sections after the section on
copying (4.1.4). Perhaps a sentence mentioning where element-wise copying
can be found would be appropriate. (Props though on including a memory
layout figure. It may not seem like much, but I've seen Java students have
no idea what an array is in memory.)

Oct 29 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
On Thu, 29 Oct 2009 00:38:33 -0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> 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!

Andrei

Still reading, but here's a quick comment. I found it odd that the
syntax for element-wise copying (4.1.7) comes sections after the section
on copying (4.1.4). Perhaps a sentence mentioning where element-wise
copying can be found would be appropriate. (Props though on including a
memory layout figure. It may not seem like much, but I've seen Java
students have no idea what an array is in memory.)

Good point, thanks.

Andrei

Oct 29 2009
Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
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!

Thanks for the excerpt! I've only had the time to give it a brief skim
so far, but it's looking good. This is what I found:

p16: int quadrupeds[100], int legs[4 * quadrupeds.length]  <-  is the
C-style array declaration syntax intended?
p20: No mention of the "new T[][](rows, cols)" syntax?
p26 (User-Defined Types as Keys): No need for opEquals?

--
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Oct 29 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tom S 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!

Thanks for the excerpt! I've only had the time to give it a brief skim
so far, but it's looking good. This is what I found:

p16: int quadrupeds[100], int legs[4 * quadrupeds.length]  <-  is the
C-style array declaration syntax intended?

Thanks, fixed.

p20: No mention of the "new T[][](rows, cols)" syntax?

Oops, completely forgot about that one.

p26 (User-Defined Types as Keys): No need for opEquals?

There currently is, but there shouldn't and it won't.

Andrei

Oct 29 2009
Mike Parker <aldacron gmail.com> writes:
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!

Andrei

p.28 line 16:

symbols in less bits

should be

symbols in fewer bits


Oct 31 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Mike Parker 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!

Andrei

p.28 line 16:

>>> symbols in less bits

should be

>>> symbols in fewer bits

Thanks, fixed.

Andrei

Oct 31 2009