If you need the change right away you can patch ac.scm yourself, or, if you don't mind waiting, pg will eventually have a new arc3.tar containing the update.
* cleared my browser cache.
* flushed my airport cache and renewed the DCHP lease.
* I had my machine off last night.
Turned it on this morning and loaded the same process. and it's happening everytime. That kind of replication and consistency suggests it's not just myclient flaking out correct?.
I mean it could be, but why ? It's like my client is flaking out because of the code loaded into it ? Maybe bad javascript or meta tags or something the browser need to process so it flakes out?
Anyway I just don't believe it's not a real error. There's more to it than clients flaking out.
T.
You'll get an "tcp error writing" when in your browser you navigate away from a page before the browser has finished downloading everything.
Usually Arc sends the entire response and closes the connection. When the browser doesn't wait, it closes the connection. Arc is then complaining that the connection has been closed on it.
If you're absolutely sure that everything has been loaded in the page before you click on anything, that would be something to look into further.
If you could catch this happening in a reproducible way we would be very, very grateful. The nature of HN means that we never can. Fortunately it happens very rarely, on the order of once every couple months. But I hate worrying about it.
I had thought of that originally, but the nature of the app is where a user would log in for 10-20 minutes per day (at least to start) and read the data. The maximum possible audience is limited to about 1000 people. Currently users pay $600 to 800 per user per month to the competition (data by email only).
I am thinking I should increase the cost a little to account for the freeloaders.
Are you able to offer all the data your competition does? $300/month would be half off ^__^
Also, is there some way to include the user's name in the downloaded data? No doubt they could edit the data to remove their name before passing it on to their colleagues, but that might be more trouble than it's worth to them.
no doubt they could edit the data to remove their name before passing it on...
I could as they do - watermark on PDF, but my model is to make the data more accessible/usable and in doing so I am making it easier to freeload, hence why I am trying to make it cheap enough that users would just sign up and pay the monthly fee and get the benefits of some customization, rather than freeload.
Also the real money isn't in the data it's in other things, but I need the audience so I'm going to offer it really cheap, get the audience, get them famliar with the software then sell modules (the real pot of gold). I could jut get it out there for free, but I need to learn this pricing/billing stuff.
That all sounds good, my only thought is if you are charging $5 for something your market is used to paying $600 for, you may appear to lack credibility... imagine going up to a guy who gets $100 haircuts and offering him a haircut for $3. Would he take the risk of getting a $3 haircut, even if it looks like it would be just as good as his usual $100 one? But, of course, if they're getting other stuff than just the data for the $600, offering just the data for $5 plus expensive modules might be perfect ^_^
The vague eventual plan is to replace alref with some form of function-call like lookup, as with tables. I'm still not sure how, but in the meantime I wanted a function that at least had the same argument order.
It be very neat for alists to be usable like tables and strings, as "functions". That would almost be like a duck-typed "database" interface. Obviously some functionalities are specific to each (shadowing older pairs in an alist, having five bazillion keys in a hash table), but it would make sketching out an application much easier -- you could change only one or two spots in your code to switch between a table or alist, and the rest of your code would still work fine. Maybe this could be another use for 'annotate -- to differentiate between "a list" and "an alist"?
In the meantime, it should be easy to write a "polymorphic" lookup function:
(def lookup (db key) ; obviously just a sketchy
(if (atom db) (db key) ; definition -- but Arc is LFSP
(alref db key))) ; so there's no warranty :)
Both Adlai's and rntz's version do what I was trying to do.
However, I was looking for a way to assign a value to the variable referenced by the one I was passed. i.e.
(= v 'b)
(= (val v) 6) ; unknown function/macro val which returns contents of v so that '= can assign 6 to 'b.
This would allow the expression above to be:
(each v '(a b c) (= (val v) (readb))) ;assigns three bytes from standard in to 'a, 'b, and 'c respectively.
Whether this is done by overloading 'unquote to work like that outside of a quasiquote, or making something called 'val, I don't know. Maybe it could be done by making val or unquote a setform? That would solve this problem, but I think it might be more useful if it worked in more places than just assignment.
If b is a lexical variable, eval won't help, since it isn't run in the lexical scope in which it's called. An Arc lexical variable will get compiled to an MzScheme lexical variable, and I don't know of a way to refer to an MzScheme lexical variable by name determined at run time. If there isn't, I suspect your only hope might be to modify the Arc compiler to generate code like
(case v
((a) (set! a n))
((b) (set! b n))
((c) (set! c n))
((d) (set! d n))
...
for all the lexical variables available at that point.
This reproduces the behavior of yours (possibly too) exactly, including giving the user 9 guesses and saying "1 tries" if you get it right the first time. The return value is different though.
(def guess ((o tries 1) (o r (rand 100)))
(when (< tries 10)
(pr "your guess: ")
(let y (read)
(prn)
(if (is y r)
(do (prn "yay")
(pr "you got it in " tries " tries."))
(do (prn y " is too " (if (< y r) "low" "high"))
(guess (+ tries 1) r))))))
Ok, I've changed each to work this way. I couldn't find a single place where I depended on the old behavior, and this will let me get rid of ontable, which I've always been dubious about.
