Disabling comments seems a little more involved. You'll need to add an attribute (say allowcomments) to the item deftem, and then check for it in:

a) displaying the commentlink in display-story, and

b) comments-active, which is checked before displaying the comment-form

  (attribute a target opstring)

And your comment about multiple copies also got me thinking that from the main Arc directory to go into the Arc prompt maybe I shouldn't have been using $ mzscheme -f as.scm

  $ ps aux |grep mzscheme

kill $(ps aux | grep '[m]zscheme' | awk '{print $2}')

and it killed one. After it was just a matter of starting-restating Arc with the changes in news.arc.

And next is the logo. Thanks for your precious advice.

After doing so the news site was down, which I believe is what Thaddeus was recommending to happen.

Then I had to restart it and detach the screen and start the process again.

That aside, most developers will do development changes on a local machine where they need not attach/reattach and this way you wouldn't need to troubleshoot your code and the host environment at the same time.

Then you create a stable deployment process. eg. Backup the old code, drop in the new code, re-attach to the existing session and either load your changes or restart the program if you're ok with some nominal downtime.

Did you mean in some other language? It's easy to build a test harness, it's usually the first thing I do with a new language, and invariably just a few lines of code.

Here's my test harness in C++, for example: https://github.com/akkartik/wart/blob/cc70d66ee6/literate/00.... Even in C++ it's just 50 lines or so. Dynamic languages are often even shorter.

(It's not a normal C++ project. I use readable diff directives inside :(..) to add the test harness to the skeleton program at https://github.com/akkartik/wart/blob/cc70d66ee6/literate/00.... But now that this is done, any function I write with 'test_' is automatically run in test mode. Look at the makefile to see how I do that with minimal code.)

I actually applied with it for Lisp In Summer Projects (http://lispinsummerprojects.org/), which is why I haven't announced it -- you're supposed to do the work yourself, without help. And people here like to help out and post code. :-p

The oauth utility is also for the LISP contest -- we'll see how far I get over the next few weeks.

Either way I'm planning on uploading a few bits and pieces to Anarki or my own repos over the next couple of weeks. (spent some time on anarki's web.arc, the state machine stuff, oauth, some lazy evaluation stuff, etc...)

Please let me know what you think -- email in profile, comment here, open bitbucket tickets, find me on the street^1, etc.

So I'll just explain what, in my mind, is the biggest difference -- how I want to use it. To run the anarki test-iso test, you execute the entire `(test-iso ..)` sexp. If you want to run a bunch of tests, you have to execute all the sexps.

That's kind of a hassle. Especially if you find a bug, have a bunch of tests that fail, then change a small thing in the function, and want to re-run all the tests.

In my unit-test.arc, all you have to do is call `(run-suites suite-name)`, and it'll run as many tests as you've got in `suite-name`. You don't have to copy a bunch of sexps into the repl or reload the file (and what if you want to run a subset of a file? You can't). Also -- and this is one of the features I'm currently working on (https://bitbucket.org/zck/unit-test.arc/issue/21/after-runni...), what if you run one hundred tests at once? Do you really want to parse -- with your eyes, like a bloody scribe -- every single line of output to find the seven tests that broke? And when you then make a fix, you're not going to want to parse them again, so you'll only run the seven that failed before. So if you broke something else, you won't find that out.

So, what falls out of my desire to run a set of tests easily and repeatably, and have summarized output? Some sort of grouping, with a single point of entry to run the tests -- that is to say, test suites.

  Can't coerce  #(tagged mac #<procedure: mkrule>) fn

---

In general, creating macro helpers for macros is harder to debug. Instead create function helpers to create the right code as a list and invoke it within the top-level macro to turn it into code. Here mkrule should probably be a function.

I think Arc's main advantages over Scheme, once all the Arc-like naming conventions and macros are in place, are setforms, defcall (not in pg's Arc), and the ssyntaxes (a:b c), a.b, and a!b. Going by the examples, Rark has setforms, and its ability to unwrap data structures using function calls indicates defcall wouldn't be hard to add if it isn't there already, but I don't see anything about ssyntax. I've been meaning to download and run Rark to see if ssyntax support is actually there after all.

Right now, Arc s-exp editing macros are straight-up unsupported. In addition to pattern matching, you have to explicitly break hygiene with leak and bind:

  (mac nif (test body ...)
    #:leak (nit)
    (bind (nit test)
      (if nit body ...)))
  
  > (nif 5 (displayln (+ "yep: " nit)) (displayln (+ "nope: " nit)))
  yep: 5
  
  > (nif nil (displayln (+ "yep: " nit)) (displayln (+ "nope: " nit)))
  nope: