What is the issue with [] in rainbow? ... Do you have an example?
I think you'll find it's a very simple example. :-p
arc> []
rainbow.parser.ParseException: Encountered "]" at line 1, column 2.
As for 'macex1, there's definitely one inconsistency, which is that it doesn't work unless car.expr works. I also briefly worried about ssyntax, but I'm not sure it's a problem; official Arc lets (assign a.b nil) cause (bound 'a.b) to be true, but I don't blame Rainbow for not emulating that.
Thank you. The bit that compiles argument lists wasn't recursing down destructuring arguments to check for optional arguments there. Fix pushed to github this morning :)
Just in case gc is an issue - you might make use of (memory) to log memory usage and better determine if that's part of the problem. Is the system fork error raised inside the arc process or in an external process? I don't understand in (2) how slowing down the routine results in increased traffic - I'm missing some of the picture there.
> System fork error raised inside the arc process?
hmmmm good question I am pretty sure it dropped out of arc and then provided a system error.
> I don't understand in (2) how slowing down the routine results in increased traffic.
It's not that I think it will increase traffic, just that if I have to slow the requests down to somehow release connections or memory, then it's not really a solution since I would like to be capable of handling future increased traffic(to much larger degrees than my 2000 connections for stocks :).
I think it's just my poor understanding of how threading/memory allocation/networking & gc work. Somehow I have it in my head that the process is not gc'ing memory or releasing connections from previous iterations before it moves on to the next, or not releasing the underlying OS thread for the get request before moving on to the next. That's probably all wrong, correct?
The process is pretty simple: download a file, load data from file to memory (assign to variable), parse the data and do the math, write the results to file, write the progress to file, wipe the variable. Rinse, Wash, & Repeat :)
I am just moving over to my new Ubuntu 10.4 Linode with Nginx. Setup is complete, data is copying over. Then I plan to run some benchmarks with out changing any code. Do a before and after to see the difference.
From there I'll start looking at that old http-get library to see if it's somehow not releasing memory (yikes!)
There are a bunch of benchmark tests with rainbow under src/arc/lib/bm-tests.arc - I wanted to cover different aspects of the system's performance (error handling and continuations for starters; I'd like to add tests specifically for conditionals, quasiquotes, different kinds of invocations (with/without optionals, destructuring etc)). Rainbow performs better in some cases, and arc3.1 beats rainbow in other cases. I'll have to grab the latest jarc and run a 3-way comparison - more news later!
Wow, this is totally awesome, thanks! The arc forum front page is the ideal place for these bugs :))
test1: a special-case optimisation for the particular case of a 2-arg function where the second was optional with a default value being a lexically-bound symbol failed to evaluate the default value, and instead just inserted the symbol name itself into the function's arguments. Fixed
test3: allowing 'nil as a parameter name broke rainbow; allowed in arc3.1. For example, (def nilarg (nil) nil). Fixed.
test4: rainbow refused to deal with (coerce '(12 34 56) 'string), arc3.1 returns "123456". Rainbow would only coerce list of chars to string, thus breaking (string '(4)). Fixed.
Multiline comments ... I didn't support them initially as they're not used anywhere in Official Arc, and hadn't noticed them in use anywhere else. I'll get to this after a bit of sleep ...
worth breaking the silence.
I appreciate it. I hope this rainbow works better for you!
Whoops, I simplified test 4 a bit too much before I posted it.
(pr "Test 6 ")
(= test6 (let args (list t nil 'nil () '() "" '(#\e "s")
'(nil "" () (t 6)))
(list (apply string args)
(apply apply + "" args)
(apply + "" args))))
(prn:if (iso test6 '("test6" "test6" "test6"))
"succeeded."
(iso test6 '("te\"s\"nil\"\"()(t 6)"
"te\"s\"t6"
"te\"s\"nil\"\"()(t 6)"))
"failed with the result expected on Rainbow."
(iso test6 (list "tnilnilnilnilesnilnil(t 6)"
(+ "t(#" #\\ "e \"s\")(t 6)")
(+ "t(#" #\\ "e \"s\")(nil \"\" nil (t 6))")))
"failed with the result expected on Jarc."
"failed with an unexpected result.")
It's probably more convoluted than it has to be, but I'm leaving it that way this time. ^_^
Note that the string literal "...\e..." crashes Rainbow and the string literal "...\\e..." (which is what I really want) behaves incorrectly on Jarc.
Also, if I paste the above code into the Rainbow REPL directly, Rainbow almost always errors out and exits. The paste works if I remove the Jarc case or the Rainbow case, and I've also found it to work if there's been quite a bit of other input during the session. There's a similar issue on Jarc (which prints a stack trace about not having enough memory to read from the input), and, well, it could have something to do with my system.
the string literal "...\\e..." (which is what I really want) behaves incorrectly on Jarc.
Yeah, I intentionally don't handle escaped strings in Jarc the same as Arc. One frustration in Java is using regular expressions. You have to say
\\s*(\\d+)\\s*
when you mean
\s*(\d+)\s*
and regex's are hard enough to read without making them more complex. So in Jarc, I decided that only \n \r \t and \\ would have a special meaning. Every other \ is treated as a literal backslash. So Jarc treats \e as the two characters \ and e. Yeah. Non-standard, non-intuitive. No argument there. But it made regex's so much nicer to read that I decided it was a worthwhile trade-off.
This has made me realize why Perl has a separate syntax for regex.
Jarc should probably have a declare to turn this behavior on and off. At least that would provide compatibility with Arc. Jarc doesn't have \x or \u syntax either, which it should.
Note that if you were to "fix" this, it would mean certain regexes would use "\\\\", and that sounds like it could be what you want the least. As for me, I don't mind whatever you choose as long as it's intentional. :-p
Yeah, \\ means \\. It's \n \r \t and \" that are
treated specially.
Though I realized Jarc needs a way
to enter non-printable characters, so I've added
\f
\a
\e
\0*oo*
\x*hh*
\u*hhhh*
None of those interfere with regular expressions. Though I still don't have an
intuitive way to put \e in a string. You can do \x5ce now (in Jarc 16)
but that's ugly. I guess \\ needs to be just \ when it's followed
by n r t f a e " 0 x or h. That's getting a bit complex, but I guess it's intuitive. Or maybe I should just add a regular expression literal with / delimiters like Perl has.
Fixed, finally. Rainbow had an optimisation that prevented copying the whole stack if it was not necessary upon entering a continuation. Alas, for the sake of the tests, that particular optimisation is gone. If I can figure out how to get it back, I will. This is the somewhat violent test case I developed for continuations in combination with 'protect, based on a previous test for co-routines:
I have no idea whether it is correct; all I can say is that arc3.1 gives the same result. Mere compatibility isn't such a high standard, at least in this case :)
'after works to cleanup after errors; but it's not implemented for jumping into continuations. This one is hurting, I haven't found a quick solution. Continuations are mean enough alone; in combination with 'protect I'm lost. More news later ... and thanks for the bug report!
then I ran Ant again - oh, the joy of compiled languages :)
ac.scm is the scheme code that compiles arc into scheme. This would be an appropriate place to plug in a debugger, by adding hooks in, for example, ar-funcall0 and ar-apply. Otherwise, there are debuggers for scheme, but using one of those wouldn't be as much fun as writing one ...
you might find inspiration in the debuggers that come with rainbow or jarc.
