www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "Try it now"

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I'm quite excited about the new look of std (right now realized only by 
http://d-programming-language.org/phobos-prerelease/std_algorithm.html). 
Here's a suggestion on how we could improve it more.

Adam wrote an in-browser evaluator for D programs. These, when presented 
on the homepage with "hello, world" in them are of limited usefulness. 
However, a personalized "try it now" button present for _each_ artifact 
in an std module would be of great usefulness.

When I try some html or javascript I find it very useful to go to one of 
those sites that allow me to try some code right then and there. The key 
aspect is that the code edit field is already filled with code that is 
close to what I'm looking for, which I can then edit and try until it 
does what I want.

Similarly, it would be great if next to e.g. 
http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion 
there would be a "Try it now" button. Clicking on that button would open 
an overlay with an edit window. The edit window initially contains the 
example text:

unittest
{
   int[] a = [ 1, 2, 4, 5, 7, 9 ];
   int[] b = [ 0, 1, 2, 4, 7, 8 ];
   int[] c = [ 10 ];
   assert(setUnion(a, b).length == a.length + b.length);
   assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
   assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9, 
10][]));
}

Then the user can change, compile, and run that program, to ultimately 
close the overlay and return to the documentation.

What do you think? This would require some work in the compiler (make 
unittests documentable, make their text available to ddoc macros) and 
some work in the front end. I hope this catches the fancy of e.g. 
Walter/Don and Adam.


Andrei
Apr 13 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Andrei wrote:

 Adam wrote an in-browser evaluator for D programs. These, when
 presented on the homepage with "hello, world" in them are of
 limited usefulness.
 However, a personalized "try it now" button present for _each_
 artifact in an std module would be of great usefulness.


Indeed. I actually wrote a little javascript thing for that
new home page that's reusable across other ddoc or similar
sites. Check it out:

http://arsdnet.net/d-web-site/std_algorithm2.html

Every time it sees a d_code block, the script adds a button.
Hit the button, and you can edit the code and send it off
to my completelyexpendable vm to compile and run it.

(It's also on my not-quite-done newsreader so example code in
newsgroup posts are detected and made editable. That's less perfect
since it's trying to pick code out of unstructured text, but it
works reasonably well.)


Of course, most examples fail to actually compile... but maybe
a few replacement rules for the text - automatically insert main()
if it's not there, import std.all or similar at the top,
replace "..." with some generic data.

I think we could make the examples work with just a few lines of
code.


Unittests are a different story though, since their code isn't
in the HTML today. If dmd did make it available though, this same
script should work on it.
Apr 13 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/13/11 3:54 PM, Adam D. Ruppe wrote:

 Andrei wrote:

 Adam wrote an in-browser evaluator for D programs. These, when
 presented on the homepage with "hello, world" in them are of
 limited usefulness.
 However, a personalized "try it now" button present for _each_
 artifact in an std module would be of great usefulness.


 Indeed. I actually wrote a little javascript thing for that
 new home page that's reusable across other ddoc or similar
 sites. Check it out:

 http://arsdnet.net/d-web-site/std_algorithm2.html

 Every time it sees a d_code block, the script adds a button.
 Hit the button, and you can edit the code and send it off
 to my completelyexpendable vm to compile and run it.

 (It's also on my not-quite-done newsreader so example code in
 newsgroup posts are detected and made editable. That's less perfect
 since it's trying to pick code out of unstructured text, but it
 works reasonably well.)


 Of course, most examples fail to actually compile... but maybe
 a few replacement rules for the text - automatically insert main()
 if it's not there, import std.all or similar at the top,
 replace "..." with some generic data.

 I think we could make the examples work with just a few lines of
 code.


Whoa, what a coincidence we were thinking along the same lines (never 
saw that).

To take this to pro level:

* Button shold be on the same like as "Example:" and spell "Try now". 
Maybe a more attractive shape/icon could help too.

* Once pressed, the subsequent edit should contain a "Cancel" that 
undoes the action.

* The compilation/running results should come in a nice inline 
variable-height stdout after the edit window, not in a new undecorated 
page. I wouldn't mind some "terminal" color scheme for that stdout with 
e.g. green on black letters or whatnot. Anyhow, the entire 
edit/compile/run flow should be very very smooth.

* Syntax highlighting in the editor :o)


 Unittests are a different story though, since their code isn't
 in the HTML today. If dmd did make it available though, this same
 script should work on it.


Agreed. For now it would be terrific if you could take this proof of 
concept full course. I'll be waiting for your diff request!


Thanks,

Andrei
Apr 13 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Andrei Alexandrescu wrote:

 To take this to pro level:
 * Button shold be on the same like as "Example:" and spell "Try
 now". Maybe a more attractive shape/icon could help too.
 * Once pressed, the subsequent edit should contain a "Cancel" that
 undoes the action.
 * The compilation/running results should come in a nice inline
 variable-height stdout after the edit window



Got partially there. Can't spend too much time on this right now,
got some work projects that need to be finished by friday. I'm
pretty sure I can finish them in a day if I have to... but I don't
want to have to.

Anyway take a look. This is where I'll leave it until the weekend:

http://arsdnet.net/d-web-site/std_algorithm2.html


Changes:
* added some border-radius to the buttons. (this is actually
  controlled in css - button.try-now {}
* Changed the text.
* Added cancel button.
* Added boilerplate code if it can't find "int main" or "void main".
  As a result, several of the examples on that page actually compile
  and run.
* Since most of them don't actually output anything, the program
  now detects output.length == 0 and says "Program run
  successfully." upon completion to give some feedback.
* The output goes into an iframe above the code editor, black on
  green. The background is changed in css (iframe.try-now) and the
  foreground is changed in the javascript (due to how iframes work,
  it sends some desired style to the other server which spits it
  back out.)
* Error messages are modified before being shown to the user so
  the filename is pretty (always "code.d" instead of sha1hash.d)
  and the line numbers match up, even if I add boilerplate.
* Included in the boilerplate are:

import std.stdio;     import std.string;  import std.conv;
import std.algorithm; import std.range;   import std.array

FIXME: it should import the module you're actually looking at
too!



As a side note, the compile is a little slow. It caches results
based on the code's hash so common examples should be fast, but
if you change things, it will take a few seconds. This is by
design - that VM's resources are limited on several levels to
avoid a naughty program from getting out of control. Alas, to
be conservative, it has to assume dmd is potentially naughty too.
dmd gets a little more resources than the programs it generates, but
not much. Hence, it's a little slow.

But I don't think its too bad.



Not done: variable height window. The iframe is always a given
height. I actually think this works pretty well, but if you
strongly disagree I can do some scripts to see about sizing it
to it's contents, to a certain degree.



 * Syntax highlighting in the editor :o)


I'm afraid I'll have to say no here... that's a pretty enormous
effort to get working well, and I hate javascript too much to
spend that kind of time with it. Of course, if someone else
has done it, I'm not above a little copy/paste action.



If you want to try this on your private copy of the docs, it should
be as simple as adding:

<script src="http://arsdnet.net/d-web-site/editable_code.js"></script>

somewhere in the file. Here's the CSS additions in my copy if
you want them too:

button.try-now {
	border-radius: 8px;
	-moz-border-radius: 8px;
	-webkit-border-radius: 8px;
	-o-border-radius: 8px;

	float: left;
	margin-right: 0.4em;
}

iframe.try-now {
	display: block;
	width: 100%;
	background-color: black;
}
Apr 13 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/13/11 5:39 PM, Adam D. Ruppe wrote:

 Andrei Alexandrescu wrote:

 To take this to pro level:
 * Button shold be on the same like as "Example:" and spell "Try
 now". Maybe a more attractive shape/icon could help too.
 * Once pressed, the subsequent edit should contain a "Cancel" that
 undoes the action.
 * The compilation/running results should come in a nice inline
 variable-height stdout after the edit window



 Got partially there. Can't spend too much time on this right now,
 got some work projects that need to be finished by friday. I'm
 pretty sure I can finish them in a day if I have to... but I don't
 want to have to.

 Anyway take a look. This is where I'll leave it until the weekend:

 http://arsdnet.net/d-web-site/std_algorithm2.html


This is very close already! Two things if you get to work on this for 
the weekend:

* The console window should be of variable height (to fit the text) up 
to some number of rows (e.g. 40), and then scroll.

* The console window should be below, not above the edit window.

* The "Compile & Run" button should be "Run" to enhance the feeling of 
instant execution.

* The two buttons should be to the right of "Example:" (with some spacing)

* We need to go through all examples and make sure they are 
compilable... :o)

This is a great contribution, Adam. Thank you!


Andrei
Apr 13 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 14.04.2011 02:37, schrieb Andrei Alexandrescu:

 
 * The "Compile & Run" button should be "Run" to enhance the feeling of
 instant execution.


Well D *is* a compiled language. Also this is an explanation for the
user why he doesn't get instant response (but has to wait two seconds or
something).

Cheer,
- Daniel
Apr 13 2011
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
new version of javascript up:
http://arsdnet.net/d-web-site/std_algorithm2.html
Apr 17 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 new version of javascript up:
 http://arsdnet.net/d-web-site/std_algorithm2.html


I suggest to add a spinning circle for the compilation wait (see Ideone site
too).

Some comments on the code examples:
- The second example for reduce(), the example of group() and minCount(), the
third example of remove() need tuple
- The example of uninitializedFill, initializeAll and schwartzSort contain
dummy ... code
- The filter() example gives Error: incompatible types caused by:
auto small = filter!("a < 3")(arr);
assert(small == [ 1, 2 ]);
- Splitter() example gives another Error: incompatible types
- the first and second examples of find() gives a import conflict error
- The third find() example doesn't find tuple and gives a missing overload error
- The example of endsWith() gives algorithm.d(3127): Error: no property 'empty'
for type 'char'
- findAdjacent() lacks an auto p = ...
- balancedParens() gives an assert error
- The example of equal() gives a approxEqual error and more
- levenshteinDistance() gives Error: static assert  "Bad binary function
q{toupper(a) == toupper(b)}. You need to use a valid D expression using symbols
a of type dchar and b of type dchar."
- levenshteinDistanceAndPath() gives a algorithm.d(3975): Error: undefined
identifier Range, did you mean alias Range1?
- The window formatting of bringToFront() seems wrong
- The second and third bringToFront() examples lack SList
- The 4th and 5th examples of remove() give an assert error
- The topN() example doesn't find "less"
- completeSort() gives some problems, maybe it can't find assumeSorted()
- makeIndex() example gives a template error
- topNCopy() example gives an error, maybe it's wrong
- setIntersection() example asserts statically
- largestPartialIntersection() and largestPartialIntersectionWeighted() can't
find Tuple

Thank you for reminding me how hugely useful is the Python doctests module :-)

Bye,
bearophile
Apr 17 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/17/2011 02:00 PM, bearophile wrote:

 Adam D. Ruppe:


 new version of javascript up:
 http://arsdnet.net/d-web-site/std_algorithm2.html


 I suggest to add a spinning circle for the compilation wait (see Ideone site
too).


Probably we're good to go without that, but it'll help once the traffic 
increases :o).


 Some comments on the code examples:


[snip]

Since you already made a pass, I suggest you write a few pull requests 
on github that make examples work.


Thanks,

Andrei
Apr 17 2011
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:

 I suggest to add a spinning circle for the compilation wait (see
 Ideone site too).


Am I actually the only person in the world who *hates* those things?

I might add it later though.
Apr 17 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/17/2011 02:35 PM, Adam D. Ruppe wrote:

 bearophile wrote:

 I suggest to add a spinning circle for the compilation wait (see
 Ideone site too).


 Am I actually the only person in the world who *hates* those things?

 I might add it later though.


I think adding the text to the "Running...\n" as soon as you get the 
request should help.


Andrei
Apr 17 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2011 12:36 PM, Andrei Alexandrescu wrote:

 I think adding the text to the "Running...\n" as soon as you get the request
 should help.


Or:

"Please wait while the D-9000 computer boots..."
Apr 17 2011
parent Andrew Wiley <debio264 gmail.com> writes:
On Sun, Apr 17, 2011 at 3:01 PM, Walter Bright
<newshound2 digitalmars.com> wrote:

 On 4/17/2011 12:36 PM, Andrei Alexandrescu wrote:

 I think adding the text to the "Running...\n" as soon as you get the
 request
 should help.


 Or:

 "Please wait while the D-9000 computer boots..."


Or
"Must DESTROY John Connor!"

