The Thermopylae excerpt of TDPL available online

[Saaa]

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