vilmibm/trunkless
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

minor cleanup

Browse Source
This commit is contained in:
nate smith 2024-04-21 20:03:36 -07:00
parent 0e114bc448
commit 17973144c5
2 changed files with 4 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
ingest_gutenberg.sh
View File

@ -4,5 +4,8 @@ p="/home/vilmibm/pg_plaintext/files/"
while read book; do while read book; do
title=`cat $p$book | guttitle.sh` title=`cat $p$book | guttitle.sh`
cat $p$book | gutcontent | phraser | gutingest "$book $title" cat $p$book \
| gutcontent \
| phraser \
| gutingest "$book $title"
done done

27
main.go
View File

@ -15,33 +15,6 @@ import (
_ "github.com/mattn/go-sqlite3" _ "github.com/mattn/go-sqlite3"
) )
// TODO multiple backends
// I've been waffling on the question of whether to support multiple backends.
// there are two narratives here.
// NARRATIVE ONE: TRUNKLESS IS AN ART MACHINE BASED ON GUTENBERG
// Trunkless is specifically about exploring the project gutenberg corpus. It's a massive corpus that depicts a particular era of the English language. This focus means anyone working with it is exploring the same phrase space.
//
// Poets wishing for a similar interface that can be used generally should consult $TOOLTHATDOESNOTEXIST for doing digital cutup poetry locally.
// NARRATIVE TWO: TRUNKLESS IS A GENERAL PURPOSE CUTUP POETRY WORKBENCH
// Embodied in trunkless is a fundamental user interface for making digital cut-up poetry. This interface can support any kind of phrase backend. Because preparing the phrase backends is time and labor consuming, the user-poets cannot add their own; however, they can submit them for addition.
// If I wanted to support multiple backends what would it take?
// - a backend selector on the web tool -- drop down
// - extension of schema to include more clear metadata -- specifically a an optional sourceURL
// - changes to this file to support pairs of (dsn, maxID)s
//
// it's not that hard but given that i'm a stopgap for adding new phrase backends it feels like wasted effort.
// what about this narrative? I launch just with gutenberg and see if I hear "wow i want this for other stuff"
// the thing is, I want it for my stuff. but I consistently don't want a web app. I want a CLI or a controller-based interface. I can sit myself and put time into working on poems from gutenberg and then see if I want to build something totally new or just add new phrase backends.
// no matter what there are improvements to phrasing I want to see before I let anyone see this (even to beta test) so the plan now is:
// ship phraser improvements
// get a deployment pipeline
// seek beta feedback
const ( const (
dsn = "phrase.db?cache=shared&mode=r" dsn = "phrase.db?cache=shared&mode=r"
maxID = 467014991 maxID = 467014991