3 ms·

They are continuations stored on the server (not a Lisp-specific feature). There is a limit on the number of continuations stored, which is why older ones come

They are continuations stored on the server (not a Lisp-specific feature). There is a limit on the number of continuations stored, which is why older ones come up as unknown or expired. This has been there since Day 1 and will probably never be changed. See also https://news.ycombinator.com/item?id=163696 https://news.ycombinator.com/item?id=163696 https://news.ycombinator.com/item?id=2677469 https://news.ycombinator.com/item?id=2677469

pg 13y ago
Closures, not continuations.
- elwell 13y ago
  Could you give a quick explanation or a link that explains how that is set up? (closures stored on server) Just curious.
  - wlievens 13y ago
    A closure is a function augmented with implicit references to the context in which it was created. In case of an upvote link it would hold references to the post you could upvote. That reference exists not in the URL but in the closure at the servers side. If you keep these objects in memory indefinitely, you'll run out of ram.
    - elwell 13y ago
      Oh, I was assuming some sort of custom implementation for doing that. If it's just hanging around in RAM, fair enough; can't see how that has scaled so well, but hey.
      - wlievens 13y ago
        Well, a closure can't be more than a couple hundred bytes, I guess. If he wants to continue with that technique, I'd hack it like this: use reflection to crawl the closure, isolate the variables bound to the closure context, serialize those (the user id's, post id's, etc). Then the closure code, which will be one of only a few "templates", can be put into a global dictionary. The serialized state goes into the URL parameters. The closure is collected, and "reified" from the global dictionary and URL state once the user performs the action. I don't know if LISP's reflection can pull this off, but I'm pretty sure it's no biggie.

3 ms·

They are continuations stored on the server (not a Lisp-specific feature). There is a limit on the number of continuations stored, which is why older ones come

by pchristensen 13y ago

pg 13y ago
Closures, not continuations.
- elwell 13y ago
  Could you give a quick explanation or a link that explains how that is set up? (closures stored on server) Just curious.
  - wlievens 13y ago
    A closure is a function augmented with implicit references to the context in which it was created. In case of an upvote link it would hold references to the post you could upvote. That reference exists not in the URL but in the closure at the servers side. If you keep these objects in memory indefinitely, you'll run out of ram.
    - elwell 13y ago
      Oh, I was assuming some sort of custom implementation for doing that. If it's just hanging around in RAM, fair enough; can't see how that has scaled so well, but hey.
      - wlievens 13y ago
        Well, a closure can't be more than a couple hundred bytes, I guess. If he wants to continue with that technique, I'd hack it like this: use reflection to crawl the closure, isolate the variables bound to the closure context, serialize those (the user id's, post id's, etc). Then the closure code, which will be one of only a few "templates", can be put into a global dictionary. The serialized state goes into the URL parameters. The closure is collected, and "reified" from the global dictionary and URL state once the user performs the action. I don't know if LISP's reflection can pull this off, but I'm pretty sure it's no biggie.