The console background is green on black over here on the Chrome 12
dev build, so there's definitely something browser specific going on.
And let me join the list of people saying this is friggin awesome. Thanks, Adam!
Apr 17 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/17/2011 01:22 PM, Adam D. Ruppe wrote:

 new version of javascript up:
 http://arsdnet.net/d-web-site/std_algorithm2.html


Great. I think this looks adequate now and ready for integration into 
d-programming-language.org.

Adam, could you please put together a pull request on github?

I'd also appreciate if you sent my way a simple script that scrapes the 
HTML for all sample code so we can work on making them work.


Thanks,

Andrei
Apr 17 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Andrei Alexandrescu wrote:

 Adam, could you please put together a pull request on github?


I've gotta figure out how that works...


 I'd also appreciate if you sent my way a simple script that scrapes
 the HTML for all sample code so we can work on making them work.


Heh, what a coincidence. I just wrote a quick one now:

http://arsdnet.net/d-web-site/extractexamples.d

It's cgi so you can see the output here, but it's trivial to
change, very short program. Fetch my dom library here
http://arsdnet.net/d-web-site/arsd/dom.d

Example output:
http://arsdnet.net/d-web-site/extractexamples


It puts in some generic imports, an empty main, and wraps
everything in unittest {}.
Apr 17 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/17/2011 02:29 PM, Adam D. Ruppe wrote:

 Andrei Alexandrescu wrote:

 Adam, could you please put together a pull request on github?


 I've gotta figure out how that works...


 I'd also appreciate if you sent my way a simple script that scrapes
 the HTML for all sample code so we can work on making them work.


 Heh, what a coincidence. I just wrote a quick one now:

 http://arsdnet.net/d-web-site/extractexamples.d

 It's cgi so you can see the output here, but it's trivial to
 change, very short program. Fetch my dom library here
 http://arsdnet.net/d-web-site/arsd/dom.d

 Example output:
 http://arsdnet.net/d-web-site/extractexamples


 It puts in some generic imports, an empty main, and wraps
 everything in unittest {}.


Looking good. Hmmm, I think we should just compile code as it is, no 
hidden artifacts. Then that adds some syntactic noise. Not sure what the 
best balance is.

Andrei
Apr 17 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/17/2011 02:29 PM, Adam D. Ruppe wrote:

 Andrei Alexandrescu wrote:

 Adam, could you please put together a pull request on github?


 I've gotta figure out how that works...


Oh, and I think learning git/github is a huge net gain outside of any 
particular project. I warmly recommend it.

Andrei
Apr 17 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Andrei Alexandrescu wrote:

 Oh, and I think learning git/github is a huge net gain outside of
 any particular project. I warmly recommend it.


Yeah, I've used git before on the command line, but never the
website.

I'll admit though that for my typical project, my idea of source
control is commenting and/or remembering how many times to hit undo
in the editor...

But when I dive into this, most the change is trivial - the script
and server side program do almost all the work. But I'd like to
at the least fix some invalid html in std.ddoc too. Both browser
scripts and my D dom module are able to figure it out anyway, but
it'd be nice if the HTML was more well formed and maybe using
better semantic tags/classnames.
Apr 17 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/17/2011 01:22 PM, Adam D. Ruppe wrote:

 new version of javascript up:
 http://arsdnet.net/d-web-site/std_algorithm2.html


One more thing: make sure you solve potential cross-site scripting that 
may occur, and prepare for seeing a fair amount of extra traffic. In the 
long run we'll prepare d-programming-language.org to handle the examples 
itself.

Thanks,

Andrei
Apr 17 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Andrei Alexandrescu wrote:

 One more thing: make sure you solve potential cross-site scripting
 that may occur


I don't think any are possible - I always escape input and output,
and if something does get through, it's on a different domain so
the browser's cross domain restriction will keep it from getting
too bad. (Indeed, these restrictions made the auto-resize a real
pain in the ass!)


 and prepare for seeing a fair amount of extra traffic.


Naturally.
Apr 17 2011
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Apr 18, 11 02:22, Adam D. Ruppe wrote:

 new version of javascript up:
 http://arsdnet.net/d-web-site/std_algorithm2.html


There are some minor styling bugs. I've only tested it on Chrome 10.

For Example: code blocks:
1. Press "Try Now", then "Cancel" - the code block becomes bold.
2. Click "Try Now" again - the "Cancel" is now in the other line

For non-Example: code blocks:
1. The "Try Now" button appear below the code.
2. Click "Try Now" and "Cancel" moves the button above the code.

----

Also, I suggest the try-now examples should allow using a different 
piece of code than the one shown.

For instance, the introductory code (the sort one) of the std.algorithm 
module clearly shows what the module does, but it absolutely useless for 
Try-Now. The result is "Program ran successfully.", so what? The user 
should be able to see how the array is sorted, how to provide a custom 
predicate, etc., and thus writeln's need to be placed after the 3 sorts. 
This can't be automated by Javascript.

I like the w3schools approach (except the new window part), where the 
main page shows a concise example to let people understand how the 
feature is used, and the "Try it yourself" link provides a complete 
program with human-readable output.
Apr 17 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
KennyTM~ wrote:

 There are some minor styling bugs. I've only tested it on Chrome 10.


Oh, I see it too. Fixed.
Apr 17 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2011 11:22 AM, Adam D. Ruppe wrote:

 new version of javascript up:
 http://arsdnet.net/d-web-site/std_algorithm2.html


Adam, this is really awesome work!

Some trivial nits:

1. The output window is offset 3 or 4 pixels to the left of the source window.

2. The source window has a 1 pixel box around it. The output window has a two 
pixel border on the left and top sides only. This makes it look out of place.

3. The lime-green-on-white text in the output window is a little hard to read 
comfortably. Perhaps a darker green?

I'm running IE9 in case these issues are browser specific.
Apr 17 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 13/04/2011 23:39, Adam D. Ruppe wrote:

 * Syntax highlighting in the editor :o)


 I'm afraid I'll have to say no here... that's a pretty enormous
 effort to get working well, and I hate javascript too much to
 spend that kind of time with it. Of course, if someone else
 has done it, I'm not above a little copy/paste action.


Hum, this seems like the kinds of things where the new Eclipse Orion 
project might be interesting and useful to integrate with:
http://www.eclipse.org/orion/

-- 
Bruno Medeiros - Software Engineer
Apr 20 2011
prev sibling parent reply Matthias Pleh <jens konrad.net> writes:
[..snip..]

Hey, that's so awesome, guys!
Keep up that work :)

°Matthias
Apr 13 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
That is so awesome, great job Adam!

Now I *finally* have an excuse for those reports I made of examples
which don't compile (where the response was "nobody said examples
/have/ to compile, they're just demonstrations..").
Apr 13 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/13/2011 1:54 PM, Adam D. Ruppe wrote:

 Indeed. I actually wrote a little javascript thing for that
 new home page that's reusable across other ddoc or similar
 sites. Check it out:


I think what you've done is very innovative and cool!
Apr 13 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/13/2011 10:54 PM, Adam D. Ruppe wrote:

 Andrei wrote:

 Adam wrote an in-browser evaluator for D programs. These, when
 presented on the homepage with "hello, world" in them are of
 limited usefulness.
 However, a personalized "try it now" button present for _each_
 artifact in an std module would be of great usefulness.


 Indeed. I actually wrote a little javascript thing for that
 new home page that's reusable across other ddoc or similar
 sites. Check it out:

 http://arsdnet.net/d-web-site/std_algorithm2.html

 Every time it sees a d_code block, the script adds a button.
 Hit the button, and you can edit the code and send it off
 to my completelyexpendable vm to compile and run it.

 (It's also on my not-quite-done newsreader so example code in
 newsgroup posts are detected and made editable. That's less perfect
 since it's trying to pick code out of unstructured text, but it
 works reasonably well.)


 Of course, most examples fail to actually compile... but maybe
 a few replacement rules for the text - automatically insert main()
 if it's not there, import std.all or similar at the top,
 replace "..." with some generic data.

 I think we could make the examples work with just a few lines of
 code.


 Unittests are a different story though, since their code isn't
 in the HTML today. If dmd did make it available though, this same
 script should work on it.


What would be helpful, I guess, to have most examples work as is, is 
systematically:
* put the code in a unitest block
* add "void main () {}"
* "import std.commonimports;"
where commonimports is a to-be-defined module publicly importing common tools 
from std.* (there was a similar discussion about scripting in D):

public import std.stdio        : write, writef, writeln, writefln;
public import std.string       : format, join;
public import std.conv         : to;
...

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 When I try some html or javascript I find it very useful to go to one of 
 those sites that allow me to try some code right then and there. The key 
 aspect is that the code edit field is already filled with code that is 
 close to what I'm looking for, which I can then edit and try until it 
 does what I want.


