July 06, 2012
On 7/6/12 10:11 AM, Paulo Pinto wrote:
> We can always make use of that information to compare compile times
> with Go. :)

Damian is working on integrating accurate compilation and run times.

Andrei

July 06, 2012
On Friday, 6 July 2012 at 12:47:59 UTC, Andrei Alexandrescu wrote:
> On 7/6/12 4:43 AM, xenon325 wrote:
>> Looks just great!
>>
>> Maybe it should output compilation/execution times as well ?
>
> I think that's a good idea. We can show the compile and run time separately, where the compilation speed should come shining.
>
> Right now clicking on "run" brings a frame title "Application output". I'm thinking, after the program finished the title could change to e.g. "Application output [compile time: 228ms; run time 157ms]".
>
> On the other hand the load on the compilation machine will influence the timings, so the numbers are not very relevant.
>
>
> Andrei

I humbly believe that information is useless.
Why? - Because at any point of time the server can be congested and those running time figures will go high...
July 06, 2012
On 7/6/12 10:43 AM, Dejan Lekic wrote:
> I humbly believe that information is useless.
> Why? - Because at any point of time the server can be congested and
> those running time figures will go high...

I decided to include those only after Damian mentioned (a) there's sufficient reserve power for the time being, and (b) we can easily scale up with need.

If we get more sophisticated about it all we might be able to report the time actually spent in that particular process.


Andrei
July 06, 2012
On 7/6/2012 5:47 AM, Andrei Alexandrescu wrote:
> On the other hand the load on the compilation machine will influence the
> timings, so the numbers are not very relevant.

I don't think the compile time of 10 line programs is relevant. All you're measuring is the time it takes to load the compiler/linker/library into memory.


July 07, 2012
On Thursday, 5 July 2012 at 16:26:02 UTC, Andrei Alexandrescu wrote:
> Damian is actively working on the UI as I'm writing this. Feel free to chime in with feedback!

When on dlang.org/ and pressing Back and then Forward again, the contents of the input area disappear on Chrome 20.0.1132.47 (OS X): http://imgur.com/TgfnT

David
July 07, 2012
On Saturday, 7 July 2012 at 06:23:03 UTC, David Nadlinger wrote:
> On Thursday, 5 July 2012 at 16:26:02 UTC, Andrei Alexandrescu wrote:
>> Damian is actively working on the UI as I'm writing this. Feel free to chime in with feedback!
>
> When on dlang.org/ and pressing Back and then Forward again, the contents of the input area disappear on Chrome 20.0.1132.47 (OS X): http://imgur.com/TgfnT
>

Nice catch David,
Unfortunately I can't do much about it as it is Webkit bug, so Chromium and Safari suffers from this.

Doesn't happen on Firefox, Opera (and probably IE - can't test right now).
It's bug described here: http://code.google.com/p/chromium/issues/detail?id=64467 and here: https://bugs.webkit.org/show_bug.cgi?id=90259

Looks like fix for this has been applied 8 days ago: http://trac.webkit.org/changeset/121552

I will try to find workaround tho.

Thanks for report David.

Best regards,
Damian Ziemba
July 07, 2012
On Friday, 6 July 2012 at 19:45:42 UTC, Walter Bright wrote:
> On 7/6/2012 5:47 AM, Andrei Alexandrescu wrote:
>> On the other hand the load on the compilation machine will influence the
>> timings, so the numbers are not very relevant.
>
> I don't think the compile time of 10 line programs is relevant. All you're measuring is the time it takes to load the compiler/linker/library into memory.
Machines running compilers are rather high quality with enough power to handle 100 requests same time but, you maybe right, every execution of produced binary has applied it's resources limits.

It has 10mb stack size, 30mb virtual memory and 5secs of CPU clock.
Compilation times maybe accurate but binary run-time may not be.

Adding this feature is 10seconds work as returned JSON already includes timers so no need to hurry with this, we should rethink this.

Personally I would say no for this.
Already enough trolls around, no need to feed them more :)
July 07, 2012
On 7/7/2012 1:44 AM, nazriel wrote:
> Personally I would say no for this.
> Already enough trolls around, no need to feed them more :)

I'd be wary about providing such data just because we can, because it is not reflective of what people will experience using dmd on their own machines, and so it is misleading and will be misused.
July 09, 2012
On Thursday, 5 July 2012 at 16:26:02 UTC, Andrei Alexandrescu wrote:
> Check this out: on http://dlang.org you can actually click in the code example and edit it, then click "Run" and pronto, you see the output!
>
> Damian is actively working on the UI as I'm writing this. Feel free to chime in with feedback!
>
>
> Andrei

Hi,

just noticed than this is broken in Firefox 13.

--
Paulo
July 09, 2012
On Monday, 9 July 2012 at 11:35:59 UTC, Paulo Pinto wrote:
> On Thursday, 5 July 2012 at 16:26:02 UTC, Andrei Alexandrescu wrote:
>> Check this out: on http://dlang.org you can actually click in the code example and edit it, then click "Run" and pronto, you see the output!
>>
>> Damian is actively working on the UI as I'm writing this. Feel free to chime in with feedback!
>>
>>
>> Andrei
>
> Hi,
>
> just noticed than this is broken in Firefox 13.
>
> --
> Paulo

Can you collaborate? I have FF 13 and it works fine. We had small glitch with updating website itself, although it should work fine from now.

David (klickverbot), are examples working for you now? (Back - Forward transition)?

Thanks
Damian Ziemba