Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 22 17:27
    epage labeled #917
  • Sep 22 17:27
    epage commented #917
  • Sep 22 17:24
    Newbytee commented #917
  • Sep 22 17:21
    epage commented #917
  • Sep 22 14:25
    Newbytee opened #917
  • Sep 14 15:03

    epage on master

    chore: Fix release process chore: Release (compare)

  • Sep 14 15:02

    epage on v0.17.4

    chore: Fix release process chore: Release (compare)

  • Sep 14 14:29

    epage on master

    chore: Fix release process chore: Release (compare)

  • Sep 14 14:29

    epage on v0.17.3

    chore: Fix release process chore: Release (compare)

  • Sep 14 13:44

    epage on master

    docs: Be consistent on license … chore: Release (compare)

  • Sep 14 13:44

    epage on v0.17.2

    docs: Be consistent on license … chore: Release (compare)

  • Sep 14 02:06

    epage on master

    chore: Move away from musl chore: Release (compare)

  • Sep 14 02:06

    epage on v0.17.1

    chore: Move away from musl chore: Release (compare)

  • Sep 14 00:03

    epage on master

    chore: Simplify release chore: Release (compare)

  • Sep 14 00:03

    epage on v0.17.0

    chore: Simplify release chore: Release (compare)

  • Sep 13 23:56

    epage on master

    chore: Release (compare)

  • Sep 13 23:56

    epage on cobalt-core-v0.17.0

    chore: Release (compare)

  • Sep 13 23:53

    epage on master

    docs: Update CHANGELOG chore: Release (compare)

  • Sep 13 23:53

    epage on cobalt-config-v0.17.0

    docs: Update CHANGELOG chore: Release (compare)

  • Sep 13 22:06
    epage closed #915
Ed Page
@epage

Can I somehow distinguish normal pages from posts in default.liquid? For posts, I want to show the published_date and tags but cobalt errors seemingly because a normal page has no {{ page.published_date }} index.

While we error for accesses, we don't for conditionals, like {% if page.published_date %}

Oh, and your contains also works

I basically would just like to have the tag index

That is something we should add spport for, feel free to open an issue

And I'd prefer if posts would not move from /posts/<date>-<title>.html to /posts/tag1/tag2/<date>-<title>.html.

Could you clarify this? Why would a post be moving?

Ed Page
@epage

Next Q: Is there a better way of snippet reuse rather than {% include "foo.liquid" %}? Basically, it would be nice if I could define some kind of functions with parameters. Right now, my included foo.liquid requires that the variables of the surrounding scope have the right name which is a bit fragile...

We implemented variable passing (cobalt-org/liquid-rust#424) but I think we did it wrong. I

We do also want to support user-defined liquid features, see cobalt-org/cobalt.rs#779

Does that mean that the liquid crate implements an older version of the liquid template language itself rather than wrapping the official shopify liquid processor?

Yes, we have a pure-Rust implementation, rather than calling into Ruby and I didn't realize how far we've fallen behind.

One feature I've started on but not gotten to finish (can't find the issue atm) is inline liquid help in cobalt (or any tool built on liquid-rust). Every use of the liquid language has its own customizations and so it'd be good to provide documentation that adapts to that.

That'd remove guess work on what tags are available
Tassilo Horn
@tsdh
epage: Thanks a lot for all those explanations! :-)
Ed Page
@epage
Oh, cobalt-org/cobalt.rs#657 is the issue for cobalt having built-in docs for liquid
And cobalt-org/cobalt.rs#440 for internal linking
David J. Weller-Fahy
@djwf
Hi guys - haven't been around for a while, but I'm trying to get back into cobalt/liquid and am having issues compiling the package (the first thing I figured I'd try). I've cloned the latest from github, performed a clean install of rust, and tried stable, beta, and nightly. I keep getting the following error:
error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found
The package it is trying to build is proc-quote-impl-0.3.2, and the line in src/lib.rs in that package is 7 "use proc_macro_hack::proc_macro_hack"
I'm assuming this is something I'm doing wrong - I'm on Ubuntu 20.04.2 LTS right now
Suggestions welcome :)
Ed Page
@epage
That is strange; I wouldn't expect proc quote impl to need libc and am unsure what would be requiring that libc version. Could you psot the full output?
The good news is that I've got all of my other projects into a stable-ish point so I can better focus on cobalt again.
I am working on the ECS conversion atm which will give us more flexible for implementing features
David J. Weller-Fahy
@djwf
Sorry - false alarm - I've been experimenting with nix for generating identical home and utility environments at home, on VPS, and at work, and I neglected to clean up a few parts of the nix environment that were interfering with the build. I'll investigate why the built files couldn't find the nix libc later, but for now I can build both liquid-rust and cobalt-bin
I'm assuming I should start on liquid, as it's a bit behind?
Ed Page
@epage

