Halfway Through the Summer -Jocelyn
I have returned, and I have much to say.
Before Dan left for vacation, there were three important tasks to complete for the Visionary Cross Project.
1. Reclaim the information about the scanning.
Using the Wayback Machine, I was able to browse through many different versions of the Visionary Cross webpage. I started in 2012, since I knew that’s when the scanning campaign took place, and gradually began collecting blog posts. Most of the ones I needed were indeed from 2012, but some useful ones came later. I’ve stored everything safely in a Google Doc and organized the posts chronologically.
Next, I took all the information from the blogs—plus the bits I salvaged from the current Visionary Cross website—and reconciled them into a rough “chapter.” It’s far from ready for public view, but it’s now in a state where Dan can review it. When he gets the chance, he can use the content to shape the chapter into his vision.
2. Investigate sizing.
On GitHub, files larger than 50MB trigger a warning (allegedly), and files larger than 100MB are simply blocked. So, I looked into GitHub’s Large File Storage (LFS). I went through the entire process to add a ~300MB model of the cross—only to discover at the end that .ply files in LFS can’t be served. Very frustrating. Mostly my fault for completing the setup before understanding what LFS is actually for. That’s on me—but still tragic.
Then I tried to put the 300MB file in Dropbox and stream it in. It felt like the Zenodo situation all over again, but I had to try—because using a 100MB model would be truly tragic. I thought it might work since Dropbox can apparently stream things like videos and sound. Alas, Dropbox has also failed us, just as Zenodo did many moons ago.
Until we have clarity from ADS, we’re in a tough spot. Do we stick with GitHub and use dreadfully low-quality models, keeping the high-quality versions tucked away on Zenodo? Or will ADS be our solution? For now, we await the decision of the ADS management committee.
3. Keep fixing the computer.
Instead of fixing the original computer, I selected a different one as my victim since no one was in Lethbridge to stop me. I chose the lab computer that’s mostly used for Zoom. A perfect candidate to turn Linux. Armed with a freshly created Linux USB key, I was unstoppable. I didn’t even have to consult YouTube or ChatGPT, except to confirm that F12 would bring up the boot menu.
While the Linux install was a great success, there were a few stumbles. I wanted to dual boot the computer, just in case—but when I went to partition the disk, it wouldn’t let me. I had mentally prepared for this moment and was determined not to mess it up, so I logged into Windows to try from there. Unfortunately, whether because I was using a limited account or because it’s a university machine, I couldn’t access the disk management tools, so I couldn’t reallocate space.
The only option was to go back into Linux, wipe the whole computer, and install the OS clean. One might wonder, “But why didn’t you just go in as a Linux superuser and use the green USB stick Dan kindly gave you to back up everything first?” So, the computer was wiped, Linux happily installed, and I proceeded to download the Dropbox ZIP files Marco gave me with all the Visionary Cross data. I also installed Zoom and Slack, rearranged what was pinned, and called it a day. Great success. My new skills were tested and I passed.
I meant to do more for the textbook, but what I did manage is a good start.
A fellow student was frustrated with Notion trying to make her pay for more blocks, so she switched to Obsidian. Naturally, I told her to find a way for us to share a vault so I could lurk in her notebooks and keep tabs on a paper. A community plugin called Relay was wound to be the solution. It’s a free way to share folders in a vault, as long as fewer than three people access them. This could be an interesting way to work on the notebook before it’s published to Quartz.
Rather than using forks in Obsidian and having Dan reconcile what he likes, he could just see what I’ve done and what he’s done and take whatever he wants. At the end, I’ll publish it on Quartz and GitHub. How nice would that be? We shall see if that’s the route we take.
I started Chapter One of the textbook, which focuses on linguistic and historical context. I’ve divided it into six sections that I believe are essential for Old English:
• “What is Old English”
• “Pre-British Isles”
• “Migration”
• “Dialects”
• “Danelaw and Vikings”
• “Norman Conquest” (with plans not to dive deeply into this one, as it’s less relevant to the course)
My favourite book on the history of the English language is The English Language by Charles Barber et al. But I’ve also looked at how Mitchell and Robinson introduce the history, and how Baker does it. These three styles are very different: Barber is thorough and lays everything out clearly; Baker discusses the evidence and primary sources that support his claims; and Mitchell and Robinson spend two pages on the history and move on. All are valid ways to introduce historical and linguistic context—and now it’s my job to decide what the priorities are for this textbook.
For now, to make the page look a little less sad and empty, I’ve pasted in an introduction to Old English from an essay I wrote last semester. So, the chapter is a bit patchy and weird at the moment.
Another slight issue with having me write the historical chapter is that my knowledge of Old English history is very focused. I tend to only know the parts I’ve needed for essays. I know a lot about language contact and Old English, I know about pagan religion in Old English, I know about runes (to an extent), and I know about women in Old English. None of this gives me the kind of grand overview I need to write a chapter like this. Most importantly, I know nothing about the political landscape or major historical events, because my interest lies much more in the language than the period. Still, this shall not stop me.
