There are plenty of other great contributions out there but this will get you started and covers the major sites that I can recall offhand. Other good links anyone?
In the past I have gotten a sqlite C binding working through an old alpha version of the ffi. It was never completely stable and was failing in the ffi. But it was doable. I had limited time and couldn't hunt down where it was failing in the ffi. I didn't have any requirements to use the FFI and was just exploring the possibility. So I moved back to SQLite using JGC's TCP server [1]. Which was a great solution! It wasn't especially portable between mac and linux (ie deploying it to my web server). But it was fast to set up and robust on the mac.
Similarly I worked on MySQL bindings but they were never robust enough to use especially in comparison to the JGC solution. This was a few versions ago before the ffi was flushed out. Maybe a similar TCP server using MySQL would make sense. I know it worked really well for me. I had problems making it portable (between Ubuntu / FreeBSD). But after those problems were worked out it was stable.
Good luck. I'm interested in what ends up working for you.
One note: I needed to change the dbslayer source code, prior to making the install, in order to eliminate the spaces that aw's combinator would choke on. It was a trivial change though...
[EDIT: Correction I was using an older version of aw's combinator - the new version handles spaces]
That's cool. It's a neat idea that by default (if there isn't an explicit reason why you have to do something else), all interfaces can be HTTP, and as a bonus use JSON as your data interchange format...
Exactly. The concept is great. Even now when I am starting to learn haskell, the first thing I am doing checking out haskells' JSON parser to communicate via HTTP. Conceptually I can keep doing this and communicate easily across any language. And since SQL to URL is so basic I can re-use/apply dbslayer to any language too.
Are you going to fix this and other small bugs in the tar or are we just going to patch them on the fly? If the plan is to patch maybe we need a thread with patches - so people can get up and running fast.
Personally I think using Anarki is fast, straightforward and community friendly... So that may be my choice in the end when arc3/mz372 has some time to stabilize.
Is there a reason you are avoiding source control?
"You guys are so fast I didn't have time to write anything about it. The purpose is to let users over a certain karma threshold flag spam and troll submissions.
It should only be used for spams and really egregious trolling, not for stuff that's merely vapid or mistaken or off-topic.
Please don't click on it just to try it out. Flags are really being recorded, so flagging something randomly could damage the reputation of the flagger and/or the submitter of the thing that got flagged."
It would have been nice to simply add a tooltip or other means of indicating some clue of what this feature was. Naturally I clicked it hoping I would be taken to a page that explained its use (since there was no help link or other info available).
I then unflagged the post since I realized it was just some sort of boolean indicator. Poor design IMO. Someone could think "flagging" was a way of marking interest or something.
I enjoy seeing real examples of arc. From my experience much more can be learned from creating live applications compared with writing interesting bits of code.
I find the language discussion interesting, don't get me wrong. Some of the discussions have actually been useful. But in the end most languages are steered by "real projects" as stefano has put it. The top real world apps that I can think of are news.ycombinator.com pageonetimes.com and ballerinc.com. I'd expect PG's and antiismist's experiences with these first real world application to effect arc as much as or more than Anarki code base. Even though there has been a lot more time and effort that has gone into Anarki.
This post has some discussion on scaling problems that PG is having with news.arc and with continuations (on news.ycombinator.com). It's worth checking out and is relevant to both the future of arc and PG's current mind set when it comes to arc's web programming model.
I was surprised to find no responses from the core group of arc forum contributors.
I like the "It's hard to beat closures for elegance" argument, but I haven't really tried the arc way for web apps yet. It's also true that over time we see higher-level languages win out over their lower-level counterparts despite initial objections about performance. So it might be that closures win eventually over initial objections about scalability. But I like readable urls, http://example.com/a?fn=fkg34lk doesn't really tell me anything.
I changed a lot of my arc.sh months ago and didn't want to commit it to Anarki.Since Anarki initially had a lot of linux users and it would have misbehaved linux.
