On Saturday, June 15, 2013 00:26:55 Ali Çehreli wrote:
> On 06/14/2013 07:17 PM, Jonathan M Davis wrote:
>  > It'll probably be the first book ever to be written entirely in ddoc.
> 
> The first ddoc book was a D book as well: ;)
> 
> 
> http://code.google.com/p/ddili/source/browse/trunk/src/ders/d.en/foreach_opa pply.d

So, you wrote your book with ddoc? I didn't know that. That's cool. It's a lot more versatile than you'd initially think.

- Jonathan M Davis

On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote:
> Heck, to throw something out there, why not "D Best Practices"?

Or "D Patterns and Practices" ?
With some David Simcha content in it (if he agrees with that of course).

On 06/15/2013 03:02 AM, Walter Bright wrote:
> On 6/14/2013 11:29 AM, monarch_dodra wrote:
>> In particular, while *stable*, it *is* still "evolving", which
>> means that while the old code still works, the patterns are still
>> shifting.
>
> One example of that is Andrei and I have been discussing the idea of
> moving import declarations from their traditional place at the top of
> the file to being in the most nested scope in which they are referenced.

One issue with local imports is that they hide local symbols.

On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
> One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro.

void main()
{
	import std.stdio;
	void writeln(string) {}
	writeln("foo");
	std.stdio.writeln("bar");
}

This writes only "bar".

On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote:
> On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
>> One issue with local imports is that they hide local symbols.
>
> Can you give an example? I can't repro.
>
> void main()
> {
> 	import std.stdio;
> 	void writeln(string) {}
> 	writeln("foo");
> 	std.stdio.writeln("bar");
> }
>
> This writes only "bar".

void writeln(string) {}
void main()
{
	import std.stdio;
	writeln("foo");
	std.stdio.writeln("bar");
}

?

On Fri, Jun 14, 2013 at 11:15:14PM -0400, Jonathan M Davis wrote:
> On Friday, June 14, 2013 19:57:52 Walter Bright wrote:
> > > Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc so that it can easily be converted into latex, html, and e-book formats rather than being tied to any particular format (I was going to use latex, but Andrei thought that a macro language would be better as latex is very tied to physical print and fixed layouts). It'll probably be the first book ever to be written entirely in ddoc.
> > 
> > This is just being a win all around!
> 
> My one major complaint about using ddoc is the need for the $(P ) macro everywhere, whereas LaTeX inserts paragraphs based on empty lines. I should probably create an enhancement request for that (and maybe even try and implement it), but I have enough to do right now that I decided that I'd just put up with it for now. But aside from the need for $(P ) macros, it's actually quite pleasant to work with.

I'm curious about how you manage to factor out / abstract away the niggling details of LaTeX, like the use of ".\ " after an abbreviation (to make it produce only an inter-word space, as opposed to the extra space at the end of a sentence), m-dash vs. n-dash, etc., some of which are quite specific to LaTeX but are quite necessary if you're going for print-quality typesetting. And what about embedded \footnote's? Section references? Do you have macros for all of them? Does it make it a bit cumbersome to type?


> I do have to process the ddoc before giving it to the compiler in order to generate the table of contents and index macros (since you can't generate those with just macros), but since I'm using a D script to do the build, that was actually pretty easy.
[...]

Isn't \tableofcontents enough to auto-generate the table of contents? Or are you talking about doing that for HTML output?


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius

On Saturday, 15 June 2013 at 15:29:23 UTC, Mr. Anonymous wrote:
> On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote:
>> On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
>>> One issue with local imports is that they hide local symbols.
>>
>> Can you give an example? I can't repro.
>>
>> void main()
>> {
>> 	import std.stdio;
>> 	void writeln(string) {}
>> 	writeln("foo");
>> 	std.stdio.writeln("bar");
>> }
>>
>> This writes only "bar".
>
> void writeln(string) {}
> void main()
> {
> 	import std.stdio;
> 	writeln("foo");
> 	std.stdio.writeln("bar");
> }

Oh, but that's not a local symbol, that's a module level symbol. The import is more local that the module level writeln, so that works as you would expect.

It also isn't a problem at all, because you can easily refer to the module level symbol by fully qualifying it.

module thismodule;
void writeln(string) {}
void main()
{
	import std.stdio;
	thismodule.writeln("foo");
	std.stdio.writeln("bar");
}

In any case, I'd recommend explicitly choosing which symbols to import in the local import to avoid name clashes.

On Saturday, June 15, 2013 08:55:11 H. S. Teoh wrote:
> I'm curious about how you manage to factor out / abstract away the niggling details of LaTeX, like the use of ".\ " after an abbreviation (to make it produce only an inter-word space, as opposed to the extra space at the end of a sentence), m-dash vs. n-dash, etc., some of which are quite specific to LaTeX but are quite necessary if you're going for print-quality typesetting. And what about embedded \footnote's? Section references? Do you have macros for all of them? Does it make it a bit cumbersome to type?

I'm early enough in the process that I haven't done much with those yet, and I'm likely to have to go back and fix that sort of thing up later (especially since about all I've done with LaTeX previously is write papers for college, and I didn't necessarily have to get everything as nice and exact as you would for a published book, so I'd likely be screwing some of that up even if I were writing directly in LaTeX). I expect to be using macros for them, but since you have to mark them up when writing in LaTeX anyway, it's not like I lose much using ddoc instead. It's just that the syntax changed. But it may be that if some of those can be automated, I'll end up doing something in the build script to manipulate the text to add that markup for me rather than using macros directly. I'll worry about that level of typesetting later. I wouldn't be worrying about that now even if I were writing directly in LaTeX.

And ddoc macros will easily allow me to add it all later. It's just that the ddoc files for stuff like html and epub will ignore them. I don't really need to create something which is completely target-agnostic. I just need to create something that easily converts to all of the target formats that I need. And ddoc will do that just fine.

> > I do have to process the ddoc before giving it to the compiler in order to generate the table of contents and index macros (since you can't generate those with just macros), but since I'm using a D script to do the build, that was actually pretty easy.
> 
> [...]
> 
> Isn't \tableofcontents enough to auto-generate the table of contents? Or are you talking about doing that for HTML output?

LaTeX will autogenerate the table of contents and the index, but html won't (and I don't think that something like epub will either, but I haven't gotten around to generating that yet). So, I have to generate the whole thing as macros, which the latex.ddoc file mostly gets rid of, and the html.ddoc file replaces with the appopriate text and links.

- Jonathan M Davis

I am referring to the beginning of this thread, but definitly wating for such a book to come out I have open a SO question (interactive media for a yet evolving langage) about effective design patterns and best practice in D. So if you have some clever methods you want to share, I am waiting for your answers. :-)

On Saturday, 15 June 2013 at 19:52:45 UTC, matovitch wrote:
> I am referring to the beginning of this thread, but definitly wating for such a book to come out I have open a SO question (interactive media for a yet evolving langage) about effective design patterns and best practice in D. So if you have some clever methods you want to share, I am waiting for your answers. :-)

the link : http://stackoverflow.com/questions/tagged/d (forget the obvious)