Phobos runnable examples - ideas request

[1100110]

On 03/28/2013 12:09 PM, nazriel wrote:
> On 03/28/2013 09:53 AM, 1100110 wrote:
>>
>> I'll work on 1. and see if we can't come up with something better!
>>
>> The code snippets are pretty much necessary IMO. They just need to be
>> fixed.
>> ----
>> int[] a = ...;
>> static bool greater(int a, int b)
>> {
>> return a > b;
>> }
>> sort!(greater)(a); // predicate as alias
>> sort!("a > b")(a); // predicate as string
>> // (no ambiguity with array name)
>> sort(a); // no predicate, "a < b" is implicit
>> ----
>>
>>
>> So what about something like this then?
>> It's not *great*, but it actually runs now.
>>
>> ---- void main() { import std.algorithm;
>>
>> int[] a = [7,5,6];
>>
>> bool greater(int a, int b)
>> {
>> return a > b;
>> }
>> // Here are a few different methods,
>> // Please note I'm doing the same work 3 times.
>> sort!(greater)(a); // predicate as alias
>> sort!("a > b")(a); // predicate as string (no ambiguity with array
>> name)
>> sort(a); // no predicate, "a < b" is implicit
>> assert(isSorted(a));// Proof that it works as expected.
>>
>> ---- }
>>
>>
>> I was gonna come up with a short script to grab all the examples, but
>> apparently github is very protective of out code, and I really don't
>> wanna do html...
>>
>> It'd be great if the js stuck the "void main()" and the imports in for
>> us at least.
>
> Yeah, option 1) may work.
> Although in most cases import moduleWeAreIn; isn't enough.
> So I guess stabbing default pack of imports maybe necessary.
>
> We can work out this way: Adding JS hash-map that will map Phobos
> modules to imports pack. Something like this:
>
> imports["std.algorithm"] = "std.algorithm; std.file: write; std.process:
> shell";
>
> What ya think? It will also allow to resolve symbol conflicts like
> std.stdio.write vs std.file.write
>
> The default view of example could stay in tact (of course validity of
> code needs to be fixed anyways), but when you Click edit, script would
> wrap example in void main() {} and append import pack I mentioned above.
>
> However I think that option number 2) may be more scalable.
> Think about like this:
>
> By default all examples are parsed and every snippet is wrapped in void
> main(){}.
>
> Script then fetches data for module we are in. Let's say: std.algorithm;
>
> What script gets is:
> - imports table - default set of imports that is appended to every
> snippet in module.
> - special cases - snippets marked explicitly may have additional options
> like: don't append main() block, add additional imports to certain
> snippet, replace module imports table with fetched ones, add default
> standard input, add default standard arguments, don't make this snippet
> runnable etc.
>
> Why it's better than option number 1?
> Maintaining this data set is way much more easy because you don't need
> to edit java script file by hand, compute md5sum, make all necessary
> changes and then make pull request that may wait a bit in pull request
> queue. You just enter (for example) http://paste.dlang.org/examples
> search for certain example in database, if it doesn't exist you just add
> it and make all changes you need. Then depending on what way we pick,
> request is added to queue and moderator accepts it or rejects OR it just
> works wiki-like, so change is visible after you submit changes.
>
> What you think?
> Anyways, if you have any questions feel free to mail me at nazriel at dzfl.pl
>
>

I think you may have hit upon something with part #2.

Stick with the script idea real quick. But make it slightly more 
generic. How many times have you wished you had a small code example for 
the immediate thing you want?

I was trying to sell D to my friend, and Bam!  readf's non-obvious 
blocking behaviour hit me!  So imagine a little script that sits in 
front of a github repo.(or whatever, the first place to look is API + 
rosetta code probably.)  You give it the name of a module, or a 
function, or just straight text with what you want.
It gives you code that it knows imports *and uses* that code.

I can't figure out what's up with readf?  I I now have more than enough 
public domain examples that (hopefullu..) I'll immediately see the problem.

So, extending that a little further, what if it's a script that can tell 
what you're looking for that can make specific offers, such as the 
official documentation.


That would definitely be a worthy project for 
D-Programming-Language/Tools, IMO.



The script could always sit in front of some website like dpaste, but 
what if it didn't have to?

That's one thing that's always bothered me, we aspired to that kind of 
ease of use(rdmd --man, for example) but it was never *quite* good 
enough to be impressed by.  Or really use, personally.

Imagine it.


$ rdmd --search std.algorithm cartesianproduct
======================================================================
auto N = sequence!"n"(0); 	  // the range of natural numbers
auto N2 = cartesianProduct(N, N);

// the range of all pairs of natural numbers 	
// Various arbitrary number pairs can be found
// in the range in finite time.

assert(canFind(N2, tuple(0, 0)));
assert(canFind(N2, tuple(123, 321)));
assert(canFind(N2, tuple(11, 35)));
assert(canFind(N2, tuple(279, 172)));
======================================================================
More? [Y/n]

$ rdmd --search println
=======================================================================
/// Read until end of file
import std.stdio;

int main() {
	string buf;
	while ((buf = stdin.readln()) !is null)
		write(buf);
	return 0;
}
========================================================================
More? [Y/n]


Best of both worlds!  It should have a full website UI for searching and 
even editing. Even if rdmd rejects it, that is something that simply 
must happen!