Time ago Walter said that online ways to try code snippets (like the ideone and

see you don't agree :-) As you remember the Go site has a similar window even
on the home page (JavaScript required): http://golang.org/



 What do you think?


I think this is a good idea that improves the usefulness of the (now active)
documentation. In my opinion it's even going to produce more bug reports for
DMD/Phobos.

Bye,
bearophile
Apr 13 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/13/11 4:26 PM, bearophile wrote:

 Andrei:


 When I try some html or javascript I find it very useful to go to one of
 those sites that allow me to try some code right then and there. The key
 aspect is that the code edit field is already filled with code that is
 close to what I'm looking for, which I can then edit and try until it
 does what I want.


 Time ago Walter said that online ways to try code snippets (like the

 good. I am glad to see you don't agree :-) As you remember the Go
 site has a similar window even on the home page (JavaScript
 required): http://golang.org/


I just wrote that examples the likes of golang.org are poor.

Andrei
Apr 13 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 * Since most of them don't actually output anything, the program
   now detects output.length == 0 and says "Program run
   successfully." upon completion to give some feedback.


This is a problem. Unittest code is not meant to produce an output, while
online snippets to try are meant to nearly always produce a meaningful output.



 Hence, it's a little slow.


I agree, it's slow, and speeding it up a little will be an important
improvement. But it's a nice page :-)



 Of course, if someone else
 has done it, I'm not above a little copy/paste action.


It may slow down editing even on modern browsers. I think it's not essential.

Bye,
bearophile
Apr 13 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
It does alarm NoScript, which blocks it. It runs fine if I disable it
though, and probably most people don't use noscript.
Apr 13 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Andrej Mitrovic wrote:

 It does alarm NoScript, which blocks it.


Well, it *is* a script...

It would be possible to move the logic server side easily enough,
but I think the scripted interface is better anyway - no need to
show the output and edit windows at all times. The script allows
us to only show them when requested.
Apr 13 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I've always wondered.. how do you detect malicious D code? Or if
there's an infinite loop in the code? Or if the compiler suddenly
crashes? Or if the compilation takes so long that DMD exhausts all
memory? It seems like a dangerous thing to allow user code execution,
but I've no idea what goes behind the scenes..
Apr 13 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Andrej Mitrovic wrote:

 I've always wondered.. how do you detect malicious D code?


It doesn't. What it does is use the ulimit feature in linux to
limit the resources available to each process so they can't do
anything.

Try it:

int[] a;
a.length = 5_000_000; // "Memory allocation failed"


for(;;) {} // forcibly terminated by the kernel after ~8 seconds

auto f = File("cool_a_file", "wt");
for(int a = 0; a < 10_000; a++)
  f.writefln("%d", a);

// reports success, but the file is actually only 8 kb:


-rw-r--r-- 1 apache apache 8192 2011-04-13 19:22 cool_a_file


1859
18 // you can see it got forcibly cut off

There's file permissions in place that you shouldn't be able to
access anything on there, except reading the system files. It's
a stock Linux install - nothing to see there. Writing is limited
to the scratchspace directory, which isn't public to the web or
anything.


What if you tried to fill the disk by creating files in a loop?
You actually can do that, until you're killed for either running
for too long or hitting the scratchspace's disk quota. I don't
know how to prevent that except for disabling files altogether,
and I think that would diminish the usefulness a little. File
examples are fun too.

(note if you do fill the scratchspace, it's not a big deal. It's
garbage collected in a way - the compile helper catches disk
full exceptions and cleans it out when needed. Still, don't do that.)

Access to the network is firewalled too. You can play on localhost
to a degree, but anything to and from the outside world is filtered.
Shouldn't be possible to run a spambot on it, since nothing on
that machine is allowed to call out, not even root.


Keep in mind that DMD lives under similar constraints. If it
goes wild, it will be killed by the kernel before too long too,
and can't make files bigger than about a megabyte. It's limited
to 256 MB of RAM.


This describes the limits in the operating system. There's
additional limits at the VM level, so even if you got root, you
couldn't do much with it. This is why it's also on a separate
domain name than anything else too - if you put a web exploit
on it, there's nothing much to do with that either. Like it's
name says, it's all completely expendable info.

Finally, I snapshotted the VM in a known good state. If you do
root the box, I can always revert to that too (considering writing
a program to automatically revert each day actually, but haven't
gotten around to it yet).

Of course, worst case scenario is I just pull the plug on it. I
hope it never comes to that, but some people are assholes, so
if I have to, it's an option.


Anyway, as you can see, I tried to cover all my bases with enough
fallback plans that I'm not concerned about malicious code at all.
Apr 13 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 Anyway, as you can see, I tried to cover all my bases with enough
 fallback plans that I'm not concerned about malicious code at all.


The author of codepad has a similar amount of healthy paranoia:

Can you break it? You're welcome to try. Let me know if you have any success!<


http://codepad.org/about

Bye,
bearophile
Apr 13 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/14/2011 02:51 AM, Adam D. Ruppe wrote:

 Andrej Mitrovic wrote:

 I've always wondered.. how do you detect malicious D code?


 It doesn't. What it does is use the ulimit feature in linux to
 limit the resources available to each process so they can't do
 anything.

 Try it:

 int[] a;
 a.length = 5_000_000; // "Memory allocation failed"


 for(;;) {} // forcibly terminated by the kernel after ~8 seconds

 auto f = File("cool_a_file", "wt");
 for(int a = 0; a<  10_000; a++)
    f.writefln("%d", a);

 // reports success, but the file is actually only 8 kb:


 -rw-r--r-- 1 apache apache 8192 2011-04-13 19:22 cool_a_file


 1859
 18 // you can see it got forcibly cut off

 There's file permissions in place that you shouldn't be able to
 access anything on there, except reading the system files. It's
 a stock Linux install - nothing to see there. Writing is limited
 to the scratchspace directory, which isn't public to the web or
 anything.


 What if you tried to fill the disk by creating files in a loop?
 You actually can do that, until you're killed for either running
 for too long or hitting the scratchspace's disk quota. I don't
 know how to prevent that except for disabling files altogether,
 and I think that would diminish the usefulness a little. File
 examples are fun too.

 (note if you do fill the scratchspace, it's not a big deal. It's
 garbage collected in a way - the compile helper catches disk
 full exceptions and cleans it out when needed. Still, don't do that.)

 Access to the network is firewalled too. You can play on localhost
 to a degree, but anything to and from the outside world is filtered.
 Shouldn't be possible to run a spambot on it, since nothing on
 that machine is allowed to call out, not even root.


 Keep in mind that DMD lives under similar constraints. If it
 goes wild, it will be killed by the kernel before too long too,
 and can't make files bigger than about a megabyte. It's limited
 to 256 MB of RAM.


 This describes the limits in the operating system. There's
 additional limits at the VM level, so even if you got root, you
 couldn't do much with it. This is why it's also on a separate
 domain name than anything else too - if you put a web exploit
 on it, there's nothing much to do with that either. Like it's
 name says, it's all completely expendable info.

 Finally, I snapshotted the VM in a known good state. If you do
 root the box, I can always revert to that too (considering writing
 a program to automatically revert each day actually, but haven't
 gotten around to it yet).

 Of course, worst case scenario is I just pull the plug on it. I
 hope it never comes to that, but some people are assholes, so
 if I have to, it's an option.


 Anyway, as you can see, I tried to cover all my bases with enough
 fallback plans that I'm not concerned about malicious code at all.


We'd need a sandbox.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 Well, it *is* a script...
 
 It would be possible to move the logic server side easily enough,
 but I think the scripted interface is better anyway - no need to
 show the output and edit windows at all times. The script allows
 us to only show them when requested.


Well designed user interfaces degrade gracefully. Here this means hiding the
output and edit windows if JavaScript is enabled, and showing them if JS is not
available on the user browser. I'd like the site to work without JS too.

Bye,
bearophile
Apr 13 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:

 Well designed user interfaces degrade gracefully.


That's exactly why I took the approach I did... see below.


  Here this means hiding the output and edit windows if JavaScript
 is enabled, and showing them if JS is not available on the user
 browser.


Showing has a cost. The site is easier to use without edit boxes
surrounding every example - it puts a lot of stuff in the way
of the content you're actually looking for; they get in the way.

While it's a cool little feature to have, it's not essential
to the site's main purpose, namely, presenting the documentation
in an easy to read fashion.

So the upsides of being fully functional (technically easy, btw,
the main thing is just a standard html form, and with the iframe
target, it'd do an inline submit without script too, no changes)
has to weighed against the downside of being cluttered.

With the script, it's possible to have the best of both worlds.
But, without the script, I just don't feel it's worth it. Toys
shouldn't get in the way of the main goal.
Apr 13 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 With the script, it's possible to have the best of both worlds.
 But, without the script, I just don't feel it's worth it. Toys
 shouldn't get in the way of the main goal.


Here's another idea:
1) detect if the user has active JS;
2) If the JS is active, then hide the in/out windows. If the JS is not active
then hide everything, both windows and "try it" button, but add at the top of
the window a link to an alternative page that's usable without JS that shows
the in/out windows too.

Bye,
bearophile
Apr 13 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:

 If the JS is not active then hide everything, both windows and "try > it"


button, but add at the top of the page an alternative page

That could work. Links to little popups to try now could work too.

For this, we'll probably want to add it to my ddoc post-processor
(same program that adds my version of the cheat sheets and tables of
contents, automatically generated from text below).

It's not in use for dmd yet, nor may it ever be, but if so this
approach will work.
Apr 13 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/13/11 6:11 PM, bearophile wrote:

 Adam D. Ruppe:


 * Since most of them don't actually output anything, the program
    now detects output.length == 0 and says "Program run
    successfully." upon completion to give some feedback.


 This is a problem. Unittest code is not meant to produce an output, while
online snippets to try are meant to nearly always produce a meaningful output.


I disagree. I find examples that use assert() much clearer than examples 
that print something to the console and then explain in a comment what 
you ought to be seeing.


Andrei
Apr 13 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 I disagree. I find examples that use assert() much clearer than examples 
 that print something to the console and then explain in a comment what 
 you ought to be seeing.


I don't understand why you say that. Isn't learning and understanding based on
feedback? If all the examples do is to show the same "assert passed" message,
then what's the point in running the examples? Just reading a static page gives
the same insight. You are able to modify them, of course, and see the modified
asserts fail, and you may add a writeln statement yourself, but... having to
modify each example to see some feedback is not a good default. I'd like to
know if other people agree with you on this.

Bye,
bearophile
Apr 13 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 04/14/2011 02:56 AM, bearophile wrote:

 Andrei:


  I disagree. I find examples that use assert() much clearer than examples
  that print something to the console and then explain in a comment what
  you ought to be seeing.




 I don't understand why you say that. Isn't learning and understanding based on
feedback?


Precisely ;-)
That's why sane unittest blocks may/should output! One needs proper data to 
study / diagnose / debig what code *actually* does.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/14/2011 02:56 AM, bearophile wrote:

 Andrei:


 I disagree. I find examples that use assert() much clearer than examples
 that print something to the console and then explain in a comment what
 you ought to be seeing.


 I don't understand why you say that. Isn't learning and understanding based on
feedback? If all the examples do is to show the same "assert passed" message,
then what's the point in running the examples? Just reading a static page gives
the same insight. You are able to modify them, of course, and see the modified
asserts fail, and you may add a writeln statement yourself, but... having to
modify each example to see some feedback is not a good default. I'd like to
know if other people agree with you on this.


I more or less agree with both of you. My problem with using asserts in code 
samples is:
* It's not a feature all languages have, thus readers may not know it (well).
* Asserts in sample is clever "highjacking" of a language feature for a clever 
side-effect.

The point of assert in true code is to catch a potential bug. The point of 
assert in sample code is to bring information to the reader, like if saying 
"this predicate holds here":
    assert(3/2 == 1);
Maybe an alias of assert for such use would help? (but I cannot find one) Or a 
simple comment would do the job better:
    // 3/2 == 1

I long for a different assert that would take one expression and a result, and 
writse out when 'assertMode' is 'verbose':
    assert(3/2, &);
    // outputs "3/2 : 1"
Then, we get both silent and verbose asserts in one go; the former for 
regression testing, the latter mode for diagnose or examples.

I currently do it that way:
     auto n = 3/2;
     writefln("3/2: %s, n);	// commented out for regression test
     assert(n == 1);

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 On 4/13/11 6:11 PM, bearophile wrote:

 Adam D. Ruppe:

 * Since most of them don't actually output anything, the program
 
 now detects output.length == 0 and says "Program run
 successfully." upon completion to give some feedback.


 
 This is a problem. Unittest code is not meant to produce an output, while
 online snippets to try are meant to nearly always produce a meaningful
 output.


 
 I disagree. I find examples that use assert() much clearer than examples
 that print something to the console and then explain in a comment what
 you ought to be seeing.


I concur. The use of asserts in the examples is generally very clear. It also 
works great as a unit test, so if/when we make it so that ddoc examples are 
taken from unit test blocks, it works out really well. The example is both 
documented and tested. You can't do that with a print statement and a comment.

- Jonathan M Davis
Apr 13 2011
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:

 This is a problem. Unittest code is not meant to produce an output,
 while online snippets to try are meant to nearly always produce a
 meaningful output.


I don't know - I like the approach Andrei took in the docs, writing
a series of true assertations.

assert(sort([4, 2]) == [2, 4]);

does look pretty neat. I guess the alternative is:

writeln(sort[4, 2]); // prints "[2, 4]"

but it's not as compact with some examples and it doesn't quite
show the same thing - writeln's implementation could change things
there and those details are really beside the point of the example.

On the other hand, having output there might be more interesting
to look at than "yay the asserts all passed!".

I could go either way.


But, regardless, there's nothing much my compile helper and
javascript can do here. The examples in the documentation would
have to be changed.


 I agree, it's slow, and speeding it up a little will be an
 important improvement.


Yeah, I'd like to speed it up too, but I've gotta strike a balance
between being useful without being easily abused or expensive.
Right now, it has a separate VM, but still shares a physical
server with some of my other sites (otherwise I wouldn't be doing
this at all... dedicating a whole server to a free toy is too rich
for my blood).

I can't let it affect those other sites, so full speed isn't really
an option.
Apr 13 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/13/2011 6:04 PM, Adam D. Ruppe wrote:

 I don't know - I like the approach Andrei took in the docs, writing
 a series of true assertations.

 assert(sort([4, 2]) == [2, 4]);

 does look pretty neat. I guess the alternative is:

 writeln(sort[4, 2]); // prints "[2, 4]"

 but it's not as compact with some examples and it doesn't quite
 show the same thing - writeln's implementation could change things
 there and those details are really beside the point of the example.

 On the other hand, having output there might be more interesting
 to look at than "yay the asserts all passed!".

 I could go either way.


One advantage of the assert() approach is you won't have to over and over again 
add in the import std.stdio;

Not having any imports makes for a faster compile, too.
Apr 13 2011
parent reply spir <denis.spir gmail.com> writes:
On 04/14/2011 06:32 AM, Walter Bright wrote:

 On 4/13/2011 6:04 PM, Adam D. Ruppe wrote:

 I don't know - I like the approach Andrei took in the docs, writing
 a series of true assertations.

 assert(sort([4, 2]) == [2, 4]);

 does look pretty neat. I guess the alternative is:

 writeln(sort[4, 2]); // prints "[2, 4]"

 but it's not as compact with some examples and it doesn't quite
 show the same thing - writeln's implementation could change things
 there and those details are really beside the point of the example.

 On the other hand, having output there might be more interesting
 to look at than "yay the asserts all passed!".

 I could go either way.


 One advantage of the assert() approach is you won't have to over and over again
 add in the import std.stdio;

 Not having any imports makes for a faster compile, too.


... and helps in having safe sandboxes. This holds for simple comments as well:

     assert(3/2 == 1);
vs
     // 3/2 == 1

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
parent reply David Nadlinger <see klickverbot.at> writes:
On 4/14/11 2:26 PM, spir wrote:

 Not having any imports makes for a faster compile, too.


 ... and helps in having safe sandboxes.


In which way exactly do I need an import to write »extern(C) int 
system(in char *); system(…);«?

David
Apr 14 2011
parent reply spir <denis.spir gmail.com> writes:
On 04/14/2011 02:40 PM, David Nadlinger wrote:

 On 4/14/11 2:26 PM, spir wrote:

 Not having any imports makes for a faster compile, too.


 ... and helps in having safe sandboxes.


 In which way exactly do I need an import to write »extern(C) int system(in
char
 *); system(…);«?


Did I write "it provides safe sandboxes"?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
parent reply David Nadlinger <see klickverbot.at> writes:
On 4/14/11 3:44 PM, spir wrote:

 On 04/14/2011 02:40 PM, David Nadlinger wrote:

 On 4/14/11 2:26 PM, spir wrote:

 Not having any imports makes for a faster compile, too.


 ... and helps in having safe sandboxes.


 In which way exactly do I need an import to write »extern(C) int
 system(in char
 *); system(…);«?


 Did I write "it provides safe sandboxes"?

 Denis


No, but you wrote that it »helps in having safe sandboxes«, and I'm 
curious how you think it would.

David
Apr 14 2011
parent reply spir <denis.spir gmail.com> writes:
On 04/14/2011 03:50 PM, David Nadlinger wrote:

 On 4/14/11 3:44 PM, spir wrote:

 On 04/14/2011 02:40 PM, David Nadlinger wrote:

 On 4/14/11 2:26 PM, spir wrote:

 Not having any imports makes for a faster compile, too.


 ... and helps in having safe sandboxes.


 In which way exactly do I need an import to write »extern(C) int
 system(in char
 *); system(…);«?


 Did I write "it provides safe sandboxes"?

 Denis


 No, but you wrote that it »helps in having safe sandboxes«, and I'm curious
how
 you think it would.


I mean imports usually bring in many more tools for naughty code. And I guess 
in some languages, naughty actions can only be performed via such imported 
modules (system control, direct memory access,...), thus forbidding import is 
an easy way of creating a sandbox. At the very minimum, forbidding import or 
limiting it to a predefined set of modules is a necessary first step, I guess.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 14.04.2011 16:56, schrieb spir:

 On 04/14/2011 03:50 PM, David Nadlinger wrote:

 On 4/14/11 3:44 PM, spir wrote:

 On 04/14/2011 02:40 PM, David Nadlinger wrote:

 On 4/14/11 2:26 PM, spir wrote:

 Not having any imports makes for a faster compile, too.


 ... and helps in having safe sandboxes.


 In which way exactly do I need an import to write »extern(C) int
 system(in char
 *); system(…);«?


 Did I write "it provides safe sandboxes"?

 Denis


 No, but you wrote that it »helps in having safe sandboxes«, and I'm
 curious how
 you think it would.


 
 I mean imports usually bring in many more tools for naughty code. And I
 guess in some languages, naughty actions can only be performed via such
 imported modules (system control, direct memory access,...), thus
 forbidding import is an easy way of creating a sandbox. At the very
 minimum, forbidding import or limiting it to a predefined set of modules
 is a necessary first step, I guess.
 
 Denis


As long as any C function can be called just by defining it, this is
just snake oil. For other languages this may work, but it'd make more
sense to just use a modified standard-lib that asserts when forbidden
functions are used.

For D (and probably any other system programming language) it makes more
sense to restrict on OS level, for example with SELinux, and assume that
the user code is pure evil.

Cheers,
- Daniel
Apr 14 2011
prev sibling next sibling parent Sequ <user example.net> writes:
 bearophile wrote:

 This is a problem. Unittest code is not meant to produce an output,
 while online snippets to try are meant to nearly always produce a
 meaningful output.


 ...



 assert(sort([4, 2]) == [2, 4]);

 does look pretty neat. I guess the alternative is:

 writeln(sort[4, 2]); // prints "[2, 4]"
 ...



 But, regardless, there's nothing much my compile helper and
 javascript can do here. The examples in the documentation would
 have to be changed.


Is it maybe possible for the Javascript to take all statements of the form:
assert(a == b);
and rewrite them (in the Source Code window that pops up) as:
writeln(a);
?
I'm sure something could be written that works for most of the code found
in the documentation (even if it doesn't work for all possible D code).
Apr 14 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/14/2011 03:04 AM, Adam D. Ruppe wrote:

 bearophile wrote:

  This is a problem. Unittest code is not meant to produce an output,
  while online snippets to try are meant to nearly always produce a
  meaningful output.




 I don't know - I like the approach Andrei took in the docs, writing
 a series of true assertations.

 assert(sort([4, 2]) == [2, 4]);

 does look pretty neat. I guess the alternative is:

 writeln(sort[4, 2]); // prints "[2, 4]"


What about

    // sort([4, 2]) == [2, 4])

? Looks to me both simpler & clearer.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/11 7:25 AM, spir wrote:

 On 04/14/2011 03:04 AM, Adam D. Ruppe wrote:

 bearophile wrote:

 This is a problem. Unittest code is not meant to produce an output,
 while online snippets to try are meant to nearly always produce a
 meaningful output.




 I don't know - I like the approach Andrei took in the docs, writing
 a series of true assertations.

 assert(sort([4, 2]) == [2, 4]);

 does look pretty neat. I guess the alternative is:

 writeln(sort[4, 2]); // prints "[2, 4]"


 What about

 // sort([4, 2]) == [2, 4])

 ? Looks to me both simpler & clearer.

 Denis


I don't like that one bit. What is it trying to achieve or improve?

Andrei
Apr 14 2011
parent spir <denis.spir gmail.com> writes:
On 04/14/2011 04:24 PM, Andrei Alexandrescu wrote:

 On 4/14/11 7:25 AM, spir wrote:

 On 04/14/2011 03:04 AM, Adam D. Ruppe wrote:

 bearophile wrote:

 This is a problem. Unittest code is not meant to produce an output,
 while online snippets to try are meant to nearly always produce a
 meaningful output.




 I don't know - I like the approach Andrei took in the docs, writing
 a series of true assertations.

 assert(sort([4, 2]) == [2, 4]);

 does look pretty neat. I guess the alternative is:

 writeln(sort[4, 2]); // prints "[2, 4]"


 What about

 // sort([4, 2]) == [2, 4])

 ? Looks to me both simpler & clearer.

 Denis


 I don't like that one bit. What is it trying to achieve or improve?


assert(sort([4, 2]) == [2, 4]);

What is it trying to achieve or improve?
plus: is this bebug code / error catching; or information to the reader?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 13 Apr 2011 21:04:25 -0400, Adam D. Ruppe  
<destructionator gmail.com> wrote:


 On the other hand, having output there might be more interesting
 to look at than "yay the asserts all passed!".


I think this is a good point.  Someone playing with a language might type  
in the example, and do:

/home/steves> dmd example.d
/home/steves> ./example
/home/steves> (ok... I guess that worked, but I'm not sure what happened)

In other words, there is a benefit to the interaction with the learner.   
In other words, you get to "see it working", rather than only see when it  
fails.  You also get a confirmation that the compiler is actually building  
something.  For the above code, all one really knows is that the compiler  
made an executable.  There's no confirmation that the code being run is  
actually what you typed in.

Sometimes, I worry that my unit tests or asserts aren't running.  Every  
once in a while, I have to change one to fail to make sure that code is  
compiling (this is especially true when I'm doing version statements or  
templates).  It would be nice if there was a -assertprint mode which  
showed asserts actually running (only for the module compiled with that  
switch, of course).

-Steve
Apr 14 2011
next sibling parent David Nadlinger <see klickverbot.at> writes:
On 4/14/11 4:03 PM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code is
 compiling (this is especially true when I'm doing version statements or
 templates). It would be nice if there was a -assertprint mode which
 showed asserts actually running (only for the module compiled with that
 switch, of course).


You are not the only one, I can't resist to do this quite often when I 
work with template-heavy code, or compiler bugs come into play.

At least for the unit tests, this could probably be integrated with a 
test harness (and named tests), which would have a verbose mode which 
logs each completed unittest block.

David
Apr 14 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running.  Every once in
 a while, I have to change one to fail to make sure that code is compiling (this
 is especially true when I'm doing version statements or templates).  It would
 be nice if there was a -assertprint mode which showed asserts actually running
 (only for the module compiled with that switch, of course).


Man, I'm very pleased to read someone else advocating for optionally verbose 
assertions.
This could use 2 arguments instead of a predicate:
     assert(expressions, value);
Example use:

unittest {
     auto args = [0, 1, -1, 999, -999];
     auto vals = [a, b, c, d, e]; // letters here represent expected values
     foreach (i ; 0..args.length)
         assert(f(args[i]), vals[i]);
}

During a test session, assert-mode is set to 'verbose'. This would print for 
instance, in case f(999) fails:
"
assert: f(0) --> a
assert: f(1) --> b
assert: f(-1) --> c
********************************
Assertion Error:
     expression  : f(999)
     expected    : d
     outcome     : whatever
********************************
assert: f(-999) --> e
"
Then, we get all we need to comfortably debug, I guess. Also note /other/ 
unittests (eg one testing g called by f) may also bring in valuable feedback 
data on how the program actually runs.

As is discussed in this thread, this verbose mode is also very nice for code 
samples (introduction to D, manuals, tutorials, howtos, and even exchanges on 
mailing lists...).

For a plain regression test, after some change has been made to a piece of 
code, assert-mode is set to 'silent'. This would only print out failure cases:
"
********************************
Assertion Error:
     expression  : f(999)
     expected    : d
     outcome     : whatever
********************************
"
Then, we just have to turn assert-mode back to verbose, and happily start 
debugging ;-)

Note: 2 friendly complementary features are (1) expected outcome may be an 
exception, (2) outcome may be expression via a string representation. This is 
the reason why output shows as '-->', not '=='.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Apr 2011 11:28:39 -0400, spir <denis.spir gmail.com> wrote:


 On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running.  Every  
 once in
 a while, I have to change one to fail to make sure that code is  
 compiling (this
 is especially true when I'm doing version statements or templates).  It  
 would
 be nice if there was a -assertprint mode which showed asserts actually  
 running
 (only for the module compiled with that switch, of course).


 Man, I'm very pleased to read someone else advocating for optionally  
 verbose assertions.
 This could use 2 arguments instead of a predicate:
      assert(expressions, value);
 Example use:


[snip]

I don't think we can change assert syntax now.  What I was looking was for  
something more like:

assert(x == y);

prints out

"asserting x == y: true"

for asserts that pass when you have the 'verbose assert' flag turned on.   
This should be easy to do in the compiler by just translating

assert(expr);

to something like:

auto result = evaluateAssert(expr);
print("asserting expr: ", result ? "true" : "false");
assert(result);

-Steve
Apr 14 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 14.04.2011 17:47, schrieb Steven Schveighoffer:

 On Thu, 14 Apr 2011 11:28:39 -0400, spir <denis.spir gmail.com> wrote:
 

 On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. 
 Every once in
 a while, I have to change one to fail to make sure that code is
 compiling (this
 is especially true when I'm doing version statements or templates). 
 It would
 be nice if there was a -assertprint mode which showed asserts
 actually running
 (only for the module compiled with that switch, of course).


 Man, I'm very pleased to read someone else advocating for optionally
 verbose assertions.
 This could use 2 arguments instead of a predicate:
      assert(expressions, value);
 Example use:


 
 [snip]
 
 I don't think we can change assert syntax now.  What I was looking was
 for something more like:
 
 assert(x == y);
 
 prints out
 
 "asserting x == y: true"
 
 for asserts that pass when you have the 'verbose assert' flag turned
 on.  This should be easy to do in the compiler by just translating
 
 assert(expr);
 
 to something like:
 
 auto result = evaluateAssert(expr);
 print("asserting expr: ", result ? "true" : "false");
 assert(result);
 
 -Steve


Another possibility are named unittests and printing out "running test
'foobar' was successful".
One message for every assert is too verbose IMHO.

Cheers,
- Daniel
Apr 14 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Apr 2011 12:35:49 -0400, Daniel Gibson <metalcaedes gmail.com>  
wrote:


 Am 14.04.2011 17:47, schrieb Steven Schveighoffer:

 On Thu, 14 Apr 2011 11:28:39 -0400, spir <denis.spir gmail.com> wrote:


 On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running.
 Every once in
 a while, I have to change one to fail to make sure that code is
 compiling (this
 is especially true when I'm doing version statements or templates).
 It would
 be nice if there was a -assertprint mode which showed asserts
 actually running
 (only for the module compiled with that switch, of course).


 Man, I'm very pleased to read someone else advocating for optionally
 verbose assertions.
 This could use 2 arguments instead of a predicate:
      assert(expressions, value);
 Example use:


 [snip]

 I don't think we can change assert syntax now.  What I was looking was
 for something more like:

 assert(x == y);

 prints out

 "asserting x == y: true"

 for asserts that pass when you have the 'verbose assert' flag turned
 on.  This should be easy to do in the compiler by just translating

 assert(expr);

 to something like:

 auto result = evaluateAssert(expr);
 print("asserting expr: ", result ? "true" : "false");
 assert(result);

 -Steve


 Another possibility are named unittests and printing out "running test
 'foobar' was successful".
 One message for every assert is too verbose IMHO.


I'm thinking of the code examples that have asserts in them.  I totally  
like the idea of code examples in ddoc being compiled as unit tests.  This  
ensures your examples don't get out of date or are not invalid (as many of  
phobos' examples are).  Nothing is worse when learning a language to  
encounter errors or unexpected results from the sanctioned examples.  This  
means they have to look like unit tests, but also be useful for learning  
(see my above issue).

A compromise might be to be able to name unit tests, and then run a  
specific unit test by name on execution only.  This allows you to ensure a  
specific unit test (and specific asserts in that unit test) are running  
without having to see all the asserts from the other unit tests, but also  
allows using asserts for general example code/testing.

This also could mean that you could simply directly compile a phobos  
module with -assertverbose -unittest and do:

./algorithm --run-unit-test std.algorithm.sort_example

to see all the asserts working for that example.

-Steve
Apr 14 2011
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 On Thu, 14 Apr 2011 12:35:49 -0400, Daniel Gibson <metalcaedes gmail.com>
 
 wrote:

 Am 14.04.2011 17:47, schrieb Steven Schveighoffer:

 On Thu, 14 Apr 2011 11:28:39 -0400, spir <denis.spir gmail.com> wrote:

 On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running.
 Every once in
 a while, I have to change one to fail to make sure that code is
 compiling (this
 is especially true when I'm doing version statements or templates).
 It would
 be nice if there was a -assertprint mode which showed asserts
 actually running
 (only for the module compiled with that switch, of course).


 
 Man, I'm very pleased to read someone else advocating for optionally
 verbose assertions.
 
 This could use 2 arguments instead of a predicate:
 assert(expressions, value);
 
 Example use:


 [snip]
 
 I don't think we can change assert syntax now. What I was looking was
 for something more like:
 
 assert(x == y);
 
 prints out
 
 "asserting x == y: true"
 
 for asserts that pass when you have the 'verbose assert' flag turned
 on. This should be easy to do in the compiler by just translating
 
 assert(expr);
 
 to something like:
 
 auto result = evaluateAssert(expr);
 print("asserting expr: ", result ? "true" : "false");
 assert(result);
 
 -Steve


 
 Another possibility are named unittests and printing out "running test
 'foobar' was successful".
 One message for every assert is too verbose IMHO.


 
 I'm thinking of the code examples that have asserts in them. I totally
 like the idea of code examples in ddoc being compiled as unit tests. This
 ensures your examples don't get out of date or are not invalid (as many of
 phobos' examples are). Nothing is worse when learning a language to
 encounter errors or unexpected results from the sanctioned examples. This
 means they have to look like unit tests, but also be useful for learning
 (see my above issue).
 
 A compromise might be to be able to name unit tests, and then run a
 specific unit test by name on execution only. This allows you to ensure a
 specific unit test (and specific asserts in that unit test) are running
 without having to see all the asserts from the other unit tests, but also
 allows using asserts for general example code/testing.
 
 This also could mean that you could simply directly compile a phobos
 module with -assertverbose -unittest and do:
 
 ./algorithm --run-unit-test std.algorithm.sort_example
 
 to see all the asserts working for that example.


I want named unit tests regardless, because then you'd get recognizable 
function names in the stack traces from exceptions that escape unit test 
blocks. Being able to print out which unit test is running or just finished by 
using a particular flag would definitely make some people around here happier 
though (much as it definitely shouldn't be the default behavior).

- Jonathan M Davis
Apr 14 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Apr 2011 13:27:32 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Thu, 14 Apr 2011 12:35:49 -0400, Daniel Gibson  
 <metalcaedes gmail.com>

 wrote:

 Am 14.04.2011 17:47, schrieb Steven Schveighoffer:

 On Thu, 14 Apr 2011 11:28:39 -0400, spir <denis.spir gmail.com>  




 wrote:

 On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running.
 Every once in
 a while, I have to change one to fail to make sure that code is
 compiling (this
 is especially true when I'm doing version statements or templates).
 It would
 be nice if there was a -assertprint mode which showed asserts
 actually running
 (only for the module compiled with that switch, of course).


 Man, I'm very pleased to read someone else advocating for optionally
 verbose assertions.

 This could use 2 arguments instead of a predicate:
 assert(expressions, value);

 Example use:


 [snip]

 I don't think we can change assert syntax now. What I was looking was
 for something more like:

 assert(x == y);

 prints out

 "asserting x == y: true"

 for asserts that pass when you have the 'verbose assert' flag turned
 on. This should be easy to do in the compiler by just translating

 assert(expr);

 to something like:

 auto result = evaluateAssert(expr);
 print("asserting expr: ", result ? "true" : "false");
 assert(result);

 -Steve


 Another possibility are named unittests and printing out "running test
 'foobar' was successful".
 One message for every assert is too verbose IMHO.


 I'm thinking of the code examples that have asserts in them. I totally
 like the idea of code examples in ddoc being compiled as unit tests.  
 This
 ensures your examples don't get out of date or are not invalid (as many  
 of
 phobos' examples are). Nothing is worse when learning a language to
 encounter errors or unexpected results from the sanctioned examples.  
 This
 means they have to look like unit tests, but also be useful for learning
 (see my above issue).

 A compromise might be to be able to name unit tests, and then run a
 specific unit test by name on execution only. This allows you to ensure  
 a
 specific unit test (and specific asserts in that unit test) are running
 without having to see all the asserts from the other unit tests, but  
 also
 allows using asserts for general example code/testing.

 This also could mean that you could simply directly compile a phobos
 module with -assertverbose -unittest and do:

 ./algorithm --run-unit-test std.algorithm.sort_example

 to see all the asserts working for that example.


 I want named unit tests regardless, because then you'd get recognizable
 function names in the stack traces from exceptions that escape unit test
 blocks. Being able to print out which unit test is running or just  
 finished by
 using a particular flag would definitely make some people around here  
 happier
 though (much as it definitely shouldn't be the default behavior).


I agree it should not be the default.

What I'm trying to do is find a solution that makes examples with asserts  
useful for learning (i.e. show that something is happening), and try and  
make it also be useful for unit test debugging.

Obviously, during normal unit tests, you want only errors to print out.

-Steve
Apr 14 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/14/2011 06:52 PM, Steven Schveighoffer wrote:

 A compromise might be to be able to name unit tests, and then run a specific
 unit test by name on execution only.  This allows you to ensure a specific unit
 test (and specific asserts in that unit test) are running without having to see
 all the asserts from the other unit tests, but also allows using asserts for
 general example code/testing.


This is precisely why I often have a single unittest block, that controls 
actual test funcs (which have names :-)

void test1 () {...}
void test2 () {...}
void test3 () {...}
unittest {
     // just uncomment func calls you want to run
//~    test1();
//~    test2();
//~    test3();
}
void main () {}

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 04/14/2011 06:35 PM, Daniel Gibson wrote:

 Am 14.04.2011 17:47, schrieb Steven Schveighoffer:

 On Thu, 14 Apr 2011 11:28:39 -0400, spir<denis.spir gmail.com>  wrote:


 On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running.
 Every once in
 a while, I have to change one to fail to make sure that code is
 compiling (this
 is especially true when I'm doing version statements or templates).
 It would
 be nice if there was a -assertprint mode which showed asserts
 actually running
 (only for the module compiled with that switch, of course).


 Man, I'm very pleased to read someone else advocating for optionally
 verbose assertions.
 This could use 2 arguments instead of a predicate:
       assert(expressions, value);
 Example use:


 [snip]

 I don't think we can change assert syntax now.  What I was looking was
 for something more like:

 assert(x == y);

 prints out

 "asserting x == y: true"

 for asserts that pass when you have the 'verbose assert' flag turned
 on.  This should be easy to do in the compiler by just translating

 assert(expr);

 to something like:

 auto result = evaluateAssert(expr);
 print("asserting expr: ", result ? "true" : "false");
 assert(result);




The problem is how do /you/ get expr's original expression? In other words, is 
there a way to do it without compiler magic?
(I think even passing expr as string and using string mixins would not do it, 
because the string must be constant.)


 -Steve


 Another possibility are named unittests and printing out "running test
 'foobar' was successful".
 One message for every assert is too verbose IMHO.


There may be a third, intermediate mode. But many times having the list of 
check result is very helpful to support one's thought, or is just what you need 
in any case. Wouldn't it be stupid to require you to write one writeln per 
assertion just because we omitted this verbode mode?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Apr 2011 14:38:32 -0400, spir <denis.spir gmail.com> wrote:


 On 04/14/2011 06:35 PM, Daniel Gibson wrote:

 Am 14.04.2011 17:47, schrieb Steven Schveighoffer:

 On Thu, 14 Apr 2011 11:28:39 -0400, spir<denis.spir gmail.com>  wrote:


 On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running.
 Every once in
 a while, I have to change one to fail to make sure that code is
 compiling (this
 is especially true when I'm doing version statements or templates).
 It would
 be nice if there was a -assertprint mode which showed asserts
 actually running
 (only for the module compiled with that switch, of course).


 Man, I'm very pleased to read someone else advocating for optionally
 verbose assertions.
 This could use 2 arguments instead of a predicate:
       assert(expressions, value);
 Example use:


 [snip]

 I don't think we can change assert syntax now.  What I was looking was
 for something more like:

 assert(x == y);

 prints out

 "asserting x == y: true"

 for asserts that pass when you have the 'verbose assert' flag turned
 on.  This should be easy to do in the compiler by just translating

 assert(expr);

 to something like:

 auto result = evaluateAssert(expr);
 print("asserting expr: ", result ? "true" : "false");
 assert(result);




 The problem is how do /you/ get expr's original expression? In other  
 words, is there a way to do it without compiler magic?
 (I think even passing expr as string and using string mixins would not  
 do it, because the string must be constant.)


compiler magic :)  I.e. this proposal requires the compiler to change the  
way assert is implemented.

-Steve
Apr 14 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/14/2011 05:47 PM, Steven Schveighoffer wrote:

 On Thu, 14 Apr 2011 11:28:39 -0400, spir <denis.spir gmail.com> wrote:


 On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every once in
 a while, I have to change one to fail to make sure that code is compiling (this
 is especially true when I'm doing version statements or templates). It would
 be nice if there was a -assertprint mode which showed asserts actually running
 (only for the module compiled with that switch, of course).


 Man, I'm very pleased to read someone else advocating for optionally verbose
 assertions.
 This could use 2 arguments instead of a predicate:
 assert(expressions, value);
 Example use:


 [snip]

 I don't think we can change assert syntax now. What I was looking was for
 something more like:

 assert(x == y);

 prints out

 "asserting x == y: true"

 for asserts that pass when you have the 'verbose assert' flag turned on. This
 should be easy to do in the compiler by just translating

 assert(expr);

 to something like:

 auto result = evaluateAssert(expr);
 print("asserting expr: ", result ? "true" : "false");
 assert(result);


Yes. Actually, I did not mean changing assert specifically, rather having an 
"asserting func" with 2 arguments, like;
     check(expression, expected_value);
Now, my post was unclear (previous ones on the topic used "check").

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code is
 compiling (this is especially true when I'm doing version statements or
 templates). It would be nice if there was a -assertprint mode which
 showed asserts actually running (only for the module compiled with that
 switch, of course).


Could this be achieved within the language?

Andrei
Apr 14 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Apr 2011 12:48:26 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code is
 compiling (this is especially true when I'm doing version statements or
 templates). It would be nice if there was a -assertprint mode which
 showed asserts actually running (only for the module compiled with that
 switch, of course).


 Could this be achieved within the language?


I think you need to do it at the compiler level to make it useful.  For  
example, an assert like:

assert(container.length == 5);

To print this out properly, I'd want to see that the assert passed, but  
also what the test was.  I think there is already some work being  
commissioned (if not already in progress) on dissecting the expression  
into string form in the compiler.

I don't know how you would do this in a DRY fashion without compiler  
help.  You can't use a mixin string because mixins are compiled in the  
context where you mix them in.

I outlined a possible solution in a response to Daniel that I believe:

1. allows one to 'see' an example working that just uses asserts
2. allows one to run specific unit tests to make sure they are working  
(via names)
3. does not require any changes to any asserts in existance.

I think this would be an awesome feature.  One of the cool things about  
the new way phobos runs unit tests (one module at a time) is that if a  
particular test fails, I can just build/run it over and over again until  
it passes.  This is huge since to run the full phobos unit tests can take  
a while.

To just be able to select on the command line how to run unit tests (I  
think overtaking the command line args for unittest-enabled code is  
reasonable) would be a great tool for debugging code via unittests and  
assert printouts.

It also gives us a smooth transition into using ddoc examples as unit  
tests.

-Steve
Apr 14 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/11 12:00 PM, Steven Schveighoffer wrote:

 On Thu, 14 Apr 2011 12:48:26 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code is
 compiling (this is especially true when I'm doing version statements or
 templates). It would be nice if there was a -assertprint mode which
 showed asserts actually running (only for the module compiled with that
 switch, of course).


 Could this be achieved within the language?


 I think you need to do it at the compiler level to make it useful. For
 example, an assert like:

 assert(container.length == 5);

 To print this out properly, I'd want to see that the assert passed, but
 also what the test was.



That would help enforce and other artifacts too. I'm thinking along the 
lines of:

void myassert(string expr = __traits(text, condition))(bool condition) {
   ...
}

with, of course, a simpler syntax.


 I think this would be an awesome feature. One of the cool things about
 the new way phobos runs unit tests (one module at a time) is that if a
 particular test fails, I can just build/run it over and over again until
 it passes. This is huge since to run the full phobos unit tests can take
 a while.


That's exactly how Phobos unittest work on Linux, and that was the 
motivation behind making it work that way.


Andrei
Apr 14 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Apr 2011 13:16:33 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 4/14/11 12:00 PM, Steven Schveighoffer wrote:

 On Thu, 14 Apr 2011 12:48:26 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code  
 is
 compiling (this is especially true when I'm doing version statements  
 or
 templates). It would be nice if there was a -assertprint mode which
 showed asserts actually running (only for the module compiled with  
 that
 switch, of course).


 Could this be achieved within the language?


 I think you need to do it at the compiler level to make it useful. For
 example, an assert like:

 assert(container.length == 5);

 To print this out properly, I'd want to see that the assert passed, but
 also what the test was.



 That would help enforce and other artifacts too. I'm thinking along the  
 lines of:

 void myassert(string expr = __traits(text, condition))(bool condition) {
    ...
 }

 with, of course, a simpler syntax.


It still isn't exactly right.  Assert has some special properties that  
cannot be duplicated exactly with library code.  Such as true lazy  
evaluation and elimination during release mode.

But yes, it would be nice to be able to get a string of the parameters of  
a function (macro?).  It would certainly make this more feasible.

However, all this is ignoring one simple thing -- the hundreds of  
thousands of lines of code (mostly from std.datetime ;) ) that already  
have asserts.  Hooking assert directly automatically gives us a tool for  
printf debugging without changing any code.

I would point out that even for this solution, we are still modifying the  
compiler.  Any particular reason why adding a new trait is more desirable  
than modifying assert?  I certainly feel that the auto-inclusion of all  
the existing asserts would far outweigh the extensibility of adding a  
trait (which could probably also be added at the same time).


 I think this would be an awesome feature. One of the cool things about
 the new way phobos runs unit tests (one module at a time) is that if a
 particular test fails, I can just build/run it over and over again until
 it passes. This is huge since to run the full phobos unit tests can take
 a while.


 That's exactly how Phobos unittest work on Linux, and that was the  
 motivation behind making it work that way.


Yeah, I know, that's why I brought it up :)

-Steve
Apr 14 2011
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 On Thu, 14 Apr 2011 13:16:33 -0400, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:

 On 4/14/11 12:00 PM, Steven Schveighoffer wrote:

 On Thu, 14 Apr 2011 12:48:26 -0400, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:

 On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code
 is
 compiling (this is especially true when I'm doing version statements
 or
 templates). It would be nice if there was a -assertprint mode which
 showed asserts actually running (only for the module compiled with
 that
 switch, of course).


 
 Could this be achieved within the language?


 
 I think you need to do it at the compiler level to make it useful. For
 example, an assert like:
 
 assert(container.length == 5);
 
 To print this out properly, I'd want to see that the assert passed, but
 also what the test was.


 

 That would help enforce and other artifacts too. I'm thinking along the
 lines of:
 
 void myassert(string expr = __traits(text, condition))(bool condition) {
 
 ...
 
 }
 
 with, of course, a simpler syntax.


 
 It still isn't exactly right. Assert has some special properties that
 cannot be duplicated exactly with library code. Such as true lazy
 evaluation and elimination during release mode.
 
 But yes, it would be nice to be able to get a string of the parameters of
 a function (macro?). It would certainly make this more feasible.
 
 However, all this is ignoring one simple thing -- the hundreds of
 thousands of lines of code (mostly from std.datetime ;) ) that already
 have asserts. Hooking assert directly automatically gives us a tool for
 printf debugging without changing any code.


Actually, std.datetime doesn't use assert much. It mostly uses a version of 
assertPred which it has as a private function. Also, I've been rewriting the 
unit tests, and that will result in far fewer actual lines with assert or 
_assertPred thanks to more looping and whatnot. It does increase the need for 
printing out the actual results from an assertion though (which _assertPred 
does on failure). And what you're asking for here is at least related to the 
requested improvements to assert which resulted in assertPred being scrapped.

- Jonathan M Davis
Apr 14 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Apr 2011 13:38:11 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 Actually, std.datetime doesn't use assert much. It mostly uses a version  
 of
 assertPred which it has as a private function. Also, I've been rewriting  
 the
 unit tests, and that will result in far fewer actual lines with assert or
 _assertPred thanks to more looping and whatnot. It does increase the  
 need for
 printing out the actual results from an assertion though (which  
 _assertPred
 does on failure). And what you're asking for here is at least related to  
 the
 requested improvements to assert which resulted in assertPred being  
 scrapped.


I forgot that assert isn't actually used much in std.datetime!

-Steve
Apr 14 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/11 12:26 PM, Steven Schveighoffer wrote:

 Any particular reason why adding a new trait is more
 desirable than modifying assert?


Absolutely!

Andrei
Apr 14 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 4/14/11 12:26 PM, Steven Schveighoffer wrote:

 Any particular reason why adding a new trait is more
 desirable than modifying assert?


 Absolutely!


Maybe I worded my question wrong.  What I meant was what *is* the  
particular reason.

And keep in mind, when I say modifying assert, I mean changing the way  
assert compiles, not changing it's usage.

-Steve
Apr 14 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/11 1:26 PM, Steven Schveighoffer wrote:

 On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 4/14/11 12:26 PM, Steven Schveighoffer wrote:

 Any particular reason why adding a new trait is more
 desirable than modifying assert?


 Absolutely!


 Maybe I worded my question wrong. What I meant was what *is* the
 particular reason.


Already mentioned it - enforce() is a prime example. Any similar 
facility could make good use the feature.


 And keep in mind, when I say modifying assert, I mean changing the way
 assert compiles, not changing it's usage.


I understand.


Andrei
Apr 14 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Apr 2011 14:57:44 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 4/14/11 1:26 PM, Steven Schveighoffer wrote:

 On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 4/14/11 12:26 PM, Steven Schveighoffer wrote:

 Any particular reason why adding a new trait is more
 desirable than modifying assert?


 Absolutely!


 Maybe I worded my question wrong. What I meant was what *is* the
 particular reason.


 Already mentioned it - enforce() is a prime example. Any similar  
 facility could make good use the feature.


Sure.  However, not modifying assert means all asserts in my code should  
now be rewritten to myassert, or whatever function is implemented.  The  
huge benefit of modifying assert is that we don't have to change any  
existing code.

I'm not saying adding a trait is not desirable, I just think it doesn't  
get us to the right place on its own.

If I ever get around to hacking the compiler, I certainly will try this to  
see how well it works.

-Steve
Apr 14 2011
parent spir <denis.spir gmail.com> writes:
On 04/14/2011 09:10 PM, Steven Schveighoffer wrote:

 On Thu, 14 Apr 2011 14:57:44 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 4/14/11 1:26 PM, Steven Schveighoffer wrote:

 On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 4/14/11 12:26 PM, Steven Schveighoffer wrote:

 Any particular reason why adding a new trait is more
 desirable than modifying assert?


 Absolutely!


 Maybe I worded my question wrong. What I meant was what *is* the
 particular reason.


 Already mentioned it - enforce() is a prime example. Any similar facility
 could make good use the feature.


 Sure. However, not modifying assert means all asserts in my code should now be
 rewritten to myassert, or whatever function is implemented. The huge benefit of
 modifying assert is that we don't have to change any existing code.

 I'm not saying adding a trait is not desirable, I just think it doesn't get us
 to the right place on its own.

 If I ever get around to hacking the compiler, I certainly will try this to see
 how well it works.


A solution may be to carefully craft the new trait-using func's interface so 
that upgrading can be automatised (rewriting tool for assert calls only); 
possibly with constraints to make the tool's life easier, like "assertions 
stands alone on their line".

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-14 18:48, Andrei Alexandrescu wrote:

 On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code is
 compiling (this is especially true when I'm doing version statements or
 templates). It would be nice if there was a -assertprint mode which
 showed asserts actually running (only for the module compiled with that
 switch, of course).


 Could this be achieved within the language?

 Andrei


Don't know exactly how he wants it to behave but I have have a look one 
of my earlier posts:

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=134796

-- 
/Jacob Carlborg
Apr 15 2011
parent reply Roman Ivanov <nospam example.com> writes:
== Quote from Jacob Carlborg (doob me.com)'s article

 On 2011-04-14 18:48, Andrei Alexandrescu wrote:

 On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code is
 compiling (this is especially true when I'm doing version statements or
 templates). It would be nice if there was a -assertprint mode which
 showed asserts actually running (only for the module compiled with that
 switch, of course).


 Could this be achieved within the language?

 Andrei


 Don't know exactly how he wants it to behave but I have have a look one
 of my earlier posts:


http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=134796

I'm somewhat shifting the topic, but it seems strange that unit tests are run
when
you run an executable. Wouldn't it make sense to run them immediately after
compilation? I mean, what would be the use case where you would want to re-run a
unit test on the code that's already compiled and tested? This could also solve
the problem with messages on success, since you can output a success message
after
compilation.

Sorry if I'm missing some obvious issue with this suggestion.
Apr 15 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 == Quote from Jacob Carlborg (doob me.com)'s article
 

 On 2011-04-14 18:48, Andrei Alexandrescu wrote:

 On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code
 is compiling (this is especially true when I'm doing version
 statements or templates). It would be nice if there was a
 -assertprint mode which showed asserts actually running (only for the
 module compiled with that switch, of course).


 
 Could this be achieved within the language?
 
 Andrei


 
 Don't know exactly how he wants it to behave but I have have a look one


 

 of my earlier posts:


 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group
 =digitalmars.D&artnum=134796
 
 I'm somewhat shifting the topic, but it seems strange that unit tests are
 run when you run an executable. Wouldn't it make sense to run them
 immediately after compilation? I mean, what would be the use case where
 you would want to re-run a unit test on the code that's already compiled
 and tested? This could also solve the problem with messages on success,
 since you can output a success message after compilation.
 
 Sorry if I'm missing some obvious issue with this suggestion.


You essentially need an executable to run the unit tests. It doesn't 
technically have to be an altered version of the normal executable, but you 
need an executable. It was probably just simplest to alter the normal 
executable so that it included the unit tests. Code coverage works the same 
way. Also, it could be desirable to build the unit tests without actually 
running them, at least some of the time, so separating the unit test build 
from actually running the unit tests can be beneficial.

Regardless, the way it works works quite well overall. What is typically done, 
I believe is create a module with an empty main specifically for running the 
unit tests. So, building with -unittest isn't usually done with the normal 
executable, and you don't typically run your normal executable with the unit 
tests included in it.

And as for the lack of messages on success, the whole idea is that there be no 
messages on success. You don't normally care about the unit tests unless they 
fail, so messages on success are just useless cruft in most cases, and it's 
_much_ easier to verify that the unit tests past programmatically if the 
output on success is nothing. Besides, if you really want to output success 
for each unit test, all you have to do is add writeln calls to the end of all 
your tests (annoying perhaps, but not hard). It would certainly be possible to 
add a flag to dmd that made it so that each test printed out on success for 
those who wanted it, but the value is questionable, and Walter and the other 
compiler devs have much more critical issues to work on.

- Jonathan M Davis
Apr 15 2011
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Roman Ivanov wrote:

 == Quote from Jacob Carlborg (doob me.com)'s article

 On 2011-04-14 18:48, Andrei Alexandrescu wrote:

 On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code is
 compiling (this is especially true when I'm doing version statements or
 templates). It would be nice if there was a -assertprint mode which
 showed asserts actually running (only for the module compiled with that
 switch, of course).


 Could this be achieved within the language?

 Andrei


 Don't know exactly how he wants it to behave but I have have a look one
 of my earlier posts:


 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=134796
 
 I'm somewhat shifting the topic, but it seems strange that unit tests are run
when
 you run an executable. Wouldn't it make sense to run them immediately after
 compilation? I mean, what would be the use case where you would want to re-run
a
 unit test on the code that's already compiled and tested? This could also solve
 the problem with messages on success, since you can output a success message
after
 compilation.
 
 Sorry if I'm missing some obvious issue with this suggestion.


	Off the top of my head, I see two reasons why running the tests
separately is a good thing:
 - It allows to run the test in a debugger;
 - Cross-compilation.

		Jerome
-- 
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Apr 15 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-04-14 16:03, Steven Schveighoffer wrote:

 On Wed, 13 Apr 2011 21:04:25 -0400, Adam D. Ruppe
 <destructionator gmail.com> wrote:


 On the other hand, having output there might be more interesting
 to look at than "yay the asserts all passed!".


 I think this is a good point. Someone playing with a language might type
 in the example, and do:

 /home/steves> dmd example.d
 /home/steves> ./example
 /home/steves> (ok... I guess that worked, but I'm not sure what happened)

 In other words, there is a benefit to the interaction with the learner.
 In other words, you get to "see it working", rather than only see when
 it fails. You also get a confirmation that the compiler is actually
 building something. For the above code, all one really knows is that the
 compiler made an executable. There's no confirmation that the code being
 run is actually what you typed in.

 Sometimes, I worry that my unit tests or asserts aren't running. Every
 once in a while, I have to change one to fail to make sure that code is
 compiling (this is especially true when I'm doing version statements or
 templates). It would be nice if there was a -assertprint mode which
 showed asserts actually running (only for the module compiled with that
 switch, of course).

 -Steve


I agree. For one of my projects I created a simple unit test "framework" 
that:

* Displays the number of tests
* Doesn't stop the whole run when a single assert fails
* Prints out the failing asserts, if any
* It's possible to add descriptions to the tests

The testing framework in use: 
http://www.dsource.org/projects/orange/browser/tests/Serializer.d#L249

The actual framework: 
http://www.dsource.org/projects/orange/browser/orange/test/UnitTester.d

-- 
/Jacob Carlborg
Apr 15 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 14 Apr 2011 01:11:48 +0200, bearophile <bearophileHUGS lycos.com>  
wrote:


 Adam D. Ruppe:


 * Since most of them don't actually output anything, the program
   now detects output.length == 0 and says "Program run
   successfully." upon completion to give some feedback.


 This is a problem. Unittest code is not meant to produce an output,  
 while online snippets to try are meant to nearly always produce a  
 meaningful output.


I thought about this - if D's reflection capabilities allowed it to
iterate over local variables, the system could simply add code to
print those, to the end of the unittest. Likely requires some
changes to the compiler, though.


-- 
Simen
Apr 13 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 04/14/2011 01:11 AM, bearophile wrote:

 * Since most of them don't actually output anything, the program

     now detects output.length == 0 and says "Program run
     successfully." upon completion to give some feedback.




 This is a problem. Unittest code is not meant to produce an output, while
online snippets to try are meant to nearly always produce a meaningful output.


All my unittest blocks produce meaningful output; there exist firstly for that. 
Am I an heretic?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/11 6:52 AM, spir wrote:

 On 04/14/2011 01:11 AM, bearophile wrote:

 * Since most of them don't actually output anything, the program

 now detects output.length == 0 and says "Program run
 successfully." upon completion to give some feedback.




 This is a problem. Unittest code is not meant to produce an output,
 while online snippets to try are meant to nearly always produce a
 meaningful output.


 All my unittest blocks produce meaningful output; there exist firstly
 for that. Am I an heretic?


No, you're just doing it wrong. Heretic might be sometimes good.

http://www.linfo.org/rule_of_silence.html

Andrei
Apr 14 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/14/2011 04:22 PM, Andrei Alexandrescu wrote:

 On 4/14/11 6:52 AM, spir wrote:

 On 04/14/2011 01:11 AM, bearophile wrote:

 * Since most of them don't actually output anything, the program

 now detects output.length == 0 and says "Program run
 successfully." upon completion to give some feedback.




 This is a problem. Unittest code is not meant to produce an output,
 while online snippets to try are meant to nearly always produce a
 meaningful output.


 All my unittest blocks produce meaningful output; there exist firstly
 for that. Am I an heretic?


 No, you're just doing it wrong. Heretic might be sometimes good.

 http://www.linfo.org/rule_of_silence.html


Right, I know that and totally disagree. This rule is IMO the exact opposite of 
human-friendliness (numerous authors on usability and friends share this 
opinion, indeed).
Also, this is not what I'm talking about: I'm not here expecting just "all 
fine, brother", but various data helping me and understand how things actually 
worked; to be short, data useful to the coder during development or debug. See 
also reply to Steven's post.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/11 10:34 AM, spir wrote:

 On 04/14/2011 04:22 PM, Andrei Alexandrescu wrote:

 On 4/14/11 6:52 AM, spir wrote:

 On 04/14/2011 01:11 AM, bearophile wrote:

 * Since most of them don't actually output anything, the program

 now detects output.length == 0 and says "Program run
 successfully." upon completion to give some feedback.




 This is a problem. Unittest code is not meant to produce an output,
 while online snippets to try are meant to nearly always produce a
 meaningful output.


 All my unittest blocks produce meaningful output; there exist firstly
 for that. Am I an heretic?


 No, you're just doing it wrong. Heretic might be sometimes good.

 http://www.linfo.org/rule_of_silence.html


 Right, I know that and totally disagree.


This is a good cue to revisit your opinion.


 This rule is IMO the exact
 opposite of human-friendliness (numerous authors on usability and
 friends share this opinion, indeed).


This may be a misunderstanding of a valid human friendliness concern 
with a simple mistake. In addition, you reject an authoritative text 
with an appeal to an undefined authority.

Applying "let me output something and eye it" at the level of each unit 
test does not scale because it makes it extremely difficult to identify 
issues once one test of many produces unexpected output. There are 
programs (such as "expect") that automate that task. The ultimate goal 
is to make errors noisy and easy to identify.


 Also, this is not what I'm talking about: I'm not here expecting just
 "all fine, brother", but various data helping me and understand how
 things actually worked; to be short, data useful to the coder during
 development or debug. See also reply to Steven's post.


I understand, and I repeat: that approach works great for exploration, 
but won't scale for systematic unit testing.


Andrei
Apr 14 2011
parent spir <denis.spir gmail.com> writes:
On 04/14/2011 07:09 PM, Andrei Alexandrescu wrote:

 Applying "let me output something and eye it" at the level of each unit test
 does not scale because it makes it extremely difficult to identify issues once
 one test of many produces unexpected output. There are programs (such as
 "expect") that automate that task. The ultimate goal is to make errors noisy
 and easy to identify.


I do agree. But this point gets very different once:
(1) One can selectively chose which tests to run, thus having only output from 
one(s) relevant to the issue at hand (eg via named unittests),
(2) one can switch from silent to verbose modes.

In the case of unittests used for regression testing (*), the silent mode would 
initially just say "there is an error here". Then switching to verbose mode, on 
relevant tests only, would provide helpful data to solve the issue.
But for me unittests are far to be useful only for regression tests. They are 
everyday development tools I constantly use: as sample code, to study what code 
actually does, te debud or improve a piece of code; even if I don't practice 
TDD at all (rarely use tests as kinf of spec).

I have talked about that already, but the message seems difficult to pass for a 
reason I do not grok.

Denis

(*) I mean, to check all still works fine after a change on an initially 
running codebase.
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 On 04/14/2011 04:22 PM, Andrei Alexandrescu wrote:

 On 4/14/11 6:52 AM, spir wrote:

 On 04/14/2011 01:11 AM, bearophile wrote:

 * Since most of them don't actually output anything, the program
 

 now detects output.length == 0 and says "Program run
 successfully." upon completion to give some feedback.




 
 This is a problem. Unittest code is not meant to produce an output,
 while online snippets to try are meant to nearly always produce a
 meaningful output.


 
 All my unittest blocks produce meaningful output; there exist firstly
 for that. Am I an heretic?


 
 No, you're just doing it wrong. Heretic might be sometimes good.
 
 http://www.linfo.org/rule_of_silence.html


 
 Right, I know that and totally disagree. This rule is IMO the exact
 opposite of human-friendliness (numerous authors on usability and friends
 share this opinion, indeed).
 Also, this is not what I'm talking about: I'm not here expecting just "all
 fine, brother", but various data helping me and understand how things
 actually worked; to be short, data useful to the coder during development
 or debug. See also reply to Steven's post.


And I have no clue what you'd want to print. Normally, if the assertion 
passes, everything's fine. Seeing output from it would just be noise. Now, 
being able to verify that a particular unit test block is running when you're 
dealing with version blocks could be useful periodically, but all you really 
need to verify is that the test is run, not what it's doing. If you need to 
debug it, you debug it. And if you need to debug it, usually the assertions 
would be failing anyway. Having debug output printing all of the time would 
just get in the way and make it harder to find what you need when you're 
actually debugging, since you'd have too much debug output if everything's 
printing debug output. So, I really don't understand what you'd be looking to 
print.

I can understand someone wanting the list of tests printed so that they could 
see where in the tests the program is, but generally, all you need to know is 
whether the tests failed, and seeing the failed assertions gives you that. So, 
ultimately, I don't really understand the push for stuff being printed during 
unit tests unless you're explicitly debugging a unit test.

- Jonathan M Davis
Apr 14 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-13 22:38, Andrei Alexandrescu wrote:

 I'm quite excited about the new look of std (right now realized only by
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html).
 Here's a suggestion on how we could improve it more.

 Adam wrote an in-browser evaluator for D programs. These, when presented
 on the homepage with "hello, world" in them are of limited usefulness.
 However, a personalized "try it now" button present for _each_ artifact
 in an std module would be of great usefulness.

 When I try some html or javascript I find it very useful to go to one of
 those sites that allow me to try some code right then and there. The key
 aspect is that the code edit field is already filled with code that is
 close to what I'm looking for, which I can then edit and try until it
 does what I want.

 Similarly, it would be great if next to e.g.
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion
 there would be a "Try it now" button. Clicking on that button would open
 an overlay with an edit window. The edit window initially contains the
 example text:

 unittest
 {
 int[] a = [ 1, 2, 4, 5, 7, 9 ];
 int[] b = [ 0, 1, 2, 4, 7, 8 ];
 int[] c = [ 10 ];
 assert(setUnion(a, b).length == a.length + b.length);
 assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
 assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9,
 10][]));
 }

 Then the user can change, compile, and run that program, to ultimately
 close the overlay and return to the documentation.

 What do you think? This would require some work in the compiler (make
 unittests documentable, make their text available to ddoc macros) and
 some work in the front end. I hope this catches the fancy of e.g.
 Walter/Don and Adam.


 Andrei


This is looking better and better each time. One thing I still don't 
like is the cheat sheet, I think it looks cluttered. I think it's just 
too much text in most of the rows. The text in the Set operations looks 
good.

I would also prefer more vertical space in some of the examples. I think 
the first example for the "reduce" function looks good but I find the 
example for the "filter" function harder to read because there's no 
empty newlines.

-- 
/Jacob Carlborg
Apr 14 2011
parent reply spir <denis.spir gmail.com> writes:
On 04/14/2011 11:30 AM, Jacob Carlborg wrote:

 On 2011-04-13 22:38, Andrei Alexandrescu wrote:

 I'm quite excited about the new look of std (right now realized only by
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html).
 Here's a suggestion on how we could improve it more.

 Adam wrote an in-browser evaluator for D programs. These, when presented
 on the homepage with "hello, world" in them are of limited usefulness.
 However, a personalized "try it now" button present for _each_ artifact
 in an std module would be of great usefulness.

 When I try some html or javascript I find it very useful to go to one of
 those sites that allow me to try some code right then and there. The key
 aspect is that the code edit field is already filled with code that is
 close to what I'm looking for, which I can then edit and try until it
 does what I want.

 Similarly, it would be great if next to e.g.
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion
 there would be a "Try it now" button. Clicking on that button would open
 an overlay with an edit window. The edit window initially contains the
 example text:

 unittest
 {
 int[] a = [ 1, 2, 4, 5, 7, 9 ];
 int[] b = [ 0, 1, 2, 4, 7, 8 ];
 int[] c = [ 10 ];
 assert(setUnion(a, b).length == a.length + b.length);
 assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
 assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9,
 10][]));
 }

 Then the user can change, compile, and run that program, to ultimately
 close the overlay and return to the documentation.

 What do you think? This would require some work in the compiler (make
 unittests documentable, make their text available to ddoc macros) and
 some work in the front end. I hope this catches the fancy of e.g.
 Walter/Don and Adam.


 Andrei


 This is looking better and better each time. One thing I still don't like is
 the cheat sheet, I think it looks cluttered. I think it's just too much text in
 most of the rows.


Agreed. May I suggest an easy (and imo sensible) doc guideline, which would 
also allow automatising cheat sheet generation?

1. The top line of each doc block defines the *purpose* of the given piece of
code
    (meaning for a func either what value it computes, or what action it
performs).
2. This line is taken as is by a cheat sheet generator.

Examples:

PI
   /** The value of pi.
       ... */

struct Circle
   /** Representation of a circle, as defined by radius & position of center.
       ... */

size_t indexOf (E elem)		// method of some collection type
   /** Index of first occurrence of elem in collection --else throws IndexError.
       ... */

void_t erase (E elem)		// ditto
   /** Erase all occurrences of elem in collection.
       ... */

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/11 6:49 AM, spir wrote:

 On 04/14/2011 11:30 AM, Jacob Carlborg wrote:

 On 2011-04-13 22:38, Andrei Alexandrescu wrote:

 I'm quite excited about the new look of std (right now realized only by
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html).
 Here's a suggestion on how we could improve it more.

 Adam wrote an in-browser evaluator for D programs. These, when presented
 on the homepage with "hello, world" in them are of limited usefulness.
 However, a personalized "try it now" button present for _each_ artifact
 in an std module would be of great usefulness.

 When I try some html or javascript I find it very useful to go to one of
 those sites that allow me to try some code right then and there. The key
 aspect is that the code edit field is already filled with code that is
 close to what I'm looking for, which I can then edit and try until it
 does what I want.

 Similarly, it would be great if next to e.g.
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion

 there would be a "Try it now" button. Clicking on that button would open
 an overlay with an edit window. The edit window initially contains the
 example text:

 unittest
 {
 int[] a = [ 1, 2, 4, 5, 7, 9 ];
 int[] b = [ 0, 1, 2, 4, 7, 8 ];
 int[] c = [ 10 ];
 assert(setUnion(a, b).length == a.length + b.length);
 assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
 assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9,
 10][]));
 }

 Then the user can change, compile, and run that program, to ultimately
 close the overlay and return to the documentation.

 What do you think? This would require some work in the compiler (make
 unittests documentable, make their text available to ddoc macros) and
 some work in the front end. I hope this catches the fancy of e.g.
 Walter/Don and Adam.


 Andrei


 This is looking better and better each time. One thing I still don't
 like is
 the cheat sheet, I think it looks cluttered. I think it's just too
 much text in
 most of the rows.


 Agreed. May I suggest an easy (and imo sensible) doc guideline, which
 would also allow automatising cheat sheet generation?

 1. The top line of each doc block defines the *purpose* of the given
 piece of code
 (meaning for a func either what value it computes, or what action it
 performs).
 2. This line is taken as is by a cheat sheet generator.

 Examples:

 PI
 /** The value of pi.
 ... */

 struct Circle
 /** Representation of a circle, as defined by radius & position of center.
 ... */

 size_t indexOf (E elem) // method of some collection type
 /** Index of first occurrence of elem in collection --else throws
 IndexError.
 ... */

 void_t erase (E elem) // ditto
 /** Erase all occurrences of elem in collection.
 ... */

 Denis


I prefer the cheat sheet contain code snippets. They are very terse and 
eloquent.

Andrei
Apr 14 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 04/14/2011 04:21 PM, Andrei Alexandrescu wrote:

 On 4/14/11 6:49 AM, spir wrote:

 On 04/14/2011 11:30 AM, Jacob Carlborg wrote:

 On 2011-04-13 22:38, Andrei Alexandrescu wrote:

 I'm quite excited about the new look of std (right now realized only by
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html).
 Here's a suggestion on how we could improve it more.

 Adam wrote an in-browser evaluator for D programs. These, when presented
 on the homepage with "hello, world" in them are of limited usefulness.
 However, a personalized "try it now" button present for _each_ artifact
 in an std module would be of great usefulness.

 When I try some html or javascript I find it very useful to go to one of
 those sites that allow me to try some code right then and there. The key
 aspect is that the code edit field is already filled with code that is
 close to what I'm looking for, which I can then edit and try until it
 does what I want.

 Similarly, it would be great if next to e.g.
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion


 there would be a "Try it now" button. Clicking on that button would open
 an overlay with an edit window. The edit window initially contains the
 example text:

 unittest
 {
 int[] a = [ 1, 2, 4, 5, 7, 9 ];
 int[] b = [ 0, 1, 2, 4, 7, 8 ];
 int[] c = [ 10 ];
 assert(setUnion(a, b).length == a.length + b.length);
 assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
 assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9,
 10][]));
 }

 Then the user can change, compile, and run that program, to ultimately
 close the overlay and return to the documentation.

 What do you think? This would require some work in the compiler (make
 unittests documentable, make their text available to ddoc macros) and
 some work in the front end. I hope this catches the fancy of e.g.
 Walter/Don and Adam.


 Andrei


 This is looking better and better each time. One thing I still don't
 like is
 the cheat sheet, I think it looks cluttered. I think it's just too
 much text in
 most of the rows.


 Agreed. May I suggest an easy (and imo sensible) doc guideline, which
 would also allow automatising cheat sheet generation?

 1. The top line of each doc block defines the *purpose* of the given
 piece of code
 (meaning for a func either what value it computes, or what action it
 performs).
 2. This line is taken as is by a cheat sheet generator.

 Examples:

 PI
 /** The value of pi.
 ... */

 struct Circle
 /** Representation of a circle, as defined by radius & position of center.
 ... */

 size_t indexOf (E elem) // method of some collection type
 /** Index of first occurrence of elem in collection --else throws
 IndexError.
 ... */

 void_t erase (E elem) // ditto
 /** Erase all occurrences of elem in collection.
 ... */

 Denis


 I prefer the cheat sheet contain code snippets. They are very terse and
