| I've been spending a bunch of time polishing up old projects in the past couple of months. I've been adding CI scripts to things that didn't have them before and publishing some repos on npm. I'll write a follow-up comment to post links to the various repos I'm talking about. . == Rainbow.js == One of those is Rainbow.js. $ npm install --global rainbow-js-arc
$ rainbow-js-arc init-arc my-arc-host-dir/
$ cd my-arc-host-dir/
$ rainbow-js-arc run-compat -e '(prn "Hello, world!")'
One of the first things I did was to simplify the license boilerplate back to a simpler Artistic License 2.0 declaration. What I had there before was a sort of tangle of Artistic License 2.0 licenses, which probably made the license look even more fearsome than it should have.Once I got to running the code, it turned out Rainbow.js needed a lot of TLC before it was in the right shape to install and invoke from a CI script. In fact, I think I had never properly run it on the Rainbow unit tests before. It's up and running them in a CI script now, and the readme's usage instructions are up to date with the new npm-based installation approach, which I've also shown off above. . == Framewarc == Another repo I spruced up is Framewarc. Framewarc is the new name for the Arc libraries I used to refer to simply as Lathe. (Lathe is a much more extensive set of repositories now. Forking the Arc parts out into their own repository has been overdue.) I've actually put Framewarc on npm, despite having little to nothing to do with JavaScript, if only so it can be installed together with Rainbow.js: $ npm install --global rainbow-js-arc framewarc
$ rainbow-js-arc init-arc my-arc-host-dir/
$ framewarc copy-into my-arc-host-dir/lib/framewarc/
$ cd my-arc-host-dir/
$ rainbow-js-arc run-compat -e \
'(= fwarc-dir* "lib/framewarc/")' \
'(load:+ fwarc-dir* "loadfirst.arc")' \
'(loadfromwd:+ fwarc-dir* "examples/multirule-demo.arc")'
As far as package managers go, I like npm. I know my way around it, it makes it easy to install CLI tools like these (which is particularly nice for publishing language implementations like Rainbow.js), it's feasible in many cases to bundle npm packages to run them in the browser, and its versioning makes it easy for users to pin against certain versions.Version pinning has pros and cons. There's a lot that can be said about how wise it is to build ecosystems full of breaking change treadmills, or on the other hand how feasible it is to disallow breaking changes altogether. But this is Arc we're talking about, and experimentation with breaking changes is part of the point, isn't it? :) Version pinning and lockfiles are tools that make things somewhat more manageable when breaking changes occur. While Framewarc was home to several experiments that are interesting in their own right, I always felt Framewarc's most successful aspect was its portability across Arc implementations and its resulting suitability as a test suite for new ones. On the other hand, I also count this as its biggest failure. Portability is an ironic thing to pursue in a language as experimental, as fun, as as unencapsulated as Arc is. Portability isn't everyone's idea of fun, and typically even I don't have fun with it so much as I find it a necessary precondition for everything else I want to do. So was Framewarc a good or bad thing to build for Arc? I think about that a lot. I didn't see people using it, which in hindsight is probably because it was a pile of code that I threw over the wall and didn't provide any tutorials for. To a large extent it felt like a way for me to say "gotcha" when someone had an Arc implementation that was slightly off, and it varied whether people appreciated hearing that kind of feedback. I felt like I was providing stop energy for a certain kind of experimentation-oriented Arc and start energy for a more compatibility-oriented kind. But whether it's good or bad, it can probably be said that Framewarc is a more beaurocratic approach to Arc. So I've named it Framewarc. It's a framework like jQuery, facilitating portability between browsers. It's a few other kinds of framework too, especially in the way its module system invades the way Arc programs are constructed. All the ideas I've had for Arc module systems are at least a little bit invasive of the programming style, so even though Framewarc has been stagnant for some time now, I think it'll be a natural home for iterating upon new module system ideas that raise up the whole ecosystem of Arc implementations. At any rate, if anyone's looking to use or to build frameworks in Arc, they might find Framewarc interesting. :) It can be good for the people who like it, without defining the Arc experience for everyone else. Currently, Framewarc is a repository on my GitHub account. I'd like to dedicate it to the arclanguage organization if that's all right. | 
