Updated: download link to reduce bounce rate AND pulled from master - #139
Updated: download link to reduce bounce rate AND pulled from master#139marcusr2ML wants to merge 4 commits into
Conversation
The script links on the DMFT tutorial pages were markdown links to github.com/ALPSim/ALPS blob URLs, so clicking one navigated the reader off to GitHub instead of downloading the script. Vendor the 20 linked scripts under content/en/tutorials/dmft/codes/, mirroring the layout used by the ED and DMRG tutorials, and convert the markdown links to anchors with a download attribute pointing at ../codes/<tutorial>/<script>. Same-origin links honour `download`, so readers now stay on the page. Files are copied verbatim from ALPSim/ALPS at commit daa7392 - the same commit the previous links were pinned to, so the vendored copies are exactly what the pages already referenced. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
egull
left a comment
egull
left a comment
There was a problem hiding this comment.
I think thats a bad idea. Now we have two copies of the same tutorial floating around. One in the source code, one on the webpage. They are the same right now but inevitably they will drift apart over time.
I see the desire to download it, but there has to be a better way. Perhaps opening the github source in a new window will avoid the issue of navigating away?
|
@egull I'll look into writing a quick javascript to handle this or maybe use github actions to update the link if the tutorial code is changed. Note: ED was already this way and DMRG and MC have been changed to this. Update: The JS fetches the script from ALPSim/ALPS over raw.githubusercontent.com (a different origin from the site) and hands the browser a blob so it saves to the reader's downloads without navigating away. |
Reverses the approach of d37960d in response to review: keeping copies of the tutorial scripts in the website repo means two copies that inevitably drift apart. Drop the 20 vendored scripts under content/en/tutorials/dmft/codes/ and point the links back at ALPSim/ALPS. To keep the reader on the page -- the reason the copies were vendored -- add a small click handler that fetches the raw file and saves it via a blob URL. The HTML download attribute is ignored cross-origin, but raw.githubusercontent.com sends access-control-allow-origin: *, so the fetch is permitted and the blob counts as same-origin for the purposes of download. Links keep target="_blank" so the no-JS path and the fetch-failure fallback open a new tab rather than navigating the tutorial away. The script is loaded from layouts/baseof.html rather than the existing custom/head-end.html partial: the theme calls that hook from _partials/, which Hugo >= 0.146 no longer resolves against layouts/partials/, so it renders locally but only builds correctly on the 0.115.4 CI pins. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The pages reproduce each script inline in a fenced block and the prose walks through it, so tracking master would let the displayed code and the downloaded file diverge silently -- the URL keeps resolving, so a link check would not catch it. daa7392 is the commit the links were pinned to before this branch, and the one the vendored copies were taken from, so the download once again matches what the page shows. Bumping it stays a deliberate edit made alongside any prose update. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
marcusr2ML
changed the title
|
Ok, interesting. That makes sense! Now is the choice of hash deliberate or should the link just go to a branch? If the tutorials in the repository change, this will not upgrade, right? |
|
@egull Yes, that was intentional. The vendor code (the folder under codes I placed in ALPSim from ALPS) was coppied from here (https://github.com/ALPSim/ALPS/blob/daa7392/tutorials/..). I believe your tutorials were pulling from this same hash, so I went with this option. Note MC uses the source branch instead. The tutorials download links should probably all be consolidated at some point. You are also correct: this will not be updated automatically. On the flip side, there will be no 404 errors because of a file name change. I think it serves as a buffer. We can implement an auto update via GitHub actions (I think). I reasoned the scripts were being pulled from the above URL for some reason, so I did not go that route. |
|
I was also battling with where to put the tutorial codes before. I think storing them in ALPS repo is better than in website repo. We just need to consistently link the webpage to the source code. One trouble, though: if we create some new tutorials and update webpages, we will have to wait for the ALPS source repo to settle before we can update webpage. |
|
@Ooolab I'm thinking of changing the hyperlinks to the live website. They are pointed at a specific snapshot of the source code repo right now. If the code is editted locally, I think the website should be ok. Maybe some GitHub actions pipelines can update links and the inline scripts for the tutorials when someone commits. |
|
I think you're overthinking this. We originally had the tutorial parameters on the web page and then again mirrored in the repo. Over time the web page tutorials stopped working, precisely because nobody bothered to check them regularly and the codes changed. With a very early version of CI (called tinderbox – probably ca. 2005) we then auto-built the tutorials together with the source to make sure they worked. What you have right now works, but to make sure that they track the current version that's in the source code I would change it to the main/master branch (I know that's now what was there before). If someone changes the tutorial in the repo the web page will break, but that's probably a good thing – it will then show up as a dead link and force up to update the tutorial if it ever gets forgotten again. This may be something to discuss in the next meeting? I'm not sure we've found the best solution yet. |
|
@egull Yeah, I think pointing to the source branch is what I am going to do. In fact, I originally did this and changed it to that above hash to be a buffer. Note, many repos inline parameters do not match the source scripts, so they have been drifting a bit. Maybe inserting a "when: manual" in the CI/CD pipeline can prompt a user to manually update the hyperlinks and inline parameters/.py text. |
Point the DMFT script downloads at the master branch of ALPSim/ALPS instead of pinning them to commit daa7392, so the tutorials always serve the current source rather than a snapshot that silently goes stale. Also bring the Japanese and Chinese DMFT pages in line with the English ones: they still carried plain markdown links to the pinned commit, so they neither tracked the source nor used the download behavior. All three language trees now use the same alps-download anchors. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
marcusr2ML
changed the title
|
This looks good now. Let's merge it (...and I'm back from holidays...) |
3 participants
Same treatment as #132 (DMRG) and #138 (MCS), now for DMFT. Just verify the download links provide the expected scripts.
Note there are a couple inconsistencies found (see below), flagged for a follow-up PR
(CLAUDE)
Problem
The script links on
dmft02–dmft08were markdown links togithub.com/ALPSim/ALPSblob URLs:Clicking one navigated the reader off to GitHub rather than downloading the script.
Change
content/en/tutorials/dmft/codes/<tutorial>/, mirroring the layout used by the ED and DMRG tutorials.downloadattribute pointing at../codes/<tutorial>/<script>. Same-origin links honourdownload, so the file saves and the reader stays on the page.Seven pages touched. No prose, parameters, or figures changed — link plumbing only.
The files are copied verbatim from
ALPSim/ALPSat commitdaa7392, which is the exact commit the previous links were already pinned to, so the vendored copies are byte-identical to what the pages referenced before.Verification
hugo --gc --minifybuilds clean; all 20 files publish topublic/tutorials/dmft/codes/.hugo server.github.com/ALPSim/ALPS/bloblinks remain undercontent/en/tutorials/dmft/.DOS/,hyb/,int/) are preserved.Inconsistencies found, for a follow-up PR
Comparing each page against the script it links, all parameters match exactly on
dmft02,dmft03,dmft06,dmft07anddmft08. Two pages disagree with their scripts, both in the same way:dmft04.mdCHECKPOINTsolverdump_U_<u>tutorial4a.pyandtutorial4b.pydmft05.mdCHECKPOINTdumptutorial5a.pyandtutorial5b.pyBoth pages also list
CHECKPOINTin their parameter tables. SinceCHECKPOINTis what writes restart files and these are long runs (MAX_TIME600 s xMAX_IT20), a reader running the downloaded script gets no checkpointing and cannot resume.dmft06s script does set it, so this is a gap in 04/05 specifically. Not addressed here — flagged for a separate PR.🤖 Generated with Claude Code