The last time I tried it, the build process had been changed to require a precompilation step for the script runner, and that precompilation step failed for me. Prior to that the lisp-based solution seemed to mostly work, but was not maintainable by me. ASDF is all I can handle; I need to have a build system on which I can rely. Admittedly, bash is about the worst programming language short of INTERCAL, but I can trust bash and make, and there are a plethora of documentation and code sample resources. I need that. I don't have the resources to beta test a new scripting framework as part of ASDF maintenance. So those are the symptoms of my allergy. Developing a scripting framework in CL is a fine project, it's just not MY project. Best, R

On Mar 28, 2016, at 18:15, Faré <fahree@gmail.com> wrote:

...

...

Going forward, we really need a Windows partner for ASDF.

What would be required to fit in? I am still in the learning phase of my CL career, but I'm mainly using Windows for my every day tasks (including programming), so I might try. Last I tried, the newfangled way of testing with asdf-tools worked well on Windows. It triggers allergy in Robert, but you might want to

On Sun, Mar 27, 2016 at 6:05 PM, Jens K. Loewe <jens.k.loewe@googlemail.com> wrote: try it.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Conservative, n.: One who admires radicals centuries after they're dead. — Leo C. Rosten

On Wed, Mar 30, 2016 at 11:31 AM, Jens K. Loewe <jens.k.loewe@gmail.com> wrote:

What was the precompilation step?

Building a asdf-tools binary, which has to be done while asdf is working.

In general, I'd propose a Perl script for everything that involves automatic file processing (it would even be easier to port it to Windows then).

That's what I was trying to get away from. Not only is installing perl (and all of cygwin) a pain on Windows, maintaining a fragile mix of bash, perl, sed was more than I was willing to do. Despite all its warts, the lisp-based asdf-tools solution is so much better than perl could ever be. The warts are mostly related to bootstrap issues when you're modifying asdf itself. I understand and respect why Robert doesn't want to deal with asdf-tools. When I spoke of "allergy" I didn't mean that it was irrational and without cause, but that as the result Robert was averse to making more attempts with it. Hopefully, whoever does Windows testing doesn't have to face as much trouble as Robert did, because they won't be modifying asdf much, but mostly just checking that asdf keeps running, which it should — the portability layer is pretty stable and though we've tweaked configuration paths recently that shouldn't affect testing much if at all (unhappily, it is mostly untested). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Love doesn't scale. — Eric S. Raymond

On Wed, Mar 30, 2016 at 3:39 PM, Attila Lendvai <attila@lendvai.name> wrote:

...

The warts are mostly related to bootstrap issues when you're modifying asdf itself.

i don't see the whole problem, but maybe the bootstrap script could check out the latest stable tag/branch into the build/ tmp directory, and compile asdf-tools while inside that asdf repo state?

That's a possibility. I kind of wanted basic functionality to work even when git is not present though, for cases where e.g. a tarball is used, or a rsync/scp of the checkout onto a test machine. My compromise of "build asdf-tools while you know you have a stable asdf" seemed good to me, but admittedly it's a cognitive burden on other maintainers, too. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Luck occurs when preparedness meets opportunity.

On Wed, Mar 30, 2016 at 4:55 PM, Robert P. Goldman <rpgoldman@sift.net> wrote:

Unfortunately, the build went south for me at the first introduction of the precompilation into the build, so stable never happened for me.

Apologies again for all the trouble.

TBH, I would suggest the building happen outside the ASDF repository entirely. Scripting isn't part of the ASDF objective, so I think having a scripting engine that one installs separately would make a lot of sense. The ASDF build tools are like bundling building of bash together with the"make" tool's build and maintenance.

I'm thinking about it, in case I go back to hacking build and test tools for CL. That was the XCVB model, BTW. But at this time, I suppose we can declare XCVB dead. ASDF improved enough that the future will be either an ASDF4, or something completely different and general purpose like Bazel.

That said, even if the build tools were restructured, I wouldn't use them. They have been too rickety for me. They have failed one too many times, and I'm not going back.

I am also unwilling to learn a new scripting framework, especially one under active development.

Sorry, but she'll scripting for me isn't broken enough for me to enter into the project of developing a new alternative to perl and python. My active research is in other fields. I'd be interested to see what you all come up with, but right now I have other priorities.

Well, it's pretty stable this days and not "under actively development" anymore, but point taken. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Pick the fight that if you win it will make every other fight easier to win. — Tarren Bragdon