Miscellaneous fixes: omit testing demos & define the license

[xgqt]

No description provided.

[rocketnia]

I deeply appreciate the contributions, but I have some bad news and recommend closing this without merging:

• The license of the Anarki package as a whole isn't accurate to summarize as Artistic-2.0. If you search the repo for "license," you'll see that some things are under some combination of LGPL, AGPL, GPLv3+, GPLv2+, MIT, and possibly other licenses.
• As the author of those demo modules, I can attest that they actually are meant to be unit tests, and I hope we keep running them as such; I made them because I didn't know how better to make a unit test for a #lang. While it's disappointing that they time out now, the timeouts represent a serious incompatibility between #lang anarki and the package server's testing time limits. (Any module that even indirectly depends on a #lang anarki module will time out!) This makes the test failure actually a rather honest representation of the state of things, and I think it might be better to leave it failing as a reminder to improve or deprecate #lang anarki, rather than letting us pretend this failure doesn't exist.

The timeouts are probably a result of Anarki taking a long time to load, which has always been a result of Arc not having an on-disk precompiled representation the way Racket has .zo files. Since a #lang anarki module depends on Anarki, it has to read and macroexpand a whole bunch of Arc files, which apparently takes longer than 90 seconds on the package server.

A long-term approach to this might be to change #lang anarki so that it loads only whatever part of the Anarki runtime it needs. There could also be an effort to make Anarki more .zo-capable, but I think that would lead to a more thorough revamp of the language design (and one that's hard to reconcile with certain hallmarks of Arc's design like pervasive mutability and a lack of encapsulation).

With so few people actively working on Anarki, maybe we should just accept that people won't currently have a good experience developing libraries on top of it using the Racket package server's norms and techniques. (Instead, people can contribute their new libraries to the lib/ directory.)

I can try to see if I can update some documentation to communicate that state of things. At any rate, that's probably a topic for a different issue thread.

Again, thank you for contributing. :) Feel free to keep doing so whenever you'd like. I get the impression you're doing this for the license information tooling you've worked on, right? Are there some goals of yours that would conflict with leaving this package licenseless and failing?

[xgqt]

I get the impression you're doing this for the license information tooling you've worked on, right?

Yup, that is correct.

Are there some goals of yours that would conflict with leaving this package licenseless

Because of empty license metadata the license is assumed to be all-rghts-resereved.

Tbh you probably should also specify the used licenses in a document inside the repo.

I dont see problem with expanding the defined license set to, ie.: '(Artistic-2.0 AND (AGPL-3.0-or-later AND MIT))

[...] and failing?

Not really a huge problem, only packages that fail to build are excluded from being used by the tool I worked on.