Specifically, arc.sh sets the environment variable "arc_dir" to the installation directory.
I would suggest making a batch file which sets the environment variable arc_dir properly before launching mzscheme -af as.scm ^^
Should probably be done correctly by providing an arc.bat I suppose, although the problem is always figuring out the installation directory... haven't hacked MSDOS batch files in a long time ^^
C:\User\Programming\Arc\arc3f\arc-f>set arc_dir=C:\User\Programming\Arc\arc3f\arc-f
C:\User\Programming\Arc\arc3f\arc-f>mzscheme -mf as.scm
Compiling arc.arc...
Use (quit) to quit, (tl) to return here after an interrupt.
<User>tl:
Unfortunately, (having learned Unix shell scripting), I never bothered to learn Windows batch files.
Also of note, arc.sh doesn't work in Cygwin:
$ sh arc.sh
> default-load-handler: cannot open input file: "c:/cygdrive/c/User/Programming/Arc/arc3f/arc-f/as.scm" (The system cannot find the path specified.; errno=3)
I pushed an untested arc.bat launcher on the anarki arc-f recently, although now that I've reviewed it it seems I used the wrong flag in the mzscheme invocation (-af instead of -mf). Could I ask you to check it out, and if so, could you check it out?
As for the cygwin stuff.... hmm. Maybe I should fix my broken WinXP machine...
@echo off
set arc_dir=C:\Program Files\ARCF
mzscheme -mf "%arc_dir%\as.scm"
This one worked for me. I'm not sure if removing the [][]'s from the file and making it windows line breaks mattered, but at least I had to move some ""'s around to get it to work.
Now just trying to get the launch-an-arc-script script working (from outside the repl). The script that is elsewhere on the website works on linux, but not windows ;). Damn pipes.
Out of curiousity: does it work even if you're on a different hard drive/directory as the installation drive/directory? The intent of that batch file is to allow you to launch Arc from anywhere, while still (1) able to access the current directory and (2) able to load library files from the arc installation directory
E:\> copy con tmp.arc
(prn "hello world!")
^Z <---- that's a control-Z
E:\> "C:\User\Programming\Arc\arc3f\arc-f\arc.bat"
Use (quit) to quit, (tl) to return here after an interrupt.
<User>tl: (using <files>v1)
t
<User>tl: (ls)
("tmp.arc") <--- you should get a list of files and stuff in the current directory, including tmp.arc
<User>tl: (load "tmp.arc")
hello world!
nil
<User>tl:
1. It is implemented as its own reader, but it uses arc/mzscheme-read for symbols and quotation syntax (the version at http://placebo.hpi.uni-potsdam.de/~robert.pfeiffer/arc/mexpr... also handles quasiquotation-syntax on its own, but is less well tested)
You can load a file in m-expression format with "(load-m filename)" (or "load-m[filename];").
2.Yes I have. The M-Expr reader converts into prefix form at read time, so the read forms look like arc code. M-Expressions are just a skin for S-Expressions, therefor I tried not to break anything by changing the run-time semantics of Arc (unlike infix.arc, which makes numbers callable, which my break drcodes currying (or my idea for automatically converting numbers in functional position into Church Numerals)).
Interesting idea, but I'm having a hard time visualizing how it would work. How do you patch source code after it is compiled and being used in a running image? I am aware of the existing (let old foo (def foo (...) (bar (old ...)))) pattern, but you seem to be implying something more that this... Or am I completely off on that aspect of it?
If the master branch still doesn't work for you, you could also try the stable branch, which should only contain bug fixes (http://github.com/nex3/arc/zipball/stable).
Specifically, MzScheme 4+ uses immutable lists, which don't work well with Arc. You might be able to try http://arclanguage.org/item?id=3954, but I personally have no experience in doing so.
Another thing (which I feel I really ought to already know the answer for...), how do you format floating point numbers (say, to three decimal places)? I could do this trivially with #'format in CL, but I don't see anything in the Arc docs to help me, and I don't know enough about Scheme to hack around it with ($ ...).
Thanks for the reminder, I had forgotten about that.
I'm still not sure that's a complete solution though... you don't really prevent access to the port, you just send an access denied message instead of serving the request. (But I don't know that much about web security, so maybe that really is sufficient.)
Not sure either. It depends on whether the Arc Server is secure/{not dumb} enough such that it won't be fooled by someone pretending to be from 127.0.0.1 , for example.
Couldn't you just make Apache or Linux firewall port 8080 so all attempts to access it from outside are blocked? (That said, I wouldn't know how to do that off the top of my head.)
I recently found a partial attempt to fix arc's gensyms on Anarki. I say partial because although 'uniq now returns uninterned symbols, 'ac-global-name still automatically interns them (in order to add "__" to the front) when they are evaluated. Thus name capture is still possible:
I believe the appropriate fix is to keep 'ac-global-name from automatically interning gensyms. I posted one possible (though ugly) solution at http://arclanguage.org/item?id=5104, but didn't commit the change because people didn't seem terribly enthusiastic at the time. Considering that someone else seems to be concerned with Arc's gensyms, I may commit a fix if I have time.
