I mean scanning Arc files or, better, the help* table and gather information in text files formatted in a wiki-friendly format in order to easily put them on the Anarki wiki.
Edit: have a look at the file lib/help-to-wiki in Anarki (just pushed it).
In anarki there is the function connect-socket, I think it is just what you want (have a look at the end of the ac.scm file, just before thread local vars).
Could be. Right now I'm still using the regular arc2, and am now trying to figure out how to deal with the input of the mud, if I've to make separate threads for reading and writing input, or that I can make use of peekc in some way to figure out when the mud has stopped sending characters to the input port. It is fun though :)
Hmm. still a bit puzzled. I seem able to read (in various ways readc, readline) no problem, but writing to cadr inout doesn't seem to trigger new input from the mud to read.
All of you, thanks for the help so far. I'll tinker on with it later, time for my primary arc project ;).
For the output problem, try flushing the out stream with flush-socket on Anarki or the corresponding flush-output from mzscheme, maybe the output is written to a buffer and there is not enough information to send to force the buffer to be flushed.
peekc hangs when I'm reading the output from telnet, but works fine (returning nil) when I'm reading out the output after the last char from a stored pipe.
In my experience peekc doesn't seem to work properly (i.e. as advertised) at all.
I assume you're doing peekc so that you can do something else while waiting for a character? If that is what you're trying to do, I suggest you use threads:
(first time I work with threads) readmud only reads one character at a time, and I want it to just keep on writing as long as there is data. I'll try to add a thread that calls readmud again the moment it returns something sensible.
Partial success. The reading bit seems to function fine (if slow ;), and I now can use arc while in the background the muds' output is being read, but still cannot write. Did add mzscheme's flush-out (but perhaps in some wrong way. Will look at it during the next work-break ;).
Maybe the problem with peekc is that it tries to read a character from the socket, but the server has yet to write that character, and peekc doesn't return nil because the server hasn't yet closed its output stream, so there is no end-of-file.
1. I've thought about this too and then looked how it worked in SBCL, and I've seen that it doesn't show tail optimized functions in the stack backtrace. I've developed a few programs with SBCL and this has never been a problem.
While scanning the stack you have to pay attention to not include functional arguments as if they were called functions. To give descriptive names to functions I would transform every lambda expression in a named function, e.g. :
(def f (x) x) --> (set f (fn (x) x)) --> (set f (__named '(f x) (x) x))
and for anonymous functions:
(fn (a b) (+ a b)) --> (__named '(fn (a b)) (a b) (+ a b))
> While scanning the stack you have to pay attention to not include functional arguments as if they were called functions.
Which is why I was proposing to subtype closures into continuations and non-continuations. Normal functions that are passed around are non-continuations, while continuation closures are created during CPS-conversion. Of course we probably need to add code in 'ccc which would probably copy a continuation closure into a non-continuation version of the closure.
I think that some kind of signature (provided by a trusted source) should suffice. Sandboxing is propbably the most secure thing to do, but it has a few drawbacks:
1) It could potentially limit the functionalities if the loaded code (e.g. access to the filesystem)
2) Efficency, because almost every operation (such as memory accesses) should be checked to be sure the application doesn't try to get out of its sandbox.
3) Implementation: it doesn't seem to be very easy to implement :)
From the implementation point of view representing characters as symbols is a real performance issue, because you would have to allocate every character on the heap, and a single character would then take more than 32 bytes of memory.
I think that's an implementation detail. You could still somewhat keep the character type in the implementation, but write them "x" (or 'x) instead of #\x and making (type c) return 'string (or 'sym).
Or, if you take the problem the other way, you could say "length-1 symbols are quite frequent and shoudn't take too much memory -- let's represent them a special way where they would only take 4 bytes".
This would require some kind of automatic type conversions (probably at runtime), but characters-as-symbols seems doable without the overhead I thought it would lead to.
In floating point arithmetic 0.0 isn't zero: it represent a range of numbers around zero, so it makes a little sense for 0/0.0 to return 0.0. I still think that raising an exception would be preferable.
I see two main reasons for this. The first is obviously pg apparent disinterest in his own creature (in the sense that he seems to don't follow the forum anymore), because this makes people think "If its creator doesn't care about it, why should I?". Maybe pg is a bit too busy in this days, but I think Arc is still too young to survive if he doesn't come back soon, beacuse there are a lot of other interesting lisp projects out there that don't give the same sense of 'pause' that Arc gives (clojure is one of them). The second reason is the immature implementation that makes it difficult to write projects of moderate size in Arc, as an example think about Arc's error messages: they usually say something like 'You've got an error' and you simply don't get any hint about where it is. This is especially true about reader errors: I've read messages saying 'error at line 5234' in a file with just a few hundreds lines!
The good news is that these problems are, IMHO, fixable. Think about arc2c and how it is trying to fix the second problem to see the direction where the Arc community should go, but these solutions require time, and new users usually don't want to wait when there are other solutions already usable out there.
"The first is obviously pg apparent disinterest in his own creature..."
I think you hit the nail on the head there. I know pg has said that he does read the posts even when he doesn't reply, but let's face it, it doesn't take too long to post a comment occasionally. If he even took the time to communicate a vision to the "community", that would be helpful. I think people would be more patient if they had a clue about where this was heading.
Although it's certainly fun to pick up a new language, it also takes time and effort, and I'd like to see more evidence that Arc will continue to progress before I invest much time into it (especially since it lacks a couple "must haves" for me currently).
So, regarding the other comment about needing more publicity in terms of someone's pet project - I think there's a catch-22 there - who's going to put together a substantial application if they're unsure if the language will survive?
"who's going to put together a substantial application if they're unsure if the language will survive?"
This is true if you're writing your application for commercial use, but if you're doing it just for fun you can even use a language written by yourself that no one else know. The biggest problem is the lack of development and debugging tools. I few weeks ago I started a project to learn a bit more about compilers, and I ended up using Common Lisp because the task was very difficult by itself and I needed a good way to debug the program. Using Arc would have meant to make a difficult project even more difficult.
I think you just proved my point. I presume your project to "learn a bit more about compilers" was not commercial in nature, and yet you chose Common Lisp. Whether a project is for fun or for profit, I'd prefer to not waste my time, and it appears you feel the same.
I think the survivability (not popularity) of a programming language is closely correlated with its usefulness to programmers.
Of course, the best way to rebut my implicit assertion is to actually "put together a substantial application" with Arc instead of talking about it, right?
However, seriously, clojure looks really interesting, being a cool language on the JVM and being purely functional. But does anybody know if it is possible in this language to make (easily) funny structures like circular lists, graphs, etc. ? AFAIK, that's the problem when you don't want to use set-car & set-cdr in Scheme (that's a problem in NewLisp too, for example) : you loose them. Did clojure manage to overcome this problem ?
