WIP - reserve #187 - pangram

[AtelesPaniscus]

I've not done this yet ... I'm interested in trying out the 'generator' to see if that helps with this slug.

So let's estimate a solution for a week from now.

[NobbZ]

Even though I have less time to spare as I hopen in #217 when I promised a small write up until sunday, I do hope to finish it anyway ;)

At least I will be here to answer your questions, even though it might take some time ;)

[AtelesPaniscus]

Please do not feel under extra pressure on my account. I though using the generator might help you (as much as i might help me). I can do it the hard way if you prefer.

Is there are thread on these generators I could read somewhere ? I think I may have got the wrong idea as to what the generator is intended to do (other than reduce tedium, of course).

Are you writing a generator in Erlang ? My first assumption was that these would be in Go as I read somewhere that Go is the Exercism project language. So then I assumed you would fork some reference implementation and make necessary and sufficient changes, many of which might be configuration changes rather than code changes.

[NobbZ]

Please do not feel under extra pressure on my account.

I do not ;) But I really need to write something as long as I remember what I did ;)

Is there are thread on these generators I could read somewhere ?

The word is said every now and then. But each track is free to choose if they use one at all or how they implement them.

Are you writing a generator in Erlang ?

Of course… It is the most straightforward thing to do… Erlang has a module to create some abstract code representation (not directly an AST) via erl_syntax and also it has pretty printer for this abstract representation in erl_prettyp, I do use those 2 to generate a module skeleton in src/foo.erl and a test file in test/foo_test.erl.

The generator itself lives in testgen/ folder of the repository, it reads canonical data from canonical-data (which is a git submodule which I will update about once a month after things have settled a bit, probably starting january).

Basically a generator for exercise ex has to get implemented in the module tgen_ex, implementing the behaviour tgen.

• Module:available/0: should return true. This is (currently) necessary to discover available generators, I do hope to get rid of it sooner or later
• Module:version/0: Should return an integer which simply represents the tests version. Its used to generate a pre-implemented test_version/0 in the stub and the accompanying version test.
• Module:generate_test/1: Shall return a tuple {ok, Test, [{Name, Arguments}]} when Test :: erl_syntax:tree() | [erl_syntax:tree()], Name :: string(), Arguments :: [string()]. Test is one or more tests in abstract format, Name the name of all functions of the module to implement that are called during the generated test and Arguments is a list of strings which represents patterns for the function stub. I prefer them to be simply names of the arguments.

[NobbZ]

Thank you! I really like this!

[NobbZ]

This is a good idea! Makes it easier to check if there are upstream changes!