eloquent.

 Andrei


Right. Sounds sensible.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
If you remove asserts then we're forced to run the examples every time
we want to remind ourselves of what the code does. With assert it's
obvious what the code does.

And besides, why discourage newbies from learning about assert?
Looking at examples with write's could make them think it's a standard
way of debugging code. "Just print all the values, and then check them
one by one to see that they're valid". Let them learn about asserts
and unittests.

Another thing is that I believe most newcomers to D are C/C++
programmers. If we show them how easy it is to check code for
validity, they might start thinking that using asserts and unittests
isn't such a bad thing after all. If you ask an average C++ programmer
whether they use asserts and unittests they'll probably say "No,
because it's too difficult to set up and run them, and I'm too lazy".
Heck, every other day someone comes up with a brand new unittest C++
_library_, and people are completely uninterested.

IMO we shouldn't be hiding D's top features just because they might
look foreign at first.
Apr 14 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/13/2011 10:38 PM, Andrei Alexandrescu wrote:

 Similarly, it would be great if next to e.g.
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion
 there would be a "Try it now" button. Clicking on that button would open an
 overlay with an edit window. The edit window initially contains the example
text:

 unittest
 {
    int[] a = [ 1, 2, 4, 5, 7, 9 ];
    int[] b = [ 0, 1, 2, 4, 7, 8 ];
    int[] c = [ 10 ];
    assert(setUnion(a, b).length == a.length + b.length);
    assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
    assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9,
10][]));
 }

 Then the user can change, compile, and run that program, to ultimately close
 the overlay and return to the documentation.


