search

latte-central / latte-kernel

The (very) small kernel of the LaTTe proof assistant
MIT License
11 stars 4 forks source link

Add deps.edn and Circle CI #6

Closed zampino closed 4 years ago

zampino commented 4 years ago

Depsifies and CI-fies the Kernel

I couldn't find an immediate replacement for lein-cljsbuild. As a future improvement, we'll add cljs build profile probably with figwheel.main https://figwheel.org/docs/create_a_build.html#running-a-build) .

zampino commented 4 years ago

@fredokun just wanted to ask what's the flow to manage the *.cljc.md? Could we remove such artifacts from git versioning? Should they be made available on some github page?

Moreover atm, running clj -A:codox produces an empty index.html (description seems correct though), I guess the codox task is missing a namespace entrypoint. Which one should be used?

If we don't plan to maintain a github page for that maybe that's irrelevant right?

In general, maybe we could give cljdoc a chance, I triggered a build of the kernel documentation and is looking kind of good. Here's a guide for docs customisations.

fredokun commented 4 years ago

@zampino thank you for the PR. Regarding CLJS, for the moment there is no active project requiring clojurescript support so if I would like the cljsbuild and test to continue to be active (no regression) , it's not critical yet that we find a replacement.

fredokun commented 4 years ago

Regarding the cljc.md stuff let me explain the rationale. I have implemented the kernel while learning about type theory. So it is really a litterate programming document and in a way, the cljc files should be created from the markdown, although it is much easier to do the other way around. There are source files where the comments are even more important than the rest. This means I would really want all files to stay "side-by-side" on github... I understand that since we have to keep them in sync it's a little bit of a burden to manage. But that's not a documentation, that's the actual source code. Apart from this, it is not that criticial that we document the kernel as a library, because the API is in a way quite low-level (and for the moment there's only one "consumer"). This is food for thoughts, I ofen change my mind. In the mean time I merge the PR.

zampino commented 4 years ago

There are source files where the comments are even more important than the rest

Makes sense, I get the point. And how do you consume these files? Do you trigger some markdown preview from your editor to review your thoughts and comments? I do it sometimes as a medium for presentation in Atom.

since we have to keep them in sync it's a little bit of a burden to manage

That could even be either automated on CI or maintained via a git pre-commit hook.

stay "side-by-side"

In the git-hook option, having the cljc.md files in a separate folder would make the flow easier, maybe?