On Mon, 18 Feb 2019, at 10:17, Lars Wirzenius wrote:
Thanks for writing another yarn implementation, the testing tool. I
too welcome it. It helps to have different takes on how it should
work, and to drive in the point that there should really be a formal
specification for the yarn language.
I don't currently have time to work on yarn, being busy with a slew of
other personal projects. A couple of years ago Daniel and I happened
to be in front of the same whiteboard and came up with some ideas for
improvements, documented in the link Daniel posted. Since then I've
felt that it'd be nice if yarn tests were easier to debug, but I
haven't got any concrete ideas for how to achieve that.
I'm also unsure how you would do that, without significantly changing the tool,
personally I'm happy with it the way it is, and if I need debug I just run with
On Mon, Feb 11, 2019 at 12:36:38PM -0500, Richard Ipsum wrote:
> On Mon, 11 Feb 2019, at 08:49, Daniel Silverstone wrote:
> > On Sun, Feb 10, 2019 at 18:14:26 -0500, Richard Ipsum wrote:
> > > Perhaps slightly odd to post this here, but I know for certain that there
> > > two yarn devs on this list and one contributor.
> > As one of those, I don't mind :D
> > > Recently I've been playing with OpenBSD and found that I wasn't
able to run
> > > my yarns there, so I wrote Tiny Yarn, which is a quite hacky
> > > in Lua/C.
> > Interesting. What in C did you need which Luxio et al. didn't provide for
> I could have used Luxio, but I wanted to keep dependencies to an absolute minimum,
> this started off as a pure C project but I decided I didn't want to do string
handling in C.
I'm in favour of keeping dependencies to a minimum, as long as it
doesn't result in too much extra work for the implementor.
I've not had time to try tinyyarn, but if I did, I'd be mostly
concerned about having to convert my PCRE regexes to plain POSIX ones.
Most of my yarns use PCRE extensions, I think. I used them originally
because, well, Python supports them out of the box.
If we decided to do a deep re-think of yarn, and re-design it from
scratch, this would be one of the things that would be thought about.
I've looked through the architecture post Daniel linked, the spec
in the cmdtest repo and also some of the gitano yarns and I can already
see that tinyyarn will not work for these yarns.
If I want tinyyarn to conform or even just run gitano's
yarns then I'd have to bring in libpcre.
libpcre could always be an optional dependency I guess.
That said, tinyyarn only exists at all because I started porting
programs to OpenBSD and needed to be able to run my tests,
now that I can do that there's less incentive to work on it...so I don't know.
The biggest hack is that I'm not even using a markdown parser
but just parsing lines with regexes. :D
This probably really restricts the syntax...