Random pithy quote: 2000 B.C. - Here, eat this root.
1000 A.D. - That root is heathen. Here, say this prayer.
1850 A.D. - That prayer is superstition. Here, drink this potion.
1940 A.D. - That potion is snake oil. Here, swallow this pill.
1985 A.D. - That pill is ineffective. Here, take this antibiotic.
2000 A.D. - That antibiotic is artificial. Here, eat this root.



Site Notice: February 14, 2021, 2:35 pm

      The new auto-snipper over at the Bar has been majorly annoying.
      
      Since the snipping stopped over at Eric's site, I've gotten the impression that the posting over there was not as automatic as I'd thought.
      
      I'm pretty sure the posting was automatic, but the initial queueing evidently wasn't. Which I would expect, actually.
      
      Now we have a new script posting to Baen's Bar and it most definitely appears to be automatic.
      
      It simply snips an apparently randomized number of characters (within broad limits) from the last point snipped and dumps them into new posts to various configured conferences.
      
      That's pretty brutal. It breaks things mid-word.
      
      It also does an amazingly bad job on punctuation and (probably) high-bit ASCII characters.
      
      It seems that most - if not all - characters it doesn't like are being converted into question marks (#3F).
      
      I don't know if that is being done by the poster-script or by the Bar software, or by the copy from the manuscript file into a text file for sourcing the snips. Probably the Bar software - it needs to keep it's own messages clear of debris. This part of the problem could have several origins.
      
      I don't know what scripting language is being used (I use PHP), but personally, I'd update the script to do two things:
      
      First build a simple, fixed translation matrix to deal with funky-character mapping. I have something of the sort in this site code for much the same reason (not elegant, I wrote it fifteen years ago and haven't touched it since). An array of strings that can be mapped to any high-bit ASCII characters (used as the array index) before generating the site file as a copy (I simply do that so I still have the original, unprocessed file still available). The same thing ought to be doable for MS Word smart-quote issues. (The use of MS Word anywhere in the process usually being the biggest source of headaches for character issues.)
      
      Second, re-write the snipper to be manually configured. As one of many possibilities, save all the queued snippets for a story in a single text file, then manually insert a fixed-tag (XML tag with posting-date attribute, simple XML start indicator, or simpler - but effective - fixed-character string start indicator) to mark snippet boundaries. You could still manually insert them at any specific characters, words, sentences, paragraphs, or scenes. Have the script read the file in, count boundaries until you reach the instance used in the last run (you'd need to save that pointer between runs) or, to avoid that, re-write the collection back to the source file, minus the just-posted part, allowing the source file to erode away as each snippet posts, each new script run posting the now-first block, and an empty source file does nothing, letting the script move on.
      
      What I'm copying over here is just painful to see and it's what's in the Bar's messaging. Not a whole lot I can do to clean it up with a script on my end.



Site Notice: January 28, 2021, 4:40 pm

      I managed to find a bug in my site code.
      
      OK... not really a bug, but definitely a limitation that I'd forgotten about.
      
      I internally label each snippet with a two-digit sequence number (for chapters - which was actually a limitation issue with one collection, many moons ago) and a series pointer value that runs from 'A' to what I thought was supposed to be 'Z'.
      
      Ten years ago, when I wrote this version, I wasn't using foreach to iterate through the pieces of my chapters. I wasn't even aware of the range function... which would have simplified much and made it more readable.
      
      No... I simply ran a for loop from 1 to 15, instead of what I thought was configured to 26, added 64 to offset the loop counter and then used chr to get my alphabetic chapter piece test value - rather than simply iterating through range( 'A', 'Z' ), which would have been simpler & faster.
      
      I was thinking that my code ran to 'Z', but today I discovered that the $maxpiecesperchaptersearch value is only configured to 15... which stops the search at 'O'.
      
      I discovered this when I added piece 'P' to Heart of Stone because someone - who shall remain nameless - evidently doesn't believe in chapter breaks in a short story.