5 ms·

arc doesn't even pass its own challenge. "link unknown or expired"... great.

evanrmurphy 16y ago
Providing independent sandboxed evaluation for every visitor to the site costs a lot of memory. On my Linode 512, it only takes about 90 users before all the memory is consumed and I have to start garbage collecting. If you saw that message when you tried to evaluate something, you probably got GC'd. I'd like to find a more graceful way of handling this. Any suggestions?
- IdeaHamster 16y ago
  JS Arc interpreter? Hey, if they can do it for Haskell… http://github.com/johang88/haskellinjavascript http://github.com/johang88/haskellinjavascript ;)
  - deleted 16y ago
    [deleted]
  - ido 16y ago
    Interesting! I don't know arc, but I'll bet compiling scheme to js is a lot easier than compiling haskell to js.
  - widgetycrank 16y ago
    Nostrademons wrote one, but it's pretty old, and I think the site is down. http://arclanguage.org/item?id=1629 http://arclanguage.org/item?id=1629
    - evanrmurphy 16y ago
      It's still up at http://jonathan.tang.name/files/arclite/index.html http://jonathan.tang.name/files/arclite/index.html
- catechu 16y ago
  I'm not familiar with Arc's internals or the effect that this would have in the context of GC, but as a hack, perhaps you could assign multiple people to a single interpreter instance, prepend prefixes to symbols to avoid collisions before evaluating (e.g. user_1_total, user_1_total, user_2_total), and make each user optionally aware of commands from other users on that instance (e.g. implemented as in-browser chat), letting individual evaluations block each other -- I doubt anyone's doing anything particularly heavy-duty or time-sensitive on your server. This is convoluted and fragile, but if I wanted to roll out "sandboxes" on limited hardware I'd start with something like this.
  - evanrmurphy 16y ago
    This is a very clever idea. Even if I don't implement it this way, your suggestion has inspired me to think outside the box. Here's an approach that's a variation/refinement of my current one: Instead of just orphaning old clients when their sandboxes get GC'd, leave them with a local copy of their REPL history. If they try to use the REPL again after a long period of silence, a new sandbox will be allocated for them (as it would be for a fresh client), and all the commands in their REPL history loaded in to bring it back to its previous state. This approach could potentially pave the way for users having persistent REPLs, even across page reloads.
- evanrmurphy 16y ago
  Update: I had to keep lowering the threshold to avoid server stalls. Currently at 50, where the site seems more stable.

Providing independent sandboxed evaluation for every visitor to the site costs a lot of memory. On my Linode 512, it only takes about 90 users before all the memory is consumed and I have to start garbage collecting. If you saw that message when you tried to evaluate something, you probably got GC'd. I'd like to find a more graceful way of handling this. Any suggestions?

IdeaHamster 16y ago
JS Arc interpreter? Hey, if they can do it for Haskell… http://github.com/johang88/haskellinjavascript http://github.com/johang88/haskellinjavascript ;)
- deleted 16y ago
  [deleted]
- ido 16y ago
  Interesting! I don't know arc, but I'll bet compiling scheme to js is a lot easier than compiling haskell to js.
- widgetycrank 16y ago
  Nostrademons wrote one, but it's pretty old, and I think the site is down. http://arclanguage.org/item?id=1629 http://arclanguage.org/item?id=1629
  - evanrmurphy 16y ago
    It's still up at http://jonathan.tang.name/files/arclite/index.html http://jonathan.tang.name/files/arclite/index.html
catechu 16y ago
I'm not familiar with Arc's internals or the effect that this would have in the context of GC, but as a hack, perhaps you could assign multiple people to a single interpreter instance, prepend prefixes to symbols to avoid collisions before evaluating (e.g. user_1_total, user_1_total, user_2_total), and make each user optionally aware of commands from other users on that instance (e.g. implemented as in-browser chat), letting individual evaluations block each other -- I doubt anyone's doing anything particularly heavy-duty or time-sensitive on your server. This is convoluted and fragile, but if I wanted to roll out "sandboxes" on limited hardware I'd start with something like this.
- evanrmurphy 16y ago
  This is a very clever idea. Even if I don't implement it this way, your suggestion has inspired me to think outside the box. Here's an approach that's a variation/refinement of my current one: Instead of just orphaning old clients when their sandboxes get GC'd, leave them with a local copy of their REPL history. If they try to use the REPL again after a long period of silence, a new sandbox will be allocated for them (as it would be for a fresh client), and all the commands in their REPL history loaded in to bring it back to its previous state. This approach could potentially pave the way for users having persistent REPLs, even across page reloads.
evanrmurphy 16y ago
Update: I had to keep lowering the threshold to avoid server stalls. Currently at 50, where the site seems more stable.