Dave Cooper (@dcooper) on GitLab, 2018-10-14.
.lisp files can now be included in the content/ directory. They are expected to call the add-content function as shown in about.lisp.
0 commits, 0 files changed
Dave Cooper (@dcooper) on GitLab, 2018-10-14.
Also put a little band-aid on the content-text computation in render-page, because the split-content-from-header was returning some NIL items in the content list (e.g. for about.html and phub.html). This should probably be fixed in split-content-from-header itself (I'd make an attempt, but I don't "do" loop, sorry).
(the band-aid is that I just put (remove nil content) (line 44)).
Erik Huelsmann (@ehuelsmann) on GitLab, 2018-10-14.
Since this is a one-shot process, do we need to compile and load the lisp file? Or can we just load it, with the same effect (but at less complexity and better performance)?
Erik Huelsmann (@ehuelsmann) on GitLab, 2018-10-14.
The title is the ony used field for now, but actually, the "header" is supposed to be full YAML (hence my use of cl-yaml to parse it). Maybe the lisp format file can "announce" a header somewhere which can be serialized in this step, instead of specializing the title?
Erik Huelsmann (@ehuelsmann) on GitLab, 2018-10-14.
I tried to update the PR for this change: on master, there's now code which removes the need for this change.
Meaning: could you update it please, as I couldn't?
Erik Huelsmann (@ehuelsmann) on GitLab, 2018-10-14.
This line has one space less that the other two and doesn't get rendered in the same "code-like" box as the other two. Could you add one more space?
Erik Huelsmann (@ehuelsmann) on GitLab, 2018-10-14.
Wondering: shouldn't this function be moved to helpers.lisp?
In general I wouldn't expect any code in globals.lisp (even more: I was already working to remove the need to have globals at all, unless they serve as special variables with dynamic extent).
Erik Huelsmann (@ehuelsmann) on GitLab, 2018-10-14.
Since *pages* now equates (populate-pages) all around, can't we remove *pages* and move the invocation of populate-pages to the argument position of process-pages where there currently is (process-pages *pages*)?
Dave Cooper (@dcooper) on GitLab, 2018-10-14.
Ok, working on addressing your discussion points now.
Is there a way for me to amend this merge request, or is it best just to close this merge request (without merging) and making a new merge request?
Dave Cooper (@dcooper) on GitLab, 2018-10-14.
Ok.
Dave Cooper (@dcooper) on GitLab, 2018-10-14.
Ok.
Dave Cooper (@dcooper) on GitLab, 2018-10-14.
Ok.
Dave Cooper (@dcooper) on GitLab, 2018-10-14.
Ok.
Dave Cooper (@dcooper) on GitLab, 2018-10-14.
Ok, I'll change the argument to add-content to be :headers instead of :title, then have it emit the headers one per line in what I understand to be the YAML header format (the same as how the title is formatted now).
Dave Cooper (@dcooper) on GitLab, 2018-10-14.
I'm sort of in the habit of always compile/loading things, maybe out of superstition as well as insufficient understanding of the nuances of eval-when rules and what actually happens during a load vs a compile.
But officially, loading a .lisp file should have the same logical effect as loading the corresponding compiled .fasl, right?
Are we sure all the cl-who stuff will happen as it's supposed to just by loading the .lisp file without compiling?
Erik Huelsmann (@ehuelsmann) on GitLab, 2018-10-14.
Hi @dcooper, you're aware that MRs get updated when you push to the same branch before they are being merged? (I.e. no need to close MRs unless you really want to cancel the "MR process".)
Regards,
Erik.
Dave Cooper (@dcooper) on GitLab, 2018-10-14.
Hi @dcooper https://gitlab.common-lisp.net/dcooper, you're aware that MRs get updated when you push to the same branch before they are being merged? (I.e. no need to close MRs unless you really want to cancel the "MR process".)
You mean I can keep pushing commits to my dcooper/cl-site master, and they'll show up in the merge request on clo/cl-site master ?
Dave Cooper (@dcooper) on GitLab, 2018-10-14.
Ok I think I get it. I just tested it - pushed a small change onto master on my fork, and indeed it showed up in the currently pending MR. Thanks for the tip and sorry for the flurry of unnecessary MRs.
Sign in to comment.