I recently started to realise a side-effect of the unittest feature is to 
provide D with "free code blocks", where one can just put any piece of code; 
code that could go on a module's top-level in a dynamic language.
Typically, this allows clean trials. Eg, does '/' perform euclidean division or 
true division, on integers / reals?

import std.stdio : writeln;
unittest {
     writeln("ints");
     writeln(2/2);
     writeln(3/2);
}
unittest {
     writeln("reals");
     writeln(2.0/2);
     writeln(3.0/2);
}
void main () {}

Sure, one can use main() for this. But unittest blocks are cleaner and allow 
structuration. In the same vein, unittests can be cleanly used to *demonstrate* 
language behaviour; for instance in tutorials, when showing issues like on 
D-leran, or for... bug reports.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling parent reply Gerrit Wichert <gwichert yahoo.com> writes:
Am 13.04.2011 22:38, schrieb Andrei Alexandrescu:

 I'm quite excited about the new look of std (right now realized only 
 by 
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html). 


I just had a look and stumbled over the short description of group:

<http://d-programming-language.org/phobos-prerelease/std_algorithm.html#group> 
         group([5, 2, 2, 3, 3]) returns a range containing the tuples 
tuple(5, 1), tuple(5, 1), tuple(2, 2), and tuple(3, 2).

