This makes it hard to use lists as keys for tables:
arc> (let x (table)
(= (x '(a b)) t)
(x (list 'a 'b)))
nil
As list returns a Scheme list and the key is not ac-niltree'd before being passed to hash-table-get or hash-table-put!, the two lists are not Scheme hash table equal? and so represent different keys in the table.
Ok, this is now fixed. The Arc def of list now makes an explicit copy. Rtm has ambitions of one day making rest args ac-niltreed copies in ac.scm, whereupon we can return to the nice simple def of list.
Not a trick question, I wasn't quite getting what you wanted to do.
Ok, so you could have the defop repl store the current user in a global variable which you could then access from the prompt. Which would work fine as long as you only had one person logging in as an admin at a time.
If you have more than one person logging in as an admin at a time and you want to know who you are from the prompt, it sounds like the challenge is to get the dynamic value of the user name into the scope of the eval'ed expression?
Right, well, notice that the repl-history*, that, and thatexpr are also global variables, and so future proofing it for multiple admins will take more work than just the eval issue.
(For getting values into the eval, one way to do it is with an MzScheme feature called parameters; I have a library to let you use those from Arc which I haven't quite finished yet).
so you can see why pat has to be a literal string with this implementation.
As to whether unrolling the match in this way will actually be more efficient... we'd need to run some timing tests to find out ^_^
By the way, it looks like your implementation of match-end doesn't work in arc2, I guess it doesn't have the negative index feature to cut from the end of a string.
timing tests ... ok, endmatch totally wins. Especially for a mismatch in which case endmatch returns early, but match-end shows no gain. These tests were run on anarki arc:
average time im ms over 100000 runs of [_ ".jpg" "hello.jpg"]
endmatch 0.029
match-end 0.064
average time im ms over 100000 runs of [_ ".jpg" "hello.png"]
endmatch 0.016
match-end 0.062
So it seems performance is a likely explanation for the way endmatch is implemented.
(interestingly, for comparison, on rainbow the time for endmatch is roughly similar (0.028,0.019) but for match-end is disastrous (0.11,0.11). I'll need to figure out why.)
You're right about my match-end not working on arc2 - I mostly use anarki as it has a bunch of convenient changes including negative offsets for cut.
Though keep in mind that effort making a particular function run faster is only useful if a significant percentage of a program's execution time is spent in that function. For example, even if your match-end runs four times slower than endmatch in rainbow, if a program spends only 0.01% of its time matching the end of strings, then making match-end run faster won't help the program run any faster.
Certainly as an optimization arc2's implementation of endmatch would appear to be premature one, considering that endmatch isn't even used in the arc2 and HN source code, much less identified (as far as I know :) as a hot point slowing down the execution of someone's program. And while I do personally find it to be a fun piece of code (demonstrating how loop unrolling can be done using macros), your implementation is a clear winner in clarity and succinctness. :-)
I used ccc in an arc parser I wrote (it's at lib/parser.arc in anarki) ... I confess however that the choice of using ccc was driven more by the desire to experience this exotic construct than by the problem itself (as well as needing something to test rainbow's ccc with). The whole thing could be rewritten more simply.
That's a good example because in this case ccc in only used within the library. Thus an implementation option is to support ccc within a library while giving up something else while running inside the library (speed, or interoperability with Java classes, etc.) that makes to feasible or easy to support ccc inside the library. (After all worst case is that you write an Arc interpreter in which it is easy to support full ccc but it runs 20 times slower). Outside you don't support full continuations, but you have your regular Java Arc implementation (which runs really fast etc.)
ccc is also used by the 'point macro in arc.arc - but it's only used as an escape continuation, which is only jumping back up the stack, not copying it, so can be implemented very easily in java without introducing performance issues.
'point is also the only place I could find ccc used in the original arc distribution.
Apache will use the first matching ProxyPass, so the one for the folder needs to come first, since / will match any request. The ! tells Apache not to proxy that path. The retry=0 is a useful addition, if your Arc server is down it tells Apache not to wait to retry it; that way Apache will start proxying again immediately when your Arc server comes back up.
I'm using git and github as an experiment, wondering what the best way to share Arc patches might be. For myself, so far using git has felt like driving a tractor trailer to get a sandwich at the corner grocery store... big, powerful, can move an awesome amount of stuff, but clumsy... necessary when you have tens of thousands of lines of code, but when your language is high enough level that you don't need that many lines of code, is git actually useful? I don't know yet. In any case, I'm happy to get patches in any form that is convenient for the sender, whether by email, pastebin, or by github's "pull request" mechanism.
SOAP is a terribly bureaucratic protocol. The only time that you'd ever want to use SOAP is if you needed to use a web service and SOAP was the only protocol it supported.
What you want is Arc's read and write functions:
arc> (tostring (write '(a b 4 5)))
"(a b 4 5)"
arc> (fromstring "(a b 4 5)" (read))
(a b 4 5)
Thanks CatDancer.... The idea I am working is to see if I can publish a web-app from my server. And that other people can develop their own interface for it. That their interface can change data on my server using web protocols over http, so that anyone one can hook up their own interface to it and choose how much or little they need to manage.
So I believe I am saying I need to use a web service, and I am not sure what options I have for protocols.
The read and write is I can do, but how do I notify my web app that a message has been sent to it for processing ?
To handle an API message, you use a regular defop... what makes it a "web" API is that it uses the same HTTP protocol that a browser uses to fetch a web page or to post a form. In fact, you can often use a browser to try out a web API. For example, point your browser to http://friendfeed.com/api/feed/public, and you'll see a JSON message containing the most recent 30 public entries published to FriendFeed.
Here's an example of a very simple API written in Arc. For debugging, I have an op called "log" which will print a message in the window I'm running Arc in. So calling "http://myserver.com/log?message=hello" will print "hello" in my server window:
The (pr "OK") prints "OK" to stdout, which is returned to the client, so if you pointed your browser at http://myserver.com/log?message=hello you'd see "OK" displayed in your browser window.
To return JSON data like FriendFeed, you can either do it by hand:
Ok I found the mz patch you created, but it's a little confusing installing it.
I tried the "patch method" but obviously the command
"patch <mz.patch"
will not work in the arc top level. i am assuming you're running mzscheme directly to run this command (which i have never done).
I tried downloading your version of arc, but it doesn't work with or sync with "anarki". I get errors.
I find the whole library part of anarki extremely confusing.
As much as I am sure people are contributing valuable code, it's like it's a dumping ground with little documentation (some exceptions). People are throwing code in odd directories with odd names and no examples for usage.
wouldn't be nice to have an install like:
/arc/required/*.arc
/arc/recommended/patch/before/*.arc; for bug fix code that has to be loaded instead of the relative core arc or mzscheme code, as opposed to after.
/arc/recommended/patch/after/*.arc; for bug fix code that can be loaded after core arc loads, but before libraries.
/arc/recommended/libraries/*.arc;
/arc/optional/; no optional files or patch files for optional libraries to be in any 'recommended' directories.
/arc/optional/patch/*.arc
/arc/optional/patch/before/*.arc
/arc/optional/patch/after/*.arc
/arc/optional/libraries/*.arc
oh and while i'm frustrated.... an ide with a picklist for the optionals that figures out for us what dependancies are in place and manage them.
To date I have just been downloading the anarki directory, but tonight I'm going to try using the "git stable" method.
Question for you CatDancer, is your copy of Arc2 the equivalent of 'git stable' ?
I don't find I am using many of the optional features in anarki (so far I only use parsecomb and arcformat which are awesome) and if I do I was thinking I could drop them on top of your arc2 copy.
Were you able to get parsecomb to do anything? I was able to get it to make matches, but I couldn't figure out how to get it to tell me which match had been made. (For example, I could have it match a number or a string, but if it matched "123" I would get "123" returned to me but I couldn't figure out how to tell that it was a number that had been matched).
iirc, I ran parsecomb in pg's arc2 by removing the documentation strings from the beginning of the def's in the source.
thaddeus, I updated my documentation at http://catdancer.github.com/mz.html to give an explanation of the patch command and how to use it. Take a look and let me know if it's helpful. (Note github has come kind of caching bug with their pages so if you go back to the page your browser will display the old version of the page if it has a copy of it in its cache; you must click the refresh button or press F5 to see the new version).
I also crossed out the explanation of how to apply the patch using "git pull", since as you discovered "git pull" doesn't work if the two git repositories don't share a common ancestor. (I suspect there is a way to do this using git, but I'll have to go looking for it).
"patch" is actually a Unix command, it comes standard with Unix. So you'd type "patch <mz.patch" in your Unix shell, inside your arc directory.
If you're running Windows, if I remember correctly patch comes with cygwin... though I'm not sure.
If you look at mz.patch you can see that it is merely adding one line to ac.scm, so if all else fails, you can edit ac.scm and add the line yourself :-)
mz.patch is a patch against pg's original arc2... I have no idea if it will work with Anarki or not.
As a note for other n00bs who want to use the mz patch on anarki, it's probably best to just manually add the one line to the ac.scm file. Running the patch will fail with an error "patch already detected". I'm no unix expert but I looked at the anarki verion and there's already extra lines added where the patch expects to place it's code line(And the "add anyway" unix prompt failed for me).
At any rate I'm now playing with your json library CatDancer. Thanks for the help along the way.
T.
I have no idea why I used ((mz integer?) v) instead of (isa v 'int) in json.arc, it sounds like it would have saved you some trouble if you hadn't needed to install the mz patch first.
Oops, I think I misspoke when I described this Arc feature as "pattern matching"; iirc what "pattern matching" means is something that lets you compare a value against a list of patterns and select the first that matched. (Perhaps including setting pattern variables to the corresponding parts of the value, which would be like what this Arc feature does).
Hmm, "auto-destructuring" or even "destructuring" as what to call it, even if is standard usage, is quite the mouthful though...
