Firefox cannot load any of the icons so all I see are broken icon images. When I wanted to hit "back" I accidentally voted it up. I was kinda hoping it would start a groundswell of enthusiasm for the comment and it would soar to the top ten.
Well, pg is probably one of them... and some folks likely really are in a position to use whatever language they like.
My day job is avionics software verification, so I don't program much for my job, per se, but what programming I do, I could likely do in Arc, and no one would care, as it's just for internal use.
I'm using OpenHosting, and now running an instance of this Arc News software, along with several small Apache-based sites.
OpenHosting was the best VPS I could find when I signed up for it, but there appear to be better deals available now. If I were doing it again (or bothered to move) I'd probably go with Slicehost.
Okay, forgive me if I'm retarded, but it's been a while since I've done any lisp and reading someone's source always takes a while.
I was trying to go through news.arc and figure out how it deals with memory, and as best I can tell, it doesn't seem to. It looks like it just loads some n most recent stories/posts on startup, and accumulates new ones in memory while simultaneously saving them.
This seems to me that if left running, the app will eventually suck up memory and need to be restarted. Is this the case, or did I miss the line in the implementation where it flushes old stories out?
I'm not convinced of that. It appears to be a macro for building a cache of various things with a timeout. It doesn't appear to touch the stories* table.
On an unrelated note, can anyone explain to me the memory model/threading mechanism interaction? It seemed at first that it was a single-threaded server, but after looking at srv.arc, it's clear that multiple threads are being spawned for the server process, yet stories, profs, and votes* aren't don't seem to be rebuilt from permanent storage, which implies the tables can be shared between processes. Which, I guess, goes back to my original question. So this isn't unrelated at all.
Hmm. After another cursory glance, yes, this appears about correct.
As for memory model: global variables are always shared between threads. The underlying implementation automatically locks tables when mutating them AFAIK.
As for suck up memory: I suppose the thinking is that a single post may very well take less than half a kilobyte, and modern computers have gigabytes of memory, so...
That was my thought too. I suppose I may have been overestimating the traffic to HN, or the size of the server or both. I guess I wanted a definitive answer about having to restart the server periodically. That seems to be the case, but it doesn't seem to be too bad.
This seems to be a pretty good model for a moderate-traffic app with data that gets modified infrequently. I don't think I'm quite ready to arc just for that, but I was wondering if this is a sensible approach in any other language, say, python? Any thoughts?
Well, Arc is still starting. In more-established languages, such approaches are unnecessary: there are libraries which will handle caching of data etc. properly, releasing unused memory for garbage collection once they are no longer accessed for some time, and rebuilding objects from permanent store if they have been disposed. In Arc it's still not yet implemented, so that approach works fine.
That said you might be interested in the so-called "Anarki" repository, which contains some of the elements I and others have built so that the server works a little better. For example: being able to serve files in subdirectories of your Arc installation, instead of the Arc installation; table-like data structures for caching data, or for persistent disk-based data; a slightly more extensible language, with some of the more common methods of extension already prepackaged in macros; etc.
Can you give an example of such libraries, off the top of your head?
I am basically interested in small multi-user applications that don't sit on top of relational databases. There really isn't too much information out there on the matter. Everyone seem to want to use a database, even for the simplest things. I suppose that given the pedigree of arc, this flat file storage business seems sensible enough.
Anyway, thanks for the pointer to anarki. I'll take a look at it.
For that matter, most languages prefer db's because of the fact that file storage operations don't have, umm, structure.
In fact the canonical Arc web app, news.arc, has a list structure to store in the "flat" file. Thus for simple apps where entities only have a few not very complex fields, textual representations of lists seem to be enough.
In other languages however their "array" syntax (which is approximately what lists are in Arc) is usually not readable by a built-in function a la lisp 'read. Also, their array syntax is usually not the center of attention, unlike in Lisp where the code syntax is itself the "array" syntax.
The only times I've seen folks here talk bad (or really even talk at all) about NewLISP is when someone specifically asks about it. I don't think anyone here is out to destroy NewLISP, or to stop people from using it. If it works for you, then go for it!
But Arc is an exercise in minimalism...hang on. pg is being pounded for Arc being too close to Lisp to be hundred-yeary, maybe we should pad the numbers. :)
That one seems kinda expensive. I'd try slicehost.com or vpslink.com depending on your bandwidth needs.
What you need is a VPS server so you can setup arc yourself.
Alternatively though, you might be able to hack arc to work on a site like nearlyfreespeech.net. Their CGI support includes mzscheme http://example.nfshost.com/versions.php
