dylan-lang / dylan-playground Goto Github PK

Could be fun to play around with mini benchmarks in the playground and share them.

Make something even simpler to use than benchmark-repeat: benchmarking (repeat: 10, print: #t) do-stuff() end which will either return the overall timing and allocation info or print it to the console, depending on the value of the print: argument. (benchmark-repeat returns a sequence of iteration values.)

Don't run the previously built executable if the current build doesn't generate an executable. I suspect this means checking the mod time on the exe before starting the build and comparing after the build.

Probably whitelist libraries and modules that are acceptable.

Limit run-time to, say, 20 seconds.

Lower right corner of code textarea seems natural.

• Start on boot
• Restart if crash
• Restart if too many open files (HTTP server bug)
• Nice to have: a /stats page to see activity

• Font is terrible.
• Use some color

Using the Graph Subclasses example to graph <object> is a nice way to kill the playground. It seems to run forever, despite some attempts in the code to prevent that via ulimit.

 3485 ?        Ssl    0:15 dylan-playground --config /home/cgay/dylan/workspaces/playground/live/config.live.xml --working-directory /
13103 ?        Z      0:00  \_ [sh] <defunct>
25202 ?        Z      0:00  \_ [sh] <defunct>
25307 ?        Z      0:00  \_ [sh] <defunct>

Presumably not calling wait() after process dies. Not sure whether it's the Playground's responsibility or whether run-application should always do it.

Provide checkboxes to enable showing DFM and assembly output.

Currently there's a bug in -dfm for the regular-expression library so can't enable it.

Currently can only generate assembly for HARP back end, IIRC.

To avoid disk full DOS attacks, limit how often one client can share code. Guessing it has to be IP based.

Rather than linking directly to DRM, LibRef, etc, put a Help button with a menu of choices.

Compiler warnings are inside a <pre> tag and they don't wrap to the window width, so they require horizontal scrolling.

Would've been useful for fraya's DOT share: https://play.opendylan.org/shared/034b4318d2a01602

CodeMirror probably?

Currently playground code always goes in ./play-<hash-code>/. Should use a slightly deeper directory structure like ./xx/yy/play-xxyy<rest-of-hash-code> instead.

Could also store metadata about whether the playground was shared and GC the ones over a certain age that haven't been shared.

After running a first example, if I choose another example, the code textfield does not change.

Firefox 83.0 (Linux 64 bits)

Basically store the example code semi-permanently based on the playground ID, but when the link is followed a new playground ID should be created so they don't conflict. I think. Probably need to set a long TTL but make a note that there are no guarantees.

Initial implementation just stores plain text of the code. Need a way to store metadata such as the version of the playground with which it was created so that I can use the correct module definition as that changes. Or possibly just the time the share was created.

Since we don't have Cap'n proto, probably compressed json.

Making this high priority so I don't have to do a data format change after we're using this more.

Use the environment-commands library instead of shelling out to dylan-compiler. This will save the startup time of dylan-compiler, currently 0.17s on the server machine.