Today I'm skimming the rest of PeePDF to describe what checks it performs & its underlying infrastructure.
Underlying infrastructure which includes cross-platform terminal abstractions, collections utilities, string utilities (ASCII-only it appears), evaluating specified PDF filters,
I see more of them rolling their own decryption; at least they're not rolling their own encryption! And integrating it into the PDF parsing.
There's a fairly-straightforward parser gathering stats.
I've already mentioned that there's a REPL, including commands for outputting the bytes of the opened file, the file's changelog, inserting a new "object" into the PDF file, apply PDF encoding or decoding filters to a given file or strings or a PDF object, decrypt the file, load a file to embed into the open PDF, encrypt the PDF file (I wouldn't trust this), output parsing errors, close the REPL, extract embedded files, hash some data, output stats, analyse or beautify embedded JS, ...
I'm reflecting upon accessibility in the arts.
I don't have answers, only questions!
What does making visual art tools (e.g. Krita & Blender) accessibility to the blind mean? Is this even desirable?
Can we non-obviously (i.e. aside from using captions) make movies which are accessible to both the blind & the deaf? Might (as I rewatch it) Spiderverse be an example?
How about videogame settings? Is online multiplayer a good thing?
With that Spiderverse example I acknowledge the scene where an alternate (from Miles Morales's perspective) Peter Parker's sharing his backstory with the visuals undermining what he's saying. If you're blind or deaf I don't think that joke would come across as well.
Then there's the whole question of feeling cultural expected to partake in much of the same media!
Before publishing tech we retold stories by word of mouth, then again computers have personalization potential!
After parsing & validating commandline arguments with fallbacks PeePDF's primary codepath initializes, parses prefix of, hashes, intermediate-parses, & parses the given file. Not all that different from Poppler! Before possibly uploading the PDF's hash to VirusTotal.Com incorporating its response into the output.
Then it choose between several different output formats! Maybe it reformats the parsed PDF to XML via LXML. Or to JSON. Or with or without adding colours to the terminal...
Some ideas I'm considering for my next hypothetical device to explore, now that I've finished discussing a hardware-Internet Communicator with self-hosted maintenance:
Continue that hypothetical to add multi-accounts, mapping, richer IM, publishing, and/or painting images.
modern CDi (could draw plenty of other retro comparisons...) equivalent running LÖVE & Lua on a RISC32fimv; with hardly a graphics or sound card!
How much computational power is desired for video creation?
Both of my polls assessing my next hypotheticals to explore have concluded! The first of these polls got a lot more votes!
Leaving aside my SQL hypothetical I've just concluded (unless you want to ask about certain datatypes?), the biggest draw would be exploring more instant messaging features! @mathiastck may be happy! And I'll explore having multiple user accounts.
I think I'll then explore a different personal-computer (LÖVE/Lua upon a RISC32fimv, barely a sound or graphics card).
A following metathread may explore digital painting (like Krita), peer-to-peer publishing (BitTorrent & Veilid), mapping, & HTML/CSS WYSIWYG editors (love to see if Ink & Switch will have something published by then for me to summarize).
Then maybe I'll figure out how much computing power's needed/desired for video creation...
But first, I've only just started reformatting my last metathread on dev tools...
Perhaps the most distinctive feature of SQL is joins! This allows devs to describe the conditions they want the returned data to fill whilst leaving it up to the database engine in which order to traverse the joins to respond.
We may even want to pull in indices to reduce the amount of compute required!
To make these decisions we'll need efficient strategies for estimating the cost of different options, without spending more time optimizing the compiled code than it'd save!
We'll probably want to gather statistics on the data held in each table (or even block comprising it) to inform these estimates!
The other challenge is that the options combine in far to many ways to consider all possibilities! Considering just the most promising partial solutions saves a lot of compute, with no guarantee it'll find the best solution.both have
Or we could utilize the hardware concurrency I've described...
When discussing writing data I mentioned a concept of "transactions" , where even if we parallelize transactions we pretend that they occur one-at-a-time. One effective strategy for this is to add extra fields to each row indicating when they were inserted & (eventually) deleted so we can determine which are present at any point in linearized time. Transaction IDs would be allocated via a counter.
I'd build an internal table of fully-committed transactions.
Another internal column could store a hamming code to detect (& recover from) when a page of flash is failing. Further it might be useful to access-control columns.
3.2/3.2 Fin on SQL! Unless there's any datatypes we want me to cover?
I reckon that the more you promote your software for others to use the more you're morally obligated to include basic accessibility features!
If the software's just for you & your friends though...
Similarly I'd advise to include internationalization from the get-go. You might as well, & the more you put it off the harder it'll be. Your community can decide which cultures its important to localize to!
To be clear: As a software developer I define "accessibility" as the ability for disabled people to use the software with their choice of tools. Internationalization refers to the ability for the software to speak multiple languages. Localization refers to its ability to speak a specific language.
Inclusivity is the overarching goal of letting anyone use your software.
In each case these values mostly boil down to "use a solid platform which took these issues into account"!
In my explorations of a distributed computing architecture for implementing SQL, the main struggle would be implementing ORDER BY.
Here we would need to buffer the results in RAM. Each block of results could be concurrently sorted by its dedicated CPU core. Since I've stated each block of RAM has one! Should parallelize well as we wait for next row...
Maybe they could speed things up using linked lists or an array of pointers?
If the data's larger than a single block then use Merge Sort.
1/
That Merge Sort could precompute the merge blocks of data we've already gathered & sorted, as we gather additional blocks. For the central processor to read out the results.
Keeping this data around until we need the space (or it gets outdated) could further speed up similar queries!
Similarly we could speed things up by implementing "BTrees" which we can efficiently updated.
A BTree involves storing a block (however large you define a "block" as) half-full of sorted data, with the other half pointing to additional blocks for the values between those. The leaves can be entirely full of sorted data, possibly duplicating data & linked together so they can be iterated over as a segmented array.
Inserting data may involve splitting a block(s) in half adding the middle-value to the parent. Possibly synthesizing a new root upon splitting it!
These BTrees make deleting, sorting, grouping, range, prefix, & equality checks near-instantaneous (log-k time). Inserting is slightly slowed down to also log-k time.
Goes far to minimizing the need for hardware concurrency! Especially useful when you're not intermingling compute into storage, say because you have a harddisk.
On this hardware-DB architecture I'm describing I'd probably store these BTree indices in RAM to minimize wearing down flash storage.