Very instructive. Thank you for doing such a thorough analysis.
',r from your snippet
(mac rdefop (r)
`(defop ,r req (rpage ',r)))
was a realization for me. Never thought of quoting a comma'd symbol in a backquoted expression before, but I like knowing it's possible. Do you find yourself doing this much, or is there usually something simpler like aw's solution available to make it unnecessary?
Thus, instead of doing (defop r), it's kind of like we're doing (defop (eval r)). That is, instead of expanding into
(defop r req (rpage 'r))
we're expanding into
(defop 10a req (rpage '10a)) ; when r == '10a
(defop 10b req (rpage '10b)) ; when r == '10b
; etc
We could've done the eval inside the macro, too, but that's often a sign you're doing something wrong --- macros are usually there to not evaluate their arguments. So we should probably use a function.
However, defop itself is a macro, so the first parameter (the op's name) won't be evaluated regardless. We still need eval.
Since this approach seems to require eval regardless, we should just look for a better solution. aw's works nicely.
Some other nitpicks over your rewrite (hey, you asked!):
1) Unless you need strings for some reason, you can probably default to symbols (they're a bit easier to use).
; Instead of
(= routes* '("10a" "10b" "15a" "20a" "20b" "30a" "30b" "30c" "40a" "59u"))
; we could use
(= routes* '(10a 10b 15a 20a 20b 30a 30b 30c 40a 59u))
2) Proper spacing & indentation saves lives. :)
; Instead of
(defop shuttle req
(each r routes* (link r)(nbsp)))
; why not
(defop shuttle req
(each r routes* (link r) (nbsp)))
; or even
(defop shuttle req
(each r routes*
(link r)
(nbsp)))
3) Though using symbols renders this point moot, fromstring is unnecessary to simply (read) from a string, since Arc's definition of read is
(def read ((o x (stdin)) (o eof nil))
(if (isa x 'string) (readstring1 x eof) (sread x eof)))
So, instead of
(fromstring rs (read))
you can use
(read rs)
If your goal is just to turn a string into a symbol, you should use
(sym rs)
This is an important distinction. e.g.,
arc> (sym "abc")
abc
arc> (read "abc")
abc
arc> (sym "(a b c)")
|(a b c)|
arc> (type that)
sym
arc> (read "(a b c)")
(a b c)
arc> (type that)
cons
Curious if any of the more advanced folks on this board can show how to properly do the above code (such that I can learn from). Or is the above code not so bad after all? Thanks.
Wow, Haskell. The chapters on "self-similar music" and "an algebra of music" look particularly interesting, I'm going to enjoy them. Thanks for the link.
my programmer senses tingle and I find myself wanting to abstract things away - you hit the nail on the head there. What's more, I'm sure there's meaning in those patterns if we could only make them explicit - listening to music is sometimes listening to a conversation in a mostly-foreign language - words here and there that you recognize, you suspect that something meaningful is being communicated, but it's just beyond your grasp.
don't let the text-only nature of Arc discourage you - no chance, I'm too far gone for that.
For your second question, we could work on getting your macro defining macro to work, if you wanted. For this particular task, personally I'd do something simpler: I'd make the link like this:
"If you aren't using the C foreign function interface, of course."
Yeah that phase actually performs stemming as well using the FFI. For a long time that was my prime suspect, but I have never been able to get stemming to segfault in isolation, either within arc or from a C program. And I have been able to get my program to segfault without the stemming.
You're right, I'll take another stab at a test case. And I'll not try so hard to make it tiny.
If you do the exact same data import with the program in the same initial state, will it segfault again? (You may need to add code to record e.g. the contents of your data files prior to the import and what exactly is being imported).
Or, if you start in a known state and run fifty data imports in a row, can you get it to segfault?
Arc is not supposed to be able to segfault MzScheme. To MzScheme, Arc is just a big program written in Scheme. And MzScheme running Scheme programs is not supposed to segfault.
(If you aren't using the C foreign function interface, of course. A messed up pointer can cause unrelated code to blow up later. So the above paragraph is true if you are only using libraries which are either written in Scheme [and/or Arc, since Arc is written in Scheme] or part of the official MzScheme distribution).
It's true that the PLT folks certainly don't want to be debugging your Arc program, but they do want to be able to get MzScheme to work. And the way to enable them to do that is to give them a test case that they can run to see the segfault. If you can. Even if it is thousands of lines of code and megabytes of data. If you give them a shell script "diedie" that runs a MzScheme program (that runs Arc and loads your program and imports your data) that segfaults, then you make it possible for them to find out what is causing the segfault.
You know, those steps were approximately what I've been trying to follow :) I thought I had boiled it down to a test case, but now I'm betrayed by it. Betrayed! :)
I don't really have a problem posting the code, but it'll be a huge ball of mud since it includes arc as well. I'm not sure the PLT folks will want to mess with that to find a bug that only occurs sometimes and may well be arc's fault.
It doesn't seem as easy as replaying a request. I encounter the error during a periodic data import phase in my server. It's not being triggered by a specific request. And it doesn't happen everytime the program goes into that phase. Sometimes I see the segfault 6 times a day (the phase runs once an hour), and sometimes everything's peachy for 3 days.
Shelling out to perl is a good idea. I think I'll try using your hack for that.
If you want to pursue this, here are some steps...
If your server dies when running live, you can get it to die yourself by feeding it the same input as it gets from your browser and/or your users.
Now you have a large and complex program that you can get to segfault by feeding it some large and complex set of data.
Then you can run the same program with the same data in the same version of MzScheme on your personal computer, and see if it segfaults there as well. (If not, perhaps it is an OS library problem).
If it also segfaults on your computer, that's good news, you're on your way to track it down.
You can ask on the PLT mailing list what debugging information they'd like to see to track down a segfault.
And, if you feel like it, you can try removing chunks of your program to find a smaller test case that triggers the segfault.
If you can get it to segfault with chunks of code that are non-proprietary to you, that you don't mind publishing, then you can even post a link to a zip or a tar containing the code and the input data and instructions on how to trigger the segfault. Then it would be possible for one of the PLT people to find their bug, even if you have to apologize that your test case is so giant because you couldn't find a smaller test case to trigger the bug.
Alternatively, if this regex code is something you could push off to do in another process (such as by shelling out to Perl to do the regex stuff for you), you could try that.
You know, that was one reason I was inclined to move to v372 - version 4 is a huge change. If PLT seems less mature now because of these errors I wanted to treat pre-4.0 and post-4.0 as separate beasts.
But I gave up on porting json.ss to v372 (it's prob something really simple; I'll mail you a file just FYI) and now I'm going to go fix non-stability issues on readwarp for a couple of days..
It's dying in the same phase as before. I emit prints before and after the regex-heavy phase. That's where it's dying. The error is still "SIGSEGV fault on 0x10000084"[1]
I mean, clearly I'm not capturing some aspect of the bug since it's not showing up in the sample test. It seems simpler to assume there's one bug in PLT scheme rather than two, and that we just don't fully understand it.
[1] update: I suppose that's just some error handler
Not sure if I'm quite following you. I think you're saying that you're getting segfaults on your new server even though your sample regex test is working; but if that's true, how do you know that it's bug C, that the segfaults are coming from the regexs?
I actually looked at Rainbow just yesterday and noticed you doing this. XD Immediately I wondered whether you'd put a link up here, and here it is.
Anyway, I think this is a great use of Arc. Whenever I'm manipulating something that has a lot of patterns in it, my programmer senses tingle and I find myself wanting to abstract things away. That way, the project is smaller and easier to wrangle, and I can't make small mistakes writing out all the patterns myself. Music is a perfect example of this, as you say.
As someone who only knows sheet music well enough to count my way eventually to the right keys on the piano, I'd like to volunteer that s2/4/5 jumps off the page for me even better than the sheet music does, since I don't have sharps and flats to worry about. In fact, I think I'd be more confident playing that opening motif if I put the Arc version in front of me. XD Chances are I just don't know what I'm missing, but still I hope you don't let the text-only nature of Arc discourage you. ^_^
