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

> 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

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.

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.

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.

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

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

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

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

We'd need a sandbox.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

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