Parsing a README.md File To Fill A Folder

Usage Show & Tell
1

I've integrated @gchiu's Cypress Tests to the GitHub workflow.

There's a certain number of things we want to have work before we "greenlight" a new libr3.wasm file. Things like Graham's prescription writing app or chess demo are examples of this.

But we don't want the test scripts for those things to live in the Ren-C repository. Because they need to change as the apps change--and they should also be running whenever those apps get a new commit pushed.

At first I just did a wget of the scripts:

cd tests/cypress/e2e
wget https://gitlab.com/Zhaoshirong/rebol-chess/-/raw/master/cypress/e2e/chess.cy.js
wget https://raw.githubusercontent.com/gchiu/midcentral/main/cypress/e2e/rx-app.cy.js

But this encountered an error, because when git has a directory with no files in it...it doesn't exist. So there was no e2e directory.

I could have just said mkdir tests/cypress/e2e as part of the workflow. But I figured making a README.md file and putting it in the directory to explain what it was would be easier.

This gave me an idea: What if I put the URLs in the README.md, and then parsed them out and fetched them? So that's what I did instead!

Here's the README.md, which has * https://whatever lines in it.

Then here's the script that uses the Ren-C GitHub Action:

- name: Collect Cypress Tests from Repositories We Want to Keep Working
  uses: metaeducation/ren-c-action@release
  with:
    script: |
      cd %tests/cypress/e2e/
      list: uparse (as text! read %README.md) [
          collect some [
              '* space [keep url!] newline
            | thru newline
          ]
      ]
      for-each url list [
          filename: second split-path url
          write filename (read url)
      ]
1 Like
2

A post was split to a new topic: What to call an Arity-1 wget or curl-like function?

3

As an interesting talking point... I originally wrote this as:

collect some [
   keep ["*" space url! elide newline]
   | thru newline
 ]

It came naturally to write that using ELIDE. I was going to brag about how cool I thought that was.

Then I thought: "Oh, silly me, I could have just made the KEEP span the URL!" So it didn't seem so cool after all.

..but... it is cool!

What's notable is that with the ELIDE, you're able to easily make the URL! the product of the rule in a reusable way.

value-bearing-rule: ["*" space url! elide newline]

uparse data [ 
    ...
    keep value-bearing-rule
    ...
]

So you can use it with KEEP or with other things.

ELIDE is an assistant in the question asked long ago about how to reuse rules. It may not be a fit for a case like what I was writing, but you can see how a slightly different case it would be useful for.

What About '* vs "*"

If you're parsing text, I think it does keep it cleaner if you use the apostrophe That's 3 less ticks!

Where this might get a bit questionable is if you've picked to define * as some kind of meaningful combinator in UPARSE. Having more ticks might be a benefit to distinguish it.

Or maybe not? I guess it all depends on whether you're using syntax highlighting that calls out the QUOTED!s, or your personal preference.

Main Point: There's Power Here You Won't Find Elsewhere

UPARSE has taken Rebol's cool (but long in the tooth) model to where it's Insaneo Style. I think it's only going to keep getting better.

1 Like