Re: Why I'm hesitating to switch to D
On Jul 3, 11 13:34, Andrei Alexandrescu wrote: On 7/2/11 11:39 PM, Walter Bright wrote: On 6/30/2011 7:31 AM, Adam Ruppe wrote: Macros: TABLE=table$0/table TH=th$1/th$(TH $+) HEADERS=tr$(TH $1, $+)/tr TD=td$1/td$(TD $+) ROW=tr$(TD $1, $+)/tr Your idea also works for lists: $(UL $(LI item 1) $(LI item 2) ) now becomes: $(LIST item 1, item 2 ) where: LI=li$1/li$(LI $+) LIST=$(UL $(LI $1, $+)) Excellent idea. To complement it, we need a text with commas kind of thing so we don't need to insert $(COMMA) in longer list items: TXT = $0 $(LIST $(TXT stuff, with, commas), stuff without commas, $(TXT got, the, idea) ) Works? Andrei There should be a DIP or Bugzilla to summarize all these improvements :)
Re: Why I'm hesitating to switch to D
On 7/2/2011 10:34 PM, Andrei Alexandrescu wrote: Excellent idea. To complement it, we need a text with commas kind of thing so we don't need to insert $(COMMA) in longer list items: TXT = $0 $(LIST $(TXT stuff, with, commas), stuff without commas, $(TXT got, the, idea) ) Works? Yes, that works. I've been using ARGS for that! But the name isn't important.
Re: Why I'm hesitating to switch to D
On 2011-07-03 00:00, Adam D. Ruppe wrote: Andrei: Yah, agreed. I've done some work on that in the past; ideally each construct would generate a div/span with its own class and then everything would be controlled by CSSs. Yes, indeed. I'd like to go a little further than it goes now too, specifically, I'd like for any D identifiers - function names, etc. - that's outputted by the generator to be a macro too. For example, in code snippets or in function signatures. MyStruct myfunction(); Shouldn't just output, it should be like: $(DDOC_GLOBAL_NAME module.name, MyStruct) $(DDOC_PSYMBOL myFunction)(); (or maybe wrapping the return value in yet another macro. The more information we have, the better.) Why? So the global name can be translated right into a link. Ideally, you should be able to click on *any* D name in the docs and go right to it. The compiler can tell the scope too - global if the name is from another module. _NAME if it's from this module. _LOCAL if it's a local variable in a function example. This way, the macro can link straight to anything, with all the accuracy of the compiler's scoping and overload resolution rules. A textual post-processor can't be that accurate, so the links won't necessarily be accurate. But, even if the compiler did nothing but identify identifiers and pass the name to a macro, that'd be an improvement since it can always link to a search engine, (Like my own http://dpldocs.info/NAME ) for the final resolution. This lack of easy cross-referencing in examples and signatures, especially across modules, is the only problem I have with ddoc itself right now. Very good idea. -- /Jacob Carlborg
Re: Why I'm hesitating to switch to D
Adam D. Ruppe wrote: Andrei: Yah, agreed. I've done some work on that in the past; ideally each construct would generate a div/span with its own class and then everything would be controlled by CSSs. Yes, indeed. I'd like to go a little further than it goes now too, specifically, I'd like for any D identifiers - function names, etc. - that's outputted by the generator to be a macro too. For example, in code snippets or in function signatures. MyStruct myfunction(); Shouldn't just output, it should be like: $(DDOC_GLOBAL_NAME module.name, MyStruct) $(DDOC_PSYMBOL myFunction)(); (or maybe wrapping the return value in yet another macro. The more information we have, the better.) Why? So the global name can be translated right into a link. Ideally, you should be able to click on *any* D name in the docs and go right to it. The compiler can tell the scope too - global if the name is from another module. _NAME if it's from this module. _LOCAL if it's a local variable in a function example. This way, the macro can link straight to anything, with all the accuracy of the compiler's scoping and overload resolution rules. A textual post-processor can't be that accurate, so the links won't necessarily be accurate. But, even if the compiler did nothing but identify identifiers and pass the name to a macro, that'd be an improvement since it can always link to a search engine, (Like my own http://dpldocs.info/NAME ) for the final resolution. This lack of easy cross-referencing in examples and signatures, especially across modules, is the only problem I have with ddoc itself right now. I tried to do something similar some time ago, but I never finished it. It might help to understand how ddoc works and what needs to be changed to output semantic macros. I also thought about implementing something like DDOC_GLOBAL_NAME. IIRC toPrettyChars() already returns the complete name, so it shouldn't be difficult. The changes: https://bitbucket.org/jpf/dmd-ddoc-old/changeset/7db05853d613 https://bitbucket.org/jpf/dmd-ddoc-old/changeset/680c738df87a https://bitbucket.org/jpf/dmd-ddoc-old/changeset/e831b01351c8 And here's a list of the new macros: https://bitbucket.org/jpf/dmd-ddoc-old/wiki/Home (The DDOC2_TEXT and WHITESPACE macros are only for backward compatibility) -- Johannes Pfau
Re: Why I'm hesitating to switch to D
Andrei wrote: Works? Yes, I like this a lot. The same technique can be used on any kind of list: $(TAGS sorting, searching) $(SEE_ALSO std.algorithm.sort, std.algorithm.indexOf, std.algorithm.canFind) Which expand to links inside a div for the macro or something so an xml processor can pull them out of the result too. (I like the color section labels for text, but for see also, I now think one of these list macros is a better fit.)
Re: Why I'm hesitating to switch to D
Johannes Pfau wrote: I tried to do something similar some time ago, but I never finished it. Looks pretty nice also looks like a lot more work than I thought it would be!
Re: Why I'm hesitating to switch to D
On 06/30/2011 11:45 PM, Daniel Gibson wrote: Am 30.06.2011 23:41, schrieb simendsjo: On 30.06.2011 23:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Yeah, I hate backticks too.. I have to press Shift+` followed by space. But often space won't work as the text editor understands that space cannot be accented or something. So I often press ` twice and backspace to delete the last one. This gives me 4 key presses just for a single character... Wee... On Linux/X11 this could be fixed by disabling dead keys (at least as long as you don't need them to place accents on letters, which depends on the languages you're writing in). Dunno what the equivalent to this setting for Windows or OSX is though. Cheers, - Daniel And if you still need some accents you can enable the compose key: http://www.hermit.org/Linux/ComposeKeys.html -- Mike Wey
Re: Why I'm hesitating to switch to D
The Compose Key is fantastic. It's a tragedy it's not enabled by default. On Sat, Jul 2, 2011 at 11:47 AM, Mike Wey mike-...@example.com wrote: On 06/30/2011 11:45 PM, Daniel Gibson wrote: Am 30.06.2011 23:41, schrieb simendsjo: On 30.06.2011 23:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Yeah, I hate backticks too.. I have to press Shift+` followed by space. But often space won't work as the text editor understands that space cannot be accented or something. So I often press ` twice and backspace to delete the last one. This gives me 4 key presses just for a single character... Wee... On Linux/X11 this could be fixed by disabling dead keys (at least as long as you don't need them to place accents on letters, which depends on the languages you're writing in). Dunno what the equivalent to this setting for Windows or OSX is though. Cheers, - Daniel And if you still need some accents you can enable the compose key: http://www.hermit.org/Linux/**ComposeKeys.htmlhttp://www.hermit.org/Linux/ComposeKeys.html -- Mike Wey
Re: Why I'm hesitating to switch to D
On 6/29/11 9:18 AM, Adam D. Ruppe wrote: James Fisher wrote: I have no experience with DDOC, but TBH I don't intend to ever have any. The beauty of ddoc is you don't need experience with it. /** this is ddoc yes just this */ My biggest criticism of it is trivial to fix, but I haven't found the time yet. That is, the std.ddoc that is used to build the main site outputs presentational html instead of semantic html. Just going through that and changing to more semantic tags - so the automatically generated data from the ddoc back end is not lost by the time it gets to html - would make a big difference. Then you can more easily apply css or other xml transformations to it. Yah, agreed. I've done some work on that in the past; ideally each construct would generate a div/span with its own class and then everything would be controlled by CSSs. Also as another note, the web pages really *aren't* written in ddoc. Take a look at std.ddoc some day... it has plain HTML for the main page structure. If the content tags were more semantic, between css and that plain html structure, boom, there's the stuff to attack for the web. No need to think about ddoc at all. I agree. It's a bit difficult for me to understand all the fuss. Arguments regarding learning of ddoc literally take longer to type than to obviate by learning. BTW, if anyone wants to contribute to the site, usage of html is not a barrier. Andrei
Re: Why I'm hesitating to switch to D
On 6/29/11 9:09 AM, James Fisher wrote: A related thought here: are we aware of GitHub site hosting? AFAICT d-p-l.org http://d-p-l.org doesn't use it, so I guess the repo is being pulled to another server? I think this has been cleared already - the d-programming-language.org website is on github. Andrei
Re: Why I'm hesitating to switch to D
On 6/29/11 1:33 PM, Adam Ruppe wrote: Dejan Lekic wrote: Conclusion: -- Get informed. To be fair, when someone is saying you aren't very good at getting the word out in a consistent way, saying get informed is just shifting the blame right back. One thing I didn't think about about is the necessity of a consistent logo. That alone is an excellent suggestion. Andrei
Re: Why I'm hesitating to switch to D
On Jul 3, 11 03:33, Andrei Alexandrescu wrote: On 6/29/11 9:09 AM, James Fisher wrote: A related thought here: are we aware of GitHub site hosting? AFAICT d-p-l.org http://d-p-l.org doesn't use it, so I guess the repo is being pulled to another server? I think this has been cleared already - the d-programming-language.org website is on github. Andrei By 'github hosting' I think he means 'github:pages' (http://pages.github.com/). Having d-p-l.org hosted outside of github is fine, as long as it is synced (pulled) frequently enough with the github repo.
Re: Why I'm hesitating to switch to D
On 6/29/11 2:58 PM, Walter Bright wrote: On 6/29/2011 12:09 PM, Adam Ruppe wrote: One thing I like about ddoc is how hands-off it is. You can put almost any text inside it and it gets passed out unmolested. I think the only character that gets disappeared or altered in ddoc is $. The more special characters in the markup language, the more trouble you're going to have. That's why Ddoc is pretty limited to $. One good thing about ddoc is its uniformity, $(name comma-sep-list) is replaced by the definition of name. That should be pretty much it. If anything I'd add to that uniformity: (a) remove the syntax which is quite difficult to use with my editors, (b) replace params: and etc. with macro-style syntax. Andrei
Re: Why I'm hesitating to switch to D
On 6/29/11 4:04 PM, Adam Ruppe wrote: Nick Sabalausky wrote: I'm firmly in the camp that HTML *is* presentation. The problem here is two things can look the same, but should be treated differently by post-processing programs. For example, lists of members. The presentational style code in std.ddoc now generates this kind of thing: dl dtenum Foo/dt dddl dtmember1/dt /dl/dd dtstruct Bar/dt blah blah blah /dl Now, suppose you want to do a post-processor of some sort to grab all enums. It's more painful than it has to be - instead of using the html structure, you've gotta scan the inner text too for the keywords. You might want them to look the same, but it's still sometimes helpful to be able to differentiate them by some kind of metadata. I'm not really against having both presentational and semantic data in the html, since the post-processor can always strip out stuff it doesn't care about. But, if that semantic stuff isn't present, it causes pain for other scenarios down the line. (Contrast to missing presentational stuff, which can be fairly easily regenerated with rich enough semantics.) When I get around to updating std.ddoc, I'll have it looking almost the same except I'd add class=struct and class=enum to the list macros too. Yes please. Excellent point. Andrei
Re: Why I'm hesitating to switch to D
Andrei Alexandrescu wrote: If anything I'd add to that uniformity: I don't know, it seems ok the way it is. The sections aren't quite macros, though they are implemented that way (sections become DDOC_SECTION and DDOC_SECTION_H). I like the way they look though. It's a natural way to organize stuff.
Re: Why I'm hesitating to switch to D
Andrei: Yah, agreed. I've done some work on that in the past; ideally each construct would generate a div/span with its own class and then everything would be controlled by CSSs. Yes, indeed. I'd like to go a little further than it goes now too, specifically, I'd like for any D identifiers - function names, etc. - that's outputted by the generator to be a macro too. For example, in code snippets or in function signatures. MyStruct myfunction(); Shouldn't just output, it should be like: $(DDOC_GLOBAL_NAME module.name, MyStruct) $(DDOC_PSYMBOL myFunction)(); (or maybe wrapping the return value in yet another macro. The more information we have, the better.) Why? So the global name can be translated right into a link. Ideally, you should be able to click on *any* D name in the docs and go right to it. The compiler can tell the scope too - global if the name is from another module. _NAME if it's from this module. _LOCAL if it's a local variable in a function example. This way, the macro can link straight to anything, with all the accuracy of the compiler's scoping and overload resolution rules. A textual post-processor can't be that accurate, so the links won't necessarily be accurate. But, even if the compiler did nothing but identify identifiers and pass the name to a macro, that'd be an improvement since it can always link to a search engine, (Like my own http://dpldocs.info/NAME ) for the final resolution. This lack of easy cross-referencing in examples and signatures, especially across modules, is the only problem I have with ddoc itself right now.
Re: Why I'm hesitating to switch to D
On 7/2/2011 3:00 PM, Adam D. Ruppe wrote: Shouldn't just output, it should be like: $(DDOC_GLOBAL_NAME module.name, MyStruct) $(DDOC_PSYMBOL myFunction)(); Sounds like a good idea for a pull request!
Re: Why I'm hesitating to switch to D
Walter Bright wrote: Sounds like a good idea for a pull request! Aye. I just wish my todo list was shorter!
Re: Why I'm hesitating to switch to D
On 7/2/2011 3:35 PM, Adam D. Ruppe wrote: Walter Bright wrote: Sounds like a good idea for a pull request! Aye. I just wish my todo list was shorter! Mine has several thousand items on it!
Re: Why I'm hesitating to switch to D
On 2011-07-02 15:55:13 -0400, KennyTM~ kenn...@gmail.com said: On Jul 3, 11 03:33, Andrei Alexandrescu wrote: On 6/29/11 9:09 AM, James Fisher wrote: A related thought here: are we aware of GitHub site hosting? AFAICT d-p-l.org http://d-p-l.org doesn't use it, so I guess the repo is being pulled to another server? I think this has been cleared already - the d-programming-language.org website is on github. Andrei By 'github hosting' I think he means 'github:pages' (http://pages.github.com/). Having d-p-l.org hosted outside of github is fine, as long as it is synced (pulled) frequently enough with the github repo. Agree. That said, it might be beneficial to use github (or some other server) as a mirror for the DMD binary packages, as http://ftp.digitalmars.com/ is notoriously slow to download from. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Why I'm hesitating to switch to D
On 6/30/2011 7:31 AM, Adam Ruppe wrote: Macros: TABLE=table$0/table TH=th$1/th$(TH $+) HEADERS=tr$(TH $1, $+)/tr TD=td$1/td$(TD $+) ROW=tr$(TD $1, $+)/tr Your idea also works for lists: $(UL $(LI item 1) $(LI item 2) ) now becomes: $(LIST item 1, item 2 ) where: LI=li$1/li$(LI $+) LIST=$(UL $(LI $1, $+))
Re: Why I'm hesitating to switch to D
On 7/2/11 11:39 PM, Walter Bright wrote: On 6/30/2011 7:31 AM, Adam Ruppe wrote: Macros: TABLE=table$0/table TH=th$1/th$(TH $+) HEADERS=tr$(TH $1, $+)/tr TD=td$1/td$(TD $+) ROW=tr$(TD $1, $+)/tr Your idea also works for lists: $(UL $(LI item 1) $(LI item 2) ) now becomes: $(LIST item 1, item 2 ) where: LI=li$1/li$(LI $+) LIST=$(UL $(LI $1, $+)) Excellent idea. To complement it, we need a text with commas kind of thing so we don't need to insert $(COMMA) in longer list items: TXT = $0 $(LIST $(TXT stuff, with, commas), stuff without commas, $(TXT got, the, idea) ) Works? Andrei
Re: Why I'm hesitating to switch to D
On 2011-06-30 21:47, KennyTM~ wrote: On Jul 1, 11 03:27, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message news:iuig3e$2m1k$1...@digitalmars.com... Back ticks are used for D raw string literals, and I now think that was a mistake. What would you have used instead? There is r... which is equivalent to `...`. I've only used `...`. I use `...` when I need to enclose a . -- /Jacob Carlborg
Re: Why I'm hesitating to switch to D
On 2011-07-01 02:19, Jonathan M Davis wrote: I switched to dvorak _and_ got one of these: http://www.kinesis- ergo.com/advantage.htm No one is going to be using my computer with my keyboard. Though honestly, as much as I like dvorak, I wouldn't advise that anyone switch to it. Too many programs assume qwerty, so all of their shortcuts are designed for it. Stuff like the shortcuts for cut, copy, and paste are on completely different places on the keyboard and don't work as well (only cut can be done with just your left hand). I had to completely remap vim to be able to use it. Other programs need their keys or shortcuts remapped to work very well. It just causes problems for stuff that assumes qwerty. So, it's likely more pain than its worth. My keyboard is awesome regardless of whether you use qwerty or dvork though. I can actually type numbers on it without looking, which I could never do on a normal keyboard, because the keys aren't vertically aligned on a normal keyboard. It's expensive, but I'm quite happy that I bought it. - Jonathan M Davis Using this keyboard: http://www.typematrix.com with the dvorak layout you can use other keys then ctrl+x/c/v for cut, copy and paste. If you look in the store, and choose Skin Only and then dvorka you can see it has keys for cut, copy and paste in similar places where ctrl+x/c/v would be on a normal keyboard. -- /Jacob Carlborg
Re: Why I'm hesitating to switch to D
On 2011-07-01 02:29, simendsjo wrote: Looks ergonomically correct, but pretty massive. I've considered TypeMatrix (http://typematrix.com/) in the past, but I think it's a bit expensive. I've never understood how keyboards with keys sitting almost vertical can be ergonomically correct. It's like pressing keys sitting on a wall. -- /Jacob Carlborg
Re: Why I'm hesitating to switch to D
On 01.07.2011 11:33, Jacob Carlborg wrote: On 2011-07-01 02:29, simendsjo wrote: Looks ergonomically correct, but pretty massive. I've considered TypeMatrix (http://typematrix.com/) in the past, but I think it's a bit expensive. I've never understood how keyboards with keys sitting almost vertical can be ergonomically correct. It's like pressing keys sitting on a wall. I know. It looks very wrong in this regard. But I like the placement of other keys like enter and backspace.
Re: Why I'm hesitating to switch to D
Robert Clipsham wrote: On 29/06/2011 19:14, Walter Bright wrote: On 6/29/2011 4:03 AM, Adam Richardson wrote: I'll admit that I looked through to see what I could help out with on the website, but ddoc stopped me in my tracks. How did it stop you? DDoc vs Markdown: * Pretty much everyone who uses github, stackoverflow, and many other sites knows some amount of markdown * I've been using D for years and I pride myself on not knowing the hideous DDoc beyond Params: Example: etc. * DDoc macros make even the simplest things ugly Sure, but it's really apples and oranges. Any such template system for markup is both complicated, limited and convenient at once. It has no power at all. DDoc is the other way around, it's a very different approach. The equivalent to ddoc's extensibility would be hacking the sources of a markdown processor to extend it. Now that's painful. You could, for example, write everything in markdown but first put it through ddoc and then process it's output with some markdown tool. That way you write mostly simple markdown and have some extra power from the macro system. That's actually the approach that ddoc for D code has: very limited sugar for the most common cases, but with the optional power to extend it. The other way around should be possible too: a markdown macro which tags a fragment for postprocessing.
Re: Why I'm hesitating to switch to D
On 2011-06-29 22:16, Nick Sabalausky wrote: Adam Richardsonsimples...@gmail.com wrote in message news:mailman.1291.1309377741.14074.digitalmar...@puremagic.com... On Wed, Jun 29, 2011 at 3:48 PM, Nick Sabalauskya@a.a wrote: James Fisherjameshfis...@gmail.com wrote in message news:mailman.1279.1309339361.14074.digitalmar...@puremagic.com... I don't aim to proselytize one mini-language over another, as they're much of a muchness. But I'd hope to convince people that: - Besides required functionality, the key reason to choose one markup/documentation/html-generating format is popularity. It opens up development to new users, frees up maintainers of old documentation generators, and gives you new tools to use for free. Markup formats are one area where Might Is Right. Popularity should *never* be a significant concern. That's how we end up with complete shit like PHP becoming widespread. Easy :) While I wouldn't use PHP for systems programming, PHP is a solid tool for building websites. It's complete garbage for building websites. It's complete garbage for *everything*. And I've dealt with PHP and PHP web apps a *lot*. I can't think of a single other web-oriented tool or language that I wouldn't rather build a website with than PHP. Even Classic-ASP with VBScript, absolutely horrid as it is, is at least a somewhat *stable* target. I wouldn't completely agree with that. I hate PHP as well but I would choose PHP rather than Classic-ASP with VBScript. -- /Jacob Carlborg
Re: Why I'm hesitating to switch to D
On 2011-06-29 22:07, Nick Sabalausky wrote: Jacob Carlborgd...@me.com wrote in message news:iufbc8$22ob$1...@digitalmars.com... On 2011-06-29 10:29, Walter Bright wrote: On 6/28/2011 11:46 PM, Jacob Carlborg wrote: I think it makes it hard when most of the pages are written in DDOC. It doesn't help to attract web designers. I have no idea what professional web designers use, but I did many web pages using html in a regular text editor. It was awful. That *is* awful. I use Ruby on Rails with the following languages (and what they compile to): HAML - HTML SASS - CSS CoffeeScript - JavaScript And Ruby of course. I wouldn't mind switching to some compile down to HTML/CSS/etc thing, but all the mature ones I've seen seem to place a strong emphasis on whitespace-syntax which is something I can't stand. YAML's about the only place I can really tolerate it (at least in large part because it's purely optional, and because it's purely a data language (but then, so are HTML and CSS)). And then there's some other rediculous thing CoffeeScript does...umm, IIRC, I think it's implicit declarations. All of the above languages (except Ruby) use indentation for scopes. implicit declarations do you mean that you don't have to declare a variable before you use it? In that case, Ruby has that as well. Comparing, for example, HAML and HTML, I think that HAML looks cleaner than HTML. Anyway, I like them. First I didn't either like whitespace aware languages but in these cases I like it. But I would never want it in D. -- /Jacob Carlborg
Re: Why I'm hesitating to switch to D
On 2011-06-29 22:31, Andrej Mitrovic wrote: I would agree that macros are a bit hard to read in ddoc. There's some nice ideas in this thread. Luckily I don't get to see garbage like this in D code: ///summary /// Required designer variable. summary private System.ComponentModel.Container components = null; Really, you need XML tags to give me 3 words of information that I could live without? It basically guarantees nobody will touch the language without an XML processing IDE/editor. Maybe VIM/Emacs do have XML processing built in so they can hide this thing, but a single '//' would do just fine here, no? :) Having XML in comments/documentation like that is just ridicules. -- /Jacob Carlborg
Re: Why I'm hesitating to switch to D
On 2011-06-30 05:35, Ary Manzana wrote: On 6/30/11 1:00 AM, Walter Bright wrote: On 6/29/2011 4:25 AM, Walter Bright wrote: Ddoc is: 7. We don't get left in the lurch if said third party quits. 8. Ddoc understands the semantics of D code. Third party doc generators never will. So the semantics of D code can only be understood by the compiler? Hmmm... The compiler will be the best tool for understanding a language. Unless you do something like Clang/LLVM does. Where the compiler and other tools build upon the same library that handles the language. -- /Jacob Carlborg
Re: Why I'm hesitating to switch to D
Jacob Carlborg d...@me.com wrote in message news:iuh6jn$3df$2...@digitalmars.com... On 2011-06-29 22:16, Nick Sabalausky wrote: Adam Richardsonsimples...@gmail.com wrote in message news:mailman.1291.1309377741.14074.digitalmar...@puremagic.com... On Wed, Jun 29, 2011 at 3:48 PM, Nick Sabalauskya@a.a wrote: James Fisherjameshfis...@gmail.com wrote in message news:mailman.1279.1309339361.14074.digitalmar...@puremagic.com... I don't aim to proselytize one mini-language over another, as they're much of a muchness. But I'd hope to convince people that: - Besides required functionality, the key reason to choose one markup/documentation/html-generating format is popularity. It opens up development to new users, frees up maintainers of old documentation generators, and gives you new tools to use for free. Markup formats are one area where Might Is Right. Popularity should *never* be a significant concern. That's how we end up with complete shit like PHP becoming widespread. Easy :) While I wouldn't use PHP for systems programming, PHP is a solid tool for building websites. It's complete garbage for building websites. It's complete garbage for *everything*. And I've dealt with PHP and PHP web apps a *lot*. I can't think of a single other web-oriented tool or language that I wouldn't rather build a website with than PHP. Even Classic-ASP with VBScript, absolutely horrid as it is, is at least a somewhat *stable* target. I wouldn't completely agree with that. I hate PHP as well but I would choose PHP rather than Classic-ASP with VBScript. Well, to be fair, if I had to choose between PHP and Classic ASP/VBScript, my choice would probably be to bash my head into a wall. Preferably brick. It's not like I'd happily pick ASP.
Re: Why I'm hesitating to switch to D
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.1298.1309383687.14074.digitalmar...@puremagic.com... Overreacting troll is overreacting. ;] Troll feeder is troll feeding :)
Re: Why I'm hesitating to switch to D
On Jun 30, 11 11:57, Walter Bright wrote:
On 6/29/2011 3:56 PM, KennyTM~ wrote:
The easier, nicer, and more productive part:
- Native support of sectioning and anchors instead of sprinkling with
h3 and
a name's.
In Ddoc, you can define your own macros to do that, for example:
H3=h3$0/h3
and then:
$(H3 This is a Header 3)
There is no reason whatsoever you are stuck with the defaults.
Right, it's possible, but it is ugly. Isn't the point to show the syntax
easier, nicer, and more productive?
Linking is also more natural.
What if the link points to another file? And what if sometimes you want
it intrafile, and another time interfile, without changing the source text?
Yes it is supported by Sphinx with the :ref:`target` syntax.
http://sphinx.pocoo.org/markup/inline.html#ref-role
In DDoc you have to write $(LINK2 foo.html#bar, bar). I don't see that
as a solution. For example, if you move MixinDeclaration to
declaration.dd, then existing link to MixinDeclaration will break
because you have to write $(LINK2 module.html#MixinDeclaration) or
define a macro in macro.ddoc, because DDoc can't automatically track the
targets. This won't happen in reST/Sphinx.
All existing approach listed in
http://d-programming-language.org/ddoc.html support inter- and
intra-file cross-referencing
And what if, for the unordered list, you wish to add a class=foo
attribute for one of them, and class=bar for another?
Why would you need to do that? Anyway, this is also supported by
docutils natively with the '.. class::' directive ('.. rst-class::' in
Sphinx):
.. rst-class:: foo
* 1
* 2
* 3
.. rst-class:: bar
* 4
* 5
* 6
http://sphinx.pocoo.org/rest.html#id2
http://docutils.sourceforge.net/docs/ref/rst/directives.html#class
- One could use an external Turing-complete parser (in Python, though)
for some
special block of documentation, e.g. the grammar list, instead of
having to hack
the macro system for the result. The latter is like having to
highlight the D
code using $(RED x) $(GREEN x) $(BLUE x) manually.
- Writing reST is really like writing document. Writing DDoc is like
writing Lisp.
- reST has better support than DDoc is many aspects (output format,
stylesheets,
plugins, documentations, etc.).
Let's say I have some C++ code, C code, and ASM code, and want them to
use different css classes. In Ddoc, I'd do:
$(CCODE
... C code ...
)
$(CPPCODE
... C++ code ...
)
$(ASMCODE
... asm code ...
)
and by defining the macros, I can set them to use div's, pre's, whatever
attributes I want, and do this as many times as I need to for ALL of the
constructs.
That's not an advantage of DDoc. As I've shown above you could use the
'.. class::' directive to assign classes, and it's also possible to
write your own directive or inline marker, more than DDoc's simple macro
system can do (e.g. it can create Phobos's links on the top without
relying on Javascript), and you could even use the '.. raw::' directive
to drop down to HTML.
But whether the document writer want to expose to these capabilities
frequently? I'd say no, they'd rather have functions to format the
document nicely by default.
Furthermore, Sphinx has the '.. code-block::' directive to even syntax
highlight those C and C++ code for you.
.. code-block:: c
int main() { return 0; }
.. code-block:: c++
template typename T
T min(const T a, const T b) { return a b ? a : b; }
.. code-block:: gas
pushl %ebp
movl%esp,%ebp
pushl %edi
pushl %esi
pushl %ebx
subl$0x01ec,%esp
calll 0x000c5361
popl%ebx
http://sphinx.pocoo.org/markup/code.html
Generally, how good or how bad your Ddoc source looks like depends on
how you've defined the macros.
This could be applied to everything, like C++ vs D ;). I'd rather the
source look good out of the box than having to define dozens of macros
to make it look good.
Re: Why I'm hesitating to switch to D
Walter Bright newshou...@digitalmars.com wrote in message news:iufs0j$pnj$1...@digitalmars.com... And, in general, I think a programming language web site should be fairly straightforward. I don't think having it look like a Coca Cola web site is appropriate for the audience. It should be easy to navigate, easy on the eyes, and just the facts, ma'am. Heh, I can just imagine a D site packed with stock photos of overly-excited models on trampolines (like they have on boxes of low-fat foods) or suits smiling into the camera because they just absolutely *love* being telephone support reps. Horrifying thought...
Re: Why I'm hesitating to switch to D
On Jun 30, 11 13:20, Walter Bright wrote: On 6/29/2011 8:35 PM, Ary Manzana wrote: On 6/30/11 1:00 AM, Walter Bright wrote: On 6/29/2011 4:25 AM, Walter Bright wrote: Ddoc is: 7. We don't get left in the lurch if said third party quits. 8. Ddoc understands the semantics of D code. Third party doc generators never will. So the semantics of D code can only be understood by the compiler? Hmmm... How many third party doc generators include essentially a compiler for every language they support - or even for any of them? You don't need a compiler to understand a language for documenting the code. A lexer is enough. And Pygment does support D. http://pygments.org/languages/ Note that I and likely James Fisher are not talking about generating header docs (i.e. Phobos docs), which point 8 will be valid. We're talking about http://d-programming-language.org/language-reference.html which restricting the choice to DDoc is unnecessary.
Re: Why I'm hesitating to switch to D
On 2011-06-30 10:13, Nick Sabalausky wrote: Jacob Carlborgd...@me.com wrote in message news:iuh6jn$3df$2...@digitalmars.com... On 2011-06-29 22:16, Nick Sabalausky wrote: Adam Richardsonsimples...@gmail.com wrote in message news:mailman.1291.1309377741.14074.digitalmar...@puremagic.com... On Wed, Jun 29, 2011 at 3:48 PM, Nick Sabalauskya@a.a wrote: James Fisherjameshfis...@gmail.com wrote in message news:mailman.1279.1309339361.14074.digitalmar...@puremagic.com... I don't aim to proselytize one mini-language over another, as they're much of a muchness. But I'd hope to convince people that: - Besides required functionality, the key reason to choose one markup/documentation/html-generating format is popularity. It opens up development to new users, frees up maintainers of old documentation generators, and gives you new tools to use for free. Markup formats are one area where Might Is Right. Popularity should *never* be a significant concern. That's how we end up with complete shit like PHP becoming widespread. Easy :) While I wouldn't use PHP for systems programming, PHP is a solid tool for building websites. It's complete garbage for building websites. It's complete garbage for *everything*. And I've dealt with PHP and PHP web apps a *lot*. I can't think of a single other web-oriented tool or language that I wouldn't rather build a website with than PHP. Even Classic-ASP with VBScript, absolutely horrid as it is, is at least a somewhat *stable* target. I wouldn't completely agree with that. I hate PHP as well but I would choose PHP rather than Classic-ASP with VBScript. Well, to be fair, if I had to choose between PHP and Classic ASP/VBScript, my choice would probably be to bash my head into a wall. Preferably brick. It's not like I'd happily pick ASP. A brick wall actually sounds better :) -- /Jacob Carlborg
Re: Why I'm hesitating to switch to D
On 6/30/2011 1:26 AM, KennyTM~ wrote:
Right, it's possible, but it is ugly. Isn't the point to show the syntax
easier, nicer, and more productive?
Ddoc has pretty much only one syntax. Sphinx seems to have a lot of them.
What if the link points to another file? And what if sometimes you want
it intrafile, and another time interfile, without changing the source text?
Yes it is supported by Sphinx with the :ref:`target` syntax.
http://sphinx.pocoo.org/markup/inline.html#ref-role
What's natural about that?
In DDoc you have to write $(LINK2 foo.html#bar, bar).
No, you don't have to. I'll often write it as:
$(CHAPTER foo, bar)
I don't see that as a
solution. For example, if you move MixinDeclaration to declaration.dd, then
existing link to MixinDeclaration will break because you have to write $(LINK2
module.html#MixinDeclaration) or define a macro in macro.ddoc, because DDoc
can't automatically track the targets. This won't happen in reST/Sphinx.
Yes, the idea that a link may be somewhere in a collection files, is probably
better.
And what if, for the unordered list, you wish to add a class=foo
attribute for one of them, and class=bar for another?
Why would you need to do that?
Style sheets. For example, sometimes you want a list to go out horizontally
rather than vertically; this is controlled by the style sheet. You specify a
class for the list, and then the layout for that class.
Anyway, this is also supported by docutils
natively with the '.. class::' directive ('.. rst-class::' in Sphinx):
.. rst-class:: foo
* 1
* 2
* 3
.. rst-class:: bar
* 4
* 5
* 6
http://sphinx.pocoo.org/rest.html#id2
http://docutils.sourceforge.net/docs/ref/rst/directives.html#class
This I don't particularly like. I've got to learn a new syntax for it, I've got
to read and learn a manual on what 'class' means for Sphinx and do some
spelunking to figure out if it is the same thing as an html class or something
different. The syntax arguably isn't better, either. It's just different. Even
worse, if I want to change the classes, I've got to do a global search/replace.
With Ddoc, I change one macro.
With Ddoc, you can read the HTML manual and apply it directly to Ddoc. Ddoc
doesn't even know what HTML is, so it has no need to replicate its functionality
in a same-only-different manner.
HTML has lots of these attributes. Are they *all* in Sphinx? What if a new one
is added to HTML? What if I want to use :: in my text? One problem with a lot of
text markup is you've got to provide escapes for all that - which is why Ddoc
pretty much sticks to $.
In Ddoc, for another example, I did the documentation for the Digital Mars C++
runtime library. For web pages, I formatted things using definition lists.
Unfortunately, those came out badly in the Kindle, but using h4 instead worked
much better. Since I had written the docs in terms of a higher level Ddoc macro,
I simply changed its definition to use h4 instead of dl, and voila! thousands of
library functions got fixed without incredibly tediously recoding each one.
For me, a viable doc system needs to have some sort of symbolic redefinition
capability. Textual macro processors have existed for a long time, and they work
well for that, which is why Ddoc went that direction. (You might notice that
Ddoc macros are a lot like makefile macros!)
(I did consider using the C macro preprocessor, but it is too specialized for
C.)
and by defining the macros, I can set them to use div's, pre's, whatever
attributes I want, and do this as many times as I need to for ALL of the
constructs.
That's not an advantage of DDoc. As I've shown above you could use the '..
class::' directive to assign classes,
Do I gotta do that every time I write a CPPCODE section?
and it's also possible to write your own
directive or inline marker,
That would be better.
more than DDoc's simple macro system can do (e.g. it
can create Phobos's links on the top without relying on Javascript), and you
could even use the '.. raw::' directive to drop down to HTML.
But whether the document writer want to expose to these capabilities frequently?
I'd say no, they'd rather have functions to format the document nicely by
default.
The default works well 95% of the time. The rest of the time it doesn't, and if
you have to leave the documentation system, it really sucks.
Furthermore, Sphinx has the '.. code-block::' directive to even syntax highlight
those C and C++ code for you.
What if you have something it doesn't highlight for you? Like D? :-)
I'd rather the source
look good out of the box than having to define dozens of macros to make it look
good.
The point is, you can customize the macros to match the semantic content of your
documentation. It is not necessarily a low level thing. For example, I might
want to document a library function like this:
$(RTLENTRY name,
$(HEADER name.h)
$(PROTOTYPE
void name();
)
$(DESCRIPTION
name() is the
Re: Why I'm hesitating to switch to D
On 6/30/2011 1:26 AM, KennyTM~ wrote: Yes it is supported by Sphinx with the :ref:`target` syntax. Take a look at this: http://sphinx.pocoo.org/rest.html#tables +++--+--+ | Header row, column 1 | Header 2 | Header 3 | Header 4 | | (header rows optional) || | | +++==+==+ | body row 1, column 1 | column 2 | column 3 | column 4 | +++--+--+ | body row 2 | ...| ... | | +++--+--+ I originally did think about doing this for tables in Ddoc. But although it looks reasonable, it is unbearably tedious to actually have to type in a complex table like this, and even worse to try and change such a table. Have you ever tried it? I have. Awful. Try writing 50 different tables that way. Next, look at: http://sphinx.pocoo.org/rest.html#sections •# with overline, for parts •* with overline, for chapters •=, for sections •-, for subsections •^, for subsubsections •, for paragraphs I challenge anyone to remember this table. Heck, I can't even remember the C operator precedence table 100%. And: http://sphinx.pocoo.org/rest.html#external-links .. _a link: http://example.com/ is that really better than: $(LINK2 http://example.com/, a link) ? Sphinx is a large and complex markup system that is arguably as much to learn as HTML is - and I still need to learn HTML. Everything in Sphinx seems to have a special syntax, while Ddoc has a single syntax. Sphinx has some nice things, like the automatic connecting of links. But I don't find it, on the whole, better. Granted, I haven't actually used it and might think differently if I did. If Sphinx was the industry standard that everyone uses, that might make it compelling in spite of its problems. But it isn't, I'd never heard of it before your links. (Of course, that might just mean I'm living under a rock!) I've seen all kinds of markup languages, starting with runoff in the 70s. I'm modestly familiar with runoff (did a term paper with it! that was the end of my typewriter), unix man, mediawiki, other wiki markups, reddit markup, javadoc, doxygen, Latex, html (of course), the crazy formats used in various web forums, etc.
Re: Why I'm hesitating to switch to D
Walter: If Sphinx was the industry standard that everyone uses, that might make it compelling in spite of its problems. But it isn't, I'd never heard of it before your links. (Of course, that might just mean I'm living under a rock!) Sphinx is kind of new, but it's used for Python docs and elsewhere. Sphinx is based on ReST, that is not new and is widely used: http://en.wikipedia.org/wiki/ReStructuredText Bye, bearophile
Re: Why I'm hesitating to switch to D
Walter Bright wrote:
In Ddoc, you can define your own macros to do that, for example:
H3=h3$0/h3
So, I was just writing up a complaint about ddoc's escaping of
characters when I looked at doc.c and found it already had a
solution... except looking at the code, it doesn't seem to be
fully implemented.
===
$ cat test72.d
extern(C) void printf(in char*, ...);
/**
Macros:
ESCAPES=/a/lol
*/
/// this is (cool) $19 span arguably wrong
void main() {
printf(Hello, amp; world!\n.ptr);
}
$ dmd test72.d -D
Segmentation fault
=
Poo. Now I wish I hadn't deleted the proposal I typed up...
generally though: have the ESCAPES thing be implemented fully, and
add ($DDOC_RAW) to bypass it, so you can still embed html in there
while getting escaped output by default.
(in std.ddoc you'd define HTML=($DDOC_RAW $0) so you can handle different
embedded
raw source differently in different output formats.)
Re: Why I'm hesitating to switch to D
On Jun 30, 11 18:25, Walter Bright wrote:
On 6/30/2011 1:26 AM, KennyTM~ wrote:
Right, it's possible, but it is ugly. Isn't the point to show the syntax
easier, nicer, and more productive?
Ddoc has pretty much only one syntax. Sphinx seems to have a lot of them.
OK, if that's a concern.
What if the link points to another file? And what if sometimes you want
it intrafile, and another time interfile, without changing the source
text?
Yes it is supported by Sphinx with the :ref:`target` syntax.
http://sphinx.pocoo.org/markup/inline.html#ref-role
What's natural about that?
In DDoc you have to write $(LINK2 foo.html#bar, bar).
No, you don't have to. I'll often write it as:
$(CHAPTER foo, bar)
The 'foo' is still here. By natural I mean once you have a 'bar', you
often don't need to care about the 'foo'. Also, in
d-programming-language.org $(LINK2 x.html#y, y) is used, but $(CHAPTER
x, y) does not exist.
I don't see that as a
solution. For example, if you move MixinDeclaration to declaration.dd,
then
existing link to MixinDeclaration will break because you have to write
$(LINK2
module.html#MixinDeclaration) or define a macro in macro.ddoc, because
DDoc
can't automatically track the targets. This won't happen in reST/Sphinx.
Yes, the idea that a link may be somewhere in a collection files, is
probably better.
And what if, for the unordered list, you wish to add a class=foo
attribute for one of them, and class=bar for another?
Why would you need to do that?
Style sheets. For example, sometimes you want a list to go out
horizontally rather than vertically; this is controlled by the style
sheet. You specify a class for the list, and then the layout for that
class.
OK.
Anyway, this is also supported by docutils
natively with the '.. class::' directive ('.. rst-class::' in Sphinx):
.. rst-class:: foo
* 1
* 2
* 3
.. rst-class:: bar
* 4
* 5
* 6
http://sphinx.pocoo.org/rest.html#id2
http://docutils.sourceforge.net/docs/ref/rst/directives.html#class
This I don't particularly like. I've got to learn a new syntax for it,
I've got to read and learn a manual on what 'class' means for Sphinx and
do some spelunking to figure out if it is the same thing as an html
class or something different. The syntax arguably isn't better, either.
It's just different. Even worse, if I want to change the classes, I've
got to do a global search/replace. With Ddoc, I change one macro.
You don't have to use '.. class::'! Directives can be manually-defined
also. I'm just illustrating this is possible with the requirement 'you
wish to add a class=foo attribute for one of them, and class=bar for
another?'
(Also I didn't say _you_ have to learn reST. For instance, the site
could be maintained by some other people in Digital Mars or the D
committee.)
With Ddoc, you can read the HTML manual and apply it directly to Ddoc.
Ddoc doesn't even know what HTML is, so it has no need to replicate its
functionality in a same-only-different manner.
Neither does Sphinx. '.. class::' is not tied to HTML either.
HTML has lots of these attributes. Are they *all* in Sphinx? What if a
new one is added to HTML? What if I want to use :: in my text? One
problem with a lot of text markup is you've got to provide escapes for
all that - which is why Ddoc pretty much sticks to $.
If you need all of these attributes, why not use raw HTML (yes there is
'.. raw::')? Besides, the output may not be HTML. Sphinx supports LaTeX,
ePub, man page, texinfo, etc. That should also be the same for Ddoc.
You can '::' escape it as ':\:', and '::' is special only at the end of
a line. In Ddoc there is $(LPAREN) and $(RPAREN) and amp; also.
In Ddoc, for another example, I did the documentation for the Digital
Mars C++ runtime library. For web pages, I formatted things using
definition lists. Unfortunately, those came out badly in the Kindle, but
using h4 instead worked much better. Since I had written the docs in
terms of a higher level Ddoc macro, I simply changed its definition to
use h4 instead of dl, and voila! thousands of library functions got
fixed without incredibly tediously recoding each one.
For me, a viable doc system needs to have some sort of symbolic
redefinition capability. Textual macro processors have existed for a
long time, and they work well for that, which is why Ddoc went that
direction. (You might notice that Ddoc macros are a lot like makefile
macros!)
OK.
(I did consider using the C macro preprocessor, but it is too
specialized for C.)
and by defining the macros, I can set them to use div's, pre's, whatever
attributes I want, and do this as many times as I need to for ALL of the
constructs.
That's not an advantage of DDoc. As I've shown above you could use the
'..
class::' directive to assign classes,
Do I gotta do that every time I write a CPPCODE section?
How is '.. class:: cppcode' different from '$(CPPCODE x)' in terms of
redundancy?
and it's also possible to write
Re: Why I'm hesitating to switch to D
On Jun 30, 11 18:50, Walter Bright wrote: On 6/30/2011 1:26 AM, KennyTM~ wrote: Yes it is supported by Sphinx with the :ref:`target` syntax. Take a look at this: http://sphinx.pocoo.org/rest.html#tables +++--+--+ | Header row, column 1 | Header 2 | Header 3 | Header 4 | | (header rows optional) | | | | +++==+==+ | body row 1, column 1 | column 2 | column 3 | column 4 | +++--+--+ | body row 2 | ... | ... | | +++--+--+ I originally did think about doing this for tables in Ddoc. But although it looks reasonable, it is unbearably tedious to actually have to type in a complex table like this, and even worse to try and change such a table. Have you ever tried it? I have. Awful. Try writing 50 different tables that way. Right. I agree this is one disadvantage in authoring the document. Although, in terms of readability, this is much better than $(TABLE $(TR $(TH Header) $(TH Header2) ) $(TR $(TD Body1) ... ) ... ) Next, look at: http://sphinx.pocoo.org/rest.html#sections •# with overline, for parts •* with overline, for chapters •=, for sections •-, for subsections •^, for subsubsections •, for paragraphs I challenge anyone to remember this table. Heck, I can't even remember the C operator precedence table 100%. That's incorrect. Please read the paragraph above it. Normally, there are no heading levels assigned to certain characters as the structure is determined from the succession of headings. However, for the Python documentation, this *convention* is used which you may follow: And: http://sphinx.pocoo.org/rest.html#external-links .. _a link: http://example.com/ is that really better than: $(LINK2 http://example.com/, a link) ? Some people may think it is, I don't, but you could write it as `a link http://example.com/`_ Sphinx is a large and complex markup system that is arguably as much to learn as HTML is - and I still need to learn HTML. Everything in Sphinx seems to have a special syntax, while Ddoc has a single syntax. Sphinx has some nice things, like the automatic connecting of links. But I don't find it, on the whole, better. Granted, I haven't actually used it and might think differently if I did. If Sphinx was the industry standard that everyone uses, that might make it compelling in spite of its problems. But it isn't, I'd never heard of it before your links. (Of course, that might just mean I'm living under a rock!) I've seen all kinds of markup languages, starting with runoff in the 70s. I'm modestly familiar with runoff (did a term paper with it! that was the end of my typewriter), unix man, mediawiki, other wiki markups, reddit markup, javadoc, doxygen, Latex, html (of course), the crazy formats used in various web forums, etc.
Re: Why I'm hesitating to switch to D
KennyTM~ wrote: Right. I agree this is one disadvantage in authoring the document. Although, in terms of readability, this is much better than $(TABLE $(TR $(TH Header) $(TH Header2) Note that textual macros can do a *lot* better than this. If we take advantage of recursive template expansion == $ cat test73.d /** $(TABLE $(HEADERS Something,Something Else, Something To End) $(ROW This is it, So is this, And the third) $(ROW This is it, So is this, And the third) $(ROW This is it, So is this, And the third)) Macros: TABLE=table$0/table TH=th$1/th$(TH $+) HEADERS=tr$(TH $1, $+)/tr TD=td$1/td$(TD $+) ROW=tr$(TD $1, $+)/tr */ $ dmd -D test73.d $ cat test73.html table trthSomething/ththSomething Else/ththSomething To End/th/tr trtd This is it/tdtdSo is this/tdtdAnd the third/td/tr trtd This is it/tdtdSo is this/tdtdAnd the third/td/tr trtd This is it/tdtdSo is this/tdtdAnd the third/td/tr/table === That's fairly readable in source and generates the html needed, that looks pretty decent. The default ddoc macros need more work than ddoc itself IMO.
Re: Why I'm hesitating to switch to D
On Jun 30, 11 22:31, Adam Ruppe wrote: KennyTM~ wrote: Right. I agree this is one disadvantage in authoring the document. Although, in terms of readability, this is much better than $(TABLE $(TR $(TH Header) $(TH Header2) Note that textual macros can do a *lot* better than this. If we take advantage of recursive template expansion == $ cat test73.d /** $(TABLE $(HEADERS Something,Something Else, Something To End) $(ROW This is it, So is this, And the third) $(ROW This is it, So is this, And the third) $(ROW This is it, So is this, And the third)) Macros: TABLE=table$0/table TH=th$1/th$(TH $+) HEADERS=tr$(TH $1, $+)/tr TD=td$1/td$(TD $+) ROW=tr$(TD $1, $+)/tr */ $ dmd -D test73.d $ cat test73.html table trthSomething/ththSomething Else/ththSomething To End/th/tr trtdThis is it/tdtdSo is this/tdtdAnd the third/td/tr trtdThis is it/tdtdSo is this/tdtdAnd the third/td/tr trtdThis is it/tdtdSo is this/tdtdAnd the third/td/tr/table === That's fairly readable in source and generates the html needed, that looks pretty decent. The default ddoc macros need more work than ddoc itself IMO. Interesting trick! Thanks. Indeed the default DDoc macros are not very good, e.g. having no inline code format ($(D x) in Phobos), and relying on the presentational aspect of HTML (e.g. DDOC_BUGS = $(RED BUGS:)$(BR)$0$(BR)$(BR)), etc.
Re: Why I'm hesitating to switch to D
On 6/30/2011 7:05 AM, KennyTM~ wrote: Right. I agree this is one disadvantage in authoring the document. Although, in terms of readability, this is much better than $(TABLE $(TR $(TH Header) $(TH Header2) ) $(TR $(TD Body1) ... ) ... ) I've actually been using different macros for that now, and it looks like: $(TABLE $(TH2 Header, Header2) $(TR2 Body1, Body2) ) which works and looks reasonable. In fact, I'll often just write it as: $(TABLE Header, Header2 Body1, Body2 ) and use a trivial microemacs macro to fill in the rest. Handy when you've got 50 lines or so to do. Next, look at: http://sphinx.pocoo.org/rest.html#sections •# with overline, for parts •* with overline, for chapters •=, for sections •-, for subsections •^, for subsubsections •, for paragraphs I challenge anyone to remember this table. Heck, I can't even remember the C operator precedence table 100%. That's incorrect. Please read the paragraph above it. Ok, my bad. http://sphinx.pocoo.org/rest.html#external-links .. _a link: http://example.com/ is that really better than: $(LINK2 http://example.com/, a link) ? Some people may think it is, I don't, but you could write it as `a link http://example.com/`_ I find the back ticks and _ parts of the syntax wacky and underwhelming. Back ticks are used for D raw string literals, and I now think that was a mistake.
Re: Why I'm hesitating to switch to D
BTW, probably the biggest shortcoming of Ddoc is that its template system does not have conditional or looping constructs. It is not a complete programming language. Such could be added, but there has been no particular need for it. Andrei surprised me by using javascript to fill that role, and perhaps that is good enough.
Re: Why I'm hesitating to switch to D
On 6/30/2011 7:31 AM, Adam Ruppe wrote: If we take advantage of recursive template expansion I worked pretty hard on getting recursion right on the templates. There are a number of subtleties on it; I had the advantage of doing macro systems before and know how to do it. You can use it a lot like car/cdr in Lisp, which you show with your table macro, which is better than mine.
Re: Why I'm hesitating to switch to D
On 6/30/2011 7:50 AM, KennyTM~ wrote: Interesting trick! Thanks. Indeed the default DDoc macros are not very good, e.g. having no inline code format ($(D x) in Phobos), and relying on the presentational aspect of HTML (e.g. DDOC_BUGS = $(RED BUGS:)$(BR)$0$(BR)$(BR)), etc. I wanted the default macros to not rely on having a style sheet.
Re: Why I'm hesitating to switch to D
On Jul 1, 11 02:48, Walter Bright wrote: On 6/30/2011 7:50 AM, KennyTM~ wrote: Interesting trick! Thanks. Indeed the default DDoc macros are not very good, e.g. having no inline code format ($(D x) in Phobos), and relying on the presentational aspect of HTML (e.g. DDOC_BUGS = $(RED BUGS:)$(BR)$0$(BR)$(BR)), etc. I wanted the default macros to not rely on having a style sheet. The default $(DDOC) could have an embedded style-sheet.
Re: Why I'm hesitating to switch to D
On 6/30/2011 6:28 AM, KennyTM~ wrote: No, you don't have to. I'll often write it as: $(CHAPTER foo, bar) The 'foo' is still here. By natural I mean once you have a 'bar', you often don't need to care about the 'foo'. Right, I agreed that Sphinx does better with that detail. Also, in d-programming-language.org $(LINK2 x.html#y, y) is used, but $(CHAPTER x, y) does not exist. Right, but defining your own macros is completely trivial, and when using Ddoc for more than a few lines, I'd expect one to define helpful macros specific to what you're writing. If you're going to avoid writing such macros, then writing Ddoc source is probably going to be clumsy. It's just not meant to be used that way - like trying to write C code without writing any functions other than main(). With Ddoc, you can read the HTML manual and apply it directly to Ddoc. Ddoc doesn't even know what HTML is, so it has no need to replicate its functionality in a same-only-different manner. Neither does Sphinx. '.. class::' is not tied to HTML either. I think you misunderstood me. I meant I don't have to learn a separate-but-equal markup language. If I know html, then using Ddoc is a no-brainer to use. If you need more than a few minutes to get the hang of it, something is wrong. Maybe if you're unfamiliar with text macros, but I can't see a person competent to write programming manuals not knowing them. Expecting someone who's expertise is flower arranging to learn/use Ddoc is likely a hopeless task. If you need all of these attributes, why not use raw HTML (yes there is '.. raw::')? Because writing HTML more than once is a giant annoying pain. With Ddoc, I hide those naughty bits in a macro, then use the macro. How is '.. class:: cppcode' different from '$(CPPCODE x)' in terms of redundancy? Since CPPCODE is a macro, it can expand to anything. I can use it to set the html tag, font, color, size, class, whatever. And, I can *change* it globally by changing the macro, not by editing each instance. It's the same rationale for why we have user-defined aliases, classes, and functions in programming languages. I think I've completely failed to make that point. What if you have something it doesn't highlight for you? Like D? :-) You contribute to Pygment! :) :-( BTW it *does* highlight D. See http://pygments.org/languages/ for the support. And when D gets a new keyword? Everyone has to wait for the next upgrade cycle of Sphinx. With Ddoc, it's automatic. OTOH, DDoc doesn't highlight anything besides D (not that it's an advantage in this context). That's right.
Re: Why I'm hesitating to switch to D
Andrei surprised me by using javascript to fill that role, and perhaps that is good enough. Or you can use D too - I made a little post-processor that parses and modifies the html to add fancier things, when needed for me. This is why I've made a few comments on making the std.ddoc macros more semanticlly rich - to make the post processor's job easier. Though, I find the straight up ddoc, even without bothering with macros at all, to be pretty much good enough for the main goal of documenting functions. Being easy and simple is more important to me than being fancy.
Re: Why I'm hesitating to switch to D
Walter Bright newshou...@digitalmars.com wrote in message news:iuig3e$2m1k$1...@digitalmars.com... Back ticks are used for D raw string literals, and I now think that was a mistake. What would you have used instead?
Re: Why I'm hesitating to switch to D
On Jul 1, 11 03:27, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message news:iuig3e$2m1k$1...@digitalmars.com... Back ticks are used for D raw string literals, and I now think that was a mistake. What would you have used instead? There is r... which is equivalent to `...`. I've only used `...`.
Re: Why I'm hesitating to switch to D
On Jul 1, 11 03:10, Walter Bright wrote: On 6/30/2011 6:28 AM, KennyTM~ wrote: No, you don't have to. I'll often write it as: $(CHAPTER foo, bar) The 'foo' is still here. By natural I mean once you have a 'bar', you often don't need to care about the 'foo'. Right, I agreed that Sphinx does better with that detail. Also, in d-programming-language.org $(LINK2 x.html#y, y) is used, but $(CHAPTER x, y) does not exist. Right, but defining your own macros is completely trivial, and when using Ddoc for more than a few lines, I'd expect one to define helpful macros specific to what you're writing. If you're going to avoid writing such macros, then writing Ddoc source is probably going to be clumsy. It's just not meant to be used that way - like trying to write C code without writing any functions other than main(). Right. Perhaps d-p-l.org should replace those $(LINK2 x#y, z) by $(CHAPTER x, y, z) also. (or $(SECTION x, y, z) depending on what y is). With Ddoc, you can read the HTML manual and apply it directly to Ddoc. Ddoc doesn't even know what HTML is, so it has no need to replicate its functionality in a same-only-different manner. Neither does Sphinx. '.. class::' is not tied to HTML either. I think you misunderstood me. I meant I don't have to learn a separate-but-equal markup language. If I know html, then using Ddoc is a no-brainer to use. If you need more than a few minutes to get the hang of it, something is wrong. Maybe if you're unfamiliar with text macros, but I can't see a person competent to write programming manuals not knowing them. Expecting someone who's expertise is flower arranging to learn/use Ddoc is likely a hopeless task. If you need all of these attributes, why not use raw HTML (yes there is '.. raw::')? Because writing HTML more than once is a giant annoying pain. With Ddoc, I hide those naughty bits in a macro, then use the macro. How is '.. class:: cppcode' different from '$(CPPCODE x)' in terms of redundancy? Since CPPCODE is a macro, it can expand to anything. I can use it to set the html tag, font, color, size, class, whatever. And, I can *change* it globally by changing the macro, not by editing each instance. It's the same rationale for why we have user-defined aliases, classes, and functions in programming languages. I think I've completely failed to make that point. OK. I agree DDoc make a very easy to define and change a macro, but this isn't a unique capability of DDoc. (Also you write your own '.. cppcode::', as I've said before. It's just not as straight-forward as DDoc :) ) What if you have something it doesn't highlight for you? Like D? :-) You contribute to Pygment! :) :-( BTW it *does* highlight D. See http://pygments.org/languages/ for the support. And when D gets a new keyword? Everyone has to wait for the next upgrade cycle of Sphinx. With Ddoc, it's automatic. If D can get a new keyword we won't see 'inout(T)' and 'auto ref' and 'final switch' and all overloads of 'static' ;-) And missing a few keywords (say, __gshared) isn't fatal. OTOH, DDoc doesn't highlight anything besides D (not that it's an advantage in this context). That's right. (actually I wanted to write not that it's _a disadvantage_ in this context. My mind lost in the double negativeness :) )
Re: Why I'm hesitating to switch to D
On 6/30/2011 12:27 PM, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message news:iuig3e$2m1k$1...@digitalmars.com... Back ticks are used for D raw string literals, and I now think that was a mistake. What would you have used instead? D has other methods for raw literals, so the ` are not only ugly, they're redundant.
Re: Why I'm hesitating to switch to D
Walter Bright wrote:
D has other methods for raw literals, so the ` are not only ugly,
they're redundant.
The best part about `` literals is you can put inside them.
You can do that with q{} too, but then the {} needs to match up
which is a bit of a hassle at times.
Re: Why I'm hesitating to switch to D
On 6/30/2011 12:22 PM, Adam Ruppe wrote: Being easy and simple is more important to me than being fancy. Exactly. Having every would be nice if feature can just sink a project with it's dead weight. Back in the 80's, the company I worked for bought a profiling tool for C. Nobody ever used it. I figured part of the problem was the manual was an inch thick. That simply discouraged anyone from bothering to invest the effort to learn it. That's why the profiler for dmd is: dmd foo.d -profile Sadly, still nobody uses the profiler. Reminds me of a Bjarne Stroustrup comment when he joked that decades ago, he imagined that it would be great if using a computer were as simple as using a phone. He said that dream came true :-)
Re: Why I'm hesitating to switch to D
Reminds me of a Bjarne Stroustrup comment when he joked that decades ago, he imagined that it would be great if using a computer were as simple as using a phone. He said that dream came true :-) I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.
Re: Why I'm hesitating to switch to D
Walter: Sadly, still nobody uses the profiler. I'm using it all the time! I'd even like a statistical profile to be added as second profiler to the standard distribution (there is one, around, for D). Bye, bearophile
Re: Why I'm hesitating to switch to D
Adam Ruppe wrote:
Walter Bright wrote:
D has other methods for raw literals, so the ` are not only ugly,
they're redundant.
The best part about `` literals is you can put inside them.
You can do that with q{} too, but then the {} needs to match up
which is a bit of a hassle at times.
There are also q°My Text{ { (} `'?°
and import(foo.txt);
Re: Why I'm hesitating to switch to D
On 6/30/2011 1:27 PM, eles wrote: Reminds me of a Bjarne Stroustrup comment when he joked that decades ago, he imagined that it would be great if using a computer were as simple as using a phone. He said that dream came true :-) I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. The correct quote is better, thanks!
Re: Why I'm hesitating to switch to D
On Jul 1, 11 04:34, Timon Gehr wrote:
Adam Ruppe wrote:
Walter Bright wrote:
D has other methods for raw literals, so the ` are not only ugly,
they're redundant.
The best part about `` literals is you can put inside them.
You can do that with q{} too, but then the {} needs to match up
which is a bit of a hassle at times.
There are also q°My Text{ { (} `'?°
and import(foo.txt);
Let's replace `...` with q`...` ;-)
Re: Why I'm hesitating to switch to D
Am 30.06.2011 22:20, schrieb Walter Bright: On 6/30/2011 12:22 PM, Adam Ruppe wrote: Being easy and simple is more important to me than being fancy. Exactly. Having every would be nice if feature can just sink a project with it's dead weight. Back in the 80's, the company I worked for bought a profiling tool for C. Nobody ever used it. I figured part of the problem was the manual was an inch thick. That simply discouraged anyone from bothering to invest the effort to learn it. That's why the profiler for dmd is: dmd foo.d -profile Sadly, still nobody uses the profiler. Are you sure? I've used it several times. But maybe there should be an article on it or something. (On why it should be used and how this is done) Cheers, - Daniel
Re: Why I'm hesitating to switch to D
On 6/30/2011 1:36 PM, Daniel Gibson wrote: Are you sure? I've used it several times. I base that on if people were using it, there'd be lots of bug reports and enhancement requests! Does anyone use it's companion, -cov?
Re: Why I'm hesitating to switch to D
On 2011-06-30 13:12, Walter Bright wrote:
On 6/30/2011 12:27 PM, Nick Sabalausky wrote:
Walter Brightnewshou...@digitalmars.com wrote in message
news:iuig3e$2m1k$1...@digitalmars.com...
Back ticks are used for D raw string literals, and I now think that was
a mistake.
What would you have used instead?
D has other methods for raw literals, so the ` are not only ugly, they're
redundant.
Actually, I find the backticks to be by far the most pleasant way to get raw
strings in D. I don't particularly like the other syntaxes for it
(particularly q{}). It may be that other considerations make it so that it
would have been better not to use backticks for raw strings, but I really like
it, and I use them all the time.
- Jonathan M Davis
Re: Why I'm hesitating to switch to D
Am 30.06.2011 22:47, schrieb Walter Bright: On 6/30/2011 1:36 PM, Daniel Gibson wrote: Are you sure? I've used it several times. I base that on if people were using it, there'd be lots of bug reports and enhancement requests! Which reminds me - IIRC there were issues with multi threaded programs. But because http://www.digitalmars.com/ctg/trace.html says Profiling of multithreaded apps is not supported. there are probably no bug reports about this - it's expected behavior. However for the profiler to be really useful (especially nowadays with multicore CPUs and std.parallelism), profiling multithreaded apps should be supported. Does anyone use it's companion, -cov? I think I've tried it once, but didn't have too much use for it (because for optimization I care more about the output of -profile) Cheers, - Daniel
Re: Why I'm hesitating to switch to D
Walter: I base that on if people were using it, there'd be lots of bug reports and enhancement requests! I have not needed enhancement requests for the profiler. But I'd like a statistical one added. Does anyone use it's companion, -cov? I use it often, but it's buggy, you can't use it for larger programs. I have never nailed down in what cases it doesn't work, sorry. I have two enhancements request since some time in Bugzilla for the coverage analyser: http://d.puremagic.com/issues/show_bug.cgi?id=4153 http://d.puremagic.com/issues/show_bug.cgi?id=4718 Bye, bearophile
Re: Why I'm hesitating to switch to D
Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile
Re: Why I'm hesitating to switch to D
On 30.06.2011 23:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Yeah, I hate backticks too.. I have to press Shift+` followed by space. But often space won't work as the text editor understands that space cannot be accented or something. So I often press ` twice and backspace to delete the last one. This gives me 4 key presses just for a single character... Wee...
Re: Why I'm hesitating to switch to D
Am 30.06.2011 23:41, schrieb simendsjo: On 30.06.2011 23:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Yeah, I hate backticks too.. I have to press Shift+` followed by space. But often space won't work as the text editor understands that space cannot be accented or something. So I often press ` twice and backspace to delete the last one. This gives me 4 key presses just for a single character... Wee... On Linux/X11 this could be fixed by disabling dead keys (at least as long as you don't need them to place accents on letters, which depends on the languages you're writing in). Dunno what the equivalent to this setting for Windows or OSX is though. Cheers, - Daniel
Re: Why I'm hesitating to switch to D
On Jul 1, 11 05:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Python's `xyz` is equivalent to repr(xyz). I think it is removed in Python 3 more because `...` is not worth the specialness as repr(). But D's `...` is much more worthy as a convenient literal syntax when involving '' or '\'. (I know some keyboard doesn't have '[' and ']'. So having no '`' shouldn't be the reason it is removed from the language.)
Re: Why I'm hesitating to switch to D
On 6/30/2011 2:39 PM, bearophile wrote: I don't have backticks on my keyboard, I got a keyboard from the thrift shop for a buck. It has `.
Re: Why I'm hesitating to switch to D
On 6/30/2011 2:04 PM, Jonathan M Davis wrote:
Actually, I find the backticks to be by far the most pleasant way to get raw
strings in D. I don't particularly like the other syntaxes for it
(particularly q{}). It may be that other considerations make it so that it
would have been better not to use backticks for raw strings, but I really like
it, and I use them all the time.
Don't worry, they're not going away!
Re: Why I'm hesitating to switch to D
Am 30.06.2011 23:50, schrieb KennyTM~: On Jul 1, 11 05:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Python's `xyz` is equivalent to repr(xyz). I think it is removed in Python 3 more because `...` is not worth the specialness as repr(). But D's `...` is much more worthy as a convenient literal syntax when involving '' or '\'. (I know some keyboard doesn't have '[' and ']'. So having no '`' shouldn't be the reason it is removed from the language.) Keyboards without []? This makes programming nearly impossible O_O
Re: Why I'm hesitating to switch to D
On 6/30/2011 2:35 PM, bearophile wrote: I use it often, but it's buggy, you can't use it for larger programs. Bug reports?
Re: Why I'm hesitating to switch to D
Am 30.06.2011 23:51, schrieb Walter Bright: On 6/30/2011 2:39 PM, bearophile wrote: I don't have backticks on my keyboard, I got a keyboard from the thrift shop for a buck. It has `. Probably his keyboard doesn't have US layout ;)
Re: Why I'm hesitating to switch to D
On 6/30/11 11:52 PM, Walter Bright wrote: On 6/30/2011 2:35 PM, bearophile wrote: I use it often, but it's buggy, you can't use it for larger programs. Bug reports? This obviously depends on the keyboard layout one is using… David
Re: Why I'm hesitating to switch to D
On Jul 1, 11 05:35, bearophile wrote: Walter: I base that on if people were using it, there'd be lots of bug reports and enhancement requests! I have not needed enhancement requests for the profiler. But I'd like a statistical one added. Does anyone use it's companion, -cov? I use it often, but it's buggy, you can't use it for larger programs. I have never nailed down in what cases it doesn't work, sorry. I have two enhancements request since some time in Bugzilla for the coverage analyser: http://d.puremagic.com/issues/show_bug.cgi?id=4153 http://d.puremagic.com/issues/show_bug.cgi?id=4718 Bye, bearophile 4718? But std.cover no longer exists in D2.
Re: Why I'm hesitating to switch to D
On 30.06.2011 23:45, Daniel Gibson wrote: Am 30.06.2011 23:41, schrieb simendsjo: On 30.06.2011 23:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Yeah, I hate backticks too.. I have to press Shift+` followed by space. But often space won't work as the text editor understands that space cannot be accented or something. So I often press ` twice and backspace to delete the last one. This gives me 4 key presses just for a single character... Wee... On Linux/X11 this could be fixed by disabling dead keys (at least as long as you don't need them to place accents on letters, which depends on the languages you're writing in). Dunno what the equivalent to this setting for Windows or OSX is though. Cheers, - Daniel I need it for my language, but very rarely, so I wouldn't miss it much. I haven't heard of this before, but I'll try to search around for solutions for windows. Thanks for the tip.
Re: Why I'm hesitating to switch to D
On Jul 1, 11 05:52, Daniel Gibson wrote: Am 30.06.2011 23:50, schrieb KennyTM~: On Jul 1, 11 05:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Python's `xyz` is equivalent to repr(xyz). I think it is removed in Python 3 more because `...` is not worth the specialness as repr(). But D's `...` is much more worthy as a convenient literal syntax when involving '' or '\'. (I know some keyboard doesn't have '[' and ']'. So having no '`' shouldn't be the reason it is removed from the language.) Keyboards without []? This makes programming nearly impossible O_O That's why C has trigraphs! (yuck)
Re: Why I'm hesitating to switch to D
On Jul 1, 11 05:54, David Nadlinger wrote: On 6/30/11 11:52 PM, Walter Bright wrote: On 6/30/2011 2:35 PM, bearophile wrote: I use it often, but it's buggy, you can't use it for larger programs. Bug reports? This obviously depends on the keyboard layout one is using… David That would be a really interesting bug if the coverage analysis depends on the keyboard layout...
Re: Why I'm hesitating to switch to D
Am 30.06.2011 23:57, schrieb KennyTM~: On Jul 1, 11 05:52, Daniel Gibson wrote: Am 30.06.2011 23:50, schrieb KennyTM~: On Jul 1, 11 05:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Python's `xyz` is equivalent to repr(xyz). I think it is removed in Python 3 more because `...` is not worth the specialness as repr(). But D's `...` is much more worthy as a convenient literal syntax when involving '' or '\'. (I know some keyboard doesn't have '[' and ']'. So having no '`' shouldn't be the reason it is removed from the language.) Keyboards without []? This makes programming nearly impossible O_O That's why C has trigraphs! (yuck) Right, totally forgot those. Is this still a problem with recent keyboards (of any layout)? I thought it was only a problem in the 70ies or so.
Re: Why I'm hesitating to switch to D
On 6/30/11 11:59 PM, KennyTM~ wrote: On Jul 1, 11 05:54, David Nadlinger wrote: On 6/30/11 11:52 PM, Walter Bright wrote: On 6/30/2011 2:35 PM, bearophile wrote: I use it often, but it's buggy, you can't use it for larger programs. Bug reports? This obviously depends on the keyboard layout one is using… David That would be a really interesting bug if the coverage analysis depends on the keyboard layout... Oh, wow, apparently I hit »reply« on the wrong post – that should go in the backticks »sub-thread«, of course. ;) David
Re: Why I'm hesitating to switch to D
Am 30.06.2011 23:58, schrieb simendsjo: On 30.06.2011 23:45, Daniel Gibson wrote: Am 30.06.2011 23:41, schrieb simendsjo: On 30.06.2011 23:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Yeah, I hate backticks too.. I have to press Shift+` followed by space. But often space won't work as the text editor understands that space cannot be accented or something. So I often press ` twice and backspace to delete the last one. This gives me 4 key presses just for a single character... Wee... On Linux/X11 this could be fixed by disabling dead keys (at least as long as you don't need them to place accents on letters, which depends on the languages you're writing in). Dunno what the equivalent to this setting for Windows or OSX is though. Cheers, - Daniel I need it for my language, but very rarely, so I wouldn't miss it much. I haven't heard of this before, but I'll try to search around for solutions for windows. Thanks for the tip. Maybe there is a solution to enable and disable them with a keyboard shortcut. I guess this is not only a problem for backticks but also for ~ and ^ (which may be more useful for everyday programming), so a way to disable/enable dead keys on the fly is probably really useful. Cheers, - Daniel
Re: Why I'm hesitating to switch to D
KennyTM~: (I know some keyboard doesn't have '[' and ']'. So having no '`' shouldn't be the reason it is removed from the language.) Even keyboards that don't have [] as first keys, have them printed on the keys as alternative symbols, because they are Far more commonly needed than backticks. Bye, bearophile
Re: Why I'm hesitating to switch to D
On 01.07.2011 00:03, Daniel Gibson wrote:
Am 30.06.2011 23:58, schrieb simendsjo:
On 30.06.2011 23:45, Daniel Gibson wrote:
Am 30.06.2011 23:41, schrieb simendsjo:
On 30.06.2011 23:39, bearophile wrote:
Jonathan M Davis:
Actually, I find the backticks to be by far the most pleasant way to
get raw
strings in D.
I don't have backticks on my keyboard, so I use them only when they
are needed. They have even removed the backticks in the Python2 -
Python3 transition partially because of this (and partially because
there is a more obvious way to do it in Python, and Python tries to
keep only one obvious way to do things).
Bye,
bearophile
Yeah, I hate backticks too.. I have to press Shift+` followed by space.
But often space won't work as the text editor understands that space
cannot be accented or something. So I often press ` twice and backspace
to delete the last one. This gives me 4 key presses just for a single
character... Wee...
On Linux/X11 this could be fixed by disabling dead keys (at least as
long as you don't need them to place accents on letters, which depends
on the languages you're writing in).
Dunno what the equivalent to this setting for Windows or OSX is though.
Cheers,
- Daniel
I need it for my language, but very rarely, so I wouldn't miss it much.
I haven't heard of this before, but I'll try to search around for
solutions for windows.
Thanks for the tip.
Maybe there is a solution to enable and disable them with a keyboard
shortcut.
I guess this is not only a problem for backticks but also for ~ and ^
(which may be more useful for everyday programming), so a way to
disable/enable dead keys on the fly is probably really useful.
Cheers,
- Daniel
~ is Ctrl+Alt+~+Space
^ is Shift+^+Space
{ is Ctrl+Alt+{
[ is Ctrl+Alt+[
( is Shift+(
~ is the most tedious as D uses it a lot.. 4 key presses.
I've seriously thought about changing to an programmer or English layout
while programming..
Re: Why I'm hesitating to switch to D
Am 01.07.2011 00:12, schrieb simendsjo:
On 01.07.2011 00:03, Daniel Gibson wrote:
Am 30.06.2011 23:58, schrieb simendsjo:
On 30.06.2011 23:45, Daniel Gibson wrote:
Am 30.06.2011 23:41, schrieb simendsjo:
On 30.06.2011 23:39, bearophile wrote:
Jonathan M Davis:
Actually, I find the backticks to be by far the most pleasant way to
get raw
strings in D.
I don't have backticks on my keyboard, so I use them only when they
are needed. They have even removed the backticks in the Python2 -
Python3 transition partially because of this (and partially because
there is a more obvious way to do it in Python, and Python tries to
keep only one obvious way to do things).
Bye,
bearophile
Yeah, I hate backticks too.. I have to press Shift+` followed by
space.
But often space won't work as the text editor understands that space
cannot be accented or something. So I often press ` twice and
backspace
to delete the last one. This gives me 4 key presses just for a single
character... Wee...
On Linux/X11 this could be fixed by disabling dead keys (at least as
long as you don't need them to place accents on letters, which depends
on the languages you're writing in).
Dunno what the equivalent to this setting for Windows or OSX is though.
Cheers,
- Daniel
I need it for my language, but very rarely, so I wouldn't miss it much.
I haven't heard of this before, but I'll try to search around for
solutions for windows.
Thanks for the tip.
Maybe there is a solution to enable and disable them with a keyboard
shortcut.
I guess this is not only a problem for backticks but also for ~ and ^
(which may be more useful for everyday programming), so a way to
disable/enable dead keys on the fly is probably really useful.
Cheers,
- Daniel
~ is Ctrl+Alt+~+Space
^ is Shift+^+Space
{ is Ctrl+Alt+{
[ is Ctrl+Alt+[
( is Shift+(
~ is the most tedious as D uses it a lot.. 4 key presses.
My keyboard (german layout) has an Alt Gr key. So for me it's AltGr+~
for ~ (and, if dead keys are enabled, +space additionally) etc.
I've seriously thought about changing to an programmer or English layout
while programming..
Me too, but I didn't really get used to it. But then again, the AltGr
combinations are still somehow bearable, while ctrl-alt combinations
sound quite annoying.
Re: Why I'm hesitating to switch to D
Walter: Bug reports? A bit later I have written: I have never nailed down in what cases it doesn't work, sorry. It means I was not able to find test cases where the bugs come out. To me they come out only in larger programs. Bye, bearophile
Re: Why I'm hesitating to switch to D
On 7/1/11 12:16 AM, bearophile wrote: Even keyboards that don't have [] as first keys, have them printed on the keys as alternative symbols, because they are Far more commonly needed than backticks. Unless you are using a QWERTZ mac keyboard. :) David
Re: Why I'm hesitating to switch to D
On 01.07.2011 00:18, Daniel Gibson wrote:
Am 01.07.2011 00:12, schrieb simendsjo:
On 01.07.2011 00:03, Daniel Gibson wrote:
Am 30.06.2011 23:58, schrieb simendsjo:
On 30.06.2011 23:45, Daniel Gibson wrote:
Am 30.06.2011 23:41, schrieb simendsjo:
On 30.06.2011 23:39, bearophile wrote:
Jonathan M Davis:
Actually, I find the backticks to be by far the most pleasant way to
get raw
strings in D.
I don't have backticks on my keyboard, so I use them only when they
are needed. They have even removed the backticks in the Python2 -
Python3 transition partially because of this (and partially because
there is a more obvious way to do it in Python, and Python tries to
keep only one obvious way to do things).
Bye,
bearophile
Yeah, I hate backticks too.. I have to press Shift+` followed by
space.
But often space won't work as the text editor understands that space
cannot be accented or something. So I often press ` twice and
backspace
to delete the last one. This gives me 4 key presses just for a single
character... Wee...
On Linux/X11 this could be fixed by disabling dead keys (at least as
long as you don't need them to place accents on letters, which depends
on the languages you're writing in).
Dunno what the equivalent to this setting for Windows or OSX is though.
Cheers,
- Daniel
I need it for my language, but very rarely, so I wouldn't miss it much.
I haven't heard of this before, but I'll try to search around for
solutions for windows.
Thanks for the tip.
Maybe there is a solution to enable and disable them with a keyboard
shortcut.
I guess this is not only a problem for backticks but also for ~ and ^
(which may be more useful for everyday programming), so a way to
disable/enable dead keys on the fly is probably really useful.
Cheers,
- Daniel
~ is Ctrl+Alt+~+Space
^ is Shift+^+Space
{ is Ctrl+Alt+{
[ is Ctrl+Alt+[
( is Shift+(
~ is the most tedious as D uses it a lot.. 4 key presses.
My keyboard (german layout) has an Alt Gr key. So for me it's AltGr+~
for ~ (and, if dead keys are enabled, +space additionally) etc.
I've seriously thought about changing to an programmer or English layout
while programming..
Me too, but I didn't really get used to it. But then again, the AltGr
combinations are still somehow bearable, while ctrl-alt combinations
sound quite annoying.
I have a norwegian layout, but I think it's quite similar.
For ~ I can use AltGr, but for { I need to bend my hand halfway around.
I've been doing this for years, and it's straining my hands. So I've
started using C-A in many cases to avoid this - in addition to switching
to dvorak.
Re: Why I'm hesitating to switch to D
On Thu, 30 Jun 2011 22:36:13 +0200, Daniel Gibson metalcae...@gmail.com wrote: Sadly, still nobody uses the profiler. Are you sure? I've used it several times. But maybe there should be an article on it or something. (On why it should be used and how this is done) Bring in the iPads! -- Simen
Re: Why I'm hesitating to switch to D
Am 01.07.2011 00:28, schrieb David Nadlinger:
On 7/1/11 12:16 AM, bearophile wrote:
Even keyboards that don't have [] as first keys, have them printed on
the keys as alternative symbols, because they are Far more commonly
needed than backticks.
Unless you are using a QWERTZ mac keyboard. :)
David
OMG.
I didn't wanna believe it, but
http://upload.wikimedia.org/wikipedia/commons/1/10/2007_09_30_de_Apple-Tastatur.jpg
proved me wrong.
The same for laptops (
http://www.elektro-export.de/epages/es114318.sf/de_AT/?ObjectPath=/Shops/es114318_Elektro-Export/Products/KB-APPLE04[1]
)
No [], no {}.. WTF.
This is the most ridiculous fact I've heard about Apple products so
far.. just unbelievable.
Cheers,
- Daniel
Re: Why I'm hesitating to switch to D
On Thu, 30 Jun 2011 23:52:38 +0200, Daniel Gibson metalcae...@gmail.com wrote: Am 30.06.2011 23:50, schrieb KennyTM~: On Jul 1, 11 05:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Python's `xyz` is equivalent to repr(xyz). I think it is removed in Python 3 more because `...` is not worth the specialness as repr(). But D's `...` is much more worthy as a convenient literal syntax when involving '' or '\'. (I know some keyboard doesn't have '[' and ']'. So having no '`' shouldn't be the reason it is removed from the language.) Keyboards without []? This makes programming nearly impossible O_O And standard Norwegian layout has them on AltGr+8/9. The pain. But using US int'l has the added advantage of confusing the hell out of my cow-orkers when they try to use my confuser (which has thus earned that title :p). -- Simen
Re: Why I'm hesitating to switch to D
On 01.07.2011 00:49, Simen Kjaeraas wrote: On Thu, 30 Jun 2011 23:52:38 +0200, Daniel Gibson metalcae...@gmail.com wrote: Am 30.06.2011 23:50, schrieb KennyTM~: On Jul 1, 11 05:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Python's `xyz` is equivalent to repr(xyz). I think it is removed in Python 3 more because `...` is not worth the specialness as repr(). But D's `...` is much more worthy as a convenient literal syntax when involving '' or '\'. (I know some keyboard doesn't have '[' and ']'. So having no '`' shouldn't be the reason it is removed from the language.) Keyboards without []? This makes programming nearly impossible O_O And standard Norwegian layout has them on AltGr+8/9. The pain. But using US int'l has the added advantage of confusing the hell out of my cow-orkers when they try to use my confuser (which has thus earned that title :p). Switch to programmer dvorak and they'll never touch your computer again.
Re: Why I'm hesitating to switch to D
Doesn't OSX have something equivalent to AutoHotkey? Also, last I heard there was an AHK version for .NET, maybe OSX can use that via the Mono project. That might be a long shot though.
Re: Why I'm hesitating to switch to D
On 2011-06-30 15:59, simendsjo wrote: On 01.07.2011 00:49, Simen Kjaeraas wrote: On Thu, 30 Jun 2011 23:52:38 +0200, Daniel Gibson metalcae...@gmail.com wrote: Am 30.06.2011 23:50, schrieb KennyTM~: On Jul 1, 11 05:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Python's `xyz` is equivalent to repr(xyz). I think it is removed in Python 3 more because `...` is not worth the specialness as repr(). But D's `...` is much more worthy as a convenient literal syntax when involving '' or '\'. (I know some keyboard doesn't have '[' and ']'. So having no '`' shouldn't be the reason it is removed from the language.) Keyboards without []? This makes programming nearly impossible O_O And standard Norwegian layout has them on AltGr+8/9. The pain. But using US int'l has the added advantage of confusing the hell out of my cow-orkers when they try to use my confuser (which has thus earned that title :p). Switch to programmer dvorak and they'll never touch your computer again. I switched to dvorak _and_ got one of these: http://www.kinesis- ergo.com/advantage.htm No one is going to be using my computer with my keyboard. Though honestly, as much as I like dvorak, I wouldn't advise that anyone switch to it. Too many programs assume qwerty, so all of their shortcuts are designed for it. Stuff like the shortcuts for cut, copy, and paste are on completely different places on the keyboard and don't work as well (only cut can be done with just your left hand). I had to completely remap vim to be able to use it. Other programs need their keys or shortcuts remapped to work very well. It just causes problems for stuff that assumes qwerty. So, it's likely more pain than its worth. My keyboard is awesome regardless of whether you use qwerty or dvork though. I can actually type numbers on it without looking, which I could never do on a normal keyboard, because the keys aren't vertically aligned on a normal keyboard. It's expensive, but I'm quite happy that I bought it. - Jonathan M Davis
Re: Why I'm hesitating to switch to D
KennyTM~ kenn...@gmail.com wrote in message news:iuik51$2t5s$2...@digitalmars.com... On Jul 1, 11 03:27, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message news:iuig3e$2m1k$1...@digitalmars.com... Back ticks are used for D raw string literals, and I now think that was a mistake. What would you have used instead? There is r... which is equivalent to `...`. I've only used `...`. That's not equivalent. The r... can't have a double-quote inside it, so it's only a half-way solution, and is probably why no one really uses it (At least that's why I never use it).
Re: Why I'm hesitating to switch to D
On 01.07.2011 02:19, Jonathan M Davis wrote: On 2011-06-30 15:59, simendsjo wrote: On 01.07.2011 00:49, Simen Kjaeraas wrote: On Thu, 30 Jun 2011 23:52:38 +0200, Daniel Gibson metalcae...@gmail.com wrote: Am 30.06.2011 23:50, schrieb KennyTM~: On Jul 1, 11 05:39, bearophile wrote: Jonathan M Davis: Actually, I find the backticks to be by far the most pleasant way to get raw strings in D. I don't have backticks on my keyboard, so I use them only when they are needed. They have even removed the backticks in the Python2 - Python3 transition partially because of this (and partially because there is a more obvious way to do it in Python, and Python tries to keep only one obvious way to do things). Bye, bearophile Python's `xyz` is equivalent to repr(xyz). I think it is removed in Python 3 more because `...` is not worth the specialness as repr(). But D's `...` is much more worthy as a convenient literal syntax when involving '' or '\'. (I know some keyboard doesn't have '[' and ']'. So having no '`' shouldn't be the reason it is removed from the language.) Keyboards without []? This makes programming nearly impossible O_O And standard Norwegian layout has them on AltGr+8/9. The pain. But using US int'l has the added advantage of confusing the hell out of my cow-orkers when they try to use my confuser (which has thus earned that title :p). Switch to programmer dvorak and they'll never touch your computer again. I switched to dvorak _and_ got one of these: http://www.kinesis- ergo.com/advantage.htm No one is going to be using my computer with my keyboard. Though honestly, as much as I like dvorak, I wouldn't advise that anyone switch to it. Too many programs assume qwerty, so all of their shortcuts are designed for it. Stuff like the shortcuts for cut, copy, and paste are on completely different places on the keyboard and don't work as well (only cut can be done with just your left hand). I had to completely remap vim to be able to use it. Other programs need their keys or shortcuts remapped to work very well. It just causes problems for stuff that assumes qwerty. So, it's likely more pain than its worth. My keyboard is awesome regardless of whether you use qwerty or dvork though. I can actually type numbers on it without looking, which I could never do on a normal keyboard, because the keys aren't vertically aligned on a normal keyboard. It's expensive, but I'm quite happy that I bought it. - Jonathan M Davis Looks ergonomically correct, but pretty massive. I've considered TypeMatrix (http://typematrix.com/) in the past, but I think it's a bit expensive. As for dvorak, I'm not quite sure. The keybindings haven't been a large problem for me. Most programs have mappings based on the name of the function (o for open), and this isn't a problem. The only vim problems is movement which now requires two hands - but I decided not to remap, and it hasn't been a problem. Games on the other hand :) I still switched quite recently, and type very slowly. And my hands actually hurt more - probably because I'm not used to it. I'm hoping that dvorak will help on strain in the long run though..
Re: Why I'm hesitating to switch to D
For ultimate escaping use:
auto str = qEOS
W I'm a string ``'q{\
EOS;
Of course then you have to make sure 'EOS' is a unique name too. You
could use some funky unicode character sequence for that, just to be
sure. :p
