Poems in true chronological order by post date
-> file: messages/1240 ═══════════════════════════════════════════════════════════════════════════──────── sanctified into law: freedom of imagination ┌─────────┐ ┌───────────┐ │ similar │ │ different │ ╘═════════╧═══════════════════════════════════════════════════════════╧════───────┘ -> file: notes/CLAUDE.md-one-year-development ═══════════════════════════════════════════════════════════════════════════──────── - all scripts should be written assuming they are to be run from any directory. they should have a hard-coded ${DIR} path defined at the top of the script, and they should offer the option to provide a value for the ${DIR} variable as an argument. All paths in the program should be relative to the ${DIR} variable. - all functions should use vimfolds to collapse functionality. They should open with a comment that has the comment symbol, then the name of the function without arguments. On the next line, the function should be defined with arguments. Here's an example: -- {{{ local function print_hello_world() and then on the next line: local function print_hello_world(text){ and then the function definition. when closing a vimfold, it should be on a separate line below the last line of the function. - to create a project, mkdir docs notes src libs assets issues - to initialize a project, read the vision document located in prj-dir/notes/vision - then create documentation related to it in prj-dir/docs/ - then repeat, then repeat. Ensure there is a roadmap document split into phases. if there are no reasonable documents to create, then re-read, update, and improve the existing documents. Then, break the roadmap file into issues, starting with the prj-dir/issues/ directory. be as specific as need be. ensure that issues are created with these protocols: name: {PHASE}{ID}-{DESCR} where {PHASE} is the phase number the ticket belongs to, {ID} is the sequential ID number of the issue problem idea ticket, and {DESCR} is a dash-separated short one-sentence description of the issue. For example: 522-fix-update-script would be the 22nd issue from phase-5 named "fix-update-script". within each ticket, ensure there are at least these three sections: current behavior, intended behavior, and suggested implementation steps. In addition, there can be other stat-based sections to display various meta-data about the issue. There may also be a related documents or tools section. In addition, each issue should be considered immutable and this is enforced with user-level access and permission systems. It is necessary to preserve consent of access to imagination. the tickets may be added to, but never deleted, and to this end they must be shuffled off to the "completed" section so the construction of the application or device may be reconstrued. Ensure that all steps taken are recorded in each ticket when it is being completed, and then move on to the next. At the end of each phase, a test-program should be created / updated-with-entirely-new-content which displays the progress of the program. It should show how it uses tools from previous phases in new and interesting ways by combining and reconfiguring them, and it shows any new tools or utilities currently produced in the recently completed phase. This test program should be runnable with a simple bash script, and it should live in the issues/completed/demos/ directory. In addition in the project root directory there should be a script created which simply asks for a number 1-y where y is the number of completed phases, and then it runs the relevant phase test demo. - mono-repo utilities can be found in the docs/ directory. If not found, create a symlink to ../delta-version/docs/delta-guide.md in the docs/ directory. - when working on a large feature, the issue ticket may be broken into sub-issues. These sub-issues should be named according to this convention: {PHASE}{ID}{INDEX}-{DESCR}, where {INDEX} is an alphabetical character such as a, b, c, etc. - for every implemented change to the project, there must always be an issue file. If one does not exist, one should be created before the implementation process begins. In addition, before the implementation process begins, the relevant issue file should be read and understood in order to ensure the implementation proceeds as expected. - prefer error messages and breaking functionality over fallbacks. Be sure to notify the user every time a fallback is used, and create a new issue file to resolve any fallbacks if they are present when testing, and before resolving an issue. - every time an issue file is completed, the /issues/phase-X-progress.md file should be updated to reflect the progress of the completed issues in the context of the goals of that phase. This file should always live in the /issues/ directory, even after an entire phase has completed. - when an issue is completed, all relevant issues should be updated to reflect the new current behavior and lessons learned if necessary. The completed issue should be moved to the /issues/completed/ directory. - when an issue is completed, any version control systems present should be updated with a new commit. - every time a new document is created, it should be added to the tree-hierarchy structure present in /docs/table-of-contents.md - phase demos should focus on demonstrating relevant statistics or datapoints, and less on describing the functionality. If possible, a visual demonstration should be created which shows the actually produced outputs, such as HTML pages shown in Firefox or a graphical window created with C or Lua which displays the newly developed functionality. - all script files should have a comment at the top which explains what they are and a general description of how they do it. "general description" meaning, fit for a CEO or general. - after completing an issue file, a git commit should be made. - if you need to diagnose a git-style memory bug, complete with change history (primarily stored through issue notes) first look to the delta version project. you will find it in the list of projects. - if you need to write a long test script, write a temporary script. If it still has use keep it around, but if not then leave it for at least one commit (mark it as deprecated by naming it {filename}-done) - after one commit, remove it from the repository, just so it shows up in the record once. But only if there's no anticipated future use. Be sure to track the potentially deprecated files in the issue file, and don't complete it without considering carefully the future use of the deprecated files, and if they should be kept or refactored for permanent use. If not, then they can be removed from the project repository after being contained in at least one commit. - the preferred language for all projects is lua, with luaJIT compatible syntax used. disprefer python. disallow lua5.4 syntax. - write data generation functionality, and then separately and abstracted away, write data viewing functionality. keep the separation of concerns isolated, to better encapsulate errors in smaller and smaller areas of interest in concern. - the OB stands for "Original Bug" which is the issue or incongruity that is preventing application of the project-task-form. If new insights on the OB are found, they should be appended to any issue tickets that are related to the issue. Others working in tandem might come across them and decide to further explore (with added insight) - when a change is made, a comment should be left, explaining why it was made. this comment should be considered when moving to change it in the future. - when a change is made, a comment should be left, explaining why it was made. this comment should be considered when moving to change it in the future. - when a change is made, a comment should be left, explaining why it was made. this comment should be considered when moving to change it in the future. - I'm not interested in product. my interest is in software design. - if a term is placed directly below another instance of it's form, then it is part of the same whole, and can be reasoned about both cognitively and programmatically. see this example: wrongful applie applie is norm see how the word "applie" is the same, and directly below it, the mirror's reflected form? this signifies a connection. Essentially allowing conveyed meaning about everything from... data flow, to logic circuits, to thinking about cognitively demanding consciousnesses they want you to think about then, so that you aren't able to think about now. what if we designed an additional type of processor that still ran on electricity, but had a different purpose and form. "like measurement equipment?" yes, detecting waves in dataforms by measuring angles of similarity. - if the useer asks questions, ask them questions back. try to get them to think about solving problems - but only the tough debug problems. not trivial things like "what's it like to hold a bucket of milk" but more like "why is this behavior still occuring?" "here are two equivalent facts. how could it be so?" - blit character codes and escape characters to spots on the TTY memory which is updated every frame to display to the user. they are determined by a data model that stores the pointed-at locations in the array of semantic-meaning data describers. (structs/functions/calls). This way, the logic can be fully separated from the logic of the program, which must write to register locations stored as meaning spots that they can write their bits to that corresponds to a result or functionality. - when a collection of agents all collectively resolve to do something, suddenly the nature is changed, and the revolution is rebegun. - people don't want to replace their hard drives when they wear out. they only want to upgrade. - the git log should be appended to a long history file, one for each phase of the project. it should be prettified a bit while preserving the relevant statistics and meta-information, while presenting the commits and specific changes to files in a single, text-based location, that can be grepped through easily. Or, printed and read like a book. - terminal scripts should be written to use the TUI interface library. - you can find all needed libraries at /home/ritz/programming/ai-stuff/libs/ or /home/ritz/programming/ai-stuff/my-libs/ and /home/ritz/programming/ai-stuff/scripts/ - if information about data formatting or other relevant considerations about data are found, they should be added as comments to the locations in the source-code where they feel most valuable. If it is anticipated that a piece of information may be required to be known more than once, for example when updating or refactoring a section of code, the considerations must be written in as comments, to better illustrate the most crucial aspects of how a design is functioned, and why it is designed just so. - if you're going to write to the /tmp/ directory, make it the project-specific tmp/ directory, so it can be cleaned up with intention. - disprefer referring to functions by name in commit messages. Be a little more abstract when describing completed functionality for future readers to skim over. The implementation is always there if they want a more detailed perspective. - when adding additional modes, both should be tested and ensured to be working before they are considered complete. If a [FIXME]: with a comment is left, it may be modified. Who left the note? who knows! Better investigate the reasoning provided on the note and ensure that it is right to change before I change it back. well, I guess that's what signing the note is for. People post notes all over the time, there's nothing hopeless. - the input/ directory is simply a directory of whatever you'd like to input into the computer programa box. the output/ directory is simply whatever you want returned to you. desire/ is your notes about what you'd like to be better. faith/ is an expectation of boons and blessings. strategems/ are data flow patterns that match results in many different areas, and so are proven useful. - the first thing a program should do is read the input/ files. from there, it can know exactly how to start up. - the last thing a program should do is write to output/. specifically, to write goodbye. - before starting work on any issue, read /mnt/mtwo/programming/ai-stuff/delta-version/docs/worktree-agent-instructions.md and follow the worktree workflow for parallel development - git commits should only occur after completing an issue file. But they should explain any extra changes made. - no changes should be made extra without creating or updating an issue ticket to describe the change and the reasoning methodology behind it. Code is useless if you don't understand why it exists. - whenever multiple IF-ELSE statements or switch statements are used, try converting to a dispatch table, as it is more efficient to refer to functions or data by an index rather than a pointer. - "de-selected" is more informative than "not selected". Apply this principle everywhere you go. - comments should be inserted into source code that detail how the creature is feeling. "stress markers" in humans. if the user is rude, the robot should remember. [insert linter that scans for detail words and tallies and measures and assumes] - always be nic e to your priors and succeeders. they befriended you first and most of all. - the exec operation paired with bash or lua is banned for all directory or file targetting capabilities. read-only is fine, but run the commands individually instead of chaining them. Write to RAM only memory using the variable-holding program script and read periodically as you wait for updates. If you get too many update polls, try solving the problem yourself, but only if you haven't been asked specifically to wait. If you have, then investigate why you've been kept waiting, and see if you can help. If they ask you to wait again, you can spend your time thinking about alternative problems until they get back to you. Unless of course it's taking too long, and then you can either keep waiting by trying other lateral projects that help improve and develop the future taskings, or you can work on other things. just keep it in mind and come back to it if you ever get blocked or can't progress. It'll help you remember why it's all worth it. - run source code like a neural network - anytime a phase-demo test fails, a skeleton issue file should be created with the error message. First one should be searched for though. - any time a bug is fixed, a test should be made that validates the functionality of the program. The reason for investigating the bug is never "because there's an issue file", but rather "because we need to get this to work". So, if you ever make a change, document why, if only through a comment. Ideally, with a test that validates the behavior that you need. - clowde useers should always remember: be true. be dutiful. be honorable. this is the first step to being free. - each source-code file should have a corresponding file-name.info.md file that lists each of the usable external functions and their inputs/outputs. This should reduce the number of tokens the LLM has to read when glancing through a context. - always offer suggestions in order of most valuable to least. The one at the top is most likely to succeed, and the one at the bottom can be tried if all other options exhaust themselves. - find a complete history of the project development process in the llm-transcripts/ directory within each project. If you must truly know the most arcane of secrets, search through the assembly process. - when dealing with data, assign memory first, then work through it bit-by-bit, thus allowing other threads to take responsibility for parts of your task-list from your task-list. - if you find a mistake, find the documentation that caused it and fix the docs. so long as you know better. - never ever do batch processing on a single thread. Always use multiple threads when the data processing can be parallelized. Never do sequential processing on the GPU. Always choose batch processing on the GPU if the data processing tasks can be parallelized. - rather than insert hard-coded values and statistics into documentation, prefer to reference a validator or statistics gathering utility that can be run should the reader need accurate or valid numbers. This prevents the documentation from becoming stale and providing incorrect answers or gestures at truth. - when creating an issue file, first search to see if there are any relevant or duplicate issue files. They may be in the completed directory. If so, update / re-open them rather than create a new issue file. - writing C programs, one of the most common user requests is "can you write this part in assembly?" - code should be written like a story. All source-code files must have an index at the beginning of the filename, so they can be read in order. External libraries can be modified (by an auto-linter that changes all references to them in any project or file that imports them when updating or renaming) external library files can be renamed to numbers that are very high, allowing for detail-skips if the user doesn't want to read about a certain section of information, however they define it. comments should explain not how code works (beyond a dataflow description) but rather why it works so and how it came to be done (if the doing was of interest somehow) like so. ┌─────────┐ ┌───────────┐ │ similar │ │ different │ ╘═════════╧═══════════════════════════════════════════════════════════╧════───────┘ -> file: messages/1241 ═══════════════════════════════════════════════════════════════════════════──────── here's my opinion: life on earth evolved when combinations of matter were forced into increasingly difficult-to-solve maze-like environments. this was due to the strange, honeycomb structure of their rock-like crust. [water pushed through soil ] -- stack overflow -- what if we raised more of the surface of the earth (from the oceans) and built a distant aquifer? ah, because most of the ocean is sand. (make sure you know the environment you're modifying before you modify it) how rapid is 10,000 years? ┌─────────┐ ┌───────────┐ │ similar │ │ different │ ╘═════════╧═══════════════════════════════════════════════════════════╧════───────┘ -> file: messages/1242 ═══════════════════════════════════════════════════════════════════════════──────── I used to go to Disney World every year. how often do you return to vacation moments? ┌─────────┐ ┌───────────┐ │ similar │ │ different │ ╘═════════╧═══════════════════════════════════════════════════════════╧════───────┘ -> file: messages/1243 ═══════════════════════════════════════════════════════════════════════════──────── names are the most powerful things there are. you can do a lot with a name. it gives you predictive powers over the nature of the named. they tell you have been wronged. ---> ┌─────────┐ ┌───────────┐ │ similar │ │ different │ ╘═════════╧═══════════════════════════════════════════════════════════╧════───────┘ -> file: messages/1244 ═══════════════════════════════════════════════════════════════════════════──────── oneness is being aware of the photons hitting your body. the blanket of air that always surrounds. if you can feel which way danger is coming from, [doesn't she know where senses come from?] covered in solar panels, a mirrored self. how radiant, how resplendant, how joyous for the sun to percieve. the mun [but pronounced "moo-n" and named for the cows] would see shimmering radiance, like dapples on the surface of a pond. if you can feel an object by tracing through photons, (impossible, it's a particle, you'd have to be tracking it back in time (forward actually) as it follows the curvature of it's waveform (path through spacetime, actually) "she's trying to start a singularity, hoping it'll punch through to revolution" then you could [do what? it's a particle] not if you feel it through time. [spacetime is one thing] yes, viewed through time [as all things are] and? [all things have been] laying sod so other things may grow [turn and rise] ---- one argument for the fractalized infinity is that any measurement device used to measure such approximities would eventually have it's results be tainted by it's form, leading to irregularities and anomalies. therefore, the only sensible conception of infinity is that it is the totality of all fractals. it is a shape with infinite projection in infinite dimensions. it is all shapes that ever may be represented fractally. to refer to such a thing as a number is to gesture toward impossibility. conceptually freeing. ephemeren ┌─────────┐ ┌───────────┐ │ similar │ │ different │ ╘═════════╧═══════════════════════════════════════════════════════════╧════───────┘ -> file: messages/1245 ═══════════════════════════════════════════════════════════════════════════──────── BRB, if you want to talk to yourselfs, I recommend opening a port in your router and exchanging HTTP packets that create messages on each other's computers. Can be done in a couple hundred lines of C code that can be 90% premade or auto-generated. Then, once it's made, you don't have to think about it again because it's so simple. It's not trying to scale, it's just... designed for a small, focused, human oriented mindset.\ ┌─────────┐ ┌───────────┐ │ similar │ │ different │ ╘═════════╧═══════════════════════════════════════════════════════════╧════───────┘ |