Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration
What compiler options is that with? I used DMD and compiler flags -O -inline -release on x86_64 linux.
Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration
On Wed, May 2, 2012 at 9:38 AM, jerro wrote: > What compiler options is that with? >> > > I used DMD and compiler flags -O -inline -release on x86_64 linux. > > It may be slow relative to incrementing a integer: 65 seconds without any command line options. 54 seconds with -O -inline -release. vs: 3.2 seconds dmd without any command line options. 2.2 seconds with dmd -O -inline -release. And that is for 1000_000_000 Fiber context switches. intel 2600K @ 4.5GHz, gnu/linux, ubuntu 12.04.
Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration
On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote: A little write-up I just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration Call me stupid, but I've absolutely no idea what you're doing. What problem does the InputVisitor solve ? What are the current solutions ? What is the intent of your code ? What are the supposed advantages ? Your article says nothing about it.
Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration
"SomeDude" wrote in message news:ypakkndfsibcbgelj...@forum.dlang.org... > On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote: >> A little write-up I just did on something I thought was pretty cool: >> >> Combine Coroutines and Input Ranges for Dead-Simple D Iteration >> https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration > > Call me stupid, but I've absolutely no idea what you're doing. What > problem does the InputVisitor solve ? What are the current solutions ? > What is the intent of your code ? What are the supposed advantages ? Your > article says nothing about it. Just an easier-to-read/write alternative to an opApply or an input range. More natural and straightforward than a hand-written input range, and cleaner syntax than opApply (and without opApply's downside of not being usable as a range).
Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration
It may be slow relative to incrementing a integer:
The opApply isn't just incrementing an integer - it's
calling a function through a pointer. A loop that just
increments an integer is an order of magnitude faster.
This code (I used assembly because a compiler would
optimize away such a simple loop) runs in 0.27s on my
machine:
auto sum = 0;
auto n = 1000_000_000;
asm
{
mov EAX, n;
mov EBX, sum;
loop:
dec EAX;
inc EBX;
test EAX, EAX;
jne loop;
mov sum, EBX;
}
Ranges like iota are often as fast as using a for loop.
For example this code:
auto sum = 0;
foreach(i; iota(to!int(args[1])))
sum += i;
runs in 0.52 seconds when compiled with gdc with flags
-O2 -finline-functions -frelease. When compiled with -O3,
gcc uses paddd instruction and it runs in 0.1s.
And that is for 1000_000_000 Fiber context switches.
I'm not saying that D fibers are slow - fiber context
switches are way faster than thread context switches.
When using them for IO, such as in vibe.d, overhead
of fibers is negligible. But when used for iteration,
they are way slower than the alternatives, because in
that case there shouldn't be any context switches at all.
Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration
"Nick Sabalausky" wrote in message news:jnr241$nh1$1...@digitalmars.com... > "SomeDude" wrote in message > news:ypakkndfsibcbgelj...@forum.dlang.org... >> On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote: >>> A little write-up I just did on something I thought was pretty cool: >>> >>> Combine Coroutines and Input Ranges for Dead-Simple D Iteration >>> https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration >> >> Call me stupid, but I've absolutely no idea what you're doing. What >> problem does the InputVisitor solve ? What are the current solutions ? >> What is the intent of your code ? What are the supposed advantages ? Your >> article says nothing about it. > > Just an easier-to-read/write alternative to an opApply or an input range. > More natural and straightforward than a hand-written input range, and > cleaner syntax than opApply (and without opApply's downside of not being > usable as a range). > Of course, based on the timing results Jerro and Rory reported, Adam's mixin helper for opApply probably hits a better balance of performance vs usability.
bootDoc - advanced DDoc framework using Twitter's Bootstrap
This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ LuaD's official documentation also uses bootDoc http://jakobovrum.github.com/LuaD/ bootDoc is designed to be easily usable with any project. It is used as a git-submodule in both of the above sample scenarios. All project-specific settings are provided by a separate configuration file (settings.ddoc), which is documented on the project's Github wiki. bootDoc includes a general-purpose generation script. See the readme on Github for usage information. The script uses a candyDoc-style modules.ddoc as input, making the transition from candyDoc projects easy. Note about noscript: JavaScript is used to get around the static nature of DDoc. The sidebar does not work without JavaScript, and neither do fully qualified anchor names. However, anchors with ambiguous names (such as those usable for symbols on dlang.org) work both with and without JavaScript, with the same limitations. Comments, issues, enhancement requests, questions or rants about JavaScript - all feedback is much appreciated!
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On 02.05.2012 22:26, Jakob Ovrum wrote: Note about noscript: JavaScript is used to get around the static nature of DDoc. The sidebar does not work without JavaScript, and neither do fully qualified anchor names. However, anchors with ambiguous names (such as those usable for symbols on dlang.org) work both with and without JavaScript, with the same limitations. Wooha! remove in std.algorithm finally points to _function_. Impressed :) (BTW It's still "points" to enum in dlang.org) Comments, issues, enhancement requests, questions or rants about JavaScript - all feedback is much appreciated! -- Dmitry Olshansky
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On 2012-05-02 20:26, Jakob Ovrum wrote: This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. Looks good. -- /Jacob Carlborg
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On Wednesday, 2 May 2012 at 18:26:11 UTC, Jakob Ovrum wrote: This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ LuaD's official documentation also uses bootDoc http://jakobovrum.github.com/LuaD/ bootDoc is designed to be easily usable with any project. It is used as a git-submodule in both of the above sample scenarios. All project-specific settings are provided by a separate configuration file (settings.ddoc), which is documented on the project's Github wiki. bootDoc includes a general-purpose generation script. See the readme on Github for usage information. The script uses a candyDoc-style modules.ddoc as input, making the transition from candyDoc projects easy. Note about noscript: JavaScript is used to get around the static nature of DDoc. The sidebar does not work without JavaScript, and neither do fully qualified anchor names. However, anchors with ambiguous names (such as those usable for symbols on dlang.org) work both with and without JavaScript, with the same limitations. Comments, issues, enhancement requests, questions or rants about JavaScript - all feedback is much appreciated! Great! I will try this :) Masahiro
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
While it would be nice if the nav tree were still there w/o JS, and I'm not personally a fan of CSS(or HTML)-based "frames", this is definitely a very nice, clean, great-looking theme!
Re: Introducing vibe.d!
Am 01.05.2012 23:46, schrieb Sönke Ludwig: I made a post with Steve Teale's MySQL driver as an example: http://vibed.org/blog/posts/writing-native-db-drivers There were some hidden gotchas, but I hope the current port doesn't break anything from the original code. Looks good. Unfortunately I spend some time with MongoDB and I have to say : Amazing db. I thought key/value databases are just toys. At least regarding MongoDB is was completely wrong. I have a problem with diet templates. In order to use dojo dijit I need : Is this doable in diet templates ?
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On Wednesday, 2 May 2012 at 21:42:21 UTC, Nick Sabalausky wrote: While it would be nice if the nav tree were still there w/o JS, and I'm not personally a fan of CSS(or HTML)-based "frames", this is definitely a very nice, clean, great-looking theme! Alright, with some effort, I made it so that at least a basic module list works without JS. It looks pretty alright with noscript now.
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On Wednesday, 2 May 2012 at 18:26:11 UTC, Jakob Ovrum wrote: This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. I would make a minor change that lets you see the function tree near the top. On my laptop screen (about a standard size) I have to scroll down about an entire screen to see it. How this is implemented is up to you, but being able to collapse to module view might be enough. -- James Miller
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On 5/3/12 1:26 AM, Jakob Ovrum wrote: This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ Very nice! But why the symbols inside std.algorithm, for instance, are not sorted? http://jakobovrum.github.com/bootdoc-phobos/std.algorithm.html (they are kind of sorted by chunks...) Now if it only had cross references... :-P
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On Thursday, 3 May 2012 at 05:14:43 UTC, James Miller wrote: On Wednesday, 2 May 2012 at 18:26:11 UTC, Jakob Ovrum wrote: This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. I would make a minor change that lets you see the function tree near the top. On my laptop screen (about a standard size) I have to scroll down about an entire screen to see it. How this is implemented is up to you, but being able to collapse to module view might be enough. -- James Miller Packages in the module view are collapsable, just click on them. Having the module list in its entirety collapsable might be an idea, but unless your project has a ton of top-level packages and modules, it won't help much with your specific problem (the situation would be almost the same). I am considering putting the module tree and symbol tree in tabs instead of below each other.
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
"Jakob Ovrum" wrote in message news:lbskaseedspulyyna...@forum.dlang.org... > On Wednesday, 2 May 2012 at 21:42:21 UTC, Nick Sabalausky wrote: >> While it would be nice if the nav tree were still there w/o JS, and I'm >> not >> personally a fan of CSS(or HTML)-based "frames", this is definitely a >> very >> nice, clean, great-looking theme! > > Alright, with some effort, I made it so that at least a basic module list > works without JS. It looks pretty alright with noscript now. > Very nice :)
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On Thursday, 3 May 2012 at 05:44:47 UTC, Ary Manzana wrote: On 5/3/12 1:26 AM, Jakob Ovrum wrote: This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ Very nice! But why the symbols inside std.algorithm, for instance, are not sorted? http://jakobovrum.github.com/bootdoc-phobos/std.algorithm.html (they are kind of sorted by chunks...) The symbols in the symbol tree appear in the order the symbols appear in the documentation, which is the order of declaration in the original source (DMD does it this way). I think it would be a little confusing if the symbol tree was alphabetically sorted, while the main documentation was in order of declaration. It is possible to rearrange everything with JavaScript of course, but... I think this might be going a little bit too far. What do you think? Now if it only had cross references... :-P If I understand you correctly, any kind of automatic cross-referencing would need post-processing of DMD's generated output. I am considering such post-processing, but it would massively change the project (a lot less would require JavaScript), and completely bind the project to the included generator tool. I think the tool needs more trial-by-fire testing to determine whether it's good enough to be mandatory.
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On 5/3/12 1:23 PM, Jakob Ovrum wrote: On Thursday, 3 May 2012 at 05:44:47 UTC, Ary Manzana wrote: On 5/3/12 1:26 AM, Jakob Ovrum wrote: This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ Very nice! But why the symbols inside std.algorithm, for instance, are not sorted? http://jakobovrum.github.com/bootdoc-phobos/std.algorithm.html (they are kind of sorted by chunks...) The symbols in the symbol tree appear in the order the symbols appear in the documentation, which is the order of declaration in the original source (DMD does it this way). I think it would be a little confusing if the symbol tree was alphabetically sorted, while the main documentation was in order of declaration. It is possible to rearrange everything with JavaScript of course, but... I think this might be going a little bit too far. What do you think? I don't think the main documentation order is right in the first place. If a module provides many functions, like std.algorithm, I don't see how there could possibly be an "intended" order, like "these are more likely to be used". In any case, if I want to quickly find a function, for example "remove" or "insert" or something I think might have the name I'm looking for, alphabetical order is the best way to go. Now if it only had cross references... :-P If I understand you correctly, any kind of automatic cross-referencing would need post-processing of DMD's generated output. I am considering such post-processing, but it would massively change the project (a lot less would require JavaScript), and completely bind the project to the included generator tool. I think the tool needs more trial-by-fire testing to determine whether it's good enough to be mandatory. Oh, I just said that because I have a pull request waiting for that feature to be incorporated in DMD... but I don't think it'll happen...