cobalt is going through a re-architecture, so liquid is a good place.

Things liquid needs:

David J. Weller-Fahy
@djwf
Gotcha - I'll work on those, thanks!
FantasyCookie17 🏳️‍🌈🏳️‍⚧️
@fantasycookie17:artemislena.eu
[m]
I've repeatedly noticed now that some of the (newer) features are undocumented… Thought about opening a PR to add a line to CONTRIBUTING.md that requires to change the documentation accordingly when a feature is added or changed in a significant way. Thoughts? I mean, whoever adds an entire feature probably knows how to use the software enough to quickly describe how to use it, so it's not like this should be impossible to do… And the problem is there isn't really a point in adding features if most users don't know how to use them or even that they exist. I've opened a few issues on that sort of thing already, the latest one that would have to be added (which I only found coincidentally by looking at release notes) is file minification…
(haven't opened an issue on that one so far)
Ed Page
@epage

The main problem is that the documentation lives in a separate repo.

The other is we need to do a better job documenting the version for a feature. Sometimes I'm hesitant to document something that isn't released yet (though I've been trying to be better about releasing often)

FantasyCookie17 🏳️‍🌈🏳️‍⚧️
@fantasycookie17:artemislena.eu
[m]
I see… That's of course an issue. Should I open an issue on the minify thing? If you tell me how this is configured, I could also just PR to the docs directly…
Ed Page
@epage
Go ahead and open an issue. I'm in the middle of stuff, so I can't lookup how to configure it
1 reply
I'll have to look to see if there is a way to merge the repos and keep github pages working
FantasyCookie17 🏳️‍🌈🏳️‍⚧️
@fantasycookie17:artemislena.eu
[m]
Alright. If there isn't any way, I could also offer my webserver, you'd just have to point some domain or subdomain to it, or I could give you a subdomain like cobalt-org.artemislena.eu 🤷🏻‍♀️
Tassilo Horn
@tsdh
Hi. Is there a config option for the RSS feed so that it includes the full postings rather than only a summary / first paragraph? I want that people can read in their feed readers without having to visit my site.
FantasyCookie17 🏳️‍🌈🏳️‍⚧️
@fantasycookie17:artemislena.eu
[m]
I don't think so. It uses the excerpt, afaik… Perhaps you can adjust the excerpt to default to the entire content somehow? Adjusting default.excerpt_separator in _cobalt.yml might work.
Tassilo Horn
@tsdh
fantasycookie17:artemislena.eu: Yeah, that seems to do the trick! Thanks.
FantasyCookie17 🏳️‍🌈🏳️‍⚧️
@fantasycookie17:artemislena.eu
[m]
Out of curiosity, what value did you set it to?
Tassilo Horn
@tsdh
fantasycookie17:artemislena.eu: "I_DONT_WANT_AN_EXCERPT_BUT_THE_WHOLE_POSTING_IN_THE_FEED"
self-documenting values are even better than comments.
FantasyCookie17 🏳️‍🌈🏳️‍⚧️
@fantasycookie17:artemislena.eu
[m]
Ah, alright. I'm not too aware of how Cobalt works internally, so didn't know whether not finding the excerpt separator might lead to it being empty.
Ed Page
@epage
A marker for what leading content should be extracted from the content as an excerpt. "" will cause no excerpt to be generated.
https://cobalt-org.github.io/docs/front/
When there is no excerpt, we use the full content
Tassilo Horn
@tsdh
Indeed, that also works. Thanks, epage.
Tassilo Horn
@tsdh
I have in a markdown listing the text: <description>{{ .Summary | html }}</description>
Now cobalt seems to try to interpret that. At least "cobalt serve --drafts" errors like shown here: https://paste.sr.ht/~tsdh/e8d899adc04844c4b558f9db21895e31b68cb72c
I'd expect that listings aren't processed but taken verbatim. Is there something I can do about it?
Ed Page
@epage
What do you mean by "listing"?
Tassilo Horn
@tsdh
epage: I mean markdown's \n...\n construct.
Or language\n...\n
tsdh @tsdh gotta go to bed now but read answers tomorrow
Ed Page
@epage
Liquid has no knowledge of markdown and gets processed first
You'll need {{ raw }} for that
Tassilo Horn
@tsdh
epage: You mean surround the ... with {% raw %} ... {% endraw %}?
Tassilo Horn
@tsdh
epage: That did the trick.