The Thermopylae excerpt of TDPL available online

[Andrei Alexandrescu]

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 at 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