Fo' shizzle. The timing of this item is great, because I've been struggling with performance in my arc-based webapp. I have one thread bringing new items into the index, and it's constantly thrashing with UI threads causing unacceptable latencies.
I don't use atomic myself. But I find that enabling the back-end thread slows down the UI threads. I've been struggling to create a simple program to illustrate this.
In fact, wrapping parts of my UI threads in atomic actually makes them more responsive[1]. I think it's because instead of getting 200 thread switches with their associated overheads, a single thread runs to 'completion'.
[1] You're right that throughput may go down, though I try to eliminate IO in atomic blocks. But latency is more of a concern to me than not wasting CPU. It's not the end of the world if new data takes a few seconds longer to make it to the index, but a few seconds in the front-end can make or break the user experience.
"vector-set-performance-stats!" in http://docs.plt-scheme.org/reference/runtime.html returns the number of thread context switches that have been performed, so you might try calling that at the beginning and at the end of an UI operation so you can see how many thread switches happened in between.
"let ,gs ,s" frequently prevents double-evaluation of 's at run-time. It seems dumb at first when the expansion of 's is just another symbol or literal, but if 's is a more complex expression, better evaluate it just once.
(mac wrong-on (var s . body)
(if (is var 'index)
(err "Can't use index as first arg to on.")
`(forlen index ,s
(let ,var (,s index)
,@body))))
Then
arc> (wrong-on x (prn "abcd") (prs index x) (prn))
abcd
abcd
0 a
abcd
1 b
abcd
2 c
abcd
3 d
nil
because
(macex1 '(wrong-on x (prn "abcd") (prs index x) (prn)))
is
(forlen index (prn "abcd")
(let x ((prn "abcd") index)
(prs index x) (prn)))
Notice that (prn "abcd") is evaluated once at the start, then once on each iteration.
Versus the arc.arc on:
arc> (on x (prn "abcd") (prs index x) (prn))
abcd
0 a
1 b
2 c
3 d
nil
because
(macex1 '(on x (prn "abcd") (prs index x) (prn)))
is
(let gs1763 (prn "abcd")
(forlen index gs1763
(let x (gs1763 index)
(prs index x) (prn))))
Here, (prn "abcd") is evaluated only once. It's bound to the gensym gs1763, which won't clash with any variable names you already have (not strictly, cf. http://arclanguage.org/item?id=5104, but that's the idea).
My definition of on seems to eval the list only once anyway, but now I'm feeling paranoid about where else I've missed this and taken a performance hit.
That's from back before the transition to arc3, so it'll now be on the arc2.master branch rather than anarki master. (Obviously, if anyone would care to translate it and push it, that would be great.)
Zounds! Since I generally read every post in the forum, I can only assume that I read your post, forgot about it, and then when I needed to transform some arguments my subconscious presented the idea to me as its own invention :_)
As far as I know it's the only seriously arc-aware editor in the world - with full syntax highlighting, paren matching, jump-to-definition, delete-surrounding-form, surround-form, expand-macro among others. And it's largely written in arc, so you can use all your arc skillz to customise it.
The catch: it depends on rainbow - http://github.com/conanite/rainbow - and hence on java (the core editor UI is a standard java component) so your enjoyment will depend on having a jdk installed.
very nice. any reason for (alref (req 'args) "code") instead of (arg req "code") ? (even if token count is a silly metric :))
One thing really confusing me: it looks like it writes the string value of the "code" parameter to the serial port, is that how it's supposed to work? (I notice it's the same in python)
I didn't think of using arg; that's obviously better.
Yes, the code parameter is written to the serial port, where it is received by the Arduino microcontroller board. This board does the work of generating the IR signal corresponding to the code. The details are at http://arcfn.com/2009/11/controlling-your-stereo-over-web-wi...
Waiters in Paris generally assume I'm an English-speaking tourist (a reasonable bet), and hand me the translated English menu. They mean well, but "Preserved Duck with Potatoes Fried in Duck Grease" doesn't sound anything like the delicious meal it usually is. I fear a translated programming language might have the same icky feel. And it would be a lot harder to share code if keywords were translated. But the tutorial ... yay.
I'm sure that Arc will always be better in the original. But to deny someone the pleasure of programming in Arc merely because they don't speak English seems... cruel :-)
This works for me, from a terminal, in my arc3.1 directory:
$ mzscheme -if as.scm
Welcome to MzScheme v4.2.1 [3m], Copyright (c) 2004-2009 PLT Scheme Inc.
Use (quit) to quit, (tl) to return here after an interrupt.
arc>
What commandline are you using that's giving you the error?
