Is this browser dependent? In Firefox 2.0.0.12 on Linux, I can't reproduce what you describe. After the first click, clicking on the same spot has no effect at all.
As kens said, it's hard to beat good old usenet. Reading comp.lang.lisp is much easier for completeness. Now if the forum had a filtering mechanism a la slashdot for me to only look at comments with a certain point threshold, I'd be happier. I think I'll make that a separate post ( http://arclanguage.com/item?id=3920 ).
I just stopped checking my older threads - if someone leaves a comment on an old item, there's no way I'm going to invest the time to go looking for it.
I'm still hoping we'll get a nice way to get bugfixes directly into the Arc codebase though. No feedback from pg yet on the other thread. I am curious if there's a reason why he's unwilling to include things such as the date fix into the codebase. I suppose it could be just lack of time at this point.
Everyone has exactly the same amount of time: 24 hours in a day.
Every task that a person does means that there is something else that they are not doing.
To incorporate bug fixes sounds easy, but consider for example all the fixes floating around for "mkdir". Each one fixes mkdir for their operating system and their version of mzscheme, yet it's time consuming to ensure that a bugfix doesn't break someone else's installation.
When a bugfix has been tested and used by lots of people and there is a consensus that it is the right thing to do, then it would be easy for Paul to incorporate it into an arcn. When someone simply says "here's a fix!", then it takes a lot more time to figure out if it is the right fix and if it isn't going to make it worse for someone else.
This why the whole "network of trust" concept as it relates to massive distributed software projects is important. I'm sure if Arc will do well then PG will need to establish people whom he trusts to aggregate packages and give him only the good ones in order to cut down his personal time investment. Some guys on this forum are definitely knowledgeable enough and motivated.
Although I'm a Lisp newbie, the more I learn about Lisp, the more I like it. However, one of my frustrations (which seems to be all too common), is dealing with the myriad of implementation choices, libraries, etc. There are pros and cons to those choices, but more cons ;)
For me, the BDFL model has worked quite well for Ruby, Python, etc. I expect I'm very biased since I'm a Ruby programmer currently, but I think it's fair to say the model works well to avoid dividing and conquering itself.
There are many things to like about Arc, but I think the fact that it could potentially unify a large community around a single implementation is very powerful.
I've also heard that it's better to put systems in place before you need them instead of afterward.
The only practical alternative to BDFL is design by committee. For Anarki, the committee is anyone with git installed. Much as I love the work being done on Anarki, the model won't scale and either pg, nex3 or someone else will end up having to make the decisions.
So I'm sort of saying... it'll work out in the end, maybe.
The conflict I see is between pg releasing Arc at this very early stage because he found it useable vs you all going batsh*t over the volatility. You are both right! It is great that the users are chomping at the bit for something stable, but pg warned everyone that this was an experimental release and he planned to trash all our code at will. :)
Looking at Arc as a Lisp veteran I can assure you all that you totally need to reset your expectations and sign up for a fun exploration of a possible (emphasis on possible, because the more I learn of Lisp-1 the more I consider it a grave error) ... of a possible sweet spot in the abstract Lisp language space.
If Lisp-1 does turn out to be a grave error, it doesn't seem like it would be that difficult to either add the Scheme features that make Lisp-1 work, or turn it into a Lisp-2, given the side of the Arc codebase.
Right now, I'm just looking for the best Lisp to develop web applications with. Ruby on Rails is my benchmark, and I think it can be improved on with Lisp, but that remains conjecture at this point.
Just to be clear. I'm not asking for stability at this point. I agree that maintaining backward compatibility would waste time & effort. Arc can still evolve like crazy and break existing code, but it would be nice to have a way for the community to feed patches & bug fixes to pg besides the Arc forum.
No, it does not work that way, although people who do not understand macros (such as Guido) live in fear of that hobgoblin.
Macros are not used to create unrecognizable languages. They are used when an API has grown to the point where writing the code to use it can be automated. That is probably hard to parse if you fear macros, because you can only fear macros if you do not know how they are used. But the idea is simple.
This little call tends to require this little call before it and this little call after it, or something like that. And this pattern appears often enough, or the Lisp developer recognizes it as the sort of thing that will appear again and again, and they just say, macro time!
They then give the macro a totally comprehensible name derived from the bits of the API being hit and, golly, no confusion.
The other time you see macros is in things like aif. There will only be so many of these, and they will confuse people not at all.
It seems to me some people want macros to be a problem. They never are.
Yes, well. In the office no one wants to touch my code, because it's built from bunches of macros, and no one else here knows how macros work. Oh well. Could be just me, I suppose.
Edit: gets even worse when I use C macros in C code ^^, they even instated a rule that loops should use for(i=0;i<limit;++i) and not my otherwise shorter repeat(i,limit) macro
We almost agree. :) I don't know, when they look at your functions do they know what they do? When they see a class name do they understand the class hierarchy? Or do they start browsing? As for repeat(i, limit) being banned, I presume because no one could guess what it does, well, I am looking at bartender's school. The more I learn about software the harder it is to work with some people. :) But I don't blame Dilbert on the C preprocessor.
LOL. I think the problem, partly, is the fact that we're attached to a Japanese company and the Japanese might not have that good a grasp of what "repeat" means (they tend to have a sneering attitude to anything non-Japanese, which means they suffer in the english-language department). I did manage to talk some guys into using repeat, but they got ordered by the Japanese to change it to "for", presumably because the Japanese knew "for", didn't know what "repeat" meant, and couldn't figure out how #define worked.
Edit: Too bad I'm a teetotaler, I'd have gone to bartender school too.
"one of my frustrations ... is dealing with the myriad of implementation choices"
As Sartre said, you are not free to be not free. Have fun with Arc, use Common Lisp. Lisp-1 buys you nothing but aggravation, minimal just means you end up building your own full tool chest that is incompatible with anyone else's so you can never share code.
The idea that Lisp's greatest strength - the inherent ability to transform to whatever you want it to be - is also its greatest weakness, since it prevents you from easily communicating with others what you intend - that is, one man's 'let (CL, Scheme) is another man's 'with (Arc).
Having ported my groovy Cells project to Arc, I can confirm that it was a pain where I sit that "only the names have been changed" in several cases. :) But pg gets the benefit of the doubt from me because I own both his books and he kinda rocks when it comes to Lisp.
The funny thing is that perhaps unbeknownst to you all the Lisp establishment is ragging on pg for Arc being too much like Lisp, you (and I a little) are hosed that he diverged from Lisp, so him being smart I would guess he is now ignoring everyone. :)
The only thing I can offer is that it totally sucks to have an installed base and not be able to change things cuz you will break all the code ofyour users. Only at times like this is an inventor free to change everything and anything, I guess pg did.
See the parent of that link for other ways to patch. I just used one of the original patches and modified slightly for arc1. For arc2, I justed used ediff in emacs and copied the old date block over.
Instead of patching each release, maybe it would be better to simply redefine the date function in separate file and always load that.
Just add more Arc processes to the balancer section. Apache listens on port 80 and each Arc process listens on a different port 8080, 8081, etc.
The mod_proxy_balancer module is what many folks use to put Apache in front of a bunch of Mongrel processes when using Rails, the same approach works for Arc, but there are cluster implications (see the parent of the link above http://arclanguage.com/item?id=3486) because Arc doesn't use a 'shared nothing' approach.
In particular, I think you'd at least want to use sticky sessions so the same browser is always routed to the same Arc process where the correct continuation(s) would reside.
You've asked a good question. pg could probably answer off the top of his head; otherwise, it may take some digging into the source. If I had to guess, I'd say that you'd have problems clustering it as is, but that's an easy guess, because clustering usually has problems :)
Ruby on Rails (and many others) use a shared nothing approach, so each node in the cluster has to read everything it needs from the database (or other store) for each request. It's very easy to scale until you overload your database, but not very efficient.
Another approach is to have the nodes in the cluster communicate information amongst themselves.
I would think using something like memcached would be pretty effective in helping to cluster news.yc
Thanks for the reply. I played with it a little bit, and I think there could be some contention. If two users created kids for the same item, the kids entry in the 'item template has to be updated to reflect the two new articles (ie, the item has to be serialized again). If the users are on different instances I believe you could lose information ... I think :)
Also, it doesn't seem save-table is safe in the sense that it just overwrites the file that's already there (as opposed to writing it with a different name, and just 'mv' over which is supposedly atomic).
It looks to me like it's the age of the story that's considered, not the age of the vote. Apparently, the stories only have their rank adjusted when a vote is made, so the solution was to have something in addition to voting drive the adjustment - in this case, randomly selecting a story.
Technically no. I read up on the spec a while back. GET parameters are probably better referred to as URL args, and they're always retrievable via the URL in the first line of the HTTP request. In the case of a POST, the content of the request may (also) have arguments.
It's not super common to use both, but it's definitely not disallowed by the spec.
I'd be interested in seeing any references about this. From what I've read, it seems the intent is to not combine them, but I haven't seen anything explicitly forbidding it. Do you have a source that indicates combining URL parameters in a POST is encouraged, or at least permitted?
"I noticed that in the case of POST handle-request-thread (srv.arc) throws away the GET args."
Which seems to be criticizing what I would consider perfectly valid behavior. I'm not sure why you would want to split your parameters for a POST between the POST parameters and pieces of the URL.
If a change to the source is being suggested, it seems reasonable to determine if it's warranted by the protocol.
I haven't checked the specs, but in most web languages I have worked with you can get GET parameters even when there is a POST. If this is not allowed by specs than I stand corrected. GET parameters are just stuck to the url so its definitely possible.. If its not allowed in theory then I stand corrected, I just often find it useful.
