Yc/TODO.md

TODO

Development

This is in order of priority.

1. Implement Yvm.
2. Implement Yvm Interpreter.
   • Implement permissions and capabilities.
   • Implement translation of value names to indices and back.
   • Have three stackpools:
     • One for stuff allocated on the stack.
     • Two for SSI values, to be switched between for every basic block.
       • This is to put BB arguments in the right order.
       • This requires that there is no "address of" instruction.
       • Instead, everything that needs an address must be stack allocated.
     • Could also use the above design for the C backend.
3. Add Variables to Yao.
4. Add Control Flow to Yao.
   • if statements.
   • for loops.
   • while loops.
5. Add Compiler and Platform Database to Rig.
6. Change All Relevant Allocations to Use Stackpools.
   • Obviously, if something needs to be dynamically allocated, it should be.
   • But all dynamic allocations should have their root in a stackpool.
   • Things that need to be dynamically allocated include:
     • Things that might change size over their lifetime.
     • Things that are owned by other things that are dynamically allocated.
     • Etc.
   • Also, make a way to attach mutex and other lock unlocking to stackpools.
     • Probably allocate a pointer to the lock.
     • Make sure to use a scope opener beforehand.
7. Add a Way for Users to Say Which Env Vars to Save with rigc.
8. Tie Config in with Build in Rig.
   • Make the config constant.
   • If the user wants to have choices, they should define multiple and pick one when executing a target.
9. Bootstrap on Mac OSX.
10. Bootstrap on Windows.
11. Finish GAML fuzz program.
12. Finish Cryptopals.
    • This is for Yar.
13. Make a context stack for random number generators.

Testing

• Add failing asserts at every new basic block. See this post.
  • Remove these as tests start to hit them.
• Add asserts for all preconditions.
• Add asserts for all postconditions.
• Add asserts for all other assumptions.

Before Release or Announcement

• Document the documentation code.
• Document the testing code.
• Make all programs output their source code.
  • This is to fulfill the requirement to share source.

Future

• Rewrite things in Yao.
  • Document the rewritten things.

Things to Add

• Add asserts everywhere.
• Add commands to opt parsing.
• Add base64 and base16 encoding.
• Tweak ternary in style?
• A copy() function that uses the Type copy() function.
• A move() function that uses memcpy() and then zeroes the source.
• Add design-by-contract facilities, if possible. See the Ada book.
• Add range-limited types like Ada.
• BigInts.
• BigRationals. Use contexts, like bcl, to specify scale and base, which are how inexact operations will be done. Also have rounding modes.
• Cross-platform pty support.
• Linenoise UTF-8 from rain1.
• ACID file writing from sqlite.
• PCG Random Number Generator.
• Date and time.
• Conversions between UTF-8, UTF-16, and UTF-32.
• File object that only allows querying information while the file is open.
  • Also, it should take Path objects to open.
  • Also, it should have its destructor be close().
• A function to make soft and hard links.
• chroot.
• Various allocators.
  • Slab allocator.
  • Allocator by Type.
• Fixed Point numbers.
• Connecting to items on the Internet.
  • Sockets, etc.
• Build modes:
  • Full
  • Alloc (has allocators, but otherwise is nostd)
  • Nostd (ideal for embedded space)
• Regex engine.
• Serialization and deserialization.
• Owned references, borrowed references, and a way to access parent pointers, if possible. (To remove the need for weak references, for example.)
• Html templating engine.
• GAML parsing and dumping.
  • Use base64 or base16 for binary data, and support that natively? Probably because otherwise, people might put nul terminators in strings, and we can't have that.
• PNG read and write.
• JPG read and write.
• SVG read and write.
• Font read for TrueType and OpenType?
• Unicode. (libicu replacement?)
• Add sqlite.
• Add bearssl.
• Add ssh, using BearSSL.
• Add key gen and signing using BearSSL.
• Add password handling, using BearSSL?
• Add compression/decompression, various formats.
• Add tar file support.
• Add nar file support?
• Add OpenGL/Vulkan/Metal/Direct3D unification API.
• nanovg replacement.
• Add GLFW replacement.
• Add Wima replacement.
• Add structured concurrency.
  • select.
  • Channels.
  • Pipe buffers (circular buffers)?
  • Cancel Tokens with deadlines (not timeouts) and also programmatic cancellation.
• Shell parsing (just commands like shlex in Python).
• Benchmark how long it takes to do a clock_gettime().
• Benchmark arithmetic implementations versus gcc/clang builtins.
• Yesno.
• Add a move that memsets the source after (yc assumes null is 0, will provide macros to test against null for the platforms that don't have it).
• Along with the move above, a copy that copies using a type's copier.
• A version of memset that works on different strides, using data passed in by pointer.
• Add different #defines such that each controls whether asserts, precondition asserts, postcondition asserts, loop invariant asserts, and loop variant asserts are compiled into the code. This is because those asserts can be expensive, such as copying an entire map to check that a postcondition assert holds (like "after insert, the size of the map is equal to the size of the old map plus 1").
• Add units, like Frink, to numbers, hardware integers, and floats. Or maybe just numbers?
• Add instrumented malloc, like SQLite. Or just use Valgrind or SQLite's?
• Add equivalent to SQLite memsys5.
• Add way to test reaction to possible failures for malloc(), I/O, network, and others. Do like SQLite, where they can make the first fail, then second, then third, etc. Also, they can make only one fail but the rest succeed, or all fail after the first failure. Do that as well, but make it possible to specify how many should fail.
• Add property-based testing, like QuickCheck, quickcheck4c, theft. I might need to write my own to take advantage of yc features.
  • It should should have an API for generating test cases, like AFL++'s custom mutator API.
  • It should have an API for trimming test cases, like AFL++'s custom mutator API.
• Test custom mutators for AFL++.
  • This includes setting the percentage of time they should run.
    • This might be different for every mutator.
  • If they are effective, use them.

Tutorials

Write tutorials for the programs. Make it a short story format, using a programmer like me and a loud, angry sysadmin as the person the programmer is teaching.

Make sure that the short story part of the tutorials can be hidden (on the website) and that without the story, the tutorials still make sense.

When showing commands, show Linux, Mac OSX, and Windows. Also make it possible to hide any of them. Also, maybe detect the user's platform and only show that one?