there seems to be one 'touple(5, 1)' too much.
Apr 14 2011
parent reply David Nadlinger <see klickverbot.at> writes:
On 4/14/11 9:38 PM, Gerrit Wichert wrote:

 Am 13.04.2011 22:38, schrieb Andrei Alexandrescu:

 I'm quite excited about the new look of std (right now realized only
 by
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html).


 I just had a look and stumbled over the short description of group:

 <http://d-programming-language.org/phobos-prerelease/std_algorithm.html#group>
 group([5, 2, 2, 3, 3]) returns a range containing the tuples tuple(5,
 1), tuple(5, 1), tuple(2, 2), and tuple(3, 2).

 there seems to be one 'touple(5, 1)' too much.


This is already fixed in Git, but Andrei apparently didn't get around to 
update the build on the website – thanks anyway.

David
Apr 14 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/11 3:00 PM, David Nadlinger wrote:

 On 4/14/11 9:38 PM, Gerrit Wichert wrote:

 Am 13.04.2011 22:38, schrieb Andrei Alexandrescu:

 I'm quite excited about the new look of std (right now realized only
 by
 http://d-programming-language.org/phobos-prerelease/std_algorithm.html).


 I just had a look and stumbled over the short description of group:

 <http://d-programming-language.org/phobos-prerelease/std_algorithm.html#group>

 group([5, 2, 2, 3, 3]) returns a range containing the tuples tuple(5,
 1), tuple(5, 1), tuple(2, 2), and tuple(3, 2).

 there seems to be one 'touple(5, 1)' too much.


 This is already fixed in Git, but Andrei apparently didn't get around to
 update the build on the website – thanks anyway.

 David


