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

It does alarm NoScript, which blocks it. It runs fine if I disable it though, and probably most people don't use noscript.

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.

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..

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

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.

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

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:

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

# tail -n 2 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.

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

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