/dev/urandom is a special file in Unix-like operating systems that spits out random bits (see http://en.wikipedia.org/wiki//dev/random). Arc isn't so great at the cross-platform thing, since it hard-codes Unix-like paths & shell commands. In this case, srv.arc breaks when trying to generate a random string because it calls rand-string from arc.arc, which tries to open /dev/urandom to get random data. The file doesn't exist in Windows (and just creating one won't do the job, since Windows doesn't say "hey, I know, I'll generate random bits when people read from this file"), hence the error.
Well, strictly I was speaking of the solutions in the thread that I linked to, but that blog post is about the issue they discussed.
It seems to work fine if you take off the 'before make directory
Yeah, those forum/blog posts were from quite awhile ago, when xdef expected its first argument to be quoted (see http://ycombinator.com/arc/tut.txt -- or any of the myriad other Lisp tutorials out there -- for an introduction to quoting).
but what exactly do I do with dev/urandom in both ac.scr and arc.arc?
I linked to that thread because it was relevant, though it didn't fix this specific bug: it's still true that pg expects Windows snafus to be fixed downstream. As rocketnia mentioned (http://arclanguage.org/item?id=12397), most seem to be solved by using Cygwin, which will give you /dev/urandom & such.
The outstanding issues I'm aware of are generally fixable outside of Cygwin, but would require a bit of code drudgery.
- The setuid bug, apparently fixed (by doing nothing when it's called, so I'm suspicious, but I don't know): http://arclanguage.org/item?id=10625.
- shash in arc.arc just uses openssl, which has a Windows binary that should work. It worked a few years ago, anyway: http://arclanguage.org/item?id=190. shash also creates a file in /tmp/, but that shouldn't be an issue, if I recall correctly from the few times I've run Arc on Windows.
- ensure-dir in arc.arc has been patched in that thread I linked to -- again, just using Racket's functions.
- rand-string uses /dev/urandom, which takes a little more doing to fix, as evidenced by the lack of changes on Anarki (the community-maintained repository for changes to Arc: http://github.com/nex3/arc). You might could rewrite it to use Racket's random number generators, but I don't really know.
String concatenation is particularly convenient after the + change for arc3.tar: http://arclanguage.org/item?id=9937. That's probably what I use + for most of the time.
I find thinking about whether or not I have to escape the "@" character is distracting
I find this is easier with proper syntax highlighting. My arc.vim ftplugin can detect if you have (declare 'atstrings t) and, if so, highlights the escaped parts of strings. That way, you know if @ is escaped just by glancing. But I don't mean to shamelessly plug, haha. I don't use atstrings either, but my reason is far lazier: in the middle of writing code, it's less effort to just use + than it is to declare then go back and start using @s.
What other goodies does your arc.vim plugin have? Is your editor at all integrated with the arc repl? Lack of a repl that I could easily send arc code to was the reason I switched to emacs after years of using vim. These days, using emacs with viper (vim emulation mode), I don't miss vim at all.
It deals with lists and strings well, which is decent: Arc's only other sequence-like type is the table (I don't think you'd ever want to treat symbols as a sequence of 1-character symbols; you'd just use a string). Tables would work better if they were properly coerced, cf. the comment above tablist and listtab in arc.arc.
The more I think about it, the more I like this model. Conceptually, it seems that map should behave like
(def map (f seq)
(map-as (type seq) f seq))
even if it's not implemented like that -- all the coercions would surely be slow. (Tangential: map would also need to handle multiple sequences.) But it makes more sense for map and coerce to at least have compatible behavior. Plus, map's current behavior is a degenerate case of the coerce-compatible map:
I've spent some time thinking about how to extend it for multiple-dispatch, and I didn't want to also think about setting the arg index to dispatch on.
When you map across a string, it coerces the whole result into a new string character-by-character. It's like if you (hypothetically) weren't allowed to have nested lists but tried to do
(map [list 1 2 3 _] '(8 6 7 5 3 0 9))
Each string element is a character, not a whole string. Thus
arc> (= s (newstring 3))
"\u0000\u0000\u0000" ; these are null characters, by the way
arc> (= (s 0) #\a)
#\a
arc> s
"a\u0000\u0000"
arc> (= (s 1) #\b)
#\b
arc> s
"ab\u0000"
arc> (= (s 2) "foo")
Error: "string-set!: expects type <character> as 3rd argument, given: \"foo\"; other arguments were: \"ab\\u0000\" 2"
Never fear! I'll show up to flog this horse in the nick of time! Y'know, before rigor mortis sets in.
Here's another I/O utility I think would be useful.
(def readlines (n (o str (stdin)))
(let line nil
(repeat n (= line (readline str)))
line))
It undoubtedly sets a variable (just not a global), though I think the "challenger" phrased the requirement as such because of a C-centric view: allocate a chunk of memory for the string, then read the string into there (which, technically, even a simple (readline) does). Anyway... With all of these, the Arc code would look something like
And I don't think I could squeeze more out of that without getting overly specific. Of course, readlines is a conventional name for something that just reads all the lines of a stream, but I think we could reasonably use names closer to Arc's allchars and filechars.
Hm. Anarki calls them w/stdoutfile and w/stdinfile, but wouldn't tofile and fromfile be more consistent with tostring and fromstring (and shorter, besides)? Then there's the whole appending business. Can't really give an optional parameter to tofile like outfile has, and toappendfile runs together horribly. What about just appendfile?
Then, using readline instead of readfile so that it (1) doesn't try to parse things as s-exprs and (2) doesn't read the entire file for no good reason, I'd envision it thus:
I'm not sure about the appendfile--given what infile and outfile do, it sounds like a procedure that creates an output-port that appends to a file. Maybe to-appendfile, appendtofile, appendingfile, tofile/append... Alternatively, we could make keyword arguments happen in Arc, and then you would just throw ":append t" or something inside the call to tofile. That would also allow for further extension with, e.g., an :if-exists argument.
How about 'tolog? Are files opened for appending for other reasons, in practice? This would also keep with the to-means-output, from-means-input pattern.
I'd try to err on the side of generality. And I'm not quite as concerned about to:output / from:input, if the names are still "clear enough".
As to waterhouse's suggestions, I had considered those names. I suppose if you read appendfile as a noun instead of a verb-and-noun, it's confusing (though infile and outfile don't really have the same problem, so it's not the train of thought my brain follows). It's hard modifying a name like tofile with a long word like append. We already have two words in tofile, so adding a third without hyphenation is stretching it, and adding hyphens breaks the flow with the other names (fromfile, tostring, etc.). We could go for something shorter, like addtofile, which delineates itself well without hyphens because each word is one syllable. If we can't avoid hyphens, using / instead (e.g., tofile/a or tofile/append) flows better, but isn't that great.
Another name that occurred to me -- and is probably my favorite so far -- is ontofile, which is still simple enough to not need hyphens, communicates intent (appending something onto a file), and worms the word to in there, painting it with the to:output / from:input correlation. Thoughts?
Another name that occurred to me -- and is probably my favorite so far -- is ontofile, which is still simple enough to not need hyphens, communicates intent (appending something onto a file), and worms the word to in there, painting it with the to:output / from:input correlation. Thoughts?
+1! ontofile is a great name, in my opinion, for all the reasons you listed.
I searched for a good portmanteau in the vein of mappend, but I don't think there is one. fappend? Sounds like frappuchino. filepend is decent, but I think I prefer ontofile.