BTW there is a proposal to change group to yield a range of ranges 
instead of a range of tuples.

Do you folks estimate this could cause significant harm to existing code?


Thanks,

Andrei
Apr 14 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 BTW there is a proposal to change group to yield a range of ranges 
 instead of a range of tuples.
 
 Do you folks estimate this could cause significant harm to existing code?


This proposal makes group closer to the semantics of the Python
itertools.groupby. This change doesn't harm my code significantly.

But in my Python code most times I use groupby I have to convert the inner
generator (the inner range) in something eager. So for me the current behaviour
of group is OK. What are the reasons to change it?

Bye,
bearophile
Apr 14 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/11 3:31 PM, bearophile wrote:

 Andrei:


 BTW there is a proposal to change group to yield a range of ranges
 instead of a range of tuples.

 Do you folks estimate this could cause significant harm to existing code?


 This proposal makes group closer to the semantics of the Python
itertools.groupby. This change doesn't harm my code significantly.

 But in my Python code most times I use groupby I have to convert the inner
generator (the inner range) in something eager. So for me the current behaviour
of group is OK. What are the reasons to change it?

 Bye,
 bearophile


The reasons for changing is that often you have groups in which elements 
are not identical, but instead in the same equivalence class. So you 
want not only their number - you want to take a look at the actual 
items. (Consider e.g. grouping some strings by their length.)

Andrei
Apr 14 2011