100DoC Log.txt

Format: #<day number>.<attempt number>. <date>

Note: running log of progress and notes that may not be code related. Also, I'm not the best speller.
Note 2: I think outloud, so the posts may be wordier then others, because I'm thinking out the process and alternatives.

#0.1. 3/18/2018:
- Project name determined thanks to a friend

#1.1. 3/19/2018:
- Fleshing out docs and making a main function. Plan for the first couple days is to get the project started, do some parsing, how to get some values from logs, and building habits
- I'm not exactly promoting this with the hashtag right now, just to get this going. I don't feel I need motivation, just less stuff to do. I constantly have ideas and write them down, but lack the time to work on it. It makes me easy to distract, so I want to build a habit naturally with everything else I have going on before I start getting "keep going!" tweets and messages.
#2.1. 3/20/2018:
- Almost missed this day (the commit for yesterday and today say they're a day later, but it's because I start late the prior day). #HabitForming
- Already a bit overthinking it because I started trying to do streaming log parsing... just parse the log right now.
- Initial log format is XML. I'm gonna have to make a config file to determine what properties describe the log, just so the log format isn't hardcoded... but that's for a bit later. Maybe tomorrow?
- Initial plan was for a C++ program... but XML parsing, streaming logs, json parsing too (config and I'm sure someone logs in JSON) are not pleasent to work with in C++ and since I want to get something running instead of dealing with frameworks and C++ package systems, I'm just gonna start with C#

#3.1. 3/21/2018:
- I wanted to try and start processing the actual log data, so I finished the XML parsing part. Should still work on making it stream the input. Noted for later.

#4.1. 3/22/2018:
- Late commit again.
- Plan: initial orginization of log output, get streaming XML working (need option parsing so I can turn this on only if needed), have log values determined by config (requires JSON parsing)
- I started late, so I only go the first one done and will do the others tomorrow

#5.1. 3/23/2018:
- If yesterday was late, this one is later...
- I load a config file of info about parsing logs. As it's very late for me, I will test this tomorrow.
- For the "temp" C# project, I decided to be a little curious and use .Net Portable Framework. I'm kinda regretting it. So many APIs just aren't available. I get it's purpose and it should be used, but going 2 levels deep to open a StreamReader? The main library just opened one internally anyway.

#6.1. 3/24/2018:
- Late start because I was finishing something up. Wrote https://github.com/rcmaniac25/setbuilder to help with that task.
- Config for log parsing now used
- Made up a syntax (like XPath) to get out XML data... maybe I should just use XPath? Thoughts for another time
- Changed version, as this isn't 1.0 yet.
- Decided that the XML streaming is a bit too large for doing at this initial phase: why?
-- The log files I initially imagined using this on are in the multi-GB range. This inital impl. loads everything into memory, and loading one or more multi-GB logs would probabaly end poorly.
-- At the same time, I can see two uses of this system (when it reaches 1.0 status):
    1. Tracing across multiple log files.
    2. Manual "debugging" of a log.
-- In both cases, the full logs aren't needed upfront. It's like a sliding window, the system/user is only looking at one part of the log at a time to find/track something.
-- So ideally, the system should load and unload as needed. "Read the first 100 lines of logs. Ok, the user is scrolling, load the next 100. Ok, they got 1000 lines in, load another 100 and unload the first 100. Wait, they did a search... load but don't persist the logs unless it has whatever they searched for".
-- I'd assume info will be cached so it's not constantly parsing. It may be useful to do some tricks, like loading whole sections of the logs into RAM but not parsing them, that way parsing is fast when it is needed.
-- While I'm thinking about some of these things, I will eventually need logging and unit tests. I know I eventually will need to parse source code, if anything, for determining the end of a function and maybe when a function is container within the calling function. Log parsing, code parsing, etc. should all be seperate components so new ones can be used as needed...
-- ...I'm starting to overthink things. Just get some useful parsing done. Tomorrow.

#7.1. 3/25/2018:
- I did not accomplish useful parsing. Instead I refactored code, got a option parser included, and allowed XML parsing to be more "advanced" for each element instead of just the log message itself.
- PSA: Socialize. You'll get good ideas by talking with people about what you're working on. In my case, I didn't do more code (and much of anything else) because I played Fortnite for the whole day. It was fun, especially with friends.

#8.1. 3/26/2018:
- I realized to bring about the idea that's in my head, I need a better way of processing through the logs. This makes me think "database" so I can do queries, but I'm not ready for that point.
-- Basically, gather all the logs together, then do a "get by thread ID" or "get by function" or "get by <random attribute>", and then breaking it down further. Hmm... this sounds like a LINQ query. Fine will we're in .Net, but may be more difficult in C++ (unless I use Rx/Ix)
- This change "broke" the inital printout system I wrote, so I needed to get it back to the inital state it was previously at
- Had a few more log attributes that I can parse. I should look into what other loggers produce/log, so I have a general common set of values and then add some "fancy" parser for supporting log values that aren't common/custom. Also, I still haven't added support for key/value attributes and parsing types of attributes

#9.1. 3/27/2018:
- Orginized the files into folders and added one more parameter. Also fixed a bug where missing parameters could cause the program to crash
- Needed a bit of abstraction for reorginizing sources
- Just realized I finished 10 days of 100 Days of Code. Woot.

#10.1. 3/28/2018:
- Late start, but today's goal was parsing attribute types (and inadvertently formalizing the "path" syntax so I don't have to do string parsing the whole time)
- Needed to touch a little more code then I wanted... but it works, and in theory could be faster then the string parsing from before
- The path system could be expanded... but at that point, it's probably better to revisit the idea of using "paths". Speaking of which, a side reason for formalizing "paths" is because when JSON and other formats are added, we don't want to need special configs for each parser type (though we should support it...)

#11.1. 3/29/2018:
- Added key-value pair support for context attributes, which should simplify things later when we want to trace by a value
- Wasn't working... found out I forgot to actually register the attribute. Yay, copy-paste bugs

#12.1. 3/30/2018:
- Next couple days are with family, so I can't get as much done as I would like...
- Added a printer class so I can support files, console, etc. printouts without needing to rewrite systems

#13.1. 3/31/2018:
- I did one more abstraction to get the parsers and printers from a factory.
- I expect 3 reactions: why? ah, good decision, and premature optimization...
- It's not premature optmization... it's premature generalization. Something of equivilent badness, but only if it's actually going to have an effect.
- In this case, and to awnser the "why", is to shrink the classes down a bit, allow for easy testing with mocks, and to prepare for the inevitable expansion of functionality.
- See, I thought up some ideas on how I want this to operate (I should write them down in some document...), and they all revolved around the GUI. But I know some of the people who have voiced interest are CLI users. Others only use a IDE like Eclipse, VS Code, or Sublime (depending on how you set it up, it can act like an IDE...)
- I can write a single app (that I would still need to move to C++) that has tens of hundreds of options and configs, letting you do anything you wanted... or I can try and be "smart". "What file type are you using? XML? Ok, I should get the XML parser." "I'm a CLI app, so I will print to the console... wait, you specifed you wanted a file, so I will now print to a file"
- How about for "how do I know I didn't break XML parsing by switching from parser X to parser Y?" Easy: tests. But, I need to expose interfaces and internal structures to change values... or I can mock them, abstracted by interfaces, to control within the actual execution class.
- And that darn porting thing. I want this in C++ so instead of requiring *nix users to install C++, or have Java installed... or some other framework. How about "extract a program from the zip, and it runs". Like a good-old portable app.
- Here's what now happens:
-- 1. Bunch of small classes, as independent functionality and decision making is broken up, makes it easier to port eventually. It also allows for making focused classes, such as one that says "what do we need to parse" and "how do we need to present it" instead of a giant code block that's all tangled together.
-- 2. Tests now can be more complex, test more functionality because it doesn't have to test functions with 30 if statements in them, and actually be written without modifying the real code. Need to start this while things are small...
-- 3. Lastly, every time I say "let me add a new feature", I don't have to "make it fit". I should have a class that defines that functionnal "idea" and where it fits in.
- TL:DR: I didn't need to do this now, but it will be easier now then when the code is already tangled.

#14.1. 4/1/2018:
- Moved a couple classes that I didn't get to yesterday, since the factories imply the internal/implementation details don't need to know. Trust the interface.
- PSA: don't kill yourself coding. It's never worth it. Take it from my own experience: I keep wanting to get a bunch of stuff done, and end up staying up late. Doing that and getting up late, so you get the sleep, is fine (so long as work, school, whatever is your real life allows it). In my case, I have been getting what I mentally averaged to 4-5 hours a sleep a night... for like 6+ months. It's made me more tired, sluggish, harder to focus, and I've gotten more sick then I'm used to. I need to break this habit...
- ...which brings me to: I'm sick and need rest. So I did an additional refactor which got rid of a redudent class, though at the detriment of being able to insert mocks easily... (didn't I write about this yesterday?). I will probably reintroduce the class or an equiv. component.
- For now, I sleep. Tomorrow, I'd like to plan further moves and maybe get a public list of tasks I'm trying to do.

#15.1. 4/2/2018:
- PSA: being sick is annoying. Take care of yourself.
- Today I worked on docs... a needed evil

#16.1. 4/3/2018:
- More doc work. I had a timeline to follow, but it was agressive when I wrote it, and probably can't do such a thing (and ideas for how/what to do also became more concrete between then and now). Simplified:
-- Day 1. figure out program name
-- Day 25. Have a library that can parse a large-ish log quickly
-- Day 50. Initial GUI that can visually show the flow of the logs
-- Day 75. Have a working library for parsing, GUI for visually debugging through the logs, support for RPCs and message tracing, have let others (I know directly) try it out and see what they think and what they want/have issues with, and start working on an offical CLI and search capability
-- Day 100. Version 1.0, with a bit of polish, integration with a real debugger (at the time, I assumed to augment a debugger with log info... but I'm not sure how much that would actually be needed), and possibly work on any stretch goals I could think of along the way.
- Talk about agressive...

#17.1. 4/4/2018:
- Thought a bit and opted to just split the program and library portions. There was no good abstract interface that would allow unit testing AND be usable by more then just one class/program.
- Instead decided to start trying to get unit tests setup, starting with spliting the program and library.
- At least add NUnit reference

#18.1. 4/5/2018:
- I've been struggling with the "dedicate 1 hour" for the 100 Days of Code project. First it was habit, next sickness, now is the disease all software engineers have: time. I look at a clock and say "I have time" and then when I next look, it's time for bed.
- Realized I missed one attribute within the logs I'm testing. Also realized the names of those attributes are not always the best, so added some docs around them.
- Wanted to get the test project setup with at least one test. Didn't like the tutorials for using NUnit within Visual Studio, but found http://www.dotnetcurry.com/visualstudio/1352/nunit-testing-visual-studio-2015 which I liked.
- So I got the test project and what would be test #0... and Visual Studio is complaining about the lib not having a .exe or .dll extension (according to the bin dir, it has a .dll extension). If it was earlier, I'd try to fix it. For now, tests pass

#19.1. 4/6/2018:
- I'm sad... I'm sad because I can't get a simple test project to work. I can and should upgrade to VS 2017, but I fail to see that as a requirement to get these tests working with .Net Core. Nearly every tutorial talks like it's so easy "add this dependency and your done" but know what, I add the dependency and my tests don't show up in the test explorer.
- It doesn't help that I'm half asleep (if you ever meet me IRL, you'll find out I'm perpetually tired. I have a small window where I can focus and get stuff done. Today I used that period to play video games)
- Welp... looks like I get to reset my progress back to 0 because I couldn't get anything done today. I am very unhappy with Visual Studio, NUnit, and the tech results I'm getting back from doing searches. This should've been "Visual Studio wants to run tests, NUnit looked for NUnit references... found them, VS is now happy to show the tests". But this isn't the case.
- I'm not calling it defeat but this is truely annoying. It's stuff like this that makes me drop projects... dependency? Right click dependencies and add to it. Good. Unit test? Seems like a half-hearted attempt to add test support but not maintain consistancy throughout (and I'm a stickler for consistancy). Packaging? I'd like to offer a single sentence response, but there are too many variables for it. Zipping a directory doesn't count, that's a hack.
- Still firm belief this is because I'm really tired.

#0.2. 4/11/2018:
- 4/7/2018: Took a short break, since I'm starting the countdown again. Namely, played around with modding a game I like
- 4/8/2018: Made the mistake of starting late again... today (and probably tomorrow) was spent trying to debug the NUnit issue. Visual Studio doesn't always show the logs for running tests, but I managed to get it a couple times and they all say they can't find "nunit.framework". My challenge now is that I'm looking through the code paths to get to the "error", and the stack traces don't match what is getting printed and what files I have. Reading, nunit (and others?) seems to suffer from VS cache issues that requires deleting the old cache. Tried, didn't work. But given the stack trace and the code I'm looking at, something's definitely wrong.
- 4/9/2018: Did a deep dive into what DLLs are getting loaded. I started too late again, and still have no lead. It's trying ot call NUnit.Engine.Runners.DirectTestRunner.LoadDriver and that just doesn't exist. I cleared caches to ensure it wasn't loading it from a strange location... I don't know where it's getting that function from. The journey continues...
- 4/10/2018: I tried a couple things... and everything has failed. VS UI, command line, extensions, packages, different versions, etc. The only thing left is to upgrade to VS 2017. It's very stupid to me. NUnit with VS support is advertised as "Supported VS 2012 RTM and newer" and yet every test, post, discussion about it is on VS 2017. I'm only one version older... VS 2015, Update 3. I kept putting off the upgrade due to laziness AND not having a need. The posts all speak of the "new" XML-based project configs making things so much easier(?). It's all very stupid and a waste of time. In fact... it's a perfect reason tests exist. At work I aim for 100% branch coverage because I'm crazy... but when I get told "your code doesn't work" I can respond back "no, you did something wrong". Then I (or a coworker) goes and automates them. When I look at the NUnit code, I see a handful of tests for the adapter. It makes me wonder "did anyone try automating the tests for VS 2012, VS 2013, VS 2015, and VS 2017 at the same time? Or did they just run the tests after telling all other contributors that they were working in VS 2017 and called it a day? But... enough of rants. Let me get VS 2017 so tomorrow I can see if I can actually DO something, and get this process going again. If it still doesn't work, I'm dropping NUnit, sending a message to the devs (and making a bug), and probably moving to xUnit or similar. No need to waste any more time. I needed to start a new attempt because tests didn't run, and from what I can tell, it's the framework/adapter that isn't working. "Famous last words" but if I upgrade to 2017 and it magically works... well, was my assumption wrong? For tomorrow.
- So after a lot of pain, needing to restart my count, and run upgrade to VS 2017... tests actually run.
- So, https://github.com/nunit/docs/wiki/.NET-Core-and-.NET-Standard half tells you what to do. I followed https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-with-nunit via CLI and some manual editing and got everything working as I'd like.
- Looking through docs now, I see the key line I missed: "FAQ -> Why can't my tests target .NET Standard? -> "...it cannot be .NET Standard, it must target a platform, .NET Core or .NET Framework."
- See, if you look at my log for #5.1, I mention .Net Portable Standard. Diving into why tests aren't working, I have since learned that .Net Standard is equiv of an interface (IDotNet), and .Net Core the impl. (DotNet). I didn't know what the difference was or why things weren't working. I am both right and wrong with what I said yesterday... the framework didn't work... but the devs don't know why and are hoping it will one day work. They blame Microsoft for wanting a hard impl. of .Net (.Net Core or .Net Framework). In the end, it was a giant waste of time. I wonder if there is some way to determine at runtime what a .Net test project is running under (Core, Standard, or Framework) and say "hey, you can't run as Standard. Needs to be a different base". It's probably something that someone has done and said "this is too much work... just write the docs" but, as is typical for docs, is in a bad location (it should really say that here: https://github.com/nunit/docs/wiki/Known-Problems) and people all it a day. Well, now I know and hopefully if someone looks at my project and has the same issue, they eventually find this log and go "yea, that should be written in a different location". I'm not exactly doing anyone a favor by not contributing a fix... but I honestly don't know if that location is the right place. It's just the one I kept coming across.
- Right as I was about to start, I noticed that the libraries have an attribute compiled into them that states the framework used. So my automated version _could_ be done. Have the test running get assembly attributes, find the framework one and, if it exists, check if it's a framework that it knows about/can use. If not, then error with a sane message. I'll note this as something to possibly contribute to NUnit at another point of time.
- I can now start working on all the other tests tomorrow.

#1.2. 4/12/2018:
- I started off tests by... reading. RTFM. If I didn't, I would've just did the "classic model" of "Assert.Equal(X, Y)" which is not what NUnit prefers. So I did a bunch of reading...
- ...and redid the existing test.
- I started late, so I didn't get to anything else. Oops. Time to get back into the habit.

#2.2. 4/13/2018:
- Wanted to spend more time on this, but I need to be up early.
- I was trying to figure out what to write a test for next and realized I had defined an ILogEntry interface, used it in ILogRegistry, but... the actual GetBy function (basically a DB/dictionary query) had hardcoded LogEntry instead of ILogEntry. So that needed to change.

#3.2. 4/14/2018:
- So I always start late and commit on the following day then the one I log for. I will probably still do that, but as I had to do stuff early yesterday, I need to commit today and "tomorrow" so it doesn't appear I skipped a day.
- Started working on more tests. First up: factories. Gave me a reason to add a mocking library (NSubstitute) and to use it. I need to read the docs a bit. I'm used to gmock/gtest, where I expect something to be called and then it complains when it is called (and wasn't expected) or isn't called (and was expected). NSubstitute seems to work off a "check after the fact" but won't tell me if something got called unexpectedly. I feel like that isn't actually the case, but I haven't gone through the logs (or written something that does that). Yet.
- Started working on LogEntry tests.

#4.2. 4/15/2018:
- More tests time. I actually gave some thought and did TDD for the remaining tests in LogEntryTests. So now things work as expected.
- Next up: LogRegistry tests. I realized I don't have a LogEntry factory and question if I need one. I can see different parsers and printers... but what's a different log entry? Yes, I can unit test it slightly easier, but at the expensive of adding a whole new factory. Given how easy it would be to add (add interface with a create function, pass into registry constructor, use...), I'll skip it and can add it if needed at a later time.
- TDD time again... this is a habit I need to get into in general. At my work, it's always easy to spend a day or two working on a class, then spend a few hours on tests and know all the paths to test. But the point is to write how you expect the program to work, not how you know it already works.
- I got a couple tests, only to realize my implementation work as I expected. Initial thought was "what am I doing wrong", then looked at the impl. and realized "I don't want that..." (getting logs by their message or timestamp). See the "todos" in LogRegistryTests.cs
- I also made the mistake of doing too much in a unit test, and it didn't work because of my GetBy impl. anyway

#5.2. 4/16/2018:
- Wrote a lot more LogRegistry tests. Half TDDed, half "was updating something in LogRegistry when I noticed a case I coded to handle, but didn't write a test for".
- The big question for this evening is "return error, or exception?" So this has been a struggle recently for me. All the time I did C# (Java, F#, and others), throwing an exception "is what you do" (TM). Then along comes C/C++. C++ has exceptions, but I've become a bit more "I want a good, clean, end-to-end opcodes" when doing native development. As such, I've seen how Windows and Linux handle exceptions, and it's not pretty. I've also learned that "-O3 optomized" tends to not mean squat if your code isn't in a specific format. Also, C++ is a lot easier to forget to cleanup a resource that was mid-process. Think:
int main()
{
    try
    {
        myFunc();
    }
    catch
    {
    }
    return 0;
}

void myFunc()
{
    std::ifstream in("log.txt", std::ios_base::in);
    doSomethingCool(in);
}

void doSomethingCool(std::ifstream& input)
{
    //...
    throw new std::exception("oops");
}
- I'd expect that the input stream would cleanup. But... I don't know. I'd like to not know, because it would make programming easier (I.e. assuming that stuff gets cleaned up for you). It's not naive, it's taking the human element into account when designing a language.
- Meanwhile, in my preferred native language: C... what's an exception?
- So with plans to move this to C++ at a later point, I had to decide: do I write C# functions without exceptions or not?
- My answer was: depends. If what I was dealing with something had a return status (either from the function itself, or as a different function), I didn't throw an exception. If it didn't, then I threw the exception.
- The way I figure it: if I'm saying "add this value to the log entry" and I want to know if it got added, instead of getting said value and comparing, I'll just look at a return code. So for all failures, return according to return code. Else, I have no idea I did something wrong... so throw the exception.
- Bonus: unrelated to ^^, I added a GetByTimestamp function to LogRegistry and changed the return from GetBy from IDictionary<object, IEnumerable<ILogEntry>> which allows me to support getting by log message* AND still works in pretty much any way I expect.
- * so, to make a grouped dictionary, I need to go through every single log...  working with yield would be better but it's still going to be very challenging to deal with large logs.

#6.2. 4/17/2018:
- I wanted to get many things done today... and it came at the fall of the unit tests.
- I didn't miss a commit or need to start the countdown again, but plans will have to be tomorrow.
- Instead I added a couple more tests and ensured LogEntry supports Equals, GetHashCode, and ToString.

#7.2. 4/18/2018:
- I typo-ed dates in my logs. I was panicking for a moment as I thought I somehow missed a day of work.
- Spent most of the time trying to see if I could get code coverage. It's something I look at work, possibly too much. Not because I'm required to, but because I want to make sure if I do anything. If I sneeze and hit a key on my keyboard, I don't cause errors. True story (sneezed, hit a key while typing a string. Compile worked, but runtime failed. Eventually found I was looking for the wrong input file). So, I write a lot of tests and want to make sure everything is covered.
- Long story short: maybe in the future, but not now. VS2017 Community doesn't support code coverage. OpenCover looks nice, but I need to make sure to have the correct command line. NUnit keeps crying it can't find nunit.framework and Google points to semi-relevant responses, but none of them "NUnit cannot find framework" so I couldn't do anything without spending much too long on it. Instead, I looked and found "dotnet test" will do the work without a hitch... except the only output format it supports is trx... and OpenCover doesn't have a clue what to do with those. And NUnit has had a year-long ticket open for adding support with exporting the test results via XML in the VS adapter. So it's one step foward and one step back.
- Planned to do some additional work, but will push it to tomorrow.

#8.2. 4/19/2018:
- Suddenly, nap. Thus: instead of doing the same task I wanted to do yesterday, I did something else: testing Equals, GetHashCode, and testing ToString(?) for LogEntry
- I tried something a bit different in I used a TestCaseSource input... then vastly overcomplicated it (see the code for why. If you don't see a complex test impl., yay?)
- I also learned about "TestCaseData" and wonder if I can/should use it. Right now I say "maybe" but will get tests working first.
- All this to get as much test coverage (sans using a tool that tells me the test coverage), so that as I do more work, I can ensure everything is working AND adding new tests is simply adding a test case rather then a whole writeup. Word of advice, taken from work experience (and it's written about enough in motivational blog posts): just start. In the case of unit tests, if I wrote everything and said I'll do it "eventually", it will never happen.
- The new challenge: VS/NUnit has decided that the 2 "Equals" tests I wrote for LogEntry are weird and did the following: made a warning/error in console about "converting" the tests, ran all the tests and said they passed, told me the two tests "did not run", told me the whole test suite didn't pass. Something's weird as I managed to get "pass", "did not run", and "fail" for the same tests at the same time.

#9.2. 4/20/2018:
- Ignore starting working on this late, I had another issue: God of War came out. Between that, Fortnite, and Parkitect (my current game collection), and a little thing called "life", I watched 8 hours fly by in an instant. This project must still go on... but a challenge:
- So I want to cover as many cases as possible. An ideal in programming, to me, is that something "just works" or works as expected. So if I create a LogEntry, I expect that I can stick them into a list. I expect I can "simply" print them out. I don't expect to use some custom formatter, LogEntryList, etc. In .Net, that means supporting ToString, GetHashCode, and Equals.
- C# makes it nice. Override those three functions, and .Net will keep running without a hitch. Don't override them and... things will still work, but you will hit cases that what you expect doesn't work, or that something might not work at all. Output a #6.2 version of the library to a GUI List and you'll find every entry is "LogTracker.Log.LogEntry" instead of a unique log message.
- Sets, Dictionaries, comparisions, ==, and many others all have the same challenge: they use one of those functions.
- But there's a different challenge: C++. I will continue to be adamant about this eventually being written in C++. C++ doesn't have the niceities of C#, so when I say "give me a set of LogEntries", it's going to ask me for something to print out the hashes of each LogEntry or hope the default works.
- So I need the values... AND I need them to work. That last part is where all the tests come into play. I want to test as many potential cases as I can without going crazy. (At work, our QA team has been working to do more "orthogonal testing" so it's not writing hundreds of tests).
- There were 3 sets of tests: non-LogEntry, LogEntry, and "complex" LogEntry. The first were accomplished with a simple array. The second required more details... and I wrote "TestObject" to be a nice wrapper for them. But when I've gone into the complex cases, it got, well, complex.
- I half wrote updates before realizing the test is not going to work as expected and will require a fair amount of rewriting. Instead, I'd rather figure out a good way to write these tests (that blends with NUnit?) so I can do my three sets of tests, but without the test itself going "easy, intermediate, hard" to implement.
- Doesn't help that I might have to do this 3 times: Equals, ToString, and GetHashCode.
- Bonus: I may have figured out an issue with tests yesterday. NUnit (or Visual Studio) use names to define tests. My helper class did a printout of LogEntry, which prints a date-time. Suddenly, all my tests pass. But then I run again a little later, and it's a _new_ set of tests, and some generic case claims it didn't run. BUT WAIT, there's more: I... scrolled down. I never scrolled up to see a couple tests were failing in general. That has been fixed, but the others haven't (and I haven't tested tests with the same name, but different classes, to see if they all show up or only one).
- For tomorrow...

#10.2. 4/21/2018:
- Yay, back to double digts in progress.
- I did a full rewrite of the Equals tests. Now with a builder for the test data
- "A BUILDER?!" says a set of devs... yes, a builder. The builder code is slightly longer then the "still in progress" TestObject (since deleted), but instead of `TestObject(arg, arg, arg, arg, arg, arg, arg, () => fancy work)`, it's closer to an explanation of what the heck it's doing.
- Also, the builder outputs a TestCaseData, which has it's own set of functions. So I'm able to utilize it to do additional work for me.
- Long story short: I can do more complex tests with less work. Only hacky element is adding attributes to the LogEntry to test against... it was either that, or make the whole thing Lazy and that would just be ugly.
- Minor refactor so test helpers are located elsewhere
- Now... fix the Equals functions so the tests pass

#11.2. 4/22/2018:
- A quick test laid to rest that "same name tests won't be shown as seperate tests". They show up with the same name, but indicate they have different sources.
- Attempted to setup GetHashCode tests... but a couple tests are failing...
- Attempt #2... this time, return the actual hash code. Somehow, the first attempt had 2 failed tests. This one has 8 failed tests. I don't know if testing hash codes is a thing. I guess it's worth testing, but I also worry about how Dictionary GetHashCode works. If it's implemented somewhere, I haven't found it. I worry it's producing some random results for me (attribute order?) but regardless, this isn't working and I can't figure what went wrong. So I'm going to trash it.
- Realized I test two attributes that are tested a second time later. So changed the Equals operation to get the values directly from the attributes, and to test the other values.
- I opted not to do a ToString, because the Printers will be doing the work, not the ToString.
- Now to ginally get back to what I really wanted to work on: TDD. I want to write all the remaining tests, without running them and without fixing the failures. Then test and fix failures...
- ...and I got 1.5 of 5 tests in before I need to call it quits. Sigh.

#12.2. 4/23/2018:
- Finished GetBy tests for LogRegistry. Technically still have to make tests for the actual implementation, but that's for another time.
- Nevermind. I wrote the remaining tests.
- Next up: ConsolePrinter. I want to test this over IOPrinter because it will actually be used. If something gets changed in IOPrinter, suddenly there will be X tests breaking, where X is every implementor of IOPrinter.
- Actually, writing that, I probably should do it for IOPrinter... Or at least have some tests "for" IOPrinter derived classes, but use the implementation (IOTester.Test(impl, outputGrabberDelegate)). This way I can run the tests on the impl, which will actually get used directly, and NOT have to write 10 tests the same way.
- First tests are... confidence tests. What if there are no logs, and just make sure I can grab console output.
- Both work, but the console output test is... not plesent. Can you imagine every test needing to check the NewLine? Probably be best to specify a new line...
- But wait, there's more! I was under the impression that NUnit ran in parallel (at work, we started non-parallel, then wanted tests to run faster, switched to parallel, and watched many break).
- As such, I wrote all the tests (at least I think so) with the expectation that they would run in parallel. Since the ConsolePrinter test would be changing the global Console.Out param, I couldn't have that run in parallel.
- I marked the test as NonParallelizable. Curiosity, I looked into it and... apparently NUnit doesn't run in parallel by default. Probably a good default, but it now meant that I wanted everything to run in parallel (unless marked).
- You can apparently mark assemblies, classes/fixtures, and methods as Parallelizable. I didn't want to go nuts right now, so I marked only fixtures (at an assembly level) as parallelizable.
- But there was no place to put the attribute. Generating the test project apparently meant it would generate the assembly info at build time... but left me without a place to put assembly level attributes. Luckily, diff tools to the rescue.
- There are attributes that tell the project not to generate the assembly info, and that left me with the ability to write my own.
- All is good in the world. Next up: writing the rest of the ConsolePrinter tests, and doing the work mentioned above.

#13.2. 4/24/2018:
- Specify our own newline, so changes in platform are easier to handle
- Abstracted IOPrinter tests
- Started working on IOPrinter tests... this is going to be either annoying, or complex.
- ...and would you look at the time. *cough* Yea, it's late (again) and I want to be able to focus on this then to be half-asleep while trying to ensure print outs occur as expected

#14.2. 4/25/2018:
- Started off trying to finish the IOPrinter tests. Made good progress, if not completed it.
- And... not feeling good. Occured just after I ate some food... that can't be good. I'm gonna have to call it a night early (unintentionally this time)
- One more, different sources

#15.2. 4/26/2018:
- Late day... probably should've done something before playing games.
- So right before I finished yesterday, I saw I had opened a tab about GetHashCode and it, like StackOverflow and others, basically said: if Equals is true, GetHashCode should too (hey, that rhymes).
- I added a GetHashCode test to the equals tests. If it's not equal, it won't test hash code. If equals, it will test hash code.
- After a short thought, I will add the GetHashCode tests, but they're simply going to be comparing the values. The && I was doing in the equals tests would mean that "equals = T && hash code = F" would tell me the test failed, but I wouldn't know where. Likewise, "equals = F && hash code = T" would mean we can have a colision between LogEntrys, but would never know because the && made it false. So a seperate test would be better. Will do this another time.
- I would've liked to start implementing the tests for ParserUtil (at least the InternalsVisibleTo is working), but as stated: it's late. And stated at another time, don't kill yourself over code. I haven't been too good at that lately. Make myself too busy.

#16.2. 4/27/2018:
- I'm still standing. Somehow. I could only spend a portion of time on this, so I started implementing test cases for ParserUtil.
- I realized part way through that I could use TestCases (instead of test) to vastly increase the number of tests without making the test file giant.
- (You don't realize the difficulty it was to write ^^. I need to go to bed. Late night D&D didn't help with being tired)
- For some reason, doing invalid tests resulted in CS0051 coming from C#. I tried changing the values, but C# continues to complain. When I didn't do TestCase, I didn't get errors... but I also didn't try compiling, so it may have happened there.
- Regardless, this kind of work should be easy. Just need to _not_ be asleep.

#17.2. 4/28/2018:
- Fixed the CS0051 issue with a test
- Added the string and int tests for casts.
- Was preparing to work on Key-Value tests, but realized it would be a bit more work then I have (the joys of working on this, late, again). I will do this tomorrow and start on testing the parser itself

#18.2. 4/29/2018:
- Right after writing yesterday's note about Key-Value tests, I realized "this is basically the same as the LogEntry tests, but with a different expected data. Instead of writing a whole new builder, I should just extend the other one."
- This was followed closely with "Wait, even better. Common logic in a parent class, then simplified top-classes". Then I was done for the night.
- I went about to do just that... and basically wrote a whole new builder. The abstractions are useful, as it will make it easy to create more advanced tests (I'm imagining XML parsing tests, and maybe GUI work too? We'll see when the time comes). The basic need is for tests that produce non-const data AND takea variable input.
- Simple input or complex setup means needing individual test cases. But complex input can't be compiled in, so it would need individual tests. But then it's a lot of copy-paste and/or a helper function to do the work. The TestCase attributes simplify testing.
- Casting Key-Value tests needed some additional helpers to make these work better. Also, adding an extension class made me very happy... because it meant that I didn't need to have some ever expanding base class AND it meant I could now do something fancy (see TestDataBuilderExtensions.For and explain how to do that in a base class. As in, C# syntax won't allow you to have a base class do some action and return a child class. But it can do it as an extension function)
- Now... the tests I came up with. Most are obvious, the last couple are going to be a pain. I put them in because I can easily see logs coming in that go "uuid=XXX-XXX-XXX; name=Smith; userData={\"name\":\"John Smith\", \"userNotes\":[\"I'm debating on if the data should be A;B;C or A,B,C. I need the result to be key=value and...
- ...that isn't going to be pretty doing a naive split right now. I'd rather the parsers NOT have to have to handle the complex cases individually. Instead, do it in the cross-parser utility classes.
- In addition, in keeping with "TDD" (notice the quotes, since I haven't been doing to good with it), I can plan these cases now and worry fix implementation later.
- It also sets up later implementations/tests such as "implicit parsing" (I don't have a better name). At some point in the future, I'd like to be able to get log data and, if the log data didn't have a specific type or there was a type mismatch, have the system determine the data type ahead of time.
- A parser (utility) that can split data without mixing up quoted data means that I can take the sample from above and do an implicit parse of the userData to JSON.
- I'm getting ahead of myself. I've spent a long time on making UT. I hope it all pays off in the end, so I can build and know all the old code still works.
- Also, these new tests broke the 100 tests count.
- I didn't get to the parser testing or ParsePath tests, but I hope to get to those within the coming days (one of those days will be catching up on movies, the other will be watching Infinity Wars. So I expect both of those to be slightly smaller updates in an effort to get to get enough sleep)

#19.2. 4/30/2018:
- So when I said "smaller updates", it ended up being very small.
- I started looking into the string split. This seems to be a perpetual problem with strings. Or at least I always seem to encounter "split a string, but if there's a quote inside the string, don't split on that"
- This might be something I spend one day on, then leave it for another time.
- In the mean time, I fixed the null case and added an additional seperator key (gut feeling is this should be a config value)
- I also added ever increasingly complex cast key-value tests...
- Note: I looked at https://stackoverflow.com/questions/554013/regular-expression-to-split-on-spaces-unless-in-quotes and it looks good, now I just need to use different seperators
- Note 2: These are the test strings that are failing because of quotes (without the C# escaping):
1. "key=value"="test=pain1"
2. "key=value;oh=boy"="test=pain1"
3. "key=value;oh=boy"="test=pain1";yep="this=pain2"
4. "let's \"use=more\" quotes"="oh boy"

#20.2. 5/1/2018:
- Oh snap, we passed our earlier "best number of build days"
- I started working on the splitting work. General idea is go through the string and mark the contents as either quoted or not. Then iterate through non-quoted and group everything by the delimiters that split up different vey-value pairs. Lastly, go through each of those groups to split it by seperator and create the key-value pairs.
- The hope is that reduces and simplifes the work needed without doing a bunch of crazy regex or writing one massive function to do the work (always a bad idea)
- Also, it occured to me: this is all overkill. I want to finish it as the above concept simplifes it to a point where I can focus on individual pieces of logic without needing to know the whole (though I've done the problem in reverse to get to the different "how" steps).
- If this doesn't work, then I'm back at my starting point. I disable the old logic, make a note to work on it (or maybe at some point add stat gathering and see how many logs actually have quoted strings), and move on. For now: one attempt.

#21.2. 5/2/2018:
- So I didn't mention it yesterday: one other reason I want to get this working is I always seem to hit this problem, but I never get a real working solution. If I can get something working, I can say I actually have a solution and can reference it whenever I hit this problem again.
- So a goal I had with CastKeyValueSplit function is to use data once. It was kind of a challenge.
- This is important to note, as I thought about how to do the next step (I got taking a individual group and turning it into a key-value pair. Now I needed to go from a single list of strings and turn them into different groups. Essentially the individual sets that make up a single key-value pair).
- ...it involved multiple loops (think: iterate; skip(x) then iterate; skip(x+y) then iterate). But I could only imagine iterating through a process, stopping, then doing it again but ignoring the results until we get to a certain point. Also, I'd need to count elements and a number of other variable creation steps to know where I was.
- So, how do I do it in one loop? Enumerator (instead of Enumerable). In order to make this work, I need to be able to return leftover data outside of the processing loop (GroupSplitExtractGroup) which would return an enumerable itself.
- C# doesn't allow yielding inside of yielding, so the seperate function was needed anyway. Wait, what's this error? I can't return anything in a yield function? Well this is a problem...
- ...one that can be fixed with a hack: class variables, like arrays, persist stack traversal. I've done this for years. It is a hack and a feature of programming languages. If this was F#, there are helper functions for enumerations that let me pass state. That would do the same thing.
- So now I define an array, save sepecific data in it, and move on. I did test it and it worked. I'm very happy.
- This may make that function non-thread safe... but only if multi-threaded/async work is done with the resulting iteration. I'm not sure and have no intention of testing it... because I have no intention of making CastField or CastKeyValueSplit async/multi-threaded.
- With that done, and working, all that's left is the QuoteGroup function. I talked with a friend who is into this kind of work and they simply stated "state machine". We'll see. It sounds nice, though I don't want to go that crazy if I can avoid it.

#22.2. 5/3/2018:
- I didn't actually get code done today. Instead of was trying to figure out what is needed to split the quoted elements from the string.
- A processing state or state machine would be useful. I can see the states being: Normal, Quoted, and EscapeCheck.
- The last one counts escape chars to ensure it's not a quote. \" is 2 chars. So if I encounter " but \ is before it, I can ignore it.
- States then are Normal -> EscapeCheck -> Quoted -> EscapeCheck -> Normal
- Tomorrow will be a short day as well.

#23.2. 5/4/2018:
- Before I ended all activity for yesterday, I thought "do I really need the EscapeCheck state?"
- Fast foward to today: I talked to the same friend as before, and they indicated all they needed was a single char look-ahead.
- I thought for a short bit and realized it would work. Though I can make life a little easier by looking behind instead of ahead.
- Looking ahead involves range checks, a complex internal state (if the char ahead of current is " and current is \, then add current AND next, then move 2 ahead. If not, then add current and continue). What's to stop trying to optimize by working two chars at a time?
- Looking behind simply means "check if it's \. If so, add char. Else, return"
- You'll notice the code is under 30 lines (excluding comments), including newline braces. There is a couple additional state elements to watch. I didn't want to return empty groups because the string was "\"", and some other pairs I checked.
- While testing, all but one test passed. After looking it over, I realized I mis-escaped the "correct" result. So I had to fix the result for the test, as the code worked just fine.
- Yay!

#24.2. 5/5/2018:
- I've been going through gui.cs (https://github.com/migueldeicaza/gui.cs) and it's pretty cool. If it wasn't for the fact that this project is _not_ going to remain in C# forever, I'd probably want to use it and see if I can extend it as a wrapper around either WPF or WinForms. It would be awesome to make a window, add a button, add a menu, etc. and... if it's running in a command line (or a flag indicates it's in command line), then run in the window like a Curses app. Else, open a GUI and run there.
- Maybe I can port it to C++... but I'm pretty sure that's what Curses and others are for. But a single UI framework for CLI and GUI would be quite nice.
- And... just found out the first version of it came out in 2007. o_o
- Slight more thought: it could be useful to basically clone the API (they aren't Oracle, and the license is MIT) and have the "driver" be able to switch between console and GUI.
- For C#, the Console driver will use gui.cs, while the GUI driver will use something else (or I'll have to write it).
- The upside is this abstraction lets me rewrite/reproduce it in C++. This way I can keep writting, the code, but now don't need to worry about the backends/drivers. C#? gui.cs and other. C++? Qt, wxWidgets, other. Heck (I both like and abhore this idea), in theory a small webserver can be started by a driver and "suddenly" the whole thing runs in a webpage. And by "run" I mean "the UI" as nobody in their right mind would use JS unless you're making a Todo app. Jokes aside, I'll note it but it's below every other task.
- One thing I got out of looking at the code, some of the newer syntax is useful. Instead of `public int Value { get { return _innerField.Value; } }` you can now do `public int Value { get => _innerField.Value; }` and if `_innerField` exists because you need to set a default? `public int Value { get; } = 1337;` I've not done C# in a bit.
- I updated some code with those new syntax nuggets.
- My intention was to work on the ParsePath function, but I couldn't figure out how to properly test it.
- NUnit doesn't seem to have something akin to "Does.Contain(<item>).AtIndex(<index>)" or "Contains.Item(<item>).AtIndex(<index>).And.Has.Property(<property name>).EqualTo(<value>)" or "Has.Member(<item>).With.Property(<peroperty name>).EqualTo(<value>).After.IndexOf(<index>)".
- That syntax could get quite ugly... but the alternative is to ensure "ParserPathElement" has an equals function and make a whole array of items then test the results.
- Challenge is the solutions I can think of has one or more of the following traits:
    - Requires a bunch of extensions that may or may not require NUnit to be updated.
    - Requires a bunch of work in the library/test set to enable writing a test.
    - Makes the test too rigid. It was a tip by a senior dev of mine: "If you write a test too rigid, every time you change the code and get the same outcome but it returns a different result, the test will break".
- The first would make me want to do the second instead. The second would possibly be a ton of boiler plate (or a IComparer) that would remind me greatly of the first attempt to write the equals tests for LogEntry.
- But the biggest worry is the 3rd case. The 2nd would imply the 3rd. The goal of the ParserPathElement is to provide a "path" to getting a piece of data out of what is generally a complex piece of data (logs aren't just a string).
- So if, for now, I say "Type, FieldType, StringValue, and IndexValue" need to be checked, then I realize that I can add a SubType for something, I can end up with tests still passing. But what if the StringValue is different based off the SubType? Like it's all lowercase or something?
- Now it becomes "all your values are wrong". Ok, fix. "Wait, I got a bug that & is not a char in Chinese. I will add a test for that". "Wait, I got the wrong Type now. Let me fix that" The SubType changes without me knowing. "Wait, now all the values are wrong again"
- The correct course of action is to add SubType checks. Guess what, now all the tests fail because SubType isn't set. Ok, set all of them. But am I now just mimicing the ParsePath function to get all the path fields? As in, writing a test that will always pass as the test comparision is written to the parser result?
- One more: what if I do some updates to ParsePath and end up never setting IndexValue anymore because it's never used in code. All tests with IndexValue now fail. Let me remove those tests...
- Back to reality: I'm now writing tests to always pass. It's not how it should work. Aside from some basic tests, I don't care about most of the contents. I just care about the last element.
- ...am I now writing a LINQ expression to get the last element or skip values (which doesn't exist as a modifier/constraint in NUnit either). I just want an index.. I want a "Last/First" option. `Is.First.Item(<item>)` or something.
- I feel like I could ramble on about this more... obviously, this isn't as easy as it could seem. It could also be that I'm overthinking it and just doing the LINQ expression/getting the value from the array is the easiest.

#25.2. 5/6/2018:
- Today ended up being suprisingly busy... so I didn't get much done.
- As my day was short, I wanted to do _something_ and my "rant" yesterday left a bad taste in the mouth. Basically: I'm unsure and possibly dissatisfied with how one is supposed to test an array of structs/classes without manually testing values.
- Two great pieces of advice I was given when I first started coding: 1) don't be afraid to delete your code. 2) Sometimes, brute force is the most efficent way.
- #2 is more true then people think. How much time has been spent on optimizing a function, method, process that... will only get used once? Or infrequently? (note: there is an inverse of this too. Not optimizing something because it's not used frequently. Often has to do with complexity and time spent on it. Like manually running tests...)
- In this case, the simplist way to do this is... to just manually interact with it. No fancy syntax. No updating of NUnit. No equality functions and tests to check them. Just write a bunch of tests and figure out optimizations once you've had to write something 40 times.
- In this process, I realized if someone wanted to manually specify field type for a string, it wasn't possible. I also realized not everyone would get the type names easily (Java dev will say boolean, C#/C++ would say bool, C would say BOOL), so I added some aliases and luckily already had a ToLower written in.

#26.2. 5/7/2018:
- Started working on individual field tests for ParsePath.
- Not too much to say today. Only a few more tests to write for ParsePath, then the last software element: the XML parser (which will probably be the largest test set of all of them)
- If there's one thing I realized: You can create this "path" but none of the values let you specify a name. I have a "named field" type, but it's under the expectation that the root log has a set of attributes that can be accessed. Reality is, it may not. Indexes don't work unless order is guarenteed.
- So <root at="hello">Message</root> and {"at": "hello", "msg": "Message"} can both be parsed, but <root at="hello"><Primary>Message</Primary><Second>Other</Second></root> and {"at": "hello", "logs": {"Second": "Other", "Primary": "Message"}} would not be parsable.
- Now, if I had a named field, I could say "/!Primary" and "/!logs/!Primary" and they would be parsable. Unlike the other tests written for the parsers, where I checked the code for what I could do (parsers are "fun" in that they aren't obvious)... the named field tests I intend to write before I implement.
- Last tests after that is to actually make some paths. I may try to take advantage of NUnit's randomization so it can make random paths to test against.

#27.2. 5/8/2018:
- Goal: finish ParseUtil.ParsePath
- 1. I need to be able to parse named fields... but I wrote the test first, and it indeed failed. I implemented the code (easy...) and it passed.
- 2. Parse an actual path... this was more tedious then tough.
- I have the unit tests generate a seed, then I use that in a Random number generator. This way the results are always reproducable, yet easy to be different.
- Next I need a path... and the data I plan to test against. It's easier to just look at the code then for me to explain.
- I also needed to test type... but only sometimes.
- Path creation requires variable lookup (for simplicity sake), but I want to ensure I don't miss a value. So I wrote a test to make sure my data sets are good. :D
- Now for the actual test: generally easy, especially since the "test" portion is basically a Builder type. I could do it in sections.
- And... it works! Yay. Means I get to move onto something else, and simple debug output means I get to double check it's actually making a path. (it was)
- Tomorrow starts the fun task of an XML parser. This will be interesting because of the complexity of writing tests for a parser AND the fact that the ParsePath util has just enabled me to create some pretty complex paths.
- I know that the XML parser pretty much doesn't let use a filter field for anything except the last element. It was written like "now that you have the field, you wnat to double check it's type". The reality is, between the possibility of a mid-path filter and the addition of the named field, you could end up with "filter to only XML elements, now give me 'UserData'".
- It makes me think "I need to keep a collection of child elements" instead of what I do now.
- But that's for tomorrow-me. Today-me is done.

#28.2. 5/9/2018:
- Today was namely looking at the XMLLogParser and figuring out what can be tested, and what should be tested.
- Tomorrow I will start working on SetConfig, which will be a little weird because it doesn't "do" anything. It affects how Parse works, but I don't want to go testing Parse to test SetConfig.

#29.2. 5/10/2018:
- VS 2017 15.7.1 came out. After updating, the Test Explorer showed tests as a hierarchy instead of list a list. It make me realize that the ConsolePrinterTests and IOPrinterTests were in the wrong namespace. Fixed.
- Otherwise, I spent nearly all night working on a different programming project. Can't release it for reasons, but I can say if you ever need formalized JSON, JSON-schema is pretty good...
- It's now too late to really do anything except look at the XML parser and go "this needs some work to make it usable for testing"

#30.2. 5/11/2018:
- Realized one change to make the XML Parser easier to test: don't require a file to read.
- I like extension classes. I used them a bunch in C# before, then mainly went over to C++... and now working in C# again, I wish more languages had them. Core functionality in the class, then all the nice "I wish it had function X" in the extension class.
- As such, file parsing is moved to the extension class.
- As for the tests... it's too late for me to be working on this stuff, but I was at least able to squeeze in a basic test.
- It was a catch 22 for me: in order to test the log parsing, I need to ensure SetConfig works. In order to test SetConfig, I need to parse data.
- One solution is the provide "get" functions for config data out of the parser. But I like the concept of a black box. I don't want to know what it's doing, I just want to provide it parameters and tell it to go.
- So providing a config and a registry and then saying "here's a log. Go" is nice.
- So basic test is just an ideal, minimal case of what to expect. I will try to get more done tomorrow. I just need to not do it late...

#31.2. 5/12/2018:
- Timing: still not working for me...
- Finally got the SetConfig tests. They're peusdo parsing tests, but only to ensure that the config values are getting used.
- If there's one thing I thought I needed, it was a multi-log test. I thought this because in my mind I thought "some logs could be "bad" and we want to skip them. So I need a test where we parse 1 and 2 logs. A test where a bad config results in no logs. And a test where a bad log results in missing logs. I need to ensure bad config and bad log are confused..."
- Reality is: right now, implementation would simply stop parsing/ignore attribute on a bad log. So there is no way to confuse them.
- I added a "todo" in the source for adding a config or some bit of code for handling bad logs without stopping parsing.
- But a weird thought occured: what if, instead of ignoring the log message (which could become confusing), we created an invalid log AND only populated the values we knew? That way, we can have a config that stops parsing all together, skips any bad logs, AND still parses the bad logs but marks them as bad.
- I like configs. It allows custimization (wow, can I not spell... I should spell check this whole document) without adding a ton of complexity. "Um, it adds complexity" then you're doing it wrong. "We accept one type of value as a key, then look for it in a dictionary" -> "we accept a customizable path to find the value, then we wrote a function that does the search". Suddenly, `dict[key]` -> `getValue(dict, key)`. You have added custimization without complexity.
- of course, there are a tone of arguments that disprove my example. But I still think there's more value in adding the custimization then not.
- Needless, the set config tests are done, and the Parse tests (including sub-tests) are next.

#32.2. 5/13/2018:
- I changed the couple tests that didn't need the double-log elements and replaced them with single-log elements.
- I also wanted to fill out the SetConfigAdditionalAttribute before moving onto Parse.
- Ahem, it took me the whole time just doing that. So no Parse tests yet. (the following is a near play-by-play. Summary is that I wish C# had F# levels of type inference and design decisions can sometimes make things like tests a pain)
- I made a concious decision to not just have a dictionary for the LogConfig. I would have to write code to normalize the names (probably just ToLower), the config files wouldn't be meta ({ "attr" : "value" } -> { "configs" : { "attr" : "value" } }), it would be easier to spot log issues at a glance (both with a debugger, and if you looked at the meta log, there would probably be more attributes then "configs").
- End result, I was trying to make this nicer to use. If I changed it, for the sake of a test, it would be more of a pain to use while the test that gets written once gets a few lines of code removed. Not worth the hassle.
- This backfired on me since in order to do the test, I needed to set config object properties. The resulting attribute values and the property names are not 1-1. The attributes are to be generic between numerous uses, while the config is supposed to describe what it is. So "SourceFile" is "SourceFilePath" but "SequenceNumber" is "LogSequencePath". There is a method to the madness of naming, but it could probably use some cleanup.
- So now I need to set these values. There's a good description I've seen that looks similar: "novice: brute force. professional: elegent complex solution. senior professional/expert: brute force". The novice reads materials to get to the professional state, and if they look at .Net, Java, JS, and others, they will see they can do reflection or class prototype manipulation. Reality is... the brute force approach is 5 lines, while the fancy and elegant solution is 150 lines spread across 7 classes and 2 utilites.
- What I really desire is for the ability to add one attribute to the LogConfig, specify what attribute it gets set to, and never have to set a test, log parser, etc.
- For now, I'm not there. cleanup of names and maybe it will be possible with a 5-10 line reflection helper function...
- Back to the point, I needed to get something to set the config and be associated with the attribute. A tuple will do... but I'll need an Action<...> to set the config or to do reflection (with a dictionary of attribute -> config name). I don't want to do reflection, so Action it is.
- I made LogConfig a struct... so I need to return it. Now it's a Func<LogConfig, LogConfig>.
- This is somewhat generic... what if I want to do a pairing or something ("attribute, value" + Func<...>) or more likely: blackbox. I don't want the test to know what is being done, I just want it to say "log, you have attribute X. Set config. Test, did you find X? Great"
- ...so I need to be able to set a name. Now it's `Func<LogConfig, string, LogConfig>`. Ok... so now I have `Tuple<LogAttribute, Func<LogConfig, string, LogConfig>>` as my type. Cue gag reflux.
- I make an array of those and... `new Tuple<LogAttribute, Func<LogConfig, string, LogConfig>>(LogAttribute.ThreadID, (conf, name) => { conf.ThreadIDPath = $"!{name}"; return conf; })),` Cue gag reflux again.
- I know, I'll make a simple helper lambda so it's readable. Instead of "types, types, types, types, actual content that you miss because types, and more types", you just see "lambda(enum, func)"
- Well, C# can't seem to do typer inference as well as I'd hope. so `var makeTuple = (type, func) => new Tuple<LogAttribute, Func<LogConfig, string, LogConfig>>(type, func)` becomes... eh, just look at the code as of this date.
- I write a whole set of comments on what this would look like in F#. With the exception of the printfn, it would be a lot smaller and cleaner.
- I learned F# for a job some years ago. It, or OCaml, are good languages to learn. If you think "I'll use Swift or some new fangled language", I can tell you from experience that you'll like them... and then if you use F#, you'll wish those languages had the same features as it. It's not perfect, but it takes out a lot of the pain of programming.
- If you actually do functional programming, instead of using a functional language to do imperative development, all the languages tend to work better but F# still comes across as easier to work with IMHO.
- Stepping back a bit: experience seeing and using multiple programming languages at this point, even if the language designers came up with the idea without outside influence, I see this:
- F#/RD groups -> (~0.5-1 year) C# -> (~0.5-1 year) Other .Net languages -> (~0.5-2 years) Python/Java -> (~1-4 years) C++/JS -> (some amount of time) "other languages"
- From async/await to Rx, LNIQ to Generics, Implicit state machines to multi-generational non-blocking GC: F#, C#, and .Net have been very far ahead of language functionality compared to other languages.
- I've heard JS devs talk about (this was a year or more ago) how in a year or so, they'd be able to use this new thing called "async and await, so we don't have to do Promises anymore". I first started using those 4-5 years prior.
- This writeup is too large... basically, I got annoyed at what had to be written to make the test data more readable, it's not gonna be any better in C++, but I with that timeline would occur faster so I don't have to type out nearly all of this.
- If one thing came to mind, it's that it might be useful to have LogConfig to have a static function for getting all the parameter names and what attributes they're associated with. I don't really want to have it do reflection, but the returns values could be useful for functions that are only executed on one-time, minimal-use functions. Would at least apply to XMLLogParser.SetConfig

#33.2. 5/14/2018:
- Realized that SetConfig uses a helper function and wanted to ensure that it gets tested.
- Started work on Parse tests... very quickly got to the end before realizing that my previously described failure tests were what I really need to test. Because the only things besides those is the failure tests, path tests, and checking files can be parsed.
- I have improvements I want to make to the parser (like streaming) but it's not time for that yet.
- Fixed the couple test failures I hit. That's it for tonight.

#34.2. 5/15/2018:
- Lost track of time. Only thing I really got done was adding a static function to get attributes and their associated "path" config.
- My intention is to use this in XMLLogParser.SetConfig with some reflection. I don't "need" reflection, but the implementation could fit into the same space it occupies now. Benefit is that the log parsers don't need to be touched when new attributes are added.
- The other reason I'm fine with using a bit of reflection is because SetConfig should not be called often. Reducing performance worries and adding complexity for the sake of coolness.

#35.2. 5/16/2018:
- Went to add reflection and... found out that nearly all the useful attributes in Type only exist in .Net Standard 2.0 and up.
- Do to some weird bug... somewhere, when I first started the project (never had a need to mention this), it defaulted the .Net Standard versions to 1.6. I updated everything to 2.0. But while everything compiled, it wouldn't execute. It complained about .Net Standard version mismatch.
- Needless to say, I didn't see a need to use 2.0 at the time, as much as I wanted to. Now I do and, luckily, it compiled and ran. I don't know if it's a newer version of VS or something. But no more crash on startup
- Added the configurable failure handling enum and unit tests, but haven't implemented yet.
- Also added more combinations for "LogConfig.IsValidValuesTest"

#36.2. 5/17/2018:
- So today I wanted to add the enum for failure handling. Along the way I had a couple ideas and remembered something...
- First, one of the failure handling options is to parse the log, but only the attributes it knows about and can parse. I call these "failed logs"
- To test if a valid log or not, I added IsValid to ILogEntry. Simple, but effective. I expect it to be a shortcut for "do I have to pay attention to what I'm doing, or can I expect that some values will be there?"
- But in order to have a failed log, without setting a variable, I need to register a failed log. Thus, ILogRegistry.AddFailedLog
- I also happened to start documenting these... I'll see how I do later on.
- While doing this, I remembered "Oh yea, I don't know the source of these log entries. I just know they exist". But I also stopped myself from giving myself more work to do right now. I can probably add that after I get failure handling added and either do or start working on the other parsing tests. Info noted in LogAttributeEnum as that's where I'd need to add an entry and what to do with it.
- I added a few additional tests and finished the failure handling tests... which don't work right now as failure handling hasn't been implemented. But that's for tomorrow.

#37.2. 5/18/2018:
- Ok, it's been a long week. I got home and fell asleep. But because I've been commiting the following day, I'm just really late on this... (I repeat "don't kill yourself for code", and didn't plan for falling asleep)
- Mainly, just wrote the unit tests.

#38.2. 5/19/2018:
- Started working on FailedLogEntry. I say "started" because as I started working to integrate it into the registry and update tests, I had a bunch of questions...
- Good questions, like can I compare LogEntry to FailedLogEntry? What about Equals?
- It's a good start, and I like some of the ideas. Also, adding this functionality means the failure handling can work as a developer intends. Or maybe, how the log source can be used. A single log may want failure, multiple file logs may want to skip, while a log stream may want to attempt to parse.
- ...and the handling questions will allow that to work without any "oh, BTW, the Equals function doesn't work if you set this one global value". It shouldn't care about your config.
- I also learned that `Property { get => "hi"; }` can be simplified to `Property => "hi";`

#39.2. 5/20/2018:
- My intention today was to figure out CompareTo, ensure support in LogRegistry, and get some tests working.
- My computer decided that all IO devices would no longer function. I got out my backup keyboard and mouse  (aka, spare) and tried those. Still didn't work. I'm literally sitting in front of my computer, with a laptop, remoted into it to write this info.
- As such, I haven't gotten all that done. I realized CompareTo is probably not the correct thing to implement because I'm only doing a single-field comparision, and it could be easy to mistake CompareTo == 0 meaning Equals == true. Since it's more a domain specific task, and it only happens inside LogRegistry, I decided to do the comparision there.
- By the time my IO devices failed, I realized "this still isn't right". Because the comparision is used for insertion, and failed logs won't have any fields upon addition. So the comparison will always follow the same path.
- I don't want to fight with the computer right now, so I will do that work tomorrow. Unit tests passed, so it's at least at feature parity.
- I wrote it at an earlier point, but one interesting aspect I'll have to write is lazy/post execution of sorting the failed resources. My head says "threadpool function to do the work when it has time, started after parsing ends" my gut says "when a parser is done, operate then". But for streams, this won't work as it may never end. But a threadpool is a bit much. Perhaps I need to be smart and if it's a stream, I need to do the parsing on the fly (with locks and all), but if a file, just do it when parsing finishes.
- Reality check: just run when done for now and figure out fancy, smart, whatever term... (the word of the year is "AI" as "machine learning" was so 2017...). It also begs the question "what happens if we don't execute it or forget to?"
- Tomorrow...

#40.2. 5/21/2018:
- So "what happens if we don't execute it or forget to?" Nothing, for the most part. The only time it has any effect is when GetByTimestamp is called. Because we don't want to to return a failed log that has no timestamp OR has a timestamp and hasn't be sorted properly.
- Only thing I don't like is doing a simple iteration to find the failed log. Involves something I had very early on: an ID. I worried that just doing equality checks would 1) be slow. 2) Could result in two of the same logs being confused, but because they were classes, the wrong log could be returned.
- With that done, the solution for "how do I know when it's done?" was to just have a function that notified the registry it was done. This would allow it to do any additional processing if needed.
- None of this stuff would scale to streaming logs or, if needed, threadsafe.
- In addition, IMutableLogEntry was originally intended for "I want to be able to modify some logs... period" and now it's expanding to an internal/LogRegistry ILogEntry... probably time to rename it.
- In other news: tests before impl was good, as nearly all those tests were done by the time I did the implementation, and now I know that the only thing that needs work (because it wasn't implemented yet) is the parser itself.

#41.2. 5/22/2018:
- I ran out of time today... but one thought that came up yesterday was that interaction LogEntry and FailedLogEntry are, and should be, only done through ILogEntry. As they are generated types, and both implement IMutableLogEntry (which requires renaming), let's move LogEntry and rename IMutableLogEntry.
- Moved LogEntry into "Internal" and renamed IMutableLogEntry to... IInternalLogEntry. It's only "supposed" to be used by internal types, so I made it internal/package (I could probably set the access modifier to internal, but IIRC (it's been a bit), internal allows access from the entire assembly when the only elements that should care are LogRegistry and the log entries themseleves)
- Want an example where unit tests are good? Ok, it's not a great example, as it was a failure of the unit test itself: the mocking library failed because it couldn't see internal types. But I wouldn't know why if I didn't have the tests.

#42.2. 5/23/2018:
- Tasks for today: support failure handling, at least make the function for "config context", and ensure existing parser tests work.
- I got 2 of 3.
- The one that didn't work: existing parser tests. If you run this build, you'll find that everything worked... because I realized I wrote a couple tests wrong and "fixed" them but now they're no-ops for all intents and purposes. So I need to fix them.
- Failure handling: done (simple refactor and making 2 functions: one for handling the good case, and one for the bad case)
- Config context... this was what I mentioned some time ago (or at least wrote a code comment for) where you could specify config values for a temp parser.
- Why? And what's with the name. Name: I couldn't think of anything better. It's a config... within a limited lifetime.
- Why: Parsers are unlikely to be "lite", and could vary on backend implementation. I have thought for a bit that larger log parsings would do better with a database, not a sorted list. What would be more efficent: opening 40 databases and then needing a system or method to sync them, opening 40 database connections to 1 DB and invoking everything async/locked, or opening 1 database connection with 1 DB and doing interaction with async/locked?
- My guess is the last one. First one: heck no. Second one: eh, each request would be async, but now it's network/io async instead of local statemachine within an application.
- So maybe instead of CreateParser(src1), CreateParser(src2), CreateParser(src3), etc. we could just do CreateParser(config) and then invoke parser.Parse(src1), parser.Parse(src2), parser.Parse(src3), etc.
- Wait... that's what we did. The problem space is how do we set the log source? (a file, a network stream, hostname, etc.). What if a file log we just want to stop parsing on bad entries, while a network we want to skip them. Now do we have to create multiple?
- This is where the config context comes in: set the config values you want to use for a specific "context" and then go. Internally, all details will be taken care of. Continue to be async or threaded, maybe chain together contexts once the data is known.
- In implementation, it allows reusing a potentially expensive parser to do lite work. I can now have 40 shims lock and unlock a mutex before adding to the list, or sending a DB command. I can do the per-stream failure handling.
- And by putting the return in a context instead of an IDisposable or similar, I know it will go away and not be forgotten.

#43.2. 5/24/2018:
- Late... again...
- After thinking about it a bit, I realized that the bad test wasn't actually bad. It was testing the parser, while I was expecting the registry to do what I was expecting (removing log entries)
- Now, the parser test was still useful as it tested "there is an element, but it's empty"
- I would add a count test, but it's really late for me so I'm going to have to put that off to tomorrow, along with writing tests for ApplyContextConfig
- I did manage to get the log file test added to ensure the file streams work.

#44.2. 5/25/2018:
- It's that time of the week where I just want to sleep. So a quick one today...
- Added a log count and tests for the work. Gave me a reason to remove a log that has no attributes.
- I wanted to save some time tomorrow... so I wrote the tests for ApplyContextConfig

#45.2. 5/26/2018:
- My attempt to save time yesterday... saved time.
- With those tests, I had an idea of what to implement for ApplyContextConfig and went about doing such a thing.
- ApplyContextConfig is now implemented. Not the cleanest method, but it does what it needs to do with minimal work.
- The biggest challenge was all the parser paths. How I see it - Naive: pass everything as different variables. Intermediate: pass seperate class with configs. Best: just reference the main class instance.
- C# has class and struct. Classes, when passed as arguments, are always by reference. Structs are copied.
- As I didn't want to make a copy function for the configs, didn't want to need to populate a config class that could be cloned numerous times or would never be cloned at all
- What I did:
-- parser paths are the only thing constant between everything, and I don't want to clone/pass a config class just for those... so I pass the parser itself around.
-- Specific config values change only when ApplyContextConfig is used, so put them into a struct so I only need to update the copy-on-set instance.
-- Since ^^ config is copied through arguments, and it contains a dictionary (one value for now, but could grow) that needs to be cloned and updated, use a struct to cut the copying to just the dictionary (which I can do if the variable is set)
-- Move all parsing functionality to static functions
-- Instance functions will use defaults when calling the static functions
-- All "context" usage will use their own config data for invoking static functions
- In the end, tests passed, thought of at least one additional one, and it works as planned and desired. I also like the idea of stacking contexts, if desired. Allows for some additional flexability.
- I'm done now... I keep adding/updating parts of this code. Thinking for a moment. Then removing them because they are not needed. Reduce, reuse(, recycle?)

#46.2. 5/27/2018:
- Simple work today: started working on the tests for path usage within the XML parser.
- One question that comes to mind is if "paths" should be generic enough that you don't need to know log data, or not.
- Like: if you end up mixing JSON and XML, or maybe XML from multiple sources, should you specify the same path OR specify multiple configs?
- I'll think about it tomorrow...

#47.2. 5/28/2018:
- So I failed to think about yesterday's question... something for tomorrow.
- I wanted to finish the parser unit tests, but just lacked the interest tonight. I finished non-combination unit tests though.
- Another question that came up (and I determined) was how filters and similar should work. Basically: everything operates on the children of the current node, unless it doesn't have children, and then it operates upon the current node.
- In this way, if the dev filters all elements, it will remove any child node that isn't an element... but if there is no child node, then it tests the existing node to determine if it is an element.
- Do the same for each path type and you'll end up with lists of nodes. It's like tree traversal, done level by level. If more then one element exists at the end, it takes the first. Assuming the XML isn't randomly output, the parser will always read it in the same order.
- It makes the system a bit more generic which means it can probably do a bit more complex processing.
- I also realized that the named node idea, using the "if no children, use self" could apply to attributes and the prior "!<name>" becomes a shortcut for the root. So now a child node with attributes can be accessed.

#48.2. 5/29/2018:
- Finished the unit tests(!!!)
- Used "confusing XML" on self. It's confusing...
- I'll work on making the tests pass tomorrow. I worry that some failures are because I'm not using NSubstitute correctly.
- So, the question from the 27th... my thought is: maybe. I say this not because of indicision, but because the only thing that isn't generic is flters.
- But filters vary by parser... isn't that the question? If those should be generic?
- XML types (that matter): element, text, cdata. JSON types: object, array, string, int, number, boolean, null?
- (XML and JSON are the two types I think _need_ support)
- Now... the only overlap I can see is `text` <-> `string`. You could argue `cdata` is also similare to `string`. But `cdata` is not the same as `text`. So you can't do a real equivilance.
- You could do `element` and `object` in theory. Though that too could be `element` and `array`, but `array` and `element` don't work.
- So if I went with generic, it would be: object, array, string, char-array. But it leaves out JSON types or starts to say the same types could be the same, which makes things... weird.
- I'd end up with needing a generic value type for the non-generic filters. Or to make the generic filters optional. I read an article a while ago that discussed "the power of defaults"
- ...but I have also learned a less talked about development strategy that I bet you've never heard of: copy-paste.
- Now combine the two and think of the outcomes:
-- Generics only: people will write generics, docs will need to mention you can do non-generics... but people won't know when to use them or those that need it will have no need to speak about it.
-- Non-generics only: people will ask why generics are needed...
-- Mixed usage: people will pick the first examples or the shortest to type
-- No docs: someone will figure something out, and it will become the de facto standard for how everyone writes configs.
- Common theme: people will take what is shown and copy it for their needs. Other types will be left by the wayside.
- Easy solution: the technical one. Instead of adding more complexity, just don't do generics.

#49.2. 5/30/2018:
- Failing tests: 15
- Rewrote path traversal function...
- Failing tests: 14
- Well, it's something. The most confusing aspect is probably my "test child nodes OR self if no child nodes" because it can cause the nodes to process to "collapse".
- So you have <parent><child><data>value</data></child><child data=value></child></parent> and you do /$elem/!data. First node to process is <parent> and it results in two elements, the two children.
- Now we go to test data and we get
-- Named element "data" from the child nodes of <child> #1
-- ...there are no child nodes in <child> #2, so check for attributes. You found one named "data", so return immediatly.
- Now, with a slight change, the node list becomes: <data>value</data> and <child data=value></child>. We've collapsed the tree a bit... but is it correct?
- Right now, because the unit tests aren't passing and some of them should (even before I had rewritten the path function), I think I'm using NSubstitute wrong... so I'm gonna work on that tomorrow before I try to fix the function more.

#50.2. 5/31/2018:
- 50 days! Half way (and I spent 48 days just doing unit tests. 50 if you count what I did when I restarted my counter... more if you count trying to get unit tests working prior).
- Code will come. These are the last tests for the most part.
- A moment of happiness: I decided to figure out what was going wrong, I needed to debug a unit test. The results I found online... basically said I needed a couple more Nuget packages, manual setup of a debug execution setting, and to run everything... and then I saw the blog was from 2004, then 2006, 2008, 2010, 2012...
- That last one (https://stackoverflow.com/questions/4103712/stepping-through-and-debugging-code-in-unit-tests) gave the exact breakthrough I needed: Test -> Debug.
- That simple bit of info meant that I was able to find out... I forgot to parse "Text" types. So I handled elements and cdata... but not text. 3 lines later, my failing tests went from 14 to 4.
- Couple more small fixes and fixing a typo in a unit test: everything is passing!
- Next up is... the stuff on the Tasks.md list... for tomorrow

#51.2. 6/01/2018:
- So, I didn't have a lot of time tonight, and I procastinated on doing this last night... but the refactor tool made it very easy: changed from LogTracker to Stethoscope for the namespace.
- I'm still not entirely thrilled with namespace, but LogTracker cornered the dev into one use of the library (to track logs) when the library itself can do more then that.
- Also, having the name of the library in the namespace probably makes it less likely to confuse with something else.
- That's all for tonight...

#52.2. 6/02/2018:
- Original plan: read through all the prior logs written here and determine if I have new tasks to add to the Tasks.md page.
- I'm very tired, what's less likely to put me to sleep?
- Making LogRegistry and XMLLogParser thread safe
- LogRegistry: not too hard... until I realize that the get functions just operate on the array... not something you just want to lock up
- XMLLogParser? Doesn't really need to be threadsafe since each operation is unique and it doesn't operate upon itself, but config and registry changes could require some locks.
- On that note, the printers also should have locks on the setting the config and registry

#53.2. 6/03/2018:
- Yesterday I started working on thread safety, today I got stuck on thread safety
- Note 1: I learned long ago that mutexes, at the speed a computer operates at, are not fast. Something like a monitor is better even if it takes a few more lines of code to build. There will always be a place for mutex, you just need to know where.
- Note 2: Faster then a monitor: just not having locking contexts... use atomics. It happens at the processor level and is much faster then anything else you can work with.
- Two issues:
-- 1. Registry iteration won't work if a log is added mid-stream while iterating, regardless of iteration location. For one, the current List implementation will throw an exception during iteration as it's been modifed.
-- 2. Log parsing relies on config attributes... that could change if the config is changed. Luckily, the values are copied for the most part.
- For #2, I planned to count how many parse operations are occuring at one time and, if config was active, not allow/delay the parsing. If parsing was active, throw an exception from the config functions.
- But while typing this I realized "the config functions aren't exposed". ILogParser doesn't expose the config functions (and neither does IPrinter), this means that the "proper" way to call those functions is to have the factory invoke them, and it invokes them before returning the implementations.
- So if anyone/anything uses them later, they're on their own. I won't try to control "advanced" or naive usage of those classes.
- That solves #2, but what about #1?
- Turns out... it's not easy, but it gives me a way to do something I have wanted to put in: Rx (observables).
- By using Rx "nearly" remove all worries of "what happens when we have millions of logs?" because Observables don't store the data and are a programatic method of doing iteration without "you removed/added an item mid-rexecution".
- In some apps, that might still be a problem, but for our usage, if the processing is past the point processing, then we don't care. If it's before, then we get that value (or for replays, we get a new value in the replay).
- This will require a custom Subject (look up "Subjects" in Rx/Observables) so we can insert values mid-stream. If/when we switch to a DB or similar to store logs, then it becomes "can a DB query get values mid-query?" if yes, then great. If not, then so long as it simply skips over it, it doesn't have any effect. So it's a win-win.
- The end goal is to allow multi-thread add/read of logs without exception. Since constant adding of logs could make it so that iteration never ends, we can't put a mutex or lock into the iteration code. Also, async-iterators are... not that great: https://codeblog.jonskeet.uk/2009/10/23/iterating-atomically/
- Past experience with Rx tells me that replacing with lists with iterators will make changing to Rx really easy... and we already switched to iterators, so this will be easy.
- Minor benefit: Rx exists for numerous languages, which means that we can move it to a different language later.

#54.2. 6/04/2018:
- Goal was to start working on switching from iterators with exposed classes, to observables
- Mostly succeeded. I didn't update GetLogBy or the storage within LogRegistry, but nearly everything else is done
- Only problem that was encountered was one of the logging tests failed because the outer subscription (threads) runs before the inner subscription (logs) finishes
- I also had to place some weird methods for converting from observable to enumeration in registry tests, first so later removal makes it apparent what needs to be replaced, second because NUnit doesn't support checking Observables and I wanted to switch to observables before doing any work for nunit so they'd be understood.
- Tomorrow's goal is to get the test to pass, finish work on LogRegistry, and then maybe move to the NUnit Observable support

#55.2. 6/05/2018:
- So the issue I encountered is that observables are pushed based. It's by design... but I had written a "nice printer type" that expected everything one-at-a-time.
- Changing to observables made this apparent now, rather then at a later point when items would've been designed for a pull-based (enumerations) system.
- Observables also force async, though it's somewhat transparent though some "ObserveOn" functions will probably be needed later.
- To the point, I did a weird trick to get the observables to be provided in a one-at-a-time manner and, since the existing concat functions would've simplfied the grouping observables to just the values, took advantage of C# 7's pattern matching syntax.
- If discriminated unions existed in C#, I'd use that since then I can just match on expected types instead of hoping for specific types.
- Speaking of pattern matching, I implemented that everywhere else where it could be used.
- I also do one more update to LogRegistry so the grouping function would use observables.
- I planned on switching the backing storage of LogRegistry to use observables, but I knew that would take a while and it's late right now and I don't want a repeat of yesterday (that work took 3.5 hours because I was re-learning Observables while implementing them, trying to find the documentation that I wanted (it used to be good...), and I progressivly get slower as it gets later)

#56.2. 6/06/2018:
- So I spent a bit reading through Rx and thinking: how do I replace the array of elements
- I came to the following requirements for the storage: I need it to replay, sorted, and "lossy". I also wanted to be able to count the number of log elements, clear the logs, and it needed a better way of handling "buffered" content.
- Why for each feature?
-- Replay: kindof obvious; need to to be able to go through logs
-- Sorted: This one will be needed when GetByTimetstamp is needed, and it's easier to sort on insert then at runtime.
-- Lossy: This is just the name I gave this... basically, given the nature of observables, if a new subscription occurs, it should replay everything. But if an existing subscription is in use, and it's getting data, and a new log comes in (say, from a new source) and has a timestamp earlier then what we've iterated on, then ignore it. We don't need to revisit the past right now.
- Clearing is easy, counting is mostly easy, and the buffered content is just to handle failed logs until the registry is notified of there completion.
- Once I realized the work is gonna be a long time, I decided to deplay it to tomorrow. Instead I did the long running "let me read through old 100DoC logs and see if there's any todos I missed". There weren't any.
- One realization is that I may have to implement Queriable, or for observables, IQbservable. I came to this because replay is easy (so long as the data is small), but sorting an observable is nearly impossible. I could stick to the array and just do AsObservable, but that's gonna get weird once we insert something mid-iteration. Maybe it's already "lossy". But I could also go to a database...
- Then my mind wondered, and I realized maybe a sub-class for specifying the storage system. List (default), InMemoryDB, FileDB, Auto? (which would switch between them as time went on... it sounds cool but probably not)
- So... if I have a DB, then I can simply request a sorted list. But wait, I've wanted to have Queriable... and IQbservable is a query-enabled observable... and queries work well with DBs.
- It just kindof all fit together, I can make a storage type for the registry, make everything queriable, and it should all produce an efficant and functional system.
- And once that's done, it should make handling large logs easier and faster... and that comes after this work. So it's just in time.
- (ok, looking at the task list, I'm doing stats next... useful for determining if the work is really useful and possibly to gather some early stats for determining "should the default storage be a list, InMemoryDB, or FileDB?")
- (ok... also missed making sure NUnit supported Observables...)

#57.2. 6/07/2018:
- I talked with a friend about the observable design for longed then expected...
- I'm going to go with the plan I had yesterday, but hide it with a factory.
- The factory will use a set of criteria (unused as of this commit) to pick which storage to use.
- But... due to that conversation going for a bit, I'll have to do the storage implementation and work tomorrow.

#58.2. 6/08/2018:
- So much for doing the storage implementation "tomorrow". And as a heads up, I hope to do more _tommorrow_...
- Basically, I took a look at IQbservable and went "this is cool... how do I utilize this?" and everyone else seems to have the same question.
- I found a promissing project (https://github.com/RxDave/Qactive) though haven't looked it over enough yet to be able to determine if it's useful...
- But besides that... it's again, many people going "it would be great to recieve values as they appear, with filters, and done server side instead of client side" and then nobody having a DB connection or something that can be utilized.
- My initial plan is just to have a list anyway, so it's not going to be anything incredible. Heck, it could just be I take the expression from the Qbservable, execute it on the list, and as I get results back, return.
- But for now, after glancing at a lot of discussions and some code, I just made an interface. I don't want it to just be a mini-ILogRegistry. it should be storage of ILogEntries and nothing more. Closer to ICollection<ILogEntry>.
- I doubt this is the final design, but I can at least do something to get an idea out.

#59.2. 6/09/2018:
- Again, not much work today.
- All I did was substitute the old implementation of LogRegistry with the initial work on implementing IRegistryStorage usage.
- Ah, a few tests didn't compile... refactored LogRegistry creation to a function for them so only one spot needs to be updated. Should probably switch to using the LogFactory anyway.

#60.2. 6/10/2018:
- We're back in business... not perfectly, but unit tests pass and test program work as expected.
- Looking at IQbservable... I think I'm in over my head. As such, my implementations for this will not be ideal, but I don't want to spent the remaining days on a proper implementation (though I know this will take longer then 100 days total).
- Basically, I don't know enough about implementing a QbservableProvider and system and how Expressions work. Ideally, all invocations that check attributes on the log should be turned into a DB query (or similar), while everything else should be lambdas and similar that run within .Net.
- Providers (to my understanding) basically take the entire query (from log in logs where log.Timestamp > DateTime.Now && log.Timestamp.Minutes > 30 select log) which has been turned into an "Expression" and iterates through it so "where log.Timestamp > DateTime.Now" becomes RemoteSQL("WHERE logTimestamp > cast((now()) as date)").Where(log => log.Timestamp.Minutes > 30).
- LINQ is extremly powerful, but after nearly 50 days of doing unit tests, I'd like to not spend the rest of it learning and implementing LINQ.
- With that explained... I got a basic storage that uses List, and ensured LogRegistry was implemented.
- I will do a bit more research tomorrow to try and determine if there are any SQL IQObservables and/or how to ensure Insert doesn't screw up log iteration (I need it to be that if a subscription hasn't gotten to the inserted member, it's returned. But if it has passed that timestamp/iteration, it doesn't return it).
- For now, everything's working again.

#61.2. 6/11/2018:
- So, today wasn't terribly productive.
- I was mainly going through code, trying to understand how IQbservable would work... long story short, I'm not doing any more work on it in the short term.
- It comes across as "the future" and "under-implemented" at the same time. And as I said else where: "I may have crossed an event horizon of code and I both want to continue and have no idea what todo"
- I can basically ignore it by using AsQbservable on an Observable, but it's not a very useful tool when used that way.
- Looking at the tasts I have, for the most part, I can ignore it for a bit. But the place where I see it being needed is when I support remote logs.
- The reason is that, as of now, I'm reading files and streams. They'll be finite for the most part. But once I'm streaming logs in from remote servers, it will go from KB and MB of log data to GB of data, streaming from one or more server at a time.
- That kind of data will require some updates to how they're inserted, possibly requireing queuing and proxies. Mutexes and Monitors may be too slow. To then read such volumes of data, having one giant stream will be like an infinite loop of log data. The ListStorage I have no will ballon in memory and probably become unusable. A DB will be needed (maybe sharding too?) and with a DB, IQbservable will actually have a real use.
- But before the DB gets created, the ListStorage type should at least work properly.
- So... lots of reading, but not a lot of code. Tomorrow I'll see if I can start and finish support for Observables within NUnit.

#62.2. 6/12/2018:
- I know this feeling... this is the feeling of "I'm going to crash, hard, because of lack of sleep". I can barely keep my head up.
- This feeling started earlier in the day, and now at this point, I'm going to have to call it quits.
- But before that, I did research on how to support Observables with unit testing/NUnit. Ideally, I'd like to support Observables directly (Assert.That(obs, Is.Empty)) rather then converting to an enumeration or processing the Observable outside of that.
- Luckily, NUnit has a page on extendable constraints: https://github.com/nunit/docs/wiki/Custom-Constraints
- Looking at the area where I expose Observables, I came up with the following items I need to support:
-- IObservable
--- Is(.Not).Empty
--- Is.SubsetOf
--- <expression>.Exactly
--- Has.Member(x)
-- IObservable<IGroupedObservable<K, T>>
--- <something to get all keys, and Concat? (to combine all values)> (though this could possibly be done with simple LINQ)
- I wanted to work on this, but you don't realize how many typos I made and words I accidently when I typed just this log because of how tired I am.
- I will work on the above tomorrow

#63.2. 6/13/2018:
- I started working on the Observable support for NUnit and hit into a number of issues. Nothing blocking, but they make what I expected to be a simplistic and elegant addition, and tarnish it a bit.
- I managed to get the Empty constraint (known as ExEmpty) implemented and will do more work tomorrow.
- Issues encountered:
-- The Custom Constraints page has an example of "public class Is : NUnit.Framework.Is". When first read, I assumed the types would clash but thought "just don't include the namespace that has Is in it"... but all the types you interact with in NUnit are in that namespace, so I had to change the name of my "Is" to "IsEx"
-- C# doesn't support extension properties (just do a Google search for why...), so what could've been "Is.Not.ExEmpty" now has to be "Is.Not.ExEmpty()"
-- It would be cool to do "Is.Not.Empty()" but for consistancy to prevent name clashes, had to rename them to ExEmpty and will do the same for other types. Also, since it's near impossible to tell 
-- NUnit doesn't let you add sub-constraints... so I had to make entierly new constraints. Ex: EmptyConstraint really just checks a few types, picks a "real constraint", then uses that for testing. I'd be great to add additional types, but I can't. Instead, for ExEmpty, I do my own type checks and if none match, I run EmptyConstraint internally.
-- For collections, there is IEnumerable and IEnumerable<T>. For Observables, there is only IObservable<T>. This meant that I needed to figure out how to interact with a type that I didn't know the type of until runtime. I made a helper function to convert to a known, generic, IObservable<object> but it took all the time I had allocated, and more, to working on this. C#'s generics are very good, but if you don't know the types ahead of time, they become near impossible without Reflection.
-- One holdup in working on other functions was, after all the work needed for just doing ExEmpty, I didn't want to spend another hour or two just doing a couple more functions.
- This has not gone as fast as I hoped. We'll see if I can finish it tomorrow.
- I'm glad I worked on it, but it's just slow going. Also, was not expecting the Observable thing to be as much work as it was. A bunch of trial-error, some research, and a couple curses.

#64.2. 6/14/2018:
- It lives!!! Ok, at least for the extensions.
- To add to the "issues" list: there are many existing constrains that could simply be extended... but even though the classes aren't sealed, the member variables are private, so I can't access them to use in an overriden ApplyTo function.
- Next up: state gathering. I expect this will appear to be easy, and will end up taking me a couple days. The weekend will also be a bit slow again.

#65.2. 6/15/2018:
- I didn't have a lot of time tonight, and I need to think about how to do the next task: stat gathering
- Something easy but also useful, I went around to everything (except parsers) and put in comments for where stat gathering should be specified
- Doing this is useful because, while I can't do it now, tomorrow I should be able to just look through everything that stats should be gathered and try to determine how the gathering should be done (static class that has some function call? instance type that can be instantiated? mix? other?)
- But that's all for now.

#66.2. 6/16/2018:
- Ok, as stated already, didn't get very far.
- Most I did was finish marking in the parser.
- I will plan out how the state system should be implemented tomorrow. I may also mark more areas depending on what I think the stat system should be.

#67.2. 6/17/2018:
- So... still not a whole lot, but the main thing was I tried to summerize some of the operations.
- I know a histogram will be something that will be created by the stat system.
- I want to be minimal and only provide stat recording thatr is as minimal as possible (think "collection.Record(value)" instead of "StatCollector.Record(Name, value, RecordStatScope.Public | RecordStatScope.GlobalStore)").
- ...then the actual statistic types will be handled in the background. Statistics like min, max, average, the previously mentioned histogram, etc.
- I'd also like self-feedback to exist as an option, so stats can be polled, written to a file, callbacks invoked or gather during runtime, etc.
- Though, I need to look to see if existing libraries/systems exist. No need to reinvent the wheel if something good enough exists already.
- Bonus: as I've been doing it as I come across them, I now use "nameof" for all argument exceptions* where I specify the argument name.

#68.2. 6/18/2018:
- So doing some searches, I came across Metrics.NET and spent today reading through docs.
- If it reminded me of anything, it's that I want to grab performance stats too. "Timers" in Metrics's API.
- The challenge I have is that I don't want the library to do configuration...
- ...but I'm also not sure if I want to abstract the logging to hide away the global Metric class or similar. And if I _do_ abstract it, then I will have to take some control of configuration.

#69.2. 6/19/2018:
- So, I'm going to directly invoke the Metrics library for now. I'd like a little more isolation instead of using globals, but it's the best library available from what I can tell.
- To start, I implemented metrics for the factory types.
- I also spent a bit of time trying to debug why things weren't working... turns out an additional dependency of System.Configuration.ConfigurationManager was needed.
- Lastly, I needed to ensure that the application and tests would be configured correctly.

#70.2. 6/20/2018:
- Implemented trival metrics.
- Was debating on the ListStorage.AddLogSorted, if I wanted to manually measure the lock time AND the actual execution, or just do (what I ended up doing) of just combining the two timers.
- It was easier to combine then to try to do StartTimer, StopTimer, Record(stop - start, ...) and then doing that only around locks and then the execution itself.

#71.2. 6/21/2018:
- Implemented non-trival metrics.
- There are probably a few more I can add, but they'd only be added because I thought of them... not because I saw a need for them. Like timing how long GetElementDataFromPath takes... realty is, it doesn't matter. ProcessElement does matter, since it limits how many logs we can go through. While GetElementDataFromPath would just be "this type of operation/length is slow"

#72.2. 6/22/2018:
- So this is a weird one... I wrote code, but thank God for unit tests... because I found out it didn't work.
- What's weird is that it should...
- Ex. Instead of "var result = x + y" I wrote "var result = Math.Add(x, y)". The first passes unit tests, the second doesn't.
- So I went off and did this: "var result = x + y; var result2 = Math.Add(x, y);" and... it too doesn't pass.
- What the heck? How does addiitonal code, that has purposly been written to not interact with the original fail?
- ...and I spoke too soon, I realized while typing this that the reader probably already read the value for the original format... but running both means that it's not getting the same values/children.
- It's late, so I'm going to stop here and try to figure out what to do tomorrow.
- The end goal was to eliminate the "root" node, since streaming and massive logs don't need millions of child nodes.

#73.2. 6/23/2018:
- So in a slight comedy of errors yesterday, I tried to replace the tree-model of XML nodes (element.Parent.Children.Contains(element)) with... a Queue.
- Take a moment to think about that... how do I take that same example and do it with a queue? Hint: you have to create a new queue.
- This is what happens when I work with little sleep. What was I actually looking for? Stack, not Queue.
- So I switched to a Stack and... everything still failed.
- Turns out, I condensed some of the logic down originally and didn't make it obvious what was happening... so I past self confused current self with what I did.
- Key: adding new elements to a parent. I went "nah, don't need this" but didn't think "um, I don't want to add elements to <root> but everything else is fine"
- With the proper container in place, a couple comments on what is being done, and ensuring that I add children at the correct moment, I was able to get everything working and passing tests.
- I repeat: unit tests are very useful... I had many of the XMLLogParser tests turn red.
- I also repeat: sleep. Don't kill yourself over code. I possibly would've had this done yesterday if I wasn't tired and realized I was using a Queue instead of a Stack. I distinctly remember going "why is there no Push function? Well, Enqueue is close enough".
- Bonus: I realized "what if a log shows up that already has a root?" and made a note that I need to support XML logs that already have roots.

#74.2. 6/24/2018:
- I didn't have a lot of time today, so I quickly added one element I mentioned yesterday: supporting logs with an existing root.
- While the flag is there, the tasks I need to do with it:
-- Support flag with ContextConfigs
-- Unit tests
-- Think about if this is applicable for other log formats... and if not, how should I handle this?
--- While I keep flip-flopping mentally if I should or shouldn't, I'd like LogConfig to be per-parser/per-log to ensure the program can support multiple log sources at the same time AND not have sub-configs or something.
--- For all I know, the sub-configs might be a better idea... but do it per-log type?
--- Other log type ideas... would they have there own variables that don't work elsewhere?

#75.2. 6/25/2018:
- Finished support for ContextConfigs and unit tests for LogHasRoot
- As I like the idea of per-log/format configs, the LogHasRoot config can be ignored by parsers that don't support it.
- I also aquired bigger logs... going up to 7GB.
- The smaller of the large logs parse just fine, though RAM usage goes to ~2.5-3GB.
- The 7GB log... didn't parse because Stream.CopyTo couldn't copy the data. Understandable, it's 7GB trying to be copied to a MemoryStream.
- I'll need to do streaming to test that one.
- One interesting one: I support XML right now, will add support for JSON later... but I forgot, there was a period of time (and many logging systems output) unstructured plaintext. I'm curious if I can support it... I don't know how at this point, but we'll think about that when the time comes.

#76.2. 6/26/2018:
- So, I wasn't sure where I should go... and decided to jsut get benchmarks.
- So no code today, just numbers.
- Rough numbers... because the metrics continue to get gathered even when we're done processing. Grabbing them right as parsing finishes would probably be good. But I'm still namely trying to gather how to read some of these metrics.
- Numbers:
-- Setup without parsing: ~20.4 MB of RAM
-- Setup with parsing: ~2636 MB of RAM
-- Logs parsed: 687,674 logs
-- Log file size: 554,220 KB
-- Parsing rate: ~22,500 logs per sec, or ~22.5 logs per ms
-- Parsing time:
--- Min: ~0.01 ms per log
--- Max: ~2.4 ms per log
--- 99% percentile of parsing: ~0.07 ms per log
-- Locks when adding to storage adds ~0.1 ms per log, at worse

#77.2. 6/27/2018:
- I'm late, but wanted to see what I could do... which wasn't much.
- I was planning on trying to implement streaming/concat Streams (https://stackoverflow.com/questions/3879152/how-do-i-concatenate-two-system-io-stream-instances-into-one) but realized "I need a different registry storage for this... it'd be too big"
- See, by the numbers yesterday, a ~500MB log file produced ~700k logs. This took up ~2.5 GB of RAM.
- The largest log I have on me right now is 7.1 GB. Using a nice ratio, that comes out to ~1.4 logs per MB, or in this case, a little over 10 million logs. Do the same for RAM, and it comes to ~36.5 GB.
- Yes, ~36.5 GB. My computer has 64 GB of RAM ("they told me I was crazy... what are they to say now?"), and while technically I'd be fine, the reality is I'd be pushing it on RAM alone. I might be fine, I might not.
- The other aspect is that LogEntry is a class right now. Which means every single one of them will be GCed and have additional data associated with them. That's a stretch to go. I'm not even sure if a List would be able to allocate a 36 GB array of memory.
- My last goal for the night was to do some unit tests, but I'm going to push that to tomorrow as it occured to me, "what if LogEntries were structs instead of classes?"
- Before I code that, my solution was to add NullStorage (think /dev/null) where every new log would just be ignored. Counted, but ignored. Nothing is stored. It's actually probably a useful type to have.
- Ok, it took longer then expected to convert FailedLogEntry to a struct (let alone LogEntry) and unit tests broke. So I need to see what happened... tomorrow.

#78.2. 6/28/2018:
- I tested the different entries as structs. I didn't measure any improvements in any metric... but did notice that it caused multiple unit tests to fail.
- So for the sake of knowing things work, and making the implementation less hacky, I'll leave them as classes.
- A quick test with NullStorage showed the XML parsing can run at 30,000 logs per sec.
- I wonder if hybrid approaches might be useful, like lockless queues. Everything goes into the queue extremely fast, but then a methodical dequeuing. This way parsing happens really fast, while storage takes as long as needed. This may be better for DBs, where it could be hitting disks instead of just RAM.
- NullStorage unit tests are done... I want to ensure all registry storage tests are in the same place, and need to make unit tests for the storage selection function. Tomorrow.

#79.2. 6/29/2018:
- I was gonna do unit tests to finish them off, but I mentally "crashed" and am very tired.
- Instead, I did some mindless work and wrote as many inline docs as I could.

#80.2. 6/30/2018:
- I decided to procrastinate the unit tests some more, and instead worked on more documentation. Not everything, but a few.

#81.2. 7/1/2018:
- I looked at the LogRegistry tests and decided that I wasn't going to remove any. Functionality could change if a null storage is used, but all other storage types should function the same.
- I also added a test for checking the desired storage type is returned for a specific criteria.
- Lastly, another bit of documentation.
- I might be a bit busy tomorrow, but if I can get the time, I'd like to start working on streaming log data (and do a bit more documentation).

#82.2. 7/2/2018:
- Ok... didn't get the time. More docs!
- Actually... I finished the docs. :D

#83.2. 7/3/2018:
- So, I was a bit late and planned to at least attempt to work on streaming and... unexpected injury(?)
- I listen to music using over-ear headphones (as is proper...) and the ear pads/cups/etc. that sit between the eat and the speaker becomes torn up on my headset. I bought new ones.
- I don't know about others, but these pads have a barely elastic band that is supposed to be stretched around the pads and then they contract and it holds the piece in place.
- I had a bit of a hard time and then I finally succeeded, I went to type out a message and... realized I couldn't feel one hand. I could barely type. At this point, it's uncomfortable.
- Instead of coding... I will read/research. A friend sent this to me: https://blog.marcgravell.com/2018/07/pipe-dreams-part-2.html
- I will read part 1 (https://blog.marcgravell.com/2018/07/pipe-dreams-part-1.html) before I get to part 2 (^^), as it's interesting and I like the concepts described.
- But that's all for now. Let's see if this doesn't sidetrack me into implementing...

#84.2. 7/4/2018:
- I basically finished witng yesterday's log, then "crashed" and didn't finish reading the article.
- I got further, but have't finished it yet. From what I've read so far, I'm tempted to switch to this Pipe/Pipeline system already.
- Years of dealing with Steams (C#), Reader/Writer (Java), I/O streams (C++), and numerous other I/O implementations have made me go "there's gotta be a better way" because even though API and usage varied between all of them, the structure was always the same: buffer, write, flush, close; buffer, read, test, loop, <repeat>, close
- C++ was probably the nicest because you didn't need the buffer stage... but if your data wasn't already in a serializable structure, you needed to convert between formats. Also, more commonly, the APIs you were working with didn't implement the << or >> operators, so you ended up needing to do buffers anyway.
- I'm not going to start on C++ templates... that's a complexity that was a mistake, even if the concept was ideal.
- Instead, the best "I/O" I've used is Rx (Reactive). Write being "ISubject<byte[]> stream = HTTPRequest.Open(url); IObservable<byte[]> dataOut = Serialize(...); stream.Subscribe(dataOut);" and read being "Deserialize(HTTPRequest.Open(url).Which(<filter empty data>))".
- Now... that actually doesn't look to good, now that I've written it, but it works so much nicer then other options.
- Pipe/Pipeline seems like either a nicer version of that (not specifically Rx, but using Rx for data streams) or at least something that would make Rx nicer to work with.
- My biggest issue with all the APIs has been knowing when data ends. Getting -1 means "we're done" but what if I simply lost connection over the network? Now I have to explictly define in API or data structure a "the data is done" in order to determine if I need to reopen the stream or not. What if I get an empty data stream? It's easy to skip an empty stream, but it's at least one additional line of code. If you do any abstraction around reading or writing, you now need to determine "where" to do that skip. Depending on where could mean you get your buffer, wrap it, start your decryption logic, get your IV, start a threadpool for IO operations, pass the buffer to the threadpool, thread to the decryption, and... nope, it was empty. No-op. But how many resources did you use to get there?
- Next annoyances: Knowing if I should write more data to IO, knowing the optimal amount of data to send, and otherwise building around the API (again, buffers for everything... as some put it, it's a code smell). I'm not sure if they have a nicer way to handle it with Pipe/Pipeline, but compressing/encrypting/etc. (and the reverse) are either a stage in the I/O that is like reading/writing inside of a read/write logic or it's encapsulation and you need to dig layers deep to get to the original stream if needed and the wrapping just repeats the logic at an intermediary layer, outside the read/write logic.
- The last one, encapsulation, is how many of the current stream I/Os work: stream = new BinaryReader(new SevenZipReader(new AESDecrypter(new FileStream(path), iv)));
- So... I'll continue reading and decide if I want to do something with it now, as I do still need to stream log data.

#85.2. 7/5/2018:
- So... I've been very slow at reading. Code articles/whitepapers are some of the dryest reading materials you can find. I'm not sure it could hold the attention of a rock.
- This article is fine, but it's not holding my attention.
- Looking up the code (which I now know is System.IO.Pipelines, which is never mentioned) and reading the articles (to the current point I'm at), I've decided...
- ...to skip it for now. As great of a concept as it is, there is literally no backend implementation. As the article puts "It's current release is like the abstract Stream class with no implementation of NetworkStream or FileStream".
- So while I want to use it, I must put function in front of cool-ness and move on.
- ...as soon as I finish reading it.

#86.2. 7/6/2018:
- So I noticed it's almost day 100... I'm going to do something weird... I'm going to branch and try to do a quick-and-dirty implementation to get something working (and will continue the log there) and then hopefully merge that back in (somehow).
- Look at branch experimental/poc for branch
- So I'm giving this a try: I want to see if I can get a simple system that I can actually use, even if not written "ideally".
- A proof of concept. Today may just be me playing around so there may or may not be much code today.
- ...and right after writing that, I realized a common logic piece I need anyway: streaming. Namely, some way to concat streams together.
- I simply (cowboy) coded and got most of the way through making a Stream that a generic interface type appended to, so that they'll iterate one after another as if one large stream.
- The biggest I have is that this needs to be support streaming logs, and NetworkStreams don't support Position (setting? Or getting too?), Seek, and Length. So I need to ensure that all my logic either has those as optional, or simply don't use them.
- The other worry I have is the code is not the cleanest (so maybe it's good it's in the branch) which means if something goes wrong, it will be a struggle to find what happened.
- I took inspiration from https://stackoverflow.com/a/3879208/492347 (https://github.com/lassevk/Streams/blob/master/Streams/CombinedStream.cs) but I allow runtime additions and don't rely on seeking and being able to use Length and Position.

#87.2. 7/7/2018:
- So my goal tonight was to get ConcatStream working in a way that would support streaming logs
- I succeeded
- There's still work to do... I could've done it, but I started watching food videos on YouTube. (I state this only for being honest, and because the videos looked really good)
- I learned that Position and Length require CanSeek position. At least, Position is documented to need it. Length isn't, but I can't figure out you'd really use Position without knowing Length, and if Position requires CanSeek, then by my logic, Length requires CanSeek too.
- Somewhat related: somehow seek lets you specify (final) positions less then 0 and greater then then length of the stream. It explicitly states it's allowed. Yet every implementation I see doesn't seem to allow it.
- Onto some cool bits, I ran a few stats with the new system. Now, a key difference is that I'm using the new NullStorage type because... I tested with the largest log I have, which is around 8BG in size. MemoryStream supports 2GB buffers... so it would never support even copying this log file. This is why I needed the appendable/ConcatStream and NullStorage. One so I could open the Streams (which is the same case for streaming logs) and the other because I simply don't have a need for storing such massive amounts of data right now.
- Numbers:
-- Parsing (without storage): ~23 MB of RAM
-- Logs parsed: ~9 millions logs
-- Log file size: ~8 GB
-- Parsing rate: ~33,500 logs per sec, or ~33.5 logs per ms
- Now, I think the interesting thing is that the parsing rate went up. "But NullStorage", yes... I'm not sure I wrote it before, but I tested before hand with NullStorage. Take NullStorage parsing rate and subtract ~10k/s.
- Statistics measured 50k/s parsing. I substracted my 10k/s and a little more to get what I think is a realistic rate once storage is used.
- But it made me go "did change in Streams make things go faster?" and I want to say no, as using the file from the last test gave me the same results. Then why the heck was this so much faster?
- I'm actually not sure. MemoryStream is very fast and skips disk I/O, FileStream hits disk (though I have an SSD... but that doesn't change getting the data for processing purposes). Nothing really changed from how the XML parser gets the data, and yet with the NullStorage, the larger log parsed 50k/s while the smaller log parsed 40k/s. There was a slight config change, but the per-log rate seemed the same.
- It's a mystery that I'll accept, as I don't think I'll get anything of that rate coming over SSH.
- Tomorrow, I'd like to finish of the stream and... figure out what I want to see as a working PoC and then start working towards that. Kinda hoping I don't have to do the DB-based storage right now, but we'll see.

#88.2. 7/8/2018:
- Finished Seek and wrote the source "optimization".
- For Seek, unlike the implementation I found, I don't produce buckets to determine progress. It reduces an aspect of complexity IMHO.
- I could probably cleanup the somewhat wacky Seek loop, but... have other things to do.
- I will do the actual planning tomorrow. Wanted to do it tonight, but still have a bunch of things to finish today.

#89.2. 7/9/2018:
- Little time crunch today, but I wrote up some things to try (Tasks.md) which is probably a stretch, but could be cool if I can pull it off.

#90.2. 7/10/2018:
- Looking at the source code that exists, if something gets added while the Observabke is running, it will stop or indicate completed.
- So... I'll have to write my own. Do it like an extension with an argument for choosing how new data/data changes are handled.
- I ran out of time, so I'll work on this tomorrow.

#91.2. 7/11/2018:
- Ran out of time again... but I wanted to get something. I made at least the boilerplate for the extension so that ICollection can be converted to an Observable.
- ICollection is chosen because the idea is that instead of an enumeration (which errors when it's contents change) we use for (int i = 0; i < collection.Count; i++)
- This will enable us to keep iterating, even if the contents change.
- I realized "but some logs run forever, so how do I do that?" and the easiest idea I had was to just have the collection never complete when it reaches the end of the collection.
- Then I went to implement it and went "maybe another time" and "what happens when I go to run unit tests?"
- FYI: this is the benefit of unit tests, as they depict how I assume people will use it. Suddenly saying "it never ends" is probably a bad idea.
- Unrelated: at the time I went "I want to work on stuff fast", I didn't assume "actually starting on work" would occur then... and still hasn't fully happened. I think I may miss a PoC on the 100 day deadline. Oh well... life of personal projects.

#92.2. 7/12/2018:
- I'm a broken record... ran out of time again. It's been a busy week and other events put me working on this later then I wanted.
- I tried to start working on an abstraction for the observable, so that I can simply write it without the IDisposable/scheduler/etc. complexity.
- I didn't get anywhere with that besides a base class that returns it's "type". I'm not sure how much I really care about the type but we'll see. It makes the function unique so it can act as an overload.
- Also, I decided the "infinite" model isn't needed. Since the LiveUpdating type will continue running even if the underlying sequence changes, a scheduler can be used to just slow things down... and then later speed them up, or something like that. No need for a special observable.
- Now... one question that came to mind: Skip/SkipLast functions basically iterate and just don't return data. Since the current extension is for a collection, can't I just do one easy skip (different starting index of ending test)?
- I'm not sure how I can pull that off without "you can't use System.Reactive.Linq", and that's not as easy as it might sound. Will look later...
- I also need to determine if I can get the ListStorage to use specific schedulers...

#93.2. 7/13/2018:
- Most of today was spent trying to figure out the best way to write an observable.
- I'm currently under the assumption that in order to get the optomizations mentioned before to work, I need to actually have control of execution. Otherwise a simple "the observable has a Subject and simply subscribes with it, then writes the collection to it" could be done.
- But there is an expected element to the creation, based on ToObservable: long running and short running schedulers.
- So when a subscription happens, if we don't want it running on "this" thread, we use a scheduler (which could still be "this" but at least it's controllable).
- But we can either process one element at a time (<process>, <potential delay/wait/thread overhead>, <process>, <potential delay/wait/thread overhead>, <process>, etc.) or all at the same time until told to stop (while(isRunning)).
- Long running schedulers will do the loop, while regular ones will do the single-element processing.
- So I need to ensure such a system is implemented, get the scheduler to ListStorage (Config?), and do one more check to determine if I overcomplicated this or not to note for later work. Bonus: get that Skip/SkipLast optimization working.
- Also, I want to look into what the benefits (as the above is my own guess as to benefits) of the two different scheduling models. Maybe it's not worth it to implement long... will have to research to find out.

#94.2. 7/14/2018:
- So the "long" running observable, needed or not, was able to be abstracted away.
- Still need to figure out how to get schedular to list storage.
- I really want to write some tests to prove this works... I'm going to hold off and try to get more stuff done first.
- Abstractions are good for scheduling/threads/etc. as you can write without needing to know about any scheduling/threads and generally keep your code smaller.

#95.2. 7/15/2018:
- Shoot... just noticed that because I made a branch that wasn't the main branch on Github, it stopped showing my commit streak. Eh, it doesn't matter (or at least, it shouldn't), but I was hoping to see such updates.
- Saw the time and needed to do something short: so all I did was add a value for get/set a scheduler for getting logs. (Scheduler = what does the "work" in an observable. The current thread handles going through a list? A thread pool handles ".Where(val => val != null)."? Etc.)
- Originally I was thinking I'd stick this in LogConfig but... "the power of defaults".
- See, LogConfig implies the data has a preference/specific scheduler for that data. Reality is, the application/consumer is the one that has to actually handle it. If a LogConfig suddenly says "run on the UI thread", the application is in trouble.
- Additionally, there's no way to specify a scheduler via JSON. A enum/parser would be needed to serialize/deserialize a scheduler. That could be problem if someone wants a special scheduler or Rx changes (and someone descides to ignore deprecation warnings)
- So since the scheduler is application specific instead of data/parser specific, I made it get/set property of the registry (which passes through to registry storage) and registry storage.
- As for "the power of defaults", a good default is one that fits most if not all situations without being a burden.
- So what is the best option for "here's 2 logs" and "here's 60 million logs" and "here's... the logs will never stop"? Tasks.
- We don't want it running on the thread that requests the observable itself.
- We don't want it running on it's own thread, as the current system will end up making at least 2 threads just for that (and if I can be smart, we want those threads for for figuring out information About the logs, not just reading them).
- There are others, but for simplicity: if tasks are used... especially with long running support, a task could be turned into thread if needed... or it could be run on some other processing element. It just offers one of the best options for execution (and for modern .Net, it should be used over threads)
- So... a good default that will probably never get changed unless it's someone who wants very specific execution.
- Important piece done, as it should mean we can sit somewhere to do processing and just pull a never ending feed from the registry which, at the same time, is being populated by a different thread attached to the parser.
- I'm behind, obviously, and my hope for a PoC by day 100 isn't going to happen. As such, I will do one "larger" side tasks before hand: Qservable/Linq. I want to see if I can get some optimizations with iteration.
- As there's no DB storage (yet), how can I get "Logs.Where(log => log.Message.Length > 10)" to run normally but "Logs.Skip(20 * 1000000).Where(log => log.Message.Length > 10)" to optimize the starting index of the iteration so it doesn't even bother with the first N items of iteration.
- Think: that can even be a start for other optmizations: "Logs.Where(log => log.Timestamp > timeOfInterest)" becomes "Logs.Skip(Logs.IndexOfFirst(log => log.Timestamp > timeOfInterest)" which, in turn, means that instead of checking every log for that timestamp, we now do a single check to find the first index (since the array is sorted) and use that as a skip point... which, per before, would already be optimized.

#96.2. 7/16/2018:
- Err... so my plan was to start working on Linq work, but I realized there was a problem with my live observable.
- A chain of challenges:
-- I need log items that I can iterate through and process (Enumerable?)
--- I would like them ASAP (Observable)
---- I want to minimize processing needed to get the data (Qbservable)
----- I want to try and get stuff done... and a DB implementation is going to be a pain as Qbservable doesn't seem to have existing DB support that's obvious to find. (Stick to list storage for now)
------ I need an observable of a list... but if the list gets insert/add, the underlying enumerable will throw an exception... (make own observable around list)
------- I need to be able to add data at the same time as reading... if I add data after the current index, it's fine as I'll read it later. I don't care if data get's added before since I'm not reading it... or do I? (today's commit and challenge)
- See, imagine you're iterating through a list (0, 1, 2, 3) and you're on index 1. Now a new item is inserted into the list at the same index. What happens? (0, 1n, 1o, 2o, 3o)
- And... you're index is still at 1. So you return item 1 at index 1 and increment indice, the insertion happens, you return item 1... from index 2.
- This is one of the reasons that Enumerables balk when changes happen during iteration, because it's a pain in the butt to handle.
- So now we need notifying lists. Note: there is a Subject called a ReplaySubject, but it doesn't do inserts and Observables don't sort... so I can't use it. There is also at least one Observable that will notify you of changes to an internal list (or something like that). I'm going off memory... not ObservableCollection... or was it?
- Regardless (we can always refactor to a better implementation later), I need to be able to track my index. So when the previous example happens, it's return item 1 at index 1 and increment indice, the insertion happens, you return item 2 from index 3.
- "Huh? How did that index change by 2? You only did 1 increment." Yes... that's the point of today's work. End goal: something that tracks any indice change that happens at or before the current index we're on.
- To get there, we first need to to get any changes to a list to be sent to whatever is tracking an index. Bonus: we could have multiple threads/tasks/etc. all tracking indexes at the same time so the list wrapper/abstraction can't store the changes.
- Once we have an abstraction (that works with ListStorage), we can send events for Add, Insert, Clear, etc.
- Once we have an abstraction with events, we can make a tracker that is independent of the list and can track indices using just the events.
- I did all this, which is lots of boilerplate I wish I didn't have to write, and updated ListStorage. The registry storage tests passed. This is not the first time I've encountered this, but it's the first time where I didn't have already written boilerplate. Fun.
- I can only commit the list abstraction because when I ran all tests, the LogRegistry tests failed. Not working on that now.
- Also, we need some atomics/locks/something in the index watcher.

#97.2. 7/17/2018:
- I put some locks around the index watcher, though I'd prefer atomics. There's not really a good way to say "atomically update these multiple values", partially because there's never been a CPU opcode for something like that.
- I half think "someone didn't think how code would be written" and half think "everyone else has figured out a way around this... yet they all use locks. Did nobody ask if that was really the best solution? Maybe it is... everyone else is doing it that way"
- For the time being, I'm using locks around that code.
- Next challenge: why aren't these tests passing?
- That's actually harder... because I didn't have the time to debug it. The closest I got to was "I concat 2 observables. One is the registry storage entries and the other is the logs being processed. Because of the threadpool scheduler that operates on the 2 observables, but not the concat, it ends up running only part of the observable when doing tests. The result is that the first assert passes, but the second doesn't."
- That's not good... as it should be "just working". I'll try having concat run on the same scheduler.
- Also not good: my expectation was that each Subscribe happens once-per-use. If all the sudden one subscribe "uses" the first observable in a concat, and then the next subscribe "uses" the second observable, then I may need to write my own concat or figure out what's going wrong with my expectaion (latter, not former...).

#98.2. 7/18/2018:
- I managed to write a unit test that reproduces my issue.
- I then managed to fix the unit test, and cause an infinite loop elsewhere...
- The issue was that the state persisted with the instance instead of every time it was run.
- This meant that the first run of something would be fine, then the second run would still have the indices of the first.
- I tried to pass state, but it came across as hacky. So I tried to pass state internally within the LiveListObservable... but that just cause an infinite loop.
- I will have to continue working on this tomorrow... err...]
- Plan B. I undid all the changes I had written and went back to the hacky-ish functional-like code. Ran the tests... everything passed.
- I will do this, so that I can finally move onto LINQ work tomorrow instead.

#99.2. 7/19/2018:
- I did some minor updates to the ScheduledObservable and LiveListObservable to make them simpler and prevent the "state is stored by the observable" using a simple state generator.
- By making a generator, when a subscribe/schedule operation occurs, the state is generated then. It's then kept throughout execution but never gets stored in the observable.
- This allows us to remove the "prepare" function (because the generator "is" the prepare function), reduce the logic for carrying the state around, and just makes it cleaner.
- No code for this right now, but I'm going to try and do a very basic implementation for skipping elements. Using https://msdn.microsoft.com/en-us/library/bb546158.aspx as a tutorial.

#100.2. 7/20/2018:
- Celebration! 100 days of codeing! It wasn't perfect, but it's better then bouncing back and forth between "should I code, should I play games, should I read?" and then doing none of those. Sleep could be better, but still.
- I've been going through the article mentioned yesterday. It's interesting... and boring, as most long-form articles are. I guess this is the stereotype of "can't focus or wants short and quick/instant results", but I literally fall asleep with these kinds of things.
- Since I won't have the LINQ stuff in progress for a bit (wanted to do something... ran out of time), a short post-mordem:
-- Project idea was good, but also a bit much for 100DoC and will definitly extend past the original lifespan.
-- Unit tests: a good idea, but I let my work-mentality for going for max coverage get the best of me. Nearly 1/3-1/2 of the 100 days were spent writing unit tests.
--- Postive part: Rx extensions for NUnit and prevented a few bugs like the recent LiveListObservable.
--- Negative part: Besides time-spent, unit tests never have a good way to orginize. Like, in JS, I've seen grouped tests... it's fake, but it still provides a "this group of tests are all related to X, while these are related to Y". NUnit (and Google Test) don't let you do that (nicely). Large blocks of tests aren't always easy to follow.
-- I'm conflicted on the C++ port. My goal is portability of the application, but the amount of work that will be needed to port this to C++ will be a 100+ days on their own. And I haven't even started on "based on these 100 logs, we can see that these are the following attributes: ..." isn't even a thing yet.
-- I like plans, but I'm willing to wing-it a bit. This code is very much "I know what the end goal is, and I have an idea on how to get there... I just have to not cowboy code it and make sure elements are well written."
-- I fell into my own trap with the 100 day PoC. I started just working on a library with a demo app, and didn't realize until a few days ago that I didn't really even have a PoC. Just a simple app that printed out what was read in.
-- .Net Standard is not well setup for new users. Once setup, it's good.
-- Same can be said of NUnit. Theory is that it can be setup quick and easy, but somehow following tutorials failed me. I realized part of it was because of .Net Standard, but there are build attributes that could've given a hint.
-- Habit building still needs some work. I want to say 1/8-1/4 of my commits are "I ran out of time, so I touched one line of code and spent more time writing the log". I know I have a nagging thought in my head "great, now that 100DoC is done, take a short break and we can get back to it later" but that will probably mean we'll never get to it, so I must keep going.
- To day 101...

#101.2. 7/21/2018:
- Out of interest, I ran one of the large log files through and timed how long it took to print. When ListCollectionIndexOffsetTracker used locks, the difference was only about 4.4%-8.3%, which may sound a bit significant, but it comes out to 20-180 logs per sec during printing. The difference is actually how big the console window is. Large window = 20 log difference, small log = 180 log difference.
- As printing should, ideally, occur on a different thread, I can see the process being closer to the 180 log difference. What's almost comical, if you didn't notice, I didn't say which was faster. The one with locks tested faster (out of 3 runs). I'm not sure what happened, but that was the measurement. As the work would be more then I want to do for the short term, and "somehow" the lock-ed version ran better then the unlocked version, I'll leave the locks.
- In addition, I'm thinking about how the LINQ provider I will be working on should, well, work. The main operation I want to handle is Skip and SkipLast. Those two become index changes and thus can be changed easily. I could even do by a certain number of instances...
- But in order for that to work, I need to make sure the values used don't change if we run or not. We need direct access to indicies, anything that changes that means we can't do our little optimization.
- So `col.Skip(100).Where(x => x > 92)` is fine because it means we go `for(int i = 100; i < col.Count; i++) { if (col[i] > 92) { ... } }`
- But if it's `col.Where(x => x > 92).Skip(100)` then we can't, because its skipping the filtered range. `int skipped = 0; for(int i = 0; i < col.Count; i++) { if (col[i] > 92 && (skipped++ >= 100)) { ... } }`
- I mentioned elsewhere, there's also the case of `Where(log => log.Timestamp > <time>)` (or `SkipUntil(log => log.Timestamp > <time>)`) because it means internally we can do `for(int i = col.BinarySearch(<time>, <special comparision>); i < col.Count; i++) { ... }` and do one fast operation since that happens once.
- I need to make a list of all operators that I can ignore as they don't change range, and maybe the inverse. The smaller list will be the one I use to determine "can I optimize this?" when the Expression evaluates the IQbservable.
- Ok... you can't tell via text, but the difference between when I wrote ^^ and this line is about 18 hours. A "short break" became a full night sleep + more. Given how I commit stuff the following day then when I worked on it, I will take advantage and commit it now. I didn't make my list of Observable operators (should actually be Qbservable operators since that is what would be used), but will get to that.

#102.2. 7/22/2018:
- In an effort to reduce the chances of missing a day, I will keep this one short
- I started making a list of all operators I can ignore and can't ignore when going to run a query.
- If I see `<skip>.<skip>.<skip>.Skip(10).<skip>.<skip>...` then I can optimize a bit. `<skip>.<skip>.<skip>.Skip(10).<noskip>.<skip>...`, I can still optimize. "<skip>.<skip>.<noskip>.Skip(10).<skip>.<skip>..." then I can't optimize execution and I need to iterate over all values till 10 have passed.
- An example of <skip> is "Map" or "ObserveOn" because they don't modify the items I'm operating on. Item 0 will be returned first, while Item 10 will be returned as the 10th item.
- Example of <noskip> is "All" and "Sum" since they change the iteration...
- Now there's a catch, and for this reason I've already given up on the list: what is skip and noskip can change based on paramters. Take Concat for an example. "Logs.Concat(<others>).Skip(100)" might at first be a <skip> because you skip the first 100 items of Logs, then go to <others>. In reality, it's <noskip> because I might only have 10 logs, so now the Expression (how all these Queryable things get run) becomes "<others>.Skip(90)". It becomes even more interesting when you know the types. So I could go and say "if I knew the lengths of some of these at the time of expression evaluation, I can do that "Logs.Concat(<others>).Skip(100)" -> "<others>.Skip(90)" optimization, which in turn (if <others> is of my own type again), I can turn it into "<others (i=90)>" and the expression has effectivly reduced to an extreme extent".
- Also, "Zip", if I know both Observables, I can tell both to skip a certain amount. I already indicated my questioning if `Where(log => log.Timestamp > <time>)` can be optimized.
- Given the complexity, I'd rather do something that leaves me uneasy but would possibly be better: just start implementing something. I can see how it works, fix things as I go, and then if I see something I could optimize, then I can try to optimize it.
- Best case, I end up with a small framework that can optimize expressions when operating on lists. Worst case, I revert a bunch of work until I get things working again.
- There are a couple aspects to wrap around: how do I know things will keep working? Is this just a time sink? Aren't there better things to work on?
- Anwsers: unit tests; now: yes, but later: no; yes
- So I do want to get to analysis and doing optmization work before having things to check for optmization is counter intuative.
- As I have yet to find a DB that does Qbservables, there's a good chance I'll have to write one myself. That's terrifying on its own (there are many more qualified people to write SQL or similar queries then me), but I may have to do it. Knowing how to work on a list first would make it a lot easier then going straight to DB.
- I need to work on unit tests again before I can go back to fancy work.
- I'm getting the itch/realized I do need a never ending "live" observable.
- See: I did the "live" observable thing to handle changes in enumerables. I planned out having one that stops when the end of the list is hit, and one that never ends. I opted to not do the never ending one (#92.2), because I believed a scheduler could change if it never ends of not. I was actually thinking of "Delay". All those still "end" and don't just keep running. In the split moment, now, when writing this, I went "but how would I do the infinite list without making it really messy?" and the solution is: I already have figured this out with IBaseListCollection.
- When I had my "oh no, when something gets inserted before the current index, the index needs to move!" resulted in basically writing a small framework to handle changes to a list.
- As such, I can to a classic academic producer-consumer. Run like normal, then when we run out of items, instead of calling OnCompleted, we instead Wait. When either the observable has been disposed or the list changes, we wake the sleeping threads and check if we are done or have new element(s), and either finish, return elements, or go back to sleep.
- So... for me to writeup tomorrow in Tasks:
-- Merge poc back into main since the goal of poc isn't even remotely close
-- Write never-ending LiveListObservable (either updating the existing, or writing something new... probably write new and merge if similar enough). May be useful to have some way to switch from Live to LiveInfinite and back. That way we can return a nice default (Live) from Logs and then the user can say "never end". Most likely a "AsInfinite" which switches internally but for LiveList but is otherwise `obs.Concat(Qbservable.Never())` for everything else.
-- One more bout of unit tests for all the work I've done since poc branch-off
-- Make simple constant Qbservable provider/expression/etc. that just executes and doesn't do anything special.
-- After ^^, start working on systems to analyze logs.
-- After a ^^ has made some progress that is usable or seems sufficently complex, start trying to optimize expressions and LiveLists
-- May need to write my own DB observable... after a DB is found that can be embeded OR external AND has notifications of when things changed (otherwise we'll never know if we're supposed to return something)

#103.2. 7/23/2018:
- In the name of "sleep", I updated Tasks.md (it... didn't change too much. Just a bit) and merged back into main

#104.2. 7/24/2018:
- Plan for InfiniteLiveListObservable work:
-- Clone LiveListObservable and update so it's "infinite"
-- Combine LiveListObservable and InfiniteLiveListObservable so it can be switched on the fly
-- Write extensions so Observables can be switched between Infinite and Finite. If LiveListObservable is encountered, it simply toggles it (note: not as easy as it sounds, as it would have to be per-state and not just global)
- For tonight, due to time (again), I simply cloned and mocked out where the sleeps would be. Didn't want to start working on monitor/sleep/etc. stuff now.

#105.2. 7/25/2018:
- I implemented the monitor system so that if we hit the end of the list, we sleep until either we're canceled or the list changes.
- The only issue is that polling was still needed. For individual execution, there was no alternative. I'm sticking to the abstraction, though I could change the disposable used.
- As for long execution... looking at source for TaskManagerScheduler (which is what we use by default), a BooleanDisposable is used for the ICancelable. This has no way of notifying that it's been canceled/disposed. Instead of resigning myself to polling, I added in some minor logic so if whatever scheduler uses CancellationDisposable, we can register to alert us when it's disposed.
- The end result is it provides a better busy-loop-plus-sleep then, well, busy-loop-plus-sleep. A classic situation... I wasn't expecting ICancelable to not have any way to be notified "this has now been disposed" but that's a different story.
- Tomorrow we try to combine LiveListObservable and InfiniteLiveListObservable, then try to see if we can switch between them on the fly. (also want to be able to start as one or the other... not just LiveListObservable and then needing to switch it)

#106.2. 7/26/2018:
- Combined the infinte and finite LiveListObservables. It's a little more complex then I'd like, but I don't see it having any additional complexity.
- I decided to put-off the switching between types until tomorrow for time purposes.
- One challenge is that info is a execution state... is not class-based. So when I go off and say change between types, I need to figure out what to do. Maybe a AsInfinite/AsFinite isn't the right function... will think about it tomorrow.

#107.2. 7/27/2018:
- The plan was to work on switching between Infinite and Finite LiveList (and maybe other Observables), though I'm still not convinced I can.
- Instead, I went to setup a simple one-time test case of execution where we wanted a value before we had it. It uncovered 2 cases I didn't think of:
- 1. This is more a test issue - When trying to cast any ValueType observable (IObservable<int>, etc.) to a generic one (IObservable<object>), the cast fails because Observable.Cast (the function being used internally) throws an exception for ValueTypes.
- 2. The CurrentIndex is not really usable once it hits the end of the list it's iterating over, when the LiveListObservable is in infinite mode.
- Fixes for #1: Observable.Cast is really just doing Observable.Select(value => (object)value), so I did exectly that. It wasn't planned work, but it works now and covers a Cast case I never actually tried. Saves trouble for later tests.
- As for #2... I did a bunch of debugging and did some changes within LiveListState.CreateState (see LiveListObservable.cs) and everything worked! And then I looked at it and went "That... is a race condition"
- The challenge is that if the list is empty, the CurrentIndex of tracker could get changed by a list event before the observable executes.
-- Ex. Empty list, Count = 0. CurrentIndex = 0. InfiniteLiveList. => Sits indefinitly. Element gets added. 1) Count = 1. 2) CurrentIndex = 1. 3) Observable executes (pulse or timeout). => Sits indefinitly.
- Order is not garenteed with events/multi-delegates, so we have to do a bit of order enforcement. We test the number of elements, and if there are elements we say "all's good" and add the tracker to get events. Else, we do it _after_ we get an event.
- The problemS are that:
-- After we get an event... what if it's a Clear? Nothing actually happens and the cycle remains.
-- If Count changes after the test against it, but before setting event handlers, we won't know the actual state we're supposed to be in.
-- And the biggest issue of them all: it doesn't actually fix the issue. So this solves the problem for an empty list that has an element added... what happens when we add a new element?
--- Zero elements: Stuck
--- Add one element: With fix=works, without fix=stuck
--- Add second element: With fix=stuck, without fix=stuck
- The real solution is to ensure I'm testing and updating current index properly.
- Basically: if CurrentIndex is at the end of the list, and an element is added to the end of the list, the element should be returned. But if the item is in the middle of the list, it shouldn't. This would prevent getting stuck at the end of a list.
- There's then the issue of event handling order. While debugging, I encounted the CurrentIndex being incremented by list execution right before the tracker updated itself. This may be solved by locking the tracker before updating.
- I will work on this tomorrow.

#108.2. 7/28/2018:
- I started way to late, looked at the work needed, and said "I can't do this at this time" and instead started working on unit tests for Collections.
- I will see if I can get to the race condition fix tomorrow, or if I should just finish the unit tests for Collections and then do the fix another day.

#109.2. 7/29/2018:
- I got to things late again, decided to work on the unit tests for Collections.
- Still need to do the events test, but decided to do that tomorrow. It's just something that looks easy, but experience tells me I'm going to spend a sizeable chunk of time on it.

#110.2. 7/30/2018:
- Postponed today due to lack of internet. I had some service done, and lost internet. Argued on the phone for a while and now exhuasted.

#111.2. 7/31/2018:
- Got internet back, but Tuesdays have also become a day where I can't get much done due to scheduled events. This is also a bad week, so besides yesterday's internet challenge, this week will probably be minimal work.
- As such, I finally got around to testing events. It wasn't long, but I realized I could make the little test class something generic for all event handlers.
- I also realized I need to test the index tracker... this is important, as I need to specify how I expect it to work in many situations... and then I can make sure the multi-day push back on the race condition fix.
- As it may be useful, I may just do the other unit tests to provide TDD setup for all the collection and observable work I did so I can ensure it works the way I'm expecting. If it doesn't work, fix the code until the tests pass.
- Once all that's done, I will have something I can ensure will work as expected... and that will be needed for doing LINQ work.

#112.2. 8/01/2018:
- I got sick so I didn't get to this when I would've liked. I hope to finish the collection tests and then start on other tests.

#113.2. 8/02/2018:
- I have some important stuff going on tomorrow, so I want to finish early...
- ...and that didn't happen due to other events, so at minimum I wanted to write up the tests to implement so I didn't just stare at "//TODO: index tracker"
- Sometimes you just need to take baby steps before you can get back to work

#114.2. 8/03/2018:
- All but the multithreading test is done for index tracking.
- I need to think about a multithreading test for it... as this could result in API changes. Mainly, the one test I know I want is inserting at/before an index while updating the index.
-- If the update occurs before the set, then the set (which right now the LiveList takes the current index and increments it while setting) will overwrite the current index.
-- If the update occurs after the set, then everything is fine.
- But if this is all happening async, then we never know the order this will occur in.
- While it might sound easy to say "locks" or "allow directly setting the current index", it still is an issue. If the index is changed right before the lock to set the index, then we still have the problem.
- One idea could be to have functions to do increment since that's all we need and we can expand the API as needed.
- Also, realized that the LiveList didn't reset the current index after creation. I didn't notice because we always start at 0, but this would break if we skip indexes.

#115.2. 8/04/2018:
- Ok, I can see this becoming a habit, which I don't like, but I need to be blunt: I keep staying up late working on everything and then getting to this last. I need to work on this project earlier so I don't look at the clock and go "I... don't have the time". So for tonight, I'm skipping... but will try to be better tomorrow.

#116.2. 8/05/2018:
- I didn't get the test, but I did finally fix the logic for the index tracker and LiveListObservable.
- I added a lock function (works similar to ApplyContextConfig) so that we can stop updating indicies multiple times, at the same time, but without exposing the lock object itself.
- I wanted to add a small bit of logic to prevent invoking the function more then once (tracker.ApplyContextLock(tracker => tracker.ApplyContextLock(...))), and went down the Rabbit Hole, to say. So it's a bit more complex then desired to ensure state is handled properly.
- Read the comments in it to get a better idea of what's going on.
- I have a messy test that I've been using to test this. Originally it failed, then I did the race-condition logic from before and it worked. I did these changes and tested, still worked. Then reverted the race-condition logic, and it still worked. So that's good.
- Next is writing some tests to actually have something to ensure it doesn't get broken.
- What happened to the index increment code? I realized my functions got weird (ResetCurrent, SetOriginalIndexAndResetCurrent, IncrementCurrent, IncrementCurrentAndResetOriginal, etc.) and that all that it was doing was simple operations that would somehow require multiple statements... and this a lock.
- Instead of doing a global lock (oh God, no) to work around our own framework, I wanted to expose the lock without, well, exposing the lock.
- Luckily, this is the exact logic we went through already for log parsers. Just, without the multithreading.
- So tomorrow (which will be busy for me, as usual), I will hopefully get to testing this.

#117.2. 8/06/2018:
- Wrote the unit tests for handling event order.
- Unfortunetly, two of the four tests fail. The logic should be correct, and playing with task continuation did managed to get one of them to start passing.
- I will play with it more tomorrow as I'm busy tonight.

#118.2. 8/07/2018:
- Took a bit of work, but got the tests working. My math was wrong.
- Also did something a little weird to ensure the ContinueWith is executed. I'd like something a little more explicit, but I worry it would be "reads code, scratches head, looks up docs, re-reads code, aha moment?" where as the "each stage increments a counter" approach means "if the count is not correct at the end, then some stage of the test didn't run"
- With that test set done, I move on to testing ConcatStream.

#119.2. 8/08/2018:
- Can't have a late night, so I simply created the unit test file for ConcatStream, wrote a TODO of what tests need to be written (at a high level), then sat and stared at the screen for a while.
- That last one is why I said "enough", because I was getting too easily distracted.

#120.2. 8/09/2018:
- Was planning to work on stream tests... and then only a couple empty base tests in, my computer's keyboard and mouse decided to no longer function.
- It took the momentum out of me and took longer then I wanted to, to fix.
- So I'll work on it again tomorrow.

#121.2. 8/10/2018:
- I only got the property-tests for one "populated" source stream.
- The functions require a bit of thinking, and I started late again and am at my "I'm done" point. So hopefully function-tests will be done tomorrow for this group.

#122.2. 8/11/2018:
- Almost got the function-tests done. I encountered one bug that needed a simple fix and it took a couple iterations of what I liked for how the test should be written.
- I'll finish these tomorrow and move on to the next group of Concat tests

#123.2. 8/12/2018:
- Finished the function-tests for a populated source.
- At least made the place holder for a "used" source. Will do those tomorrow (hopefully, all of them)

#124.2. 8/13/2018:
- Simplified my plans for the stream tests a bit as the "idea" of testing many combinations is fine, the reality is some of them are already tested.
- Once you eliminate those tests, it becomes only a handful that would "exist for the sake of existing"
- Instead, I'm simplifying it to "single stream" and "two streams" (I'm assuming 2 is enough, and all > 2 setups will behave has two streams... but internally be > 2.
- And to let me actually work on this tomorrow, I wrote what I needed to write tests for. Though "seek" is going to be a pain due to combos of tests.

#125.2. 8/14/2018:
- The next couple days and into the next week, I won't have a lot of time so I will do a handful of unit tests at a time.
- I got CanSeek and Length tests done for multi-source concat.
- I got thrown off by the Length one because the only concat source that I know of that has CanSeek = false is a native Stream with CanSeek = false.
- This means everything I test that expects an exception (as Length when CanSeek = false is documented), suddenly doesn't happen. So I had to throw an exception, and then expect that exception in the test... which is weird.

#126.2. 8/15/2018:
- Wrote the AppendSource tests but realizing that the optimize "method" doesn't really work... and yet it does what I wanted (which is adjust based on source index)
- I'll need to fix that tomorrow (which will be about the most I can do tomorrow)
- I also wonder if I should have it auto-optimize if CanSeek is false. So your reading finishes a source... remove it?
- Random: I also wonder if I should add to the extensions to support IEnumerables so they can be appended as well. Bonus: if a 0 length source is added, should it just get removed on the spot? (it would mean another method in the "source" interface so I can go "is this empty but _can_ grow?")

#127.2. 8/16/2018:
- In the process of fixing yesterday's issues, I also enabled all seekable streams to update the position of the ConcatStream
- I might want to optimize the code for AppendSource, but I will implement all tests first so I don't screw something up later.
- Adding the following line to have a "more normal" commit, since the prior work was done early and not commited at the usual time.
- Per the updated AppendSource, I now have a few more tests I need to write for it since it should update position within the ConcatStream.

#128.2. 8/17/2018:
- Added tests for position.
- The last test, the "invalid" one. That's a bit wacky as it's invalid in what someone might expect it to do with regards to Position, but valid in expectation... and it gets weirder when you try to work with it...
- In fact, thinking about it, I'm gonna add logic to prevent you from doing such a thing unless the stream is not seekable.
- So the "invalid yet valid" thing: I can add a stream that has already been partially used. But if I add a second stream that is partially used, it screws things up. 2 streams, position=10, length=20. Concat... what is the position?
- That's the "invalid" part. The valid part (such as when it can't be seeked) is being able to say "ready 20 bytes" and it reads 20... but it's really 10 from the first (at the end of the stream) and 10 from the second (at the end of the stream).
- If I were to allow appending something like that with seekables would screw up seeking, screw up position (my above example: first stream would say ConcatStream.Position=10, second stream would say... ConcatStream.Position=10 because there's no other way to pick a position. Then after reading 20 bytes, it's ConcatStream.Position=30 BUT ConcatStream.Length=40 AND you can't read anymore. You could also then seek -40 which would result in ConcatStream.Position=-10). So I can't allow that.
- Tomorrow: first CanSeek=true stream is always valid... second CanSeek=true stream must have position=0 OR position=length. Otherwise it has to be CanSeek=false. Tests will have to be updated.

#129.2. 8/18/2018:
- Fun fact: I almost didn't have a commit yesterday because I lost power but it came on for just long enough for me to commit the code and push it.
- So I realized that a CanSeek=true stream is valid if it's "sourceIndex" aka, current.
- But I also realized that if reading or seeking have already occured, the values can't be touched.
- I at least added some tests (but need tests for the "can't append some types if read/seek have been used)
- As this is a bit bigger then before, I'll attempt to work on it tomorrow so I don't have to fight the clock today.

#130.2. 8/19/2018:
- I only added 2 variables. I need to finish really early today and the work shouldn't be "hard" but it's a bit more then I can easily do in a short time frame.

#131.2. 8/20/2018:
- I went through and wrote a bunch of code for AppendSource... but I can barely stay awake right now.
- It's like coding under the influence, and contrary to any movie or university discussion, it isn't a sign of proficency. It's a sign that your code will probably have bugs in it.
- So instead of buggy code, I'm going to review/finish this tomorrow instead.
- I did write the test cases though.

#132.2. 8/21/2018:
- I did the work and... all the tests pass. Yay!
- I also realized I had a couple functions that do a simple task but don't do value checks. Usually, this is bad. But in this case, they aren't needed. They're just abstracted out functions. Doing checks when there is no way the data could get messed up (sans memory corruption) is basically a no-up. But since we have a bunch of tests, what better place to enforce it then in a `#if DEBUG` block.
- I got a bit annoyed with having multiple booleans, and simply combined them all into one flag set.

#133.2. 8/22/2018:
- Read tests with multiple streams are done.
- That's it. Nothing crazy. Took a couple tries with testing reading across source bounds, because reading 2 bytes (independently) produces different Read invocations then reading 2 bytes (consecutively).
- Next up: seeking

#134.2. 8/23/2018:
- I'm tired today, so just plan out what tests to write.
- I probably write too many tests (at work, we do... I can't remember the name of it, but it's described as "make a truth table, remove all impossible combinations, write tests for those... and also only write for specific combos"
- The end result of ^^ is that 12 tests = 98% coverage, 14 = 98.5% coverage, 20 = 99%, 50 = 99.5%, 148 = 100% coverage. I fudged those numbers, but the example stands.
- I'd love 100%, but 98.5% will do since I can write so many fewer tests. But I have no idea if I'm writing too many or not.
- For ConcatStream, I have a bunch that test 1 stream. Then when I go to 2 streams, and I have a set of tests that test the first stream... but why?
- For now, I'll continue. But when I go to do the observables, I will try to keep them to non-duplicates.

#135.2. 8/24/2018:
- Seeking support. Not too bad, though at least it tests moving between streams.
- Makred out what tests to write to finish StreamTests

#136.2. 8/25/2018:
- Today was a long day.. so the most I got was a few initial tests around the internal types that wrap streams and byte arrays.

#137.2. 8/26/2018:
- I ended up doing a lot of stuff today and didn't have a lot of time...
- ...and I just mentally crashed.
- So, I only did a few tests. Would've liked to finish them, but something that was supposed to be "quick" wasn't quick.

#138.2. 8/27/2018:
- Alas, it's done.
- I actually started early enough to finish the ConcatStream unit tests.
- I won't have a lot of time tomorrow, but I might be able to at least make/setup the test files. If I'm lucky, I might also be able to start writing the "//TODO" statements

#139.2. 8/28/2018:
- As stated yesterday, I didn't have a lot of time. But I at least got the test file setup.

#140.2. 8/29/2018:
- Ok, so I had a rough day... and fell asleep. So this is very "late"...
- So I only wrote a couple TODOs and will write more later in the day

#141.2. 8/30/2018:
- I didn't get to this until late due to catching up from everything I had planned todo yesterday...
- So as I said "earlier", I expanded the TODOs. It's not every unit test, but it's at least a better idea of what will be written

#142.2. 8/31/2018:
- I did a lot of things today... and time wasn't on my side. It's very late for me right now.
- The most I did was make one test to ensure null inputs to ToObservable/GetObservableType doesn't break anything

#143.2. 9/01/2018:
- Did not do well due to how late things were yesterday, so finished the simple tests for creating and checking the observables.

#144.2. 9/02/2018:
- Continuing the tradition of doing this much later then I should...
- I'm stuck on a small mental challenge. I want to test that execution is the same between normal and long running schedulers... but I don't really know how to check they are the same besides going "no data, now some data, wait, now more data" and checking they both do the same within a small timeframe
- But that's hard, requires threads, coordination, and more... it's not worth that much work.
- At the same time, just throwing a mock in and ensuring that the expected functions are invoked... is also probbaly unnecessary because if it didn't, then there's a bigger issue with the API or it's changed.
- Yet... it would be good to ensure that regardless of scheduler, the observables do the same thing.
- Also, one benefit of the mock-approach is that I can pass in my own cancelation tokens and test the ones will actually notify when they've been invoked. Essentially allowing me to use a "real" sleep instead of a polling one, which I have to use because it doesn't seem any scheduler provides a sleep that notifies.

#145.2. 9/03/2018:
- So this morning I wrote a couple TODOs for testing schedulers. I would do both, mock some basic tests, then (hopefully using mocks) would do a comparision between long and regular schedulers.
- I started working on it and hit a roadblock pretty quickly: the schedule functions are generic or extensions.
- What this meant is that the functions I was using were not actually member/interface functions, but extension functions. I can't mock those...
- But what about the actual functions, the generics? Nope. See, mocks expect known types: I have my List<T> and I'm going to test adding an "int", but ints can only be used if it's List<int>. This, I will mock List<int> to test Add(int value).
- But in this case, what is happening is that I have an internal state for the observable, which is passed into the extension function... which then does it's own wrapping/invocation. So without step-by-step testing to figure out the perfect state match, I can't test it.
- There are a few Stack Overflow articles saying that's what people did to get around this issue. As a coworker once told me "that test is too rigid". What happens if the extension functions change? What if I change my state? Both can or would result in changtes to the state down the line.
- The result is (example. Not actually tested) .Net Standard 2.0 tests pass but .Net Standard 2.1 do not. It becomes too tightly coupled. It goes against what we're supposed to test.
- Which brings me to the current state... I will not be testing schedulers. I will attempt to use two real schedulars for testing and expect them both to pass.
- That is probably how it should've been done. I will leave the TODOs in this commit just so they're recorded, but they'll be removed in the next commit.

#146.2. 9/04/2018:
- So I got the idea "just have the schedulers be arguments" and proceeded to write some initial tests where the schedulers are passed in as an argument.
- This allows us to write the tests we want, and then if there's any difference between schedulers, it will be discovered upon execution of the test with that scheduler.
- Now I can simply write the test
- I didn't have time to do more then the initial experiments. Also, remembered I wanted a confidence-check test (tests that go "I'm testing a scheduler that is long running, and one that isn't... right?")

#147.2. 9/05/2018:
- I was up too late last night, so I didn't want to spend too much time tonight working on this.
- Also, infinite and finite observables will have different implementations.
- So before I go kicking myself on trying to test something that "doesn't end", I wanted to do the finite cases.
- I drew the line before testing "insert" functionality, because that will be both with and without threading... and that will be it's own pain.
- So, to save time, and my sanity: no threads or infinite observables today.

#148.2. 9/06/2018:
- I did the finite insert function.
- I was gonna do a threaded and non-threaded version, but the whole ability to dynamically insert and get a value during iteration requires a lot more data. I will attempt to write a test for this at another time.
- ...so I only did the non-threaded.
- I then started thinking about the infinite observable but then... just lost interest (for tonight).
- Sometimes at work I go on autopilot. Today was one of those days. I went all day and refactored/abstracted about 30 files varying from 1-2 lines to 50-70. It was more mechanical then thinking.
- Doing that for hours... I was hungry, tired, and just wanted to finish it and go home. Unfortunetly, that leaves me in a bit of a shell-shocked state of "I... don't know what to do/want to do/do I want to do something?" state.
- So I'm calling it a night so I don't just stare at these couple TODOs without actually doing anything.

#149.2. 9/07/2018:
- "Don't not-sleep kids"
- I've been tired all day, and got to my home late. I had a number of other tasks todo...
- All I did was update dependencies and switch the tracker app to .Net Core 2.1 (I read it's much faster then 2.0)

#150.2. 9/08/2018:
- Another busy day means not much gets done...
- Or does it?
- I managed to get the first (real) infinite test written. It's ugly, but testing frameworks just aren't written for "infinite".
- Ideally, I would've loved to just call "obs.Wait()" but specify a timeout.
- There is no such thing... rather then write one, I just used Subscribe, have the scheduler do something else (my way of saying "the scheduler isn't frozen or something") and wait until the second operation is done before saying "so, did it work?"
- It does, though it's not fast (um... there are thread sleeps) and I'm a bit worried it's too complex for the tests I'm trying to do. But I should be able to adapt it for the remaining tests pretty easily.
- I could do that now, but I'm late... again.

#151.2. 9/09/2018:
- I got the base-test for existing items.
- I then started on insertion... and it didn't work. I will need to look at it tomorrow, as it's a little more complex then originally expected.

#152.2. 9/10/2018:
- I was lucky, I didn't need to do too much to fix the insertion test.
- Basically, I forgot the purpose of the live observables: allow iteration as they are modifed.
- The challenge is that by the time the insertion happens (non-threaded), the iteration is already done.
- Knowing this, I avoided the threaded test for finite observables. I'm wondering if I should still do them because...
- ...for infinite tests, non-threaded will produce a different result just because of how the value check is being done (finite - new subscription each test, infinite - one subscription per test).
- But, for the threaded tests: they should have the same response: if the insertion happens after the subscription finishes, the inserted value won't be there. Otherwise, it will be there.
- Bonus "should I do this?" is changing the finite observables to test the same as the infinite observables.
- "yes" but it should be an additional test. The ToEnumerable test is still something to test, and won't work for infinite observables, but having the tests be the same will make it easier to do direct comparisions of results.

#153.2. 9/11/2018:
- I made sure the basic test operated the same way as for finite as it did for infinite observables
- I was going to do the same for insertion... but I would have no way to test this.
- Since the finite observable would finish, I couldn't do a check that the inserted value wasn't returned without re-running the observable OR threading it...
- ...which answers the question of if I should still do a threaded insertion test for finite observables.
- I also updated the "what the heck is happening" inside the insert infinite observable tests.
- Tomorrow I'm hoping to do the threaded tests.

#154.2. 9/12/2018:
- I managed to figure out the threaded insertion tests
- The challenge I had was how to ensure that insertion would occur at or during observation of the list.
- The ideal test would be: 1. subscription starts. 2. Insert value. 3. finish observation.
- ...but unless I add some backdoor/tracking function to what is essentially List<T>, which would just make it more complex... and I'd feel the need to test THAT api too.
- (cont.) I have no way to ensure that when the subscription starts, teh insert didn't already occur.
- For that reason, I did two things: use Parallel.Invoke (which from an API perspective, should ensure the insertion occurs "at or during" observation) and to ensure things aren't messed up, I do the observation before insertion.
- And yes, to ensure that I won't accidentally insert at or during observation, I delay... by 1 ms.
- In the end, the tests pass. I hope I covered it properly... but for now, it should be good enough.

#155.2. 9/13/2018:
- Today was a late day, and I am not in the right mindset. I was even told "you seem more absentminded then usual today".
- As I am struggling to focus, I will simply note the "TODO" and work on it tomorrow.
- The "TODO" is testing the "wait" functionality of an infinite list, where it should not be complete, but will OnNext the values added to the end of the list.
- I'll need to think about the CancellationDisposable test I also want to write... simply because every scheduler doesn't seem to use it and I don't want to write my own Scheduler.

#156.2. 9/14/2018:
- I ran into an interesting issue implementing the "wait" functionality.
- I wrote the tests... they were a lot similar before I tried enforcing thread order. Why thread order? When I tried it without threads, it just... didn't run. It hung.
- UPDATE:
-- The working tests, I went back to the earlier, simplier model and it worked!
-- Since I didn't need to do thread ordering, do some sleeps, and otherwise argue with the system, I was able to reduce the tolerence to 50 ms instead of 150 ms.
-- So that reduces the issue down to just how the execution/tracker works.
- CONT.
- I realized the issue was the index tracker. Again. I don't know if there's a way to replace this or something... but I need some way to account for item insertion. Err.
- The problem was that when using a list, there are no events for anything that happens. This means that the live observable just checks index position against list count.
- But for a base list, it creates a tracker and specifies index 0 of a value. Observation begins and... it waits at index 0, count 0.
- Suddenly a value gets added. Now, the index tracker goes "I'm at index 0, a value was added to index 0, this means the index I was tracking is now index 1". Observation now waits at index 1, count 1.
- It basically gets stuck.
- How to fix this? I knew I had to look at the tracker because... as I suspected, my update function uses "<=" for insert and add.
- I wonder if I need <= for add?
- UPDATE: I originally intended to just go "I will work on that tomorrow" at this point, but curiosity always gets me (and I got some good sleep so I'm not half asleep and can focus on this). As such, we continue...
- I moved the Add case to a seperate if statement and changed <= to < for it. Ran collection tests: all pass. Ran the "wait" tests and... it passed! It was as I suspected, the indicies matched and moved the current index.
- Now, it basically makes the add case useless because unless your current index is < the value added, nothing happens. If current index is = the value added, nothing happens.
- If current index is > the value added, then it moves... but the index is passed the index of the value added... and "add" puts items at the end of the list, so current index is passed the end of the list.
- I will leave it for now and remove it later.
- I also left in the more-complex test, but will remove it later too.
- Note: threshold went 10 -> 25 -> 50 -> 100 -> 150 -> 1 sec -> 100 -> 10 -> 25 -> 30 -> 50 ms throughout the development of this test. Some other tests failed at seemingly random points. I'm not sure what kind of timing I should expect or why some other tests failed... but as it works sometimes and not others, I will investigate when it fails.

#157.2. 9/15/2018:
- No progress. I've been playing about and sometimes tests fail, sometimes they pass.
- The particular tests are ones using threading or checking times.
- Ok, I did actually make a bit of progress because I realized I have a hard-coded timeout. The live observables have a hard-coded timeout. I made the +/- value in the test "that" + 25 ms. This way if it's at that point, it doesn't always fail.
- I have other tests that are complaining about missing or extra values, which is probably the index tracker again. But I need to look into it.
- Bonus: they never fail when run on their own, but do when _all_ tests are run. So it's probably a thread/task switching challenge. Yay.

#158.2. 9/16/2018:
- Not enough time to do any work today.
- I keep running the tests and noting the ones that fail.
- Most failures can probably be resolved by adjusting delays and timers. It makes me wonder:
-- 1) If non-observable tests that also involve timing are as sensitive, or are they actually not written correctly
-- 2) Can I write a setup function to kickoff a couple tasks to try and create a "current" timing and then save as a variable to use by the tests.
- Could be worth a check on both... but not this immediate moment.

#159.2. 9/17/2018:
- So I ran an attempt of #2 and... it didn't work.
- I'm wondering how I can try to resolve this... I don't have many ideas off the top of my head.
- Tomorrow will be busy, so I won't get much done but I'll see if I can do #1 and just review tests that involve timing and try to figure out if any of them are as unstable as the Observable tests. Hopefully not.

#160.2. 9/18/2018:
- The only real spot where #1 could happen is the Collection tests
- But... the tests are for lock contention. Basically, it's either right or wrong, depending on what process gets to the lock first.
- So I don't need to worry about that as it's not: right, wrong, maybe?
- That was the most I got done today. I will need to decide tomorrow what I should do next...

#161.2. 9/19/2018:
- I had a rough morning because I was up late yesterday... I need to end things early. I didn't get a chance to "make a decision"... tomorrow.

#162.2. 9/20/2018:
- After multiple days of pushing back, I finally thought about "what to do"
- Basically: nothing
- The issue of failing tests happens randomly. I'd like to make them not-random, but the only way I can get 2 things to happen at the same time is with tasks/threads.
- Using tasks/threads means the test is at the mercy of the system's scheduler.
- Without doing some overly complex rewrite of observables to have triggers or events or something that says "go now", I don't know when I should run without simply specifying a hard-coded delay.
- In addition, the last 2 tests... I'm not doing. The one for CancellationDisposable usage isn't possible without writing my own long scheduler, and it's not something I expect to ever do.
- If somewhere down the line, I decide that I need my own scheduler, then I will write this scheduler and implement the test... but I don't need anything except the default schedulers right now, so I can't do the test. See the comment in the code about this.
- I also had "do long test"... I don't know what that was for. I may have something written in the logs that says what that is, but I'm not sure off the top of my head.
- Regardless, the best I can think of a long test is either: 1) running hundreds of values. 2) waiting for a value with an infinite observable.
- For 1) There shouldn't be a difference between short and long runs, so if it doesn't work with short, it won't work with long. And the only thing a long test would provide is "this works for a long time", and that will be quickly noticed during execution (and probably would be better spotted in perf. then a unit test).
- For 2) I essentially already wrote that.
- Thus... both are kindof unneeded for additional implementation.
- With that done (!!), I'd like to make a decision on if I _need_ to be able to switch between infinite and finite observables.
- I'll leave it there for tonight just so I have something to do tomorrow... and I'm tired.

#163.2. 9/21/2018:
- Ok, I can't really do any work tonight as I have a busy day coming up...
- So, a decision: I will give an attempt to switch between finite and infinite live observables.
- If I can't get it to work, then I have the slight challenge/annoyance of needing either 2 properties in ILogRegistry (finite and infinite) or needing a "get" function that takes an argument.
- I'm not sure if it should be just a change of type (obs.AsFinite()...), a testable type (obs.FiniteUntil(x => x > 30)...), or something else.
- Bonus: it's nice to talk about doing this, but observable operations don't expose the internal observable. So liveObs.AsFinite() would work, but liveObs.Where(x => x > 10).AsFinite() would not. So how would I walk the operation list and get to the root operations?
- Maybe... this is an IQbservable? This way at evaluation time, we can get the root observable and apply the request (or at least have a reference to it) while the rest of the operations occur later.
- For tomorrow... and probably the day after, to decide.

#164.2. 9/22/2018:
- I simply don't have time tonight... punting to tomorrow (as warned yesterday)

#165.2. 9/23/2018:
- Err... I finally get to this and, due to the past week or so + busy and long past couple days, I crashed.
- So... tomorrow. Again...

#166.2. 9/24/2018:
- So... I was sick yesterday and didn't realize it until about the time I wrote yesterday's quick writeup. Reminder to not to kill yourself with code.
- Also, I like where I ended #163.2, in that I think this is a IQbservable.
- At first I would just have a simple AsFinite()/AsInfinite() operator.
- Later I may add the testable type version which could be useful for cases where a log ends. Imagine: registry.Logs.AsInfinite().AsFiniteWhen(log => log.Message.Contains(": Shutdown Started"))...
- It may seem weird and unneeded at first, but the ability to say "run indefinitly" is great for logs, while knowing when to stop is great for log processing. It would be possible to say "this is a complete log, which means we can say that any IDs that match this are linked to this log, and all other IDs have nothing to do with this log"
- So... not needed for the home app/test, but needed when logs are run for days and days at a time.
- The only real way to make that happen is to evaluate it from a LINQ standpoint. We would be able to say "every operator, filtered of non-infinite/finite operations, is now fin, fin, infin, fin-when. Thus, run as infin, but pass a callback/ref to the wrapper used in fin-when so that when it finally triggers, we can inform the base-level live observable to switch to finite"
- It also means we have less of a problem with LINQ running on a encapsulation model, as we can say at execution time "this is the actual source" and operate on it to effect the operators that occur later.
- It means I finally get to go to onto a topic I keep staring at but never get to: writing a LINQ provider and implementing IQbservable.
- This will take a bit of time, but is a welcome change from infrastucture and unit tests... and putting off doing work because I don't want to write more unit tests for a bit.
- ...though, once I at least get something basic, I should at least to some TDD.
- Might just do some prep tomorrow... but then days after should be actual code.

#167.2. 9/25/2018:
- I didn't really get prep done. I just made a folder... not a whole lot that does.
- Tomorrow.

#168.2. 9/26/2018:
- So I went to start and realized... I don't really know where to start.
- Instead of winging it, I'm going to go with the approach I'm taking for this whole application: incremental work
- So I'm going to do/attempt this tutorial: "Walkthrough: Creating an IQueryable LINQ Provider" (https://msdn.microsoft.com/en-us/library/bb546158.aspx)
- ...adapting it to be used in an observable. I will change the "source" of the data, but then clean it up and start to expand it as I need it.
- One idea that crossed my mind, not sure how well it will work out, but have this be a middle-man-type system.
- As in, I don't want to go crazy with doing all the parsing and would rather have a real implementation do the work... so intercept the execution, get the values I care about, and send the modified query to the underlying implementation.
- An example: say we have a SQL-based log registry. I'm unaware of any IQbservable implementations for SQL... so do a normal IQueryable for SQL, get whatever I care about, and send the rest to the provider in SQL.
- Since I don't have any DB system yet, instead, I want to strip out the verbs I want (such as skip, take, AsFinite, etc.) and then let the existing implementations take care of the rest.
- It would only really work for types that don't modify type, but... first we do the tutorial, which I'll start tomorrow.
- Right now is a very basic implementation that is just a class with a couple interface functions defined. This will get replaced.

#169.2. 9/27/2018:
- I'm late, so for today I'm only doing the first step in the tutorial

#170.2. 9/28/2018:
- ...and this time I'm falling asleep. I got another section of the tutorial done and already know there's difference (IQbservableProvider vs. IQueryProvider)
- I will skip the server part and just return a constant execution of... something. But that's for tomorrow.

#171.2. 9/29/2018:
- So, I was a bit naive and understand better: the provider and queryable (qbservable) are specific to the data being handled.
- So in Stethescope's case (remember? That's the name of this thing), the LogRegistry or more specifically, the registry storage, would have it's own qbservable implementation and provider.
- Perhaps after some work, some generic functions can be determined where there's one qbservable and different providers... or maybe it's different qbservables and one provider. Depends... I think it's more likely to be different providers, as each storage will have it's own backend data that needs to be provided.
- As such, I will just copy and paste the tutorial (even though it's for a queryable instead of a qbservable), and then work on an actual implementation for ListStorage.
- It's interesting to see how the execution runs. I like it. And the example just so happens to deal with a list of data. I can see adapting this to return the live observable instead.
- I added "more complex query capabilities" and also inadvertently wrote a very basic word search index. Oops. I think it's cool, but would definitly not cut it in the performance department.

#172.2. 9/30/2018:
- Started working on a "real" implementation for ListStorage
- It probably won't be as complex as the tutorial... maybe.
- All I expect to do is to get the expression, find anything that skips a number of elements, get that value, and then directly return a live obersvable with an offset.
- Finally, modify the expression so it doesn't have the skip operator... and swap the ListStorageQbservable for the live observable and let it run.
- All the other stuff mentioned on previous days will be extra. Basic is just the skip code right now.

#173.2. 10/01/2018:
- So I tried to wrap my head around who owns what (does the qbservable own the underlying data source? The provider? Something else?) and decided on "something else".
- The general reason was that, well, the qbservable owns the data...
- But if someone takes the provider (that "describes a qbservable") and asks it to create a query for a random expression, the expression has no knowledge of the underlying data source.
- So then it's the provider that owns the data! But wait...
- If the provider owns the data, then the qbservable can be made generic. <done>
- So now the provider owns the data... but the execution happens in the qbservable. So then the qbservable is going to be created with the data, provided to the provider, then the provider will have the qbservable execute it?
- That doesn't sound right. It's a circular dependency. Perhaps there was a good reason why, unlike the standard Linq queryable interfaces, a qbservable provider doesn't do the execution.
- But there's an additional catch: nobody seems to have an explanation of who should do the excution. Most examples I see online execute somewhere else and let the queriable/qbservable and provider be a duo that enables compiler and programatic execution.
- So then out conclusion: something else owns the data.
- But I'm going to have a simple list, a DB, and who knows what else... I now need unique qbservables and providers?
- Nah, I already made the qbservable generic, why not make the provider generic too. Now I added a new thing: an evaluator.
- Simple: it knows it's data, and it takes an expression and turns it into the lowest form of data that is needed to execute: an observable.
- So now each storage can have it's own evaluator, which may know what it can and cannot optimize or process, and simply says "have at it" and then the generic qbservable and provider can be evaluated or produce custom expressions to be evaluated and handle all the wacky code for Linq.
- But I will start work on the evaluator tomorrow. For now, I have made progress that I am happy with.

#174.2. 10/02/2018:
- Nothing is implemented, but I wanted to give this a run. It worked but I saw some issues.
- Main one: my guess on the Provider was more then true, it's used for turning expressions into queries. What I didn't expect is that it's almost "automatic".
- `from v in data where v.Name.StartsWith("Steve") select v.Id;` does the following:
-- 1. Qbservable(<const expression>)
-- 2. #1.Provider.CreateQuery(Where(<const expression>, <lambda #1>))
-- 3. #2.Provider.CreateQuery(Select(Where(<const expression>, <lambda #1>), <lambda #2>)
-- 4. #3.Subscribe(<observable>)
- What this means is that if my goal is "replace <const expression> with the actual source of data", I need to be able to find that expression multiple iterations down the road.
- So I opted to add a type to search for. Similar to the tutorial code, I want the innermost value. Otherwise some sub-log data (embedded query) will suddenly have the the inner expression modified, while the outer one is left untouched and will error (maybe?)
- My attempt to do this meant that if #3 changes some type before #4, then doing a search for that constant will give me the outer constant not the inner constant... and again, we're error (maybe?).
- So I moved the type-storage to the provider, because that provider will be used for each query. And the source query is the data source, everything else is (probably) built upon that.
- So provider knows the data source type, I should be able to start on actual code tomorrow.

#175.2. 10/03/2018:
- I have an idea of how to do this. I blocked it out and got to work.
- While I made good progress, I wanted to ensure I wasn't writing throw out code, so I manually tested a bit.
- This is when I realized my error: Evaluate<T>, where T is... an observable of some type. Not the type used by the observable.
- I need to redo the code a bit to fix this, but it's late, so it's not happening today.
- I also need to do some work on the SkipCalculator (as I don't have any code that uses the skips, so I need to ensure that works (and define some tests while I'm at it, though they'll be implemented later)

#176.2. 10/04/2018:
- I had a lot to do tonight and have a busy day tomorrow. I need to skip tonight. I'm tired enough I can't focus on getting the type-issue resolved
- Also, next couple days/week will be only minor work as I'm going to be busy

#177.2. 10/05/2018:
- I got to this late but was trying to work on it earlier in the day... I didn't succeed.
- So this has become an interesting problem.
- Basically:
-- Expression of type ILogEntry is made.
-- Expression passed into CreateQuery along with a new expression.
-- Eventually, the expression type changes (IObservable<ILogEntry> -> IObservable<IGroupedObservable<object, ILogEntry>>)
-- This means that the "T" in the generic has gone from ILogEntry to IGroupedObservable<object, ILogEntry> (which is effectivly IObservable<ILogEntry>)
- So the challenge now is: how do I get the lowest original input?
- Answer: I don't!
- This isn't a generic. The original data source isn't type T, it's type ILogEntry.
- I save the original expression type so that I can find it later and replace it with the data. But since the data isn't generic, I can skip the generic and just treat T as ILogEntry.
- The one challenge I can see is I want to do a test early on type... but this isn't actually hard, just a GetType iteration.
- So my original challenge is actually pretty easy. If/when I make a generic version of this solver, then it will be a bit of work... but not right now.
- And... I started working on it and the type element is a bit much for me at this hour, so I will work on it tomorrow.

#178.2. 10/06/2018:
- I was having difficulty with Type, and it became really late again. So I will have to do it tomorrow... Err...

#179.2. 10/07/2018:
- I did some thinking and realized: I don't need this type check.
- The type to check isn't <T> it's "sourceType" and sourceType only exists as a "hey, this is the type to remove", and that type should already be known as the evaluator has a specific constructor so it's known that the specific data will be used.
- With that finally done, on to the next part: the SkipCalculator.
- Already, an issue: Original plan expected a depth-first search of graph traversal, but ExpressionVisitor is programatic in the different expression elements choose how to visit and evaluate.
- This means that "source.Concat(extra).Skip(10).Where(b => b.True)..." becomes "Concat(Skip(Where(..., <lambda>), 10), source, extra)" and evaluates: Where, Skip, Concat
- So my original plan of "source, concat, skip, where... stop executing because the where will screw things up" needs to actually be "<maybe a skip exists somewhere...>, where... ok we need to reset the counter because a where will screw things up, skip, concat, source"
- If there's anything I dislike (about both approaches) is somehow I need to check everything... does this function do an evaluation or is it an identity-type function? It doesn't do a "skip" for us, does it?
- That's what makes this weird. There is the chance that we can't do any optimization, and that's fine. It's just sad that nothing could be done.
- But there's an additional task: getting an amount of data to skip means we don't need the skip. We don't want to double-skip, so we need to remove them.
- I will do that work later because the next couple days, I may not be able to work late, but also because that comes across as more of a reduce operation then a update/modify operation (which is most common with ExpressionVisitor).

#180.2. 10/08/2018:
- I removed the processSkips boolean in SkipCalculator.
- I then started working on a proper implementation... but realized this will take more time then I can do right now.
- I will do it either slowly over a couple days, or once my event is done and I have time.

#181.2. 10/09/2018:
- Bit of work to ensure that the proper skip amount is known and reset if user lambdas are used.
- That's all for today.
- ...forgot to commit last night. Commiting early this morning.

#182.2. 10/10/2018:
- So there is one thing I need to do, and one I want to do.
- Need to do: modify the expression tree to remove skips.
- Want to do: the skip calculaor and the tree modification should have the same logic, just have different results.
- "Don't prematurely optimize" So I'll skip the want for now...
- I started working on the tree modification. I got somewhere and have an idea of what to do, but I need to get the state logic flags right.
- I see 3 stages:
-- 1. <random call><one or more skips><random call>
-- 2. <one or more skips><random call>
-- 3. <random call><one or more skips>
-- 4. <one or more skips>
- Wait, I said 3. Why are there 4 listed? Because if I can get 1-3 done, the 4th should happen without any work and thus doesn't need to be tested.
- The stages are to hit edge cases on what can happen.
- That is why there is "state flags" because what might previously be handled when no skip is found, suddenly becomes "we have to handle this outside of the processing functions" and thus state is needed to check.
- I didn't get it working. I got down the tree, but not back up. So <call 1>(<skip 1>(<skip 2>(<call 2>))) got to <call 1>(<call 2>) but then when processing <call 1>, the state I was tracking didn't do what I expected and I ended up with the original expression tree again.
- It's also late (I'm trying to be done earlier), and I don't see it being done quickly... so I will work on it tomorrow.
- Pay no attention to what I was doing... I tried planning ahead, then saw the time and started just throwing state combos at the wall to see what sticked... and then just stopped. So the code is weird and may be "why would anyone do this?" right now.

#183.2. 10/11/2018:
- This code gives me a slight gag reflux.
- Read it and tell... well, pretend I'm listening, but tell me you understand what the heck is happening?
- What is happening?
- Basically, I iterate through the tree, then when I realize I need to skip functions, I start to skip them. All other functions get pushed into a stack.
- As I finish iteration, I pop expressions off the stack. If there was an expression to use, I return it. Else, I return the `Visit`'s child.
- It works and meets all my test cases... but it is hard to understand from looking at, and there is probably a better way. No, there is a better way... I just need to think about it.
- The "better way" that popped into my head is to do 2-3 passes. First pass I just determine if there are nodes I can skip (ironically, called Skip).
- The last pass I re-visit the tree, but if I encounter a node I don't need, then I return the prior visit's child. There's probably a bit of state so that if I have started to modify the tree, I know to modify the arguments again, otherwise I'll get the original tree again.
- The "maybe" middle step? Just look at the list of method calls and determine if there's anything to remove.
- It may just reduce function size and make it easier to read... which is Very important. Experienced programmers have hit this, novice's, pay attention: one day you will find code that people will say "we don't know how it works, it just does" and you will stare at it and go "but I need to modify it...".
- If code is not readable or maintainable, it will be worked around with hack after hack.
- Bonus with the code I wrote right now: all but 3 tests pass. Woot! Will rewrite tomorrow...

#184.2. 10/12/2018:
- I was planning on doing the refactor... but it was late so I decided to just write a log stating that and going on...
- Then curiosity got the best of me, for the failing unit tests.
- Issue has been found and resolved. 100% unit test passing (though still flaky when running all tests)

#185.2. 10/13/2018:
- I prepared to do the refactor of the Skip... stuff, when a nagging thought came to em and I realized I would be stupid to ignore it.
- I should write unit tests for this.
- I started working on the unit tests so I could ensure the current version worked, and that the new version will continue to work.
- I won't finish it today, simply due to time, but hope to finish it tomorrow.

#186.2. 10/14/2018:
- I'm trapped in a time loop where I keep thinking I did stuff on this project today, but then keep finding out I didn't when I go to commit
- As such, I'm breaking out by leaving this status and working on the unit tests tomorrow.

#187.2. 10/15/2018:
- I'm late... and I was thinking "I may have to move this to tomorrow" but decided to at least do a couple tests, since tomorrow will be short
- I figured out what lambda tests I wanted, though the end result should still be "it works"
- But the point is to try a bunch of combos to see if everything works when evaluating it
- Perhaps once additional evaluators are created, all these tests will be refactored to functions, and the tests will simply create different IQbservables.
- One thing I did realize is that this is just going to bloat Observable tests... so to make it easier to isolate, move it to it's own test fixture
- That's where I'll end it tonight.

#188.2. 10/16/2018:
- Couple additional tests.
- As the story goes... Was planning on doing more, but one evening event took longer then expected.
- Tomorrow...

#189.2. 10/17/2018:
- Finished the unit tests
- Only issue is one of them fails...
- I did a quick look and went "this requires more time" since everything appears to be working, but the numbers I expect and the numbers I get are different.

#190.2. 10/18/2018:
- Figured out the bug. Apparently it was a "quote" instead of a "lambda"
- That fixed, we're all good with the unit tests.
- Only thing... that's all I can do tonight.

#191.2. 10/19/2018:
- So I could say a lot here... but I won't because, basically, I'm writing some code and seeing how I feel about it.
- A challenge I have is handling complex operations, in a repeatable fashion, that have a logical set of steps... AKA, a state machine.
- So originally, as written #183.2, I went "I can just do a couple stages. One to gather, one (optional) to analyze, and one to count/operate"
- This sounds easy, but I must look ahead: I'm not just dealing with Skip and a count.
- What happens when I start going "I have to make exceptions for 30 functions, do an extra operation... and do this 2 or more times: one for getting info, one for modifying the expression tree, one for... something"
- That's gonna be very ugly. Do I start making many sub-functions so I invoke the "main" function, which does a Visit, which invokes a stage, which calls a test, then does something else, then invokes another stage, etc.?
- I can't say I won't... but trying to represent this logically, and in a way that I can modify to do a bit of that sub-logic differently will be... hard.
- Where I am now: counting how much to skip and removing these skips are two classes. I don't know if I want to do both in one class, if I want to keep them seperate, or if I want to do something else (that I haven't determined)
- A state machine (with some arguments) would allow me to say "execute 'this' particular state machine" and have it take some argument/logic unit that, for this, is one or more lambdas that do the specialized action.
- I'd be able to know the logic will run the same for both, and the lambdas would allow the results to be different.
- I could do the seperate or the combined operations AND they would look like a set of small functions that do easy to understand operations, and they could be mixed and matched. Basically a functional programming-style state machine.
- Sounds like something some college/university student would go "that's cool! Do it!"
- But as someone who is known to have minimal amounts of time, and has worked for a number of years, I know the answer: it depends.
- The system sounds great, but it is a fare amount of overhead, and it would require implementing a state machine system or finding a library (and that library might now work the way I want).
- Is it worth it? "Find out in the next episode" because I have other things to do.
- Tomorrow I'll try doing the system I wrote for the tree modification. If I have time, I'll turn that into a simple state machine. If things work out, I'll consult some friends to see if they're horrified or go "that's awesome" or something in-between.

#192.2. 10/20/2018:
- Ok, managed to get SkipTreeModifer switched to the pesudo-state machine.
- I had a short chat with a friend (waiting for others to provide opinions) which basically went "a complex recursive function is worse then a state machine"
- The next thing I'll try is to figure out/find/make a state machine class so I can start to focus on "how to make this code cleaner/more compact"
- If I like the code, I'll keep it (may keep the state machine code anyway). If I don't, or the friends can convince me otherwise, I'll comment it out at least until I start adding more functions.
- If I commented out, and add more functions and it becomes too complex, I'll switch to the state machine. Else it will be the implementation already and I'll remove the commented code.

#193.2. 10/21/2018:
- Ran out of time today...
- The goal today, which I'll move to tomorrow, was figuring out the next stage of going to a state machine for processing.
- All but one individual that I asked stated they found a complex recurisve function worse then a state machine.
- The one individual then stated they believed the state machine was more complex based on how it would be traversed efficently in parallel and handle groupings of possible states.
- I took that as "if you execute a state machine multiple times in parallel, it the handling of state and processing would be very complex and may make the state machine worse then the recursive function"
- They backed it up with https://swtch.com/~rsc/regexp/regexp1.html (there example was also regex).
- I pointed out that I would be running single threaded (I may want to add a lock to enforce this) and they responded "then complex recursive would be more complex"
- But it made me curious: I don't know what the future would entail. Should I write my own state machine to fit my current plan? Use an exisiting one that may vastly exceed what I need right now but may fit the needs in the future? Do I continue with a compact recursive function and adjust later?
- Technical superiority/perfection isn't the goal, maintainability is.
- Most of the other parts that have been written were written as "this is what I want" and adapted as needed.
- But the most important part of this whole system is being able to take this stream of logs and determine, for example, "this specific set of logs is really just the log-equiv. of a stack trace starting from this function"
- 1. That's hard. 2. I need to be able to take gains where I can find them.
- As such, I need to run queries and expressions. The less work I need the query to do, the better. It means one less thing to fail, one less thing to trace, less memory and CPU time, etc.
- But to complete this will mean the full end-to-end system will have a complex mid-section, that needs to be efficent and not prone to error.
- And to bring this full circle, to ensure that requires the code to be maintainable.
- Letting .Net simply execute a full expression is a nice fallback, but as time goes on the "optimized" system will need improvement.
- Which... oh, this went on much longer then expected. In short: things are going to get complex, need to be maintainable, reduce resources, and it's unknown what the best path is.
- As per other implementations, I will see as time goes on. If I suddenly end up with a PoC that doesn't go much further then Skip... then besides rewriting/combining the Skip* classes, I'm not sure the state machines will be needed. But I'll learn that as I go. Perhaps I'll be going "why did I think I could do this with a recursive function?"
- Last thing before my tiring-mind keeps repeating itself, state machine impls:
-- Custom (ideally, let me define a state machine that can be used/altered by arguments so that I can define/update it once, but what happens can change for whatever purpose I have for it)
-- Stateless (https://github.com/dotnet-state-machine/stateless), seems it may go further then I need right now... but may be ideal for long term
-- System.Activities.Statements.StateMachine (.Net native, http://msdn.microsoft.com/en-us/library/system.activities.statements.statemachine.aspx), good that there is a built in one... but info seems to only present it as being built with a utility which may reduce it's reusability.
- Also forgot, based on the earlier conversation, I wonder if there's any merit to supporting parallel state executions or "grouping" (whatever that is...). Would I eventually end up with the evalulator passing the expression into a "big" state machine and either the original expression is returned or some (super) optimized one? Sounds nifty, but is it ideal?
- Cutting myself off now...

#194.2. 10/22/2018:
- So I thought for a short bit and will try Stateless. Based on the description, it was supposedly written to be simpler then Windows Workflow (System.Activities.Statements.StateMachine).
- It doesn't really work the way I envisioned, and will need a wrapper, but it also is probably the most flexible for my needs at the moment.
- And I don't need to spend the time to write my own state machine...
- 2 thoughts have nagged me:
-- 1. Can I do the entire LINQ evaluation (at least for ListStorage) as one large state machine?
-- 2. What the heck does this look like?
- For #1: this needs a picture
- For #2: I made a picture (Docs/LisStorageEvaluatorLINQStates.puml) which is in PlantUML format.
- The picture made me go "yes, it is possible... though a wrapper is needed" and "I want some others to take a look and determine if they see a state machine or a flowchart"
- In some ways, it looks like a flow chart to me... but state machines are basically flow charts. Or is it flow charts are basically state machines?
- Regardless, I have something I can reference when I go to rewrite code. I won't have much time tomorrow, but I'll see how far I can get.
- I think my first step will be combining the two classes so I only have one to need class to do work on/use.

#195.2. 10/23/2018:
- Yea... I don't have the time tonight.
- I probably could, but I need to fix my sleep schedule and this won't help it right now.
- Tomorrow.

#196.2. 10/24/2018:
- And tomorrow came... and the code was finished :D
- I combined the two skip classes, made it a bit more functional (very very minor bit...), and reduced the amount of code that the evaluator actually has.
- All the tests passed but... I've had another nagging thought: is it working?
- Like, the tests pass, which means it does what I want it to as an end goal. But did it reduce the expression to?
- I'll... figure that out tomorrow. After I know everything works, then I'll go on to the actual state machine work.

#197.2. 10/25/2018:
- Started looking through Stateless.
- Didn't get very far... and this is about the most I can do tonight...
- Next couple days will be short.

#198.2. 10/26/2018:
- I got to this too late. I need to look at how to setup Stateless.
- It can do a lot... I just wish it could store some variables.
- How do I basically say "I'm in this state, store/use this data" so I can just say "here's a state machine, Fire this off... then get me the internal data.
- Just... something to prevent me needing to store a global state. It would make it a self-contained system.

#199.2. 10/27/2018:
- Unfortunetly I am unable to get the time tonight.

#200.2. 10/28/2018:
- For day 200 (...ignore the days I didn't get to doing work...), we have a state machine.
- I read through some blogs, looked at code, and got through all the functions that the state machine had.
- I was iffy at first, but I think I got the hang of it.
- I need to do the actual implementations and then we'll see if everything goes according to plan.

#201.2. 10/29/2018:
- And... everything is now implemented. And it passes unit tests :D
- 3 things:
-- 1. I turned the one "big pain" into a small class (the ExpressionVisitor doesn't have state, so if I want a simple function that I can say "visit and do X" I'm stuck with coding the decision logic. This way it's a generic lambda)
-- 2. Right now there's this external state that pains me a bit. Assuming the code expands, there will be additional states or sub-SMs. I can either make an outer SM, or be able to keep state info internal. I realized I could use TriggerWithParameters to carry the state between states... but I'm not doing that yet.
-- 3. I had a moment... where I didn't finish the state machine (it basically did setup) and I ran a unit test instead if debugging it. And it passed. This caught me as bad because it means I don't know if my code is actually doing the work or just acting as an identity function. As such, I need to work on the unit tests so without the skip processor, it fails.
- I won't have a lot of time tomorrow, but I will be doing #2 and #3 next... not sure if in the same order.

#202.2. 10/30/2018:
- Technically I should do the unit tests first, but as stated yesterday, the external state pains me.
- Fix the pain... Stateless is very cool in the sense that it's quite flexible and since it doesn't maintain it's own state, you do all the work for state management.
- This means, in the skip processor's case, I will pass the state via paramaterized triggers.
- I got a good portion working, but have other work todo.
- It's questionable if this is needed, but a self-contained (to an extent) state machine could make it easier to work with in the long run.
- Why? It basically becomes a functional programming language. There is no external state that needs to be tracked, just the state itself.
- It plays into (potential) future expansion where new states or components result in an additional state of trigger usage... but nothing else changes. No additional "but if coming from this state, don't do this" logic. A temporary oddity results in easier to maintain code.

#203.2. 10/31/2018:
- Ok, it's not perfect, but the state machine now has it's own "immutable" internal state that it passes around.
- Basically it's a funtional-style state machine (someone is gonna yell at me over this... I know it)
- I didn't get to working on the test expression comparison, but I'll do that tomorrow.
- This was more then I expected. I still have to compare execution between the recursive and state-machine implementations (and I'd like to time it too).
- Todos: unit test exprssion comparison; compare recursive and state-machine implementations; move on to more advanced implementations(?)

#204.2. 11/01/2018:
- Got a partial wrapper for expression comparision but forgot that there will be at least on const replacement internally... so the comparision will always have the same result.
- Once I fix do something about that, I can call the code done and go on to the comparisons and advanced usage.

#205.2. 11/02/2018:
- Finished the expression comparision.
- Now, just to prevent confusion, I compare the expression strings instead of the expression because, AFAIK, 2 expressions can be the same but have different structures (consts and values and whatnot).
- So the Expression comparision would always say "different" but the string comparision would say "same".
- Maybe something to look at later, but for now, that's all I'm doing tonight.
- Tomorrow I may not have too much time, but I'll try to do a comparsion between state machine and recursive implementations.

#206.2. 11/03/2018:
- Today just... ran out of time. I tried at one point, but spent it staring at the code instead of doing anything.
- Tomorrow.

#207.2. 11/04/2018:
- And... push back to tomorrow.
- My mental prep for the comparision tests basically got me to go "this isn't something I can do in a couple min. Will be an hour or more" and I don't want to spend that hour "now"

#208.2. 11/05/2018:
- And... I did something today.
- Minor: I didn't have the time to do the main work, but I did need something for timing...
- Luckily, there's already a metrics collection code written so I don't need to do any work in collecting the times.
- Main time I want to know is how long it takes to evaluate. Subscription atomics should be negligible since no execution happens until the schedulers decide to.
- So with non-implementation specific metrics setup... tomorrow may be busy, but I'll see.
- Plan is collect a couple execution runs of the state machine. Then make 2 branches: one will have the original 2 recursive classes. The second will have the middle-ground; recursive/fake-SM single class. Collect stats from those and compare (along with lines of code and general complexity)

#209.2. 11/06/2018:
- Ok, this time, I had the time...
- Instead I was catching up with election stuff (there's real stuff outside these screens)... I'll try again tomorrow

#209.2. 11/07/2018:
- So I actually managed to get the "fake" state machine implemented, and all unit tests passed without modification :D
- I was thinking to maybe to the real original impl, but decided I would call it a night at that...
- ...then I started to gather stats.
- But I realized a potential issue: when I go to do the measurements, I measure the subscription time.
- This may not seem like an issue, except there are 2 bad measurements that could occur:
-- 1. I have one non-standard function, and that function could be running differently... and the results could skew the rest of the measurements.
-- 2. Subscribe time is not what I want to measure... I want to measure how long it takes to "Evaluate" an expression. I may be getting "lock the IScheduler impl's queue and enqueue this request for execution"
- I'll have to resolve those issues tomorrow (though I see a more likely case of me implementing the final experimentm, and then doing the metric fix later)

#210.2. 11/08/2018:
- Did the second branch and got the original recursive code implemented.
- The good news? It also passed unit tests!
- I'm behind on some things today, so I'm going to work on the fixes for the measurements tomorrow.

#211.2. 11/09/2018:
- Fixed #1 for consistancy
- Next up: benchmark fixes.
- So, I realized I can't leave this permanent... and I can't think of a good way to do otherwise without implementing a debug implementation (which I don't want)...
- ...but I require calling Subscribe twice. First time just runs the expression evaluation, second time will actually subscribe to it.
- Now, to see if it matters: yes.
- I did 3 runs with and without the "evaluate only" code. Numbers:
-- Total evaluations: 30
-- Evaluation only:
--- Average "total time": avg(83+72+65)=73.33ms (~2.44ms per eval)
--- Min time (one evaluation): min(0.03, 0.03, 0.04)=0.03ms
--- Max time (one evaluation): max(73.22, 65.21, 56.52)=73.22ms
--- Average std-dev of the 3 runs (that doesn't sound right...): avg(13.01+11.68+10.12)=11.60ms
-- Evaluation and Subscription:
--- Average "total time": avg(250+152+201)=201.00ms (~6.70ms per eval)
--- Min time (one evaluation): min(0.66, 0.49, 0.56)=0.49ms
--- Max time (one evaluation): max(132.82, 109.53, 113.54)=132.82ms
--- Average std-dev of the 3 runs (that doesn't sound right...): avg(23.65+19.42+19.99)=21.02ms
- Stats are not my strong suit, so forgive me if I did it wrong.
- Given that the difference is more then or near a factor of 2, I only want the evaluation results.
- Also, while the normal build stat (eval and sub) won't get the same numbers used in the benchmarks, it would at least return the numbers that people will actually have when they run this.
- Next up: grabbing the numbers from the other branches.
- ...it's late, I'll get the numbers tomorrow

#212.2. 11/10/2018:
- Results:
-- fake-sm
--- Average "total time": avg(14+12+13)=13.00ms (~0.43ms per eval)
--- Min time (one evaluation): min(0.02, 0.02, 0.02)=0.02ms
--- Max time (one evaluation): max(10.14, 8.48, 9.80)=10.14ms
--- Average std-dev of the 3 runs (that doesn't sound right...): avg(1.84+1.52+1.76)=1.71ms
-- recursive
--- Average "total time": avg(12+11+11)=11.33ms (~0.37ms per eval)
--- Min time (one evaluation): min(0.02, 0.02, 0.02)=0.02ms
--- Max time (one evaluation): max(9.30, 8.30, 7.81)=9.30ms
--- Average std-dev of the 3 runs (that doesn't sound right...): avg(1.68+1.50+1.43)=1.54ms
- So... this is fun.
- So, from an evaluation POV, the real state machine is 5.5-6.5x slower then the fake state machine or recursive function.
- On top of that, the real SM is 345 lines of code (LOC), fake SM is 194 LOC, and the recursive function (which is 2 classes) is a total of 143 LOC.
- Now, if I had to go from LOC + perf only... I'd go with the fake SM because it doesn't repeat functionality between 2 classes and only has a minor perf hit while breaking up functionality.
- But there's a small catch with if I revert back to fake SM or use the real one and take the perf hit: I don't believe expression evaluation to be a bottleneck for execution.
- "Explain?"
- First, Pros and cons for the state machines
-- Real
--- Pro: Easily extensible, can inspect graph to ensure it meets expectations, library can possibly be sped up, logic can be followed, formal design that can be viewed and maintained
--- Con: Slower by an avg. factor of 6, larger file, relies on an external library.
-- Fake
--- Pro: Faster by a sizable amount, smaller file, self contained, easy to understand in concept
--- Con: Can't tell at a glance how the program runs, is informal (and some will question "can't you use a real SM"
- Second, How often will this run?
-- This... can't really be answered. But the way I see it, the largest evaluations whould only happen upon user change.
-- Like, the user adds a new server to pull logs from. It generates 1-x expressions that need to be evaluated.
-- "What about when the result of an expression is operated upon?" well, unless the C# compiler decides that every time, say, group has a new key, it needs to create a new expression, it will create one expression and evaluate it once. We then calculate the result and save it.
-- Which is why, if my understanding is correct, user action is the only time things will happen.
-- Thus, expressions won't evaluate too often... and processing time isn't too much of a factor.
-- Minor: also, remember that the evaluate/subscribe operation takes over 2x the amount of time as just evaluate. So the time savings still has a floor of total execution time.
- So if time isn't really a factor, then it comes down to... "the real state machine has a larger source code file"? Basically.
- There are a lot of additional benefits to using the real state machine over the fake one.
- Now it does mean that if I start doing dynamic evaluations (totally possible), and they happen very frequently, the fake state machine may be a better option. Or... "why not both?"
- What if, for the built in types, the real state machine is used. With all it's depth and inter-connected-ness or whatnot. But then for dynamic expressions, just use the similar code that will evaluate a lot faster (hoping that user-defined expressions are short lived)
- TL:DR - benchmarks are useful, but speed of evaluation may not actually be important... in which case the older impls. just don't have the benefits of the real state machine. So I'll keep the current impl.
- What's next? I need to check... it's late, I'll look tomorrow.

#213.2. 11/11/2018:
- I spent today reading backwards and will review:
-- #101.2 (minor...)
-- #102.2
-- #163.2
-- #166.2
-- #168.2
- Namely, these are ideas for what to do next on observable evaluation.
- Outside of evaluation, I want to determine if I can finally move the ListStorage to use the evaluator instead of "AsQbservable".
- If that can be switched, and all tests pass, then I want to make sure that the application actually works. (It did before, but haven't tested since before the evaluator was written)
- With that, I just need to decide (there's a lot of deciding here, isn't there?) if I should go onto "write expressions to do actual log evaluation" or "continue working on more and more evaluation improvements".
- Decision: write expressions. As they're written will determine what evaluator updates should be done.

#214.2. 11/12/2018:
- I still need to review the days I listed yesterday, but in the mean time, I have switched ListStorage to use the real Qbservable system.
- All unit tests passed and the Tracker program ran without issue.
- As such, I wanted to ensure there was no difference between the Qbservable and non-Qbservable versions of Tracker.
- I was short on time, so I didn't want to figure out how to run Tracker (which, being a .Net Core app, lacks an executable)
- Instead, I opted to add a new Printer that could print to a file.
- It can use some work, but otherwise works well.
- I have it append, though I'm not sure if it needs to.

#215.2. 11/13/2018:
- Forgot to mention yesterday, I don't have the time today... tomorrow!

#216.2. 11/14/2018:
- Yea... so the reason I didn't have time yesterday... I ended up basically doing stuff from sundown to sunrise.
- I was exhausted and had was going to push this work off...
- Then a family emergency occured and I'm now quite some distance away... so I'm defenitly pushing things off
- I'll post statuses, but I'm not sure when I'll get the time to do work on this for a bit.

#217.2. 11/15/2018:
- Just so it's known, circumstances have basically prevented me from doing anything besides read articles off my phone.
- I manage to get on long enough to write these statuses and then I'm done for the day.
- Err...

#218.2. 11/16/2018:
- Ok, I have a end date for everything going on right now.
- I'm "free" again in 2 days but I'm not sure I'll be able to work on this then.
- But I'll figure that later.

#219.2. 11/17/2018:
- Again, pushing off...

#220.2. 11/18/2018:
- I'm back!
- ...and didn't write code...
- Instead, I reviewed the writeups I had done previously (list from #213.2) and made some notes.
=Notes=
SkipLast
`Where(log => log.Timestamp > <time>)` (or `SkipUntil(log => log.Timestamp > <time>)`) because it means internally we can do `for(int i = col.BinarySearch(<time>, <special comparision>); i < col.Count; i++) { ... }`
Do I want to handle "All" and "Sum" or similar?
type (obs.AsFinite()...), a testable type (obs.FiniteUntil(x => x > 30)...)
^^ maybe see if I can grab some element that, upon trigger, will affect the inner observable. As in, on queue, notify to the dataSourceObservable (inside ListStorageEvaluator) to change types.
...still need to ensure that it's done per-subscription and not per-observable
AsFinite()/AsInfinite()
registry.Logs.AsInfinite().AsFiniteWhen(log => log.Message.Contains(": Shutdown Started"))...
Middleman system for the DB IQbservable so that I can grab the variables I care about, modify the expression, then send a modified expression to the DB and/or have the DB's usual expression run while I modify/add to it's results.
=======
- Now, I need to do something with those notes... but that's for tomorrow :D

#221.2. 11/19/2018:
- I got to this too late, but I wanted to figure out if I could at least implement/plan SkipLast.
- It's "a bit harder" because it means I would need to buffer results by N amount otherwise I never know if the source will end or not.
- It's not "clean". If I know the source length, I can use that. But if not, then it's hoping I actually skip the remainder.
- It could also be memory intensive because of the buffer, and I dislike the potential of time-delay on publication.
- But... if you can tell, it's not simple, and I already said it's late.
- Tomorrow (though it will be short, as every Tuesday is).
- If I can't do this tomorrow, I may try to at least figure out what queries I want to write for actual execution.

#222.2. 11/20/2018:
- Err...
- I had plans to do work, then slept in (it's the first of multiple holidays here... staying up late and sleeping in the next day are normal)
- ...then took a little longer then expected to do some tasks, missed a train, made an appoitment I realized I needed, and by the time I got to this, I would only have a few minutes...
- So I pushed it off, thinking I could get to it later, but I want to break the "stay up late, sleep in" cycle for once as it's made up and it's not just a shift of a sleep schedule
- You actually can't get as much done. Right up there with being able to drink and code... you're going to be asking yourself "what was I thinking" when you wake up
- So... need to push off again.
- Err...

#223.2. 11/21/2018:
- Stop me if you've heard this one before:
- I wanted to code, but it's late and I need to go to bed...
- Heard it before? Now for the twist...
- I wanted to code, but it's late... so I couldn't do the SkipLast (#221.2, #220.2).
- Then I thought "maybe define what expressions are needed to get the data I want", but... I don't even know what I want.
- So, I daydreamed about how I would pitch this app (remember, I wanted to write this for work. So I imagined doing a tech talk about how to use this).
- Part of the way through, I realized "I'm not trying to figure out everything about this program", I'm just trying to think of what expressions to write and "what's next".
- I wrote this:
=Notes=
Stats on what functions are used in expression evaluation (so I know what I should focus on more for optimization)
Update tracker to print async (print as it reads, perhaps a way to early out)
Progression:
1. Print the logs as recieved
2. Print functions (only the first time...)
3. Print functions (only when the known functions change, so when new branches are found, so we need to start a DB of functions)
4. Print stack trace (try to determine when functions are called by other functions)
Start to try and parse log values to better do #4 (define the "format" for a line to be parsed)
Group together print functions/actions so that they can be used as needed and not just for a stream-print
Paramaterize them... this way I can say "show me all calls to a specific function"
Do some LINQ expression evaluation updates (see notes from #220.2). Possibly work on the infinite/finite switch mech (this way we can read a function, then say "this function is done" if all log lines are within a known function and only do the "new" notification when something isn't in it)
Try to start cross referencing data between threads based on what is parsed in logs + known functions.
As it's expected there's some system maintaining lists of functions, call stacks, and log-line specific parsing info... have some background processor that will retroactivly update stuff. This way if half a function gets parsed and returned while the first half is "too old" for the live observable, all log statements will be processed. Also possibly requires log registry to have user-data that can be applied for a log line (and maybe a way to say "this has been updated")
Make all the collected/calculated info exportable so it can be re-loaded as needed.
See if I can mark (manually for now) the start of an invocation (such as a user connecting to a server or application startup) and tracing it's entire execution between multiple threads
Now try to do ^^ automatically (do the stack trace backwards, where does the first moment of invocation occur) and record starting points
Additional grouping to do a histogram of how common an error/line/etc. is in for a specific file, function, program, log, etc.
... (I'm not trying to writeup everything... just a "what to do next")
Something something build a list of good executions and then when something deivates, point this out
Also, any way to find all similar exections? Like, if a specific branch is hit, how many other times is this invoked? Also, if something goes wrong, how many others had the same issue?

File browser (connect to multiple remote machines, then use a file browser to basically say "open this specific file" or "open this log within this timeframe")
=======
- Tomorrow will be tough, but I'll see if I can at least get expression stats written.

#224.2. 11/22/2018:
- So, I started working on the expression stat... and then got distracted and learned I needed to get up early. Joy.
- I will finish it tomorrow.

#225.2. 11/23/2018:
- Ok, I was able to finish the metric/stat collector.
- Realized I was looking for "Counter" and not Histogram.
- Also, seperated out the expression visior that has a callback instead of it being an embedded class for SkipProcessor.
- ...that was the point yesterday when I went "I don't have the time..."
- In the mean time, I got some nice stats for expression evaluation within the unit tests:
    [<computer> - ListStorageEvaluator] Expression Methods
             Count = 125 Commands
       Total Items = 8
            Item 0 = 01.60%     2 Commands [System.Reactive.Linq.IQbservable`1[TSource] LastOrDefaultAsync[TSource](System.Reactive.Linq.IQbservable`1[TSource])]
            Item 1 = 03.20%     4 Commands [System.Reactive.Linq.IQbservable`1[TSource] SkipWhile[TSource](System.Reactive.Linq.IQbservable`1[TSource], System.Linq.Expressions.Expression`1[System.Func`2[TSource,System.Boolean]])]
            Item 2 = 06.40%     8 Commands [System.Reactive.Linq.IQbservable`1[TSource] Skip[TSource](System.Reactive.Linq.IQbservable`1[TSource], System.TimeSpan)]
            Item 3 = 09.60%    12 Commands [System.Reactive.Linq.IQbservable`1[TResult] Select[TSource,TResult](System.Reactive.Linq.IQbservable`1[TSource], System.Linq.Expressions.Expression`1[System.Func`2[TSource,TResult]])]
            Item 4 = 13.60%    17 Commands [System.Reactive.Linq.IQbservable`1[System.Reactive.Linq.IGroupedObservable`2[TKey,TSource]] GroupBy[TSource,TKey](System.Reactive.Linq.IQbservable`1[TSource], System.Linq.Expressions.Expression`1[System.Func`2[TSource,TKey]])]
            Item 5 = 19.20%    24 Commands [System.Reactive.Linq.IQbservable`1[TSource] Skip[TSource](System.Reactive.Linq.IQbservable`1[TSource], Int32)]
            Item 6 = 21.60%    27 Commands [System.Reactive.Linq.IQbservable`1[TSource] Concat[TSource](System.Reactive.Linq.IQbservable`1[TSource], System.IObservable`1[TSource])]
            Item 7 = 24.80%    31 Commands [System.Reactive.Linq.IQbservable`1[TSource] Where[TSource](System.Reactive.Linq.IQbservable`1[TSource], System.Linq.Expressions.Expression`1[System.Func`2[TSource,System.Boolean]])]
- I will see if I have time to do anything tomorrow. Last event of the month.

#226.2. 11/24/2018:
- Plan: do some work
- Reality: got back to my home late, pushed tasks from today to tomorrow morning, and thus need to end early
- Result: I wasn't sure if I could do anything today, and while I planned to, turns out I couldn't.
- Tomorrow

#227.2. 11/25/2018:
- Another day, another "I don't have time" day...
- But I wanted to do something, so I checked #223.2 and saw "make Tracker async" and thought "that shouldn't be bad"
- While doing that, I came to the realization that I haven't really done any async work and there are other small tasks todo.
- So as an ammendment to #223.2
=Notes=
- Do more work on IOPrinter with async and print modes
- Parser should also be async
- Tests for async...
- Need to change UserConfigs to AdditionalConfigs or something (needs a better name)
- Need to formalize config values (will these be globals? I'm thinking yes because other configs can be created)
- Need way to clone config (this way a primary config can exist and extra configs can be added later without affecting the primary config)
- Need way to clone an ILogEntry to another registry (primaryRegistry.Logs.<query>.Subscribe(log => queryRegistry.CloneLog(log));)
=======
- So I want to finish async code for IOPrinter tomorrow, then I'll move onto the other tasks.

#228.2. 11/26/2018:
- I got distracted by a lot of things today...
- I went to add a method to change what print mode the IOPrinter would be in (maybe this should be generalized?), but I saw the time and went "not now"
- So, I'll have to push stuff back to tomorrow... which will be busy, so if I can't do tomorrow, the standard push back until I can.

#229.2. 11/27/2018:
- Yea... it's too late for me to do this work right now

#230.2. 11/28/2018:
- ...
- So I finally get to this and I sit staring at the IOPrinter to-be-PrintMode and going "what the heck is this?"
- So, here is/was my grand vision: I wanted to be able to say "I have these logs, I want to print them" and to not have to customize the printing
- In other words, a IPrinter is an adapter between the log registry and whatever the dev/user wants.
- This could be "print to the console", "write to an HTML email", "render to a texture"?, and "populate a UI element". Etc.
- IOPrinter was one level down (or up...) from IPrinter where a text-based, one-way print would be performed but the printing functionality didn't need to be rewritten for each IO object.
-- IO object is a TextWriter.
- Then along came #223.2 and I said "in order for this to work as I want, I need to run the printing async"
- But, I have a challenge: my test code is basically sequental and not really designed for a continious stream of log data.
- This gave rise to PrintMode. The plan was simple: a generic guide/config for specifying what to print.
-- Should we print colors?
-- What colors go to what log attribute?
-- What size is the font?
-- What's the widest thing we should print?
-- Just print the function names...
-- Print the function names and timestamp...
-- Now print it in the order: timestamp + function name...
-- Etc.
- Basically, I looked at PrintMode and went "what the heck is this?" because print formats are complex.
- Thinking out loud (see above) basically tells me "this probably needs to be a string-based format string" but I need something higher level.
- And... at the current time of the day, I'm not sure what it is. I just know "format will define the per-log prints, but not 'group logs by thread ID' or 'only print functions'"
- Heck, this seems like I'm leading to the "grouping" stuff I mentioned in #223.2 where I group logs to define a "function" or "thread"
- Maybe it means I'll have some higher-level "registry" of such things...
- Now, again, time. It's late, and this tells me this is more work then what it needs to be at this point. I like the thoughts, but it's too soon.
- Instead, I'll hack a simple list print of logs' function name (tomorrow work) and go back to async work.
- If anything, having async in place will force my hand a bit to "when I go to do the work, I need to to work async"
- The last thought for the night: I will make a small key/index in this log for the days to remember so I don't just creat a linked-list of design plans.

#231.2. 11/29/2018:
- Time strikes again...
- I planned to do this earlier, but enough other things happened that I didn't get to it.
- I started... but I'm tired and realized "even with just planning on printing function names, the async implementation is not easy"
- Basically, when PrintAsync is called, the logs should be printed... and then I can await/Continue/etc. when it's done. Or, I can cancel it and it stops then and there.
- Observables can be converted to Tasks, but I do want the cancelation to be cleanly done (and I'm not sure if it just calls the dispose on the subscribe and then calls it a day, or if something else happens)

#232.2. 11/30/2018:
- Ok, I wrapped my head around some of the Task components (namely, there is no "stop" which I thought existed... and Cancel, which I too thought existed, is really the CancellationToken's Cancel function)
- With that, I managed to write a basic async print and make it a little more formal so it can be canceled.
- I gave it a couple tests (manual) and it worked just fine.
- As for unit tests: as expected, everything passes except the ConsolePrinterTests. That will be the case for a bit... they will be outdated eventually and will need to be updated.
- That's enough for today.
- If anything happened, I need to make the parser async. I'll do/start that tomorrow.

#233.2. 12/01/2018:
- I took on too many tasks today
- I will hope to get stuff done tomorrow...
- No... this week.
- I tend to take on too many tasks, and it gets late (that's why I keep pushing things off)
- This week is a company event that I need to be mentally capable for, so I plan to go to bed early...
- And if life and distractions suddenly make it late, I'm going to have to cut time from this.
- It's not the lowest-rank item on my usual todo, but it's easy for "simple" stuff to suddenly take hours. Especially when it involves other people, where I can't time box it so easily.

#234.2. 12/02/2018:
- I wasn't sure if I would have the time, but I managed to implement async support for the XML Parser.
- In addition, I made some temp classes fir handling sync/async calls for parser and printer.
- They're temp because once C# 8 comes, and I can use default interface implementations, I don't need them.
- Minor: an interface with an implementation in it is... weird.
- Yet, what is an abstract class with no implemented functions? An interface.
- So prior to C# 8, you could make an interface with an abstract class, but not the other way.
- I haven't read the details, but I could see the compiler and runtime getting some extra work to provide only the type that's needed.
- Bonus: it reduces some of the annoyances with abstract classes and interfaces (see the temp classes for an example... why do I have to implement an interface function for an abstract class? Why can't I just say "the extender of the abstract class has to implement it" and save me a few lines of code?)
- Next up: tests. My favorite /s
- It actually is good because, as stated, this week will be busy. Tests are annoying but generally can be done "I only got 2 done today" or similar.

#235.2. 12/03/2018:
- Behind on time, so didn't really do too much besides look at the async imples that have been done
- Using the diff, I figure out what I need to test... which is really just the Parse/PrintAsync functions themselves.
- I plan to work on at least one of them tomorrow.

#236.2. 12/04/2018:
- NOOOOOO...
- I forgot to commit this... and then I closed the window without saving...
- Basically, I finished the async tests... they were easier then expected
- All I have left is to do #227.2 tasks and then that set of tasks are done
- I will commit with adjusted time since I had everything prepared to be commited and then didn't...

#237.2. 12/05/2018:
- Worked on finishing tasks from #227.2.
-- LogConfig.UserConfigs -> LogConfig.ExtraConfigs
-- Some docs about what LogConfig.ExtraConfigs are available
-- Added ability to clone LogConfig
- I was thinking of doing the final task, cloning log entries in the registry) but I still have a bunch of stuff to do and not a lot of time.
- So, tomorrow.

#238.2. 12/06/2018:
- I made the interface function for cloning a log in a registry...
- ...and then I realized "test driven development" so I wrote what tests I needed and made the first base test
- Tomorrow is an important day, so I want to get to bed early. I'm going to leave it at that one test and write the rest tomorrow.

#239.2. 12/07/2018:
- Plan: finish the unit tests for CloneLog, maybe start/do CloneLog.
- Reality: this week was rough, and now that it's over, I crashed... so I only got the non-failed log CloneLog written.
- I'll do the failed log CloneLog unit tests done and maybe start/do CloneLog itself

#240.2. 12/08/2018:
- Ran out of time today... today ran longer then expected.

#241.2. 12/09/2018:
- Timing still isn't working out.
- Now, I did spend about half an hour looking at the code...
- ...my challenge is determining "what" I want the result to be in the test.
- Again, TDD. Does a blank failed log clone to a blank failed log? Does the log have to be "notified"/done before it can be cloned?
- So... those take a bit to think about and I really don't want to be excessivly late to bed again, so I would rather not go crazy trying to figure this out
- Besides, the later it gets, the less I can thing straight anyway. So I probably wouldn't be able to do much anyway.

#242.2. 12/10/2018:
- Ok, I determined how I want this to work...
- ...and wrote the tests.
- With that done, all that's left is to do the CloneLog.
- ...which is for tomorrow

#243.2. 12/11/2018:
- ...and I poorly timed things. I have to skip today.

#244.2. 12/12/2018:
- And... ran out of time. But I wanted to do something.
- So I did a naive implementation of CloneLog.
- My expectation is this is what most people would assume is what CloneLog would look like implemented.
- Reality is, TDD. Of the tests I wrote, this implementation took me from 8 failing tests to... 6.
- Yes, there is enough missing functionality that of the 9 tests I wrote, 6 still don't pass. 2/3.
- I hope to be able to work tomorrow, but it will actually be a busy evening and I might have to push proper work to the next day.

#245.2. 12/13/2018:
- I had an event today. It was scheduled for 1 hour. It took 3.
- As such, I'm very behind on everything and don't know why I'm still up.
- To put it short, I fixed one more unit test... but I'm not sure if I like the solution.
- How do we know if the log is from the same registry that is now being asked to clone it?
-- Naive: add an owner field to the log
-- Better, but more memory: have a owner UUID
-- Better, but slower: search the the log's UUID in the registry storage. Do a binary search or something.
- Wait... the storage is possibly going to be actively updated... which means the log may be in there, but the indicies may change before such a search could be done.
- Well, darn.
- I did the naive approach and, while some people would say "that's fine", I see this:
-- Owner would be a reference
-- Reference in .Net (or C++) is 8 bytes on 64 bit systems, 4 bytes on 32 but systems.
-- Largest test log: ~9 million logs
-- Total size of adding one reference to log files: ~68 mb
- Is 68 mb large?
- Alt: my computer has 64 gb of RAM. I did that just so I wouldn't have to go out and buy more RAM in a few years.
- Nearly everyone else asked "why?"
- After talking with people (and looking at Steam hardware stats), I learned the weird case that 8 gb is still vastly common.
- I think 16 gb should be the min for many computers...
- ...because websites/browsers use a lot of RAM and so many applications are poorly written from a memory usage perspective.
- So a measly 0.8% of a common user RAM (and if you work in corp, your computer is probably about the same) is used by identifying "should I just return" in a clone function that isn't likely to be commonly used but is there for completeness sakes.
- So, "Is 68 mb large?": yes
- I would like to be better at memory usage and not fall for the modern stereoytype/status quo of "we have plenty of RAM".
- "We" may have it, but not everyone does. Let's actually not use it all up.
- Lastly, we still have the chance we'd need to serialize this to a DB. That's HDD/SSD storage... but it implies a UUID or similar will be needed.
- That is usually 16 bytes.  So the end result is ~136 mb.
- But wait, one more thing (while I go "oh snap" at looking at the clock): ~9 million is one test log. What about multiple of those size logs and potentially being used by people (*cough* my friends are interested *cough*) who I know have bare min machines in the first place.
- But, I'm struggling to stay up (which is, of course, why I wrote a long writeup), so: night

#246.2. 12/14/2018:
- Trying to improve sleep schedule
- Instead of doing more, I will do "enough"
- Today's enough was fixing the cause of the rant from yesterday: no more owner variable
- I spent some time learnined multiple programming languages for fun. One of them was Dart.
- Dart's language guide has the following: AVOID storing what you can calculate (https://www.dartlang.org/guides/language/effective-dart/usage#avoid-storing-what-you-can-calculate)
- I like it. Part of why I like it is because code processing and development improve, while developers understanding how to keep memory usage down does not.
- The other part of why I like it is because we can optimize it ourselves if we need to.
- Imagine our list storage. Do a TakeUntil/count operation... optimize that internally to a binary search. Suddenly, finding an element becomes O(log n) instead of O(n) of a raw search, or wasting 68 mb of RAM.
- Before I was doing a ReferenceEquals. In C/C++, this would just be a comparison between pointers. I would like to believe that ReferenceEquals was fast, but as it's a generic value, it may do a little more then that. Like many managed lanuages, generic comparision functions tend to be slower then specialized ones.
- For now, O(n) isn't a problem because: nobody uses CloneLog. I'm adding it because I thought of a reason it would be used (namely, making specialized log groups for doing calculations on), but am still many days away from even starting that.
- By the time I get to it, I can probably go "time to optimize it" or at least I should see some stats of slowdowns from doing O(n).
- "Yo, the prior operation was O(1)" well... ok, I'm monologuing too much. Basically: I prefer to save memory over CPU usage.
- Tomorrow I'll try to work on the other CloneLog tests: I think the hard one for me will be "how do I know if a failed log entry has notifed? As that will decide between which storage to add it to.

#247.2. 12/15/2018:
- First: I failed to get more unit tests working. There's a reason for this...
- Second: I have a small moto: use cases are bad. They force a design based on an expectation, and it breaks/needs to be rewritten when someone goes outside of that expectation.
- I firmly believe that many problems in many industries would be fixed if they didn't design for a use case.
- With that in mind, I designed CloneLog with a use case in mind.
- Doh! - Homer Simpson
- The reason use cases are popular is that it provides a boundary that a design or plan can fit into. It makes life easier.
- In my case, I had this expectation that a user would go through a set of logs in another registry and try to clone some of them.
- The logs in another registry would either be "being processed" or "published". If they're being processed, it means that this is either happening in a parser or the registry is not very large/being manually used.
- Thus, I shouldn't need to worry about the 3rd case where the log has no info that would indicate it is or is-not inside of a registry.
- Huh? Yea, 1.) what if someone makes their own log entry? 2.) If an empty log or one not using the sort attribute (which is timestamp) is cloned, there's no way to know if it has been processed (for both those cases, it would basically no longer be owned by the registry) or not (would be "in processing").
- As such, I wrote a truth table and defined the cases where the edge case would occur (see the CloneLog function).
- So, with the good use cases (determining if we add to storage or to "in processing") done, some of the unit tests should be working now?
- Wrong... because I wrote those exact use cases for the tests.
- I don't have the time tonight, but I'll need to figure out: do I want to change the tests to not do those use cases, add tests to test the good uses cases too, actually figure out how to determine if in-processing or not
- But, that's for tomorrow.

#248.2. 12/16/2018:
- And tomorrow never came.
- Ran around a bunch today and ran out of time...

#249.2. 12/17/2018:
- I put in some thought, and am now late to sleep, so I'll keep this short
- I didn't want to add memory usage, and realized that the only difficult spot I was having was with failed logs.
- Failed logs have one stored value (that isn't an attribute). I co-opted the attribute in an effort to solve my problem.
- I wanted a notification that a log has been processed. If I know what state it's in, I know where it sits inside whatever registry it's a part of.
- In addition, I looked over the logic a bit and did a small change.
- It's a bit weird, but I just let a log sit... fester? in the registry if it has no Timestamp, but is notified. Maybe I shouldn't, but it's not... bad.
- I also wanted to make sure that if someone tries to do stuff with failed logs that aren't in the registry, the metrics don't count it as a success action.
- Lastly, a small log to ensure that the rest of the logic is maintained.
- Now, all but one unit test passes. I had to change one test as my testing logic wasn't correct for how things happen (um, TDD? Yea yea... but I want the logic to work this way)
- That last one will be interesting: how to ensure a registry doesn't duplicate a log. We check for our own logs, but not for another log for a nth time (where n > 1).
- Tomorrow will be short... good chance it will be pushed off. I didn't accomplish some things tonight, so I need to do them tomorrow.

#250.2. 12/18/2018:
- So plans actually changed and I have time...
- And then I took advantage of that time to do other required tasks, one of which went about an hour longer then expected.
- To top it off, all that "I need sleep" posts? I was informed today that lack of sleep was affecting my work.
- I was worried before... but that's a big red flag that I need to make some changes to plans and schedules.
- As such, I need to time box this work and actually be strict on it.
- I already failed.
- But I will be stopping work on this tonight.
- The main issue I have right now is that I need to ensure I don't produce a duplicate entry that has already been cloned.
- I bade a base function, but realized that the implementation is questionable.
- What I'd really like is to either combine the "contains" and "find" functions or to store a list.
- I'm leaning towards the storing of a list because I can actually start to play around with machine learning (to a very minor extent).
- Think: one log is cloned... just do a iteration through the values and call it a day.
- Now, hundreds of thousands of logs are cloned... make a list of IDs that have already been cloned.
- Wait, now I have a hundred thousand item set that I have to iterate through.
- So maybe a timed cache of sorts? Or expiring values? If something has been around for more then a second or so, perhaps it's not worth it to hold on to because nobody is looking them up.
- Maybe it's overcomplicating it. But a goal is to balance memory and performance.
- I managed to save a small amount of data by having that search to determine if the registry already contains the log.
- I do worry it's slow. There are probably solutions for this (start searching, save the IDs we've touched and if the next search doesn't find it's item inside that log, then start iterating through the main list again)
- Again, the dreaded use case: how often will this be used? Bonus: how often are the edge cases we hit going to happen?
- Even better bonus, and an example why use cases aren't always good: what if someone wants duplicates?
- But, again, I'm late and need to stop.
- For tomorrow.

#251.2. 12/19/2018:
- At the end of yesterday, the thought running through my head was "those are all cool ideas... but it's premature optimization"
- I brought in an outside opinion on the matter... and they agreed.
- I proposed to just do a basic iteration through elements and will do optimizations later.
- They liked the LINQ-level optmizations over doing it in-registry, which I agreed with.
- They also recommended a Bloom filter. I stopped at that point as I had the answer I was wondering about :P
- It's confirmation bias, but it's also true.
- The LogRegistry is fully operational again.
- I'm calling it quits for now.
- The following days might be a bit short, with Christmas and whatnot almost here. We'll take it day by day.
- Ah, that means that #227.2 is done! This means the next fun steps are to do #223.2.

#252.2. 12/20/2018:
- Timing just isn't working today. Tomorrow...

#253.2. 12/21/2018:
- Yea, bout that. I can tell you now, tomorrow... isn't going to be better.
- We'll see about the day after.

#254.2. 12/22/2018:
- Yep, not happening today.

#255.2. 12/23/2018:
- Ok, so the past couple days have been hectic.
- Now... the main holiday for me is here, so I'm still not ready to do work.
- I'll see if timing is nicer, but I doubt it

#256.2. 12/24/2018:
- I actually wasn't able to login to the computer (which was remote) the bast couple days.
- So I'm just recording a status

#257.2. 12/25/2018:
- Again, catch up

#258.2. 12/26/2018:
- Ok, I can't do today as I was trying to get everything else in life straightened out.
- Hopefully tomorrow I will get back to this.

#259.2. 12/27/2018:
- So I didn't get any code done today, but I at least gathered that the next thing to work on is logging.
- Specifically, a combination of #223.2 and #230.2
- The description of #223.2 has that the "progression" needs to first print the logs as they are recieved.
- Now, initially I thought "this is what is parsed" but I'm thinking I may have meant the raw log line, unparsed.
- The only problem with that is, due to the fact that the lines are parsed, I don't know if the parsed log element is a single line or multi-line.
- What's to stop someone from producing an XML-based log where each value is it's own XML element? <log><time>now</time>...</log>?
- Printing that raw is not ideal. Instead, I will print just the attributes it contains.
- Then, over time, I'll print more and more.
- How? That darn'd printmode config. I'll define something for it and see how it goes.

#260.2. 12/28/2018:
- Guess who realized they were missing something... me.
- Need to push off this work because I forgot to write it in my daily TODO.

#261.2. 12/29/2018:
- Looks like I won't have the time tonight.
- I Needed to get some things done before tomorrow, and, well I got them done at the cost of not having this done.
- The other part of it is that I did some tests and, as I stated #256.2, I wasn't able to login remotely to my computer (luckily, I'm not remote for these tests)
- I attributed it to the software and will have to contact support about it.
- In the mean time, I am using a different program (temp) to access my computer but... it runs off temp passwords/codes.
- This means that if I'm lucky, I can continue working on this. If I'm unlucky, I won't be able to contact through that program and I'm stuck.
- "yo, git is decentralized" yea, and I have a bunch of extra notes and whatnot that I don't commit to the published code.
- The only thing I'd be able to do is say "Status" and say I can't do the work or it's untested/I want to rewrite/replace it
- Or, I can just do the "set author date" when making the commits once I arrive back to my computer
- It buys me a bit more time to do other tasks...

#262.2. 12/30/2018:
- I was able to get in today...
- For my sanity and time, I decided to define the printMode in documentation.
- I will write the code later (starting with predefined modes, then defining the custom modes)
- Ironically, I have experience with this. (https://bitbucket.org/rcmaniac25/blackberry-10-extensions/src/b6a36515c733ee8465b9b831e6cf30106c60fa4d/BBX/src/rebuild/util/text/StringUtilities.java#StringUtilities.java-773)
-- The real meat of that is https://bitbucket.org/rcmaniac25/blackberry-10-extensions/src/b6a36515c733ee8465b9b831e6cf30106c60fa4d/BBX/src/rebuild/util/text/PrintUtility.java
- I won't go into detail, just know in the past I did BlackBerry development (I enjoyed it!) and was a bit more naive on code licensing...
- ...but one thing that was vast-majority/entierly written by me was a near-standard implementation of printf (spec version in the PrintUtility code) written in Java 1.4
- You know the point where Java stopped being difficult to use? That was Java 1.5 (it got bad again later, but that's another topic).
- I am very proud of what I did, especially for the time.
- The last element worked on was how to properly format floating point numbers. I utilized an arbitary number system, also written by me, just to do that.
- Efficent? Doubtful at best. Effective? Yes.
- To the point, I've done this before. I will write this on my own because I want to and can use some "modern shortcuts" to speed things up.
- For now: I have written the documentation for the work, though I'm missing some details on the pre-defined formats.
- Finishing the formats will be the last work I do tomorrow, and maybe starting on code.
- A key is to not go too nuts with coding this, as it's just a starting point. I can always do a full implementation later on when it's more needed.

#263.2. 12/31/2018:
- I expanded the formatting some more
- It's a little larger then originially planned, but hopefully is still generally easy to implement.
- But, I just want to write out the one format for my sanity and then I'll start on code.
- The temptation to go write to format parsing is strong... I must resist...
- See you all next year

#264.2. 01/01/2019:
- Happy New Year!
- I have to ensure I time-box my work so I'm not always late.
- I finished the formatting (and hopefully corrected the markdown while at it).
- Not 100% sure if there's anything else I want to do with it.
- I'm concerned that with how I'm using it, the changes I'd want to do will turn it into a Turing-complete language and, well, it's a formatting language and shouldn't be Turing-complete.
- The end result may be that some formats aren't "perfect" unless it's a predefined format.
- I started working on the code, with the most just being what exists already but now "proper".
- I'm not sure if I want to throw an exception if the format is invalid/unknown, or if I should just eat it and use a default.
- Gut is saying "exception".

#265.2. 01/02/2019:
- Event today ran long today... so I need to skip.

#266.2. 01/03/2019:
- I don't have a lot of time...
- But I managed to get the "general" format and add a forgotten pre-defined format
- So: general format is implemented. The catch block might be a little more then I want, but it's fine. Should still be plenty fast.
- Looking at what I planned for pre-defined formats, I realized I had "general", "functions only when they appear for the first time", and "functions only when they change"
- ...yet, the function I implemented was "always print out the function". So I added the missing one ("print only when hasn't been printed before") and a way to use that in the format.
- Tomorrow I'll need to do an update to the delegate becuase a couple some of the values requires state, and the delegates don't handle that right now.

#267.2. 01/04/2019:
- All pre-defined functions implemented, delegate updated, and a simple lookup added.
- Next up: error handling for "you specified an invalid format", unit tests for the formats, maybe an update for the existing console unit tests, ...
- ...and lastly: start work on the print mode format.
- Stretch goal (and not likely to happen): see if I can implement PrintThreadTraces in this new format AND can I move the format printing out of IOPrinter?
- What do I mean by that last one? I've seen it before: customeWriterClass.startWrite(...); cwc.writeText("hello"); cwc.changeColor(Blue); cwc.writeText("world"); cwc.endWrite();
- So now put all format handling and printing in one spot, and then an interface for handling the writing.
- IOPrinter will wrap the write operations into something for TextWriter.
- A GUI could ignore the write operations and just put into an existing GUI element.
- Sub-classes could swap out the writer and result in "IOPrinter simply writes" while ConsolePrinter replaces the writer so colors and other elements can be handled.
- It's past when I should be thinking about this, so this all sounds nice now, but my concious is saying "stop doing scope creep" and I'll give it some time before going "yay or neh"

#268.2. 01/05/2019:
- I had a bit of a wacky moment today, so I kinda lost some urge to do work today.
- I at least made the decision that "if your config is bad, throw an exception"
- Why? Because it's a library. If you used a specific class and used a config value wrong, it would throw an exception.
- For the actual program, a try/catch around SetConfig could result in "load config. Popup: Config is invalid for X"
- But, that's it for now.

#269.2. 01/06/2019:
- Timing isn't working out today. Will do stuff tomorrow.

#270.2. 01/07/2019:
- I managed to write unit tests for the "General" printMode and it's failure case.
- I'll do others another time.
- It's something...
- If I seem "meh" in writing, imagine having a bad sleep schedule. Making it worse. And then work starts after the new year... so I'm tired, trying to fix my sleep schedule, and the rest of the world keeps going on and I am determined to go on with it.
- Basically, I'm tired and will be for a bit until I fix my sleep schedule.

#271.2. 01/08/2019:
- Finished pre-defined printMode tests.
- It actually uncovered a bug in the generated strings.
- That's the point! So it's good I did this.
- Tomorrow I start on the fun part: custom print formats

#272.2. 01/09/2019:
- Things got late, so I wanted this to be quick
- I realized "this should have tests before it has code"
- I actually started writing the tests... and then realized "wait, I need edge cases"
- Edge cases: null print mode, empty string, etc.
- I wrote these, start working on other tests before going "It's late. Let me stop"
- But then... doubt. I Looked at the tests I wrote and said "I'm just doing random tests. There is no progression where I can use a prior test to write a new one"
- In addition, I realized "do I really want the edge case to do that?" Like, I originally wrote that a null printMode should throw an exception. But should it? What if I want default and want to check for that "printMode" exists?
- Random text should provide an error, because if we don't have the printMode format indicator (@) then we expect a pre-defined printMode. But random text would never exist as a printMode... so, exception.
- Deleted everything, made a couple comments... but I'm done now.
- I'll try to implement those tomorrow, but I'm sleep deprived and feel a little funny (I think sleep deprivation finally kicked in and I feel tired at a good time instead of really late at night)
- In addition, I may have a wacky schedule coming up (not sure yet). In one case, work will continue. In another, I won't be able to do anything for a few days. I'll need to see.

#273.2. 01/10/2019:
- Ok, so my schedule will continue.
- But today, I got home too late and could only do one test (that I decided on the result after yesterday)

#274.2. 01/11/2019:
- Planned to work on this
- Lots of distractions today... and just needed to relax a bit
- Tomorrow

#275.2. 01/12/2019:
- Finally got to finish the "special case" tests.
- That's all I could do today...
- I wasn't sure how I wanted to handle the configs, then realized they should handle the same as the log attribute paths.
- In those cases, we just skip all null, empty, or whitespace strings.

#276.2. 01/13/2019:
- Late start, need to end early today + some unexpected plans and one longer-then-expected project = no time today

#277.2. 01/14/2019:
- Initial tests for custom formats
- That's all for now

#278.2. 01/15/2019:
- Err... important day at work tomorrow, so I need to skip tonight...

#279.2. 01/16/2019:
- Wrote the first attribute test...
- Then decided not to do the others today, and instead enumerated all the tests to implement

#280.2. 01/17/2019:
- Something I expected to take 15 min took 1.5h, so no time today... err

#281.2. 01/18/2019:
- This seems to be a trend... It's late, so I only did a little work (at some point, I won't be late, and suddenly I'll get a bunch done)
- So one more test... done

#282.2. 01/19/2019:
- I finished all non-combination attribute modifier tests
- AKA: all the ones I could go "this modifier does X" and not need to combine mods or conditions or "raw" or... you get the point
- I'll try to finish or get further tomorrow

#283.2. 01/20/2019:
- Ok... not "this" tomorrow, tomorrow's tomorrow.
- I'm trying something out, and need to have stricter deadlines on some of the things I do...
- So this ended up getting the short straw

#284.2. 01/21/2019:
- Ok, almost done.
- So the only tests that need to be written are testing pre-defined formats against the format they're supposed to represent, and using multiple modifiers.
- The reason those two aren't done are this:
-- Compare formats: the test class wasn't written with the expectation that multiple formats would get used in the same test. So I need to do a few changes so it does work
-- Multiple modifiers: honestly, I have this idea in my head to have a whole mess of logs... then for the printed out log to say "the quick brown fox jumps over the laxy dog". But to figure out what the logs to add to test all the modifiers at least once is... not easy.
- Cont. Doing an exhaustive test shouldn't be needed, and doing a random test could result in some combo being skipped. It's lose-lose.
- That's why I have the "quick fox" example stuck in my head. I figure I may not hit every case, but it will show off that all modifiers have an effect.
- ...and a thought that just came to mind: should order of the operators matter?
- My gut feeling says "yes" because it makes it both easier to code (I can just make an ordered list/array when parsing) but also because it offers the user more control over what happens.
- Maybe only valid logs is more important then if the value changed. Or maybe the value change is more important.
- Someone else can come up with "why", but it gives the dev more control and makes my code easier to write.
- So... yes, order matters.
- Next couple days may be short (again, trying something out) but if I get the time, I'll ry to get at least one of the two additional tests done.

#285.2. 01/22/2019:
- As expected, I don't have time tonight. Maybe tomorrow.

#286.2. 01/23/2019:
- Ok, I'm earlier... but I have people who are expecting stuff from me, so that takes priority.
- Maybe tomorrow.

#287.2. 01/24/2019:
- I made the comparison tests.
- Now, I haven't tested the tests... but that's for once I have an impl.

#288.2. 01/25/2019:
- Poor timing today. Will do stuff tomorrow

#289.2. 01/26/2019:
- Yesterday: dah! I didn't plan well and now it's late and I still haven't done anything
- Now: dah! I didn't plan well and now it's late and I still haven't done anything
- I need to skip again. I didn't get as much sleep as I'd like, got a late start, procrastinated, had a few unexpected moments, and I'm still going...
- ...but I haven't gotten to this. I'm ending everything else and then going to bed.

#290.2. 01/27/2019:
- I tried... but the most I got was "I need to test ordering of modifiers" as well.
- See, I could automate generation... but I don't know if I could come up with an easy set of rules for how to create the "expected" values.
- I don't want to implement the parser twice, one to run and one to generate a test result... as they'd be doing the same thing.
- I'd rather create the expected value by hand but also don't want an exhaustive set of tests, especially since some combos are invalid (will only print valid or invalid values...)
- Also, maybe "modifier" is the wrong term... but I need to check that another time.

#291.2. 01/28/2019:
- I'm late again, but I wanted to stop pushing things off...
- I finally came to a mental conclusion, and realized a bunch of my "modifiers" were actually "conditionals"
- I started doing the change, but need to do the following still:
-- Modify test names
-- Modify actual char. location within formats.
-- Modify PrintModeCustomAttributeConditionAndModifier (do an error handler and conditional, while taking the existing test and (see below))
-- Work on actual conditional tests

#292.2. 01/29/2019:
- I thought I might skip today, but wanted to at least put the little re-factor behind me.
- I did everything _but_ doing the mixed-conditional tests.
- One interesting question that came to mind while doing this: I had added the ability to apply a modifer to an entire log, or to a specific attribute...
- ...but since those are now conditionals, they are in front of the attribute. So now... "@+{Message}"
-- Does this print the message only if it's the attribute is part of a valid log?
-- Does this do anything unless it's a valid log?
- Those two questions may sound similar, but they aren't. If I changed it to "@+{Message} World", the following would occur for Message="Hello":
-- Does this print the message only if it's the attribute is part of a valid log?
--- Valid log: "Hello World"
--- Invalid log: " World"
-- Does this do anything unless it's a valid log?
--- Valid log: "Hello World"
--- Invalid log: ""
- While updating everything, and writing the above, the thought "how do I determine the correct answer to the question... or do I try and be smart when picking"
- That told me enough. A professor once told my class "Work smarter, not harder" and a coworker became well known to me for saying "You're trying to be smart in this function. Be similar"
- The point I took from the two is similar: Don't do more work then you have to.
- In this case, I am writing a string format. There is no reason for me to go and do deductive reasoning or something to determine the most-likely case of what they meant.
- Why? Because if someone else (or myself) ever went "hey, I only want this to apply to my attribute... but it's applying to the log line" then I now need to edit the format/logic/etc.
- Instead, I want to be verbose and deterministic. I will add a seperator between the conditionl for a log line, and the conditional for an attribute.
- But that's for tomorrow-me to figure out.

#293.2. 01/30/2019:
- I didn't figure out the seperator yet...
- But I finally bit the bullet and wrote up the list of comparision tests I "can" do.
- Not every modifier can be combined (ex. only print if it's from both a valid and invalid log), which reminded me I need to test invalid combos (and what they'd do)
- So... yay. That's a step towards finishing this.
- The bad news: tomorrow's a busy day, so I'm probably not doing/going to do much tomorrow.

#294.2. 01/31/2019:
- Yep... no time today

#295.2. 02/01/2019:
- Crashed... not doing things tonight.

#296.2. 02/02/2019:
- Ok, so after yesterday, I'd like to try and not fall back to old habits again.
- So I wanted to end the cerebral + lazy + poorly timed case of these last unit tests.
- ...and I did.
- So everything is now all "TODO"s are written out which means...
- Tomorrow I start to code the tests.
- Woot! Once that's done, I can do the actual format code and move on to... it's been so long, I don't know what my plan was after this.
- (Good thing it was written down at the bottom of this page)

#297.2. 02/03/2019:
- There was an event today... and I ran out of time. :(

#298.2. 02/04/2019:
- I managed to get a good amount done today...
- So I got to the tests, and... lost track of time.
- I still got a few tests done, but I had a thought: how can I make it apparent that the combos do something different?
- So it will take a couple iterations as I write the tests, but I hope to end with all the tests for combos being the same, with only the format being different.
- In-fact, now that I wrote that. I'm going to take the couple tests I have for (valid) combos and turn it into test cases to enforce the point.
- Tomorrow may be a day I miss, just a thing that happens...

#299.2. 02/05/2019:
- Actually had some time. Almost finished the tests (yay!)

#300.2. 02/06/2019:
- In celebration of 300 days of... making a log, I finished the unit tests
- That means tomorrow* I can start working on implmentation.
- But while working on a couple tests I realized "what if a value doesn't exist?"
- "Um, you have a conditional and tests for this" Um, yes... but I don't have "use non-existing value in custom format"
- I thought about it (aka, I got distracted for about 2 hours) and came to the conclusion: error handler
- Basically, if a custom format tries to use a format that doesn't exist, it will throw an exception. So what's a default handler?
- ... why not something that everyone go "that shouldn't be there"
- So I wrote a test for that :D
- * by tomorrow I mean "I'm busy, again, so may have time"

#301.2. 02/07/2019:
- So after additional conversations with work, I'm going to try and better orginize my time.
- As such, while I have/had the time today to do a bunch of work on this, I decided to just get some basic components written out.
- Namely, I wanted to make a wrapper around the visitor pattern I'm going to implement for printing formats.
- I opted to put the parser (just an empty function right now) into the wrapper.
- If I don't do that, I'll have to implement the parsing elsewhere. Ideally, in it's own function/class.
- It brings me to "OrderedPrintMode"... I don't like the name entierly, as it implies there is an unordered version. But it's the best I could come up with.
- Also, I mean, it's essentially a glorified List<T> with a few extra functions. It's ordered. It contains the values needed to define a custom print mode.
- Hence: ordered print mode.
- Tomorrow I hope to start coding the elements and then (maybe) start doing the parsing.

#302.2. 02/08/2019:
- So I was a bit stumped on how to start this...
- I opted for a simple conditional interface.
- ...yea. I'm not sure if it will stick, but I've ran out of time today and can't really focus on what to do for it.

#303.2. 02/09/2019:
- Ok, I wrote a few execution steps (docs) because...
- ...I ran out of time.
- I started early, but didn't have enough time to do everything I wanted today. Then planned to do more work later... and never got there.
- So... tomorrow.
- Oh, also: thought of a better name then OrderedPrintMode -> PrintModeFormat. I'm going to try and name classes after the component they represent/documented as.
- In addition, I thought of another modifier: something todo if a conditional failed.
- I'm thinking along the lines of print "value" if it's a new log but if it's not new, print "..."
- This would allow for doing something similar to what normal debuggers do where a value is deemed unimportant because it's already seen/used.
```
This is a test; user=John Jacob Jingleheimer Schmidt
Also a test; user=John Jacob Jingleheimer Schmidt
Still a test; user=John Jacob Jingleheimer Schmidt
Maybe a test?; user=John Jacob Jingleheimer Schmidt
Nah; user=Steve
Ah, ok; user=John Jacob Jingleheimer Schmidt

<<becomes>>

This is a test; user=John Jacob Jingleheimer Schmidt
Also a test; user=...
Still a test; user=...
Maybe a test?; user=...
Nah; user=Steve
Ah, ok; user=John Jacob Jingleheimer Schmidt
```

#304.2. 02/10/2019:
- So I'm a bit stumped on how modifiers should be implemented.
- I decided to chat with a friend on the topic.
- In the end, we were both kind-of stumped. But we did get one idea out of it...
- ...basically, IPrinter should also have a factory element to it, and the modifiers should be generic/for just plane text.
- The result is a simple implementation that a IPrinter's factory could then be retrieved and printer-specific modifiers could be retrieved.
- This would solve the issue of "you can't realistically write a single API that would work for every possible scenario/implementation.
- I'm not trying to develop the perfect API. I'm trying to write one that works for the ideas/goals I have with the hope I won't have to rewrite the API.
- I still plan to work on it in a iterative fashion, so the API I wrote is certainly not staying. But for this commit, it is.

#305.2. 02/11/2019:
- Instead of getting stuck on modifiers and conditionals, I decided to grab onto the component mentioned yesterday: a factory.
- I implemented the interfaces for said factory and will be implementing some of the other necessary types next.
- The sequence I expect to implement:
-- 1. types needed to "build" a print mode format.
-- 2. Put the components together.
-- 3. Implement the parser.
-- 4. Actually implement the modifiers and conditionals.
- Now, why not swap 3 and 4? Because... just gut feeling tells me that if I do it the other way, I'll be spending so much time trying to design a perfect interface for the modifiers and conditionals.
- I expect coming up with something that works, even if sans-modifiers and conditionals, will be more valuable and easier to answer the question that's been dogging me of "how should it (the interfaces) look?"
- As typical, tomorrow I may not have too much time. If any.

#306.2. 02/12/2019:
- My plans for today were actually canceled...
- ...and then I fell asleep and didn't get anything done. Not on this project, not on anything else.
- Joy :P

#307.2. 02/13/2019:
- Wrote (but didn't implement) the default factory.
- Started writing the ProcessLog portion of the PrintModeFormat.
- Tomorrow I should be able to start combining/implementing the factory and the actual ProcessLog function and the data-types needed betweent them.

#308.2. 02/14/2019:
- Simply: the high level components needed for printing are done.
- Next is the individual elements that will be processed, and parsing the format.

#309.2. 02/15/2019:
- Implemented "Raw" and ensured that there was an exception handler... thing.

#310.2. 02/16/2019:
- Ok, this is a weird one.
- I have the time to do this work and an idea of what to do (for a printable element) but I have many projects. I have many things I want to do.
- And today, I need to stop putting off something that's been egging me on as something I "can't" do, and want to try and do it.
- This means I either stay up late, or I push Steth off until tomorrow.
- Well... you can probably guess which one I'm going for... tomorrow

#311.2. 02/17/2019:
- Today was a very lazy day... so when it came time to work on this, I was conflicted.
- "Oh, here we go again" well, I should be sleeping (as usual). I should be doing some other tasks.
- I should be finishing the print code.
- I didn't, as that's not that simple.
- The big part for today was at least putting in "StandardElement" which is a normal print element.
- I didn't do much work on it, but at least wrote a bit of base code. I realized: this is kinda useless until I have parsing.
- So, I stopped. I think I'll try doing some parsing tomorrow so I can actually run unit tests against this code and get things to pass.
- I was also conflicted, but decided to add it as a function in the element factory.
- Why was that conflicted? Because I want the factory, but I thought about it for conditionals and modifiers. I didn't think of it for "raw" and "attribute"
- I'm just not sure if it's the way to go... but, one upside is I now get to think of more unnecessary ways to utilize it.
- Example: I can now say "if you only use defaults, I can used a SimpleElement" that simply prints an attribute. Everything else can use StandardElement...
- Or maybe I should have one that does attributes + conditionals, as that will probably be common. But many (default) types have error handlers... so maybe
- ...<gets yanked off the keyboard before explaining one of the downside of factory types: complexity and ambiguity>

#312.2. 02/18/2019:
- So, I went "let me see how quick I can write a parser, since it's late"
- That was the first red flag.
- Then was the second red flag, seeing the things I "needed" to do tonight.
- The third and final red flag was when my mind went "wait, state machines are useful for parsing"
- I agree, but there's no way I'm going to get anything going in the time I have.
- I instead did a bunch of stuff that I marked as needing work (but didn't do). Ex. "wait, after each log print, it should print a newline" so I implemented a new line.
- Tomorrow I may or may not have time to do stuff.
- Regardless, the next task is to do is make a parsing class for the state machine to exist in (I'd rather not clutter up PrintModeFormat, which isn't for parsing)
- Random: I changed from "if(!init) init = true;" to "init |= true;" so there wouldn't need to be a branch statement, and the same goal is accomplished.

#313.2. 02/19/2019:
- And, as expected, no time... tomorrow

#314.2. 02/20/2019:
- Ok, wanted to do something quick.
- Result: I wrote an empty-implementation of the parser class.
- The idea I went with is that the parser is the container of elements. An IList, basically.
- I'm too lazy (and short on time) to do that now (though it's not necessarily hard. Just time consuming).
- But, that's it for tonight. Hope to actually start the state machine tomorrow.

#315.2. 02/21/2019:
- Ok, so nothing major happened.
- I did start the state machine... as in, I made a function called CreateStateMachine which returns null.
- I need to figure out the states and triggers... which is the point I went "I'm not staying up _that_ late"

#316.2. 02/22/2019:
- Got distracted... no time tonight

#317.2. 02/23/2019:
- Dah! I'm rubber-banding between too many tasks.
- Also, doesn't help that I woke up today when I would usually be eating dinner. >:(
- I don't have the time tonight... :(

#318.2. 02/24/2019:
- ... the past couple days have been a mess for me..

#319.2. 02/25/2019:
- Finally sat down and wrote the first draft of the parser state machine
- Most I can really do tonight... but it's at least a useful step.
- Standard "might not be able to do anything tomorrow"

#320.2. 02/26/2019:
- As expected, no time tonight

#321.2. 02/27/2019:
- Not expected, no time tonight.
- Short explanation for the past couple days: "despretly" trying to get something done at work -> work a little later then desired -> tax season + some personal projects that are just so engrossing that I loose time + "oh shoot, I need to get <life task> done" -> it's late and I still haven't done this codebase... err, hopefully tomorrow will be better -> it isn't...
- Also, one of my engrossing projects has gained enough interest that people have actually paid me to do some things for them. That automatically puts it at a much higher importance then non-paying endevours (my personal projects are not cheap...)

#322.2. 02/28/2019:
- Due to one additional issue coming up yesterday, I had to push finishing my taxes off till today
- So... tax day
- Tomorrow may be delayed again because I also "need" to do the project I'm being paid for...

#323.2. 03/01/2019:
- Turns out I had an issue with taxes, so needed to fix that and OOOO did you see the rocket launch?
- Wait, what was I doing again? Ah yes... oh, look at the time.
- Yea, I hoped to get stuff done today and ended up just getting distracted by everything else.

#324.2. 03/02/2019:
- My daily planner, I wrote "Do something!" and I did
- Well... "Do something!" was supposed to imply "do more then just say that I ran out of times"
- Instead, I at least updated the State and Trigger.
- Hopefully, I'll time things better tomorrow and do and actually start writing the state machine.

#325.2. 03/03/2019:
- <spits out drink> Oh snap! I actually did something!
- I wanted to at least have _something_ for the state machine...
- ...instead, I wrote the first couple states, some triggers, the state that gets passed around, and the (outer) parsing function.
- Now... with that said, the next 2 days will be hectic because: tomorrow I have a random event, the day after is a reoccuring event that makes me go "might not get anything done"
- I hope to get the parser done this week because... the upcoming weekend will be weird. Big family event, and due to a different issue I have, I'm not always able to get into this system to do any work.
- But that's for later.

#326.2. 03/04/2019:
- I shouldn't be up right now...
- Be happy, I managed to write the log conditional parsing element.
- Took a little longer to get through it because I was basically defining the format of these states.
- So that's the general format of each state... but I'm happy with it. Could probably do with a bit of consolidation (once more states are written).
- Imagine having one giant code block, with for loops and if statements and switch statements and "bla".
- That would be unreadable, unable to update and maintain.
- But that's all for now. Usual "tomorrow might not get anything done"

#327.2. 03/05/2019:
- Ok, I did a bit of cleanup for the most part.
- I wrote the state machine configuration for "Part", though the implementation is not there.
- Main cleanup aspects I did:
-- consts for parser components (what char = a specific conditional, etc.)
-- handling multi-concurrent chars of the same type. Basically: + is conditional, ++ is raw, +++ is conditional and a raw, etc.
- The only issue I can see happening is when someone tries to do Ex. "@++{Message}". Is that:
-- +, +{Message}
-- "+", {Message}
- What about "@+++{Message}". Is that:
-- "+", +{Message}
-- +, "+", {Message}
- What about "@++++{Message}". Is that:
-- +, "+", +{Message}
-- "++", {Message}
- Yea... so I didn't think of that until I was doing the cleanup. I'm not sure if I want to swap Attribute Conditional and Modifier, throw an error, default to Attribute before Log format, add a divider
- That's for tomorrow or later. For now, I hope nobody needs that.

#328.2. 03/06/2019:
- Ok, ran out of time tonight. Have to be up very early.
- One thought that came yesterday was that I have this lookup for conditional and modifiers... but what about for "parts"?
- Turns out it's possible, so I wrote the variable for that.
- ...but that's about the extent of what I did. Hopefully I'll have time tomorrow to do more.

#329.2. 03/07/2019:
- Ok, I ran out of time and have to get something done before hand.
- Yes, I've used that line a bunch, but when 40 people show up at my door and I don't have it done, it's not going to end up well for me
- So it's more important.

#330.2. 03/08/2019:
- Plan: do work
- Reality: computer crashed while away... so I spent the time I would've done code, trying to fix it.
- I failed...

#331.2. 03/09/2019:
- Oh look, the time changed
- I started with "let me just define the steps needed to do things with 'part'"
- It then went to "I got a few min"
- Now it's DAH!
- As such, the code is there... but it's oddly "sparse" and I didn't update the graph that describes the state machine

#332.2. 03/10/2019:
- Finished: counter, raw processing, part handling, and a bit of error handling
- :D
- Next up with be attribute parsing.
- That + error handler (modifier) and parsing will be done.
- Final piece to the print component would be an implementation of the factory elements.

#333.2. 03/11/2019:
- Wanted to do something quick: wrote the decision logic for picking what to do about "attributes"
- It's a bit interesting... the decision to use a state machine for this means the indvidiual actions are compact and generally easy to read.
- I realized one issue I could hit with attribute parsing ({ vs {{, etc.) but I simply made a todo for another time.
- One other aspect to think about is if I should move that logic to CountTillMarker.
- Actually... yes. Yes I should. Tomorrow(?)
- If I do the work in CountTillMarker, not only do I prevent having multiple RAW objects, but I can natually say "here's new chars"
- Though, one issue I realized: how do I know for sure? Like, if I say "test for '{'" and I get '^', which is a special char, do I now need to know that too?
- I will think about this another time...

#334.2. 03/12/2019:
- Unexpected mental "crash". Went to bed very early... so nothing happened today

#335.2. 03/13/2019:
- Wow, so... it happened again.
- Note to self: bed = sleep. Stop laying in bed when one feels tired with the expectation of getting up in a few min, and instead go to bed.

#336.2. 03/14/2019:
- I didn't fall asleep this time, but I did realize that I'm getting into a "I have all these things that _must_ be done and I haven't done any of them" moment (again)
- As such, I focused on those today.
- I do plan to work on this tomorrow.

#337.2. 03/15/2019:
- ... ****
- So, I'll put it this way. I planned to do stuff today. I was all setup... then "all these things that _must_ be done" crept in and said "hey, remember you were gonna writeup a biz plan for starting your own company? You have others who want in... might want to do it"
- So I did that instead...
- I plan to do it tomorrow...

#338.2. 03/16/2019:
- I did something!
- So I did a bit of refactoring so instead of a whole bunch of dictionaries for attribute, modifier, conditional, etc. there's one table of special chars with a set of flags.
- This should make it easier to add or change flags.
- It also means I get to resolve the issue proposed in #333.2.
- With a single dictionary of special chars, CountTillMarker can operate and simply do a lookup of special chars and, if one is found, then do the same operation as HandleLogConditional and only indicate it's a special char if there's an odd number of the special chars.
- But... it's late, so that's work for tomorrow.

#339.2. 03/17/2019:
- I wanted to get the CountTillMarker updated but need to re-evaluate the logic a bit.
- At re-reading the code (admittedly, while half alseep), I tink there's a logic error with the existing impl.
- Outputs should be the number of chars. till a terminating char (exclusive).
- 0 is a return if we are at the end of a string or the terminating char is the char at the current parsing index.
- Current implementation will only return 0 when we're at the end of the string.
- It seems to give an extra char in general... I realized "ah, I'm using length for char testing instead of testLen"...
- ...then I went through the logic again and while I fixed the extra char issue, it didn't give me 0 when the term. char. was the first char. again.
- Ok... that's not a hard fix, but it also means my compact logic isn't going to be as compact... let me rethink this.
- Err... let me rethink this when I'm not half asleep so I don't make mistakes.

#340.2. 03/18/2019:
- That was annoying...
- Regardless, I rewrote CountTillMarker twice.
- Once to fix the issue.
- Once more to refactor it so it didn't "staircase" too much.
- In between, I realized where a marker was when it was a special char was repeated, not obvious.
- Was it at the beginning or the end of a repeated special char?
- I added a flag... and then moved on, never implementing the flag.
- I implemented it and also wrote a small helper function so that raw strings didn't have to be "converted" inside an element factory.
- This means that the element factory doesn't have to know about the special chars when it gets a raw... it just has to know it's a raw (string).
- So, that it all done.
- I may not have a lot of time tomorrow... we'll see how cognative and overscheduled I am...

#341.2. 03/19/2019:
- Ok, yet another new state... ok, I just copy and pasted one as it did the work
- Well, attrubute conditional parsing was supposed to be that easy...
- ...but then I remembered that conditionals are part of IElement creation.
- So... store the parts of an element and then create at the end?
- Probably would be good to have a "create element" step that gathers the parts and actually creates the element.

#342.2. 03/20/2019:
- So, this one is boring...
- I didn't really have time today, so I simply added "FinalizePart" as a state to be done after parsing an attribute-part.
- This step will let us assemble/create an element after modifiers or attribute-references are processed.

#343.2. 03/21/2019:
- I crashed today... so nothing happened

#344.2. 03/22/2019:
- Ok, so I spent more time then expected on this, but I got the attribute reference part done.
- It was a little weird because it works like Part, but if the format "finished" it was an error.
- So I needed to get the couple edge cases, some general error handling, then choose a branch for a success case, along with a late failure case.
- I was thinking of trying to write the attribute format handling, but didn't want to do that at this very moment (it's a bit late)

#345.2. 03/23/2019:
- So... close...
- I got distracted half-way through working on this and finished attribute format support, and probably could've done modifier and finalize part.
- But... that distraction has caused it to now be late, and my focus is getting pulled to other subjects.
- Tomorrow I'd like to finish the "parts" and see just how far the tests get.
- After doing some fixes so tests pass*, I still need to support the error handler conditional.
- *I typed this but realized: I don't have any elements in the factory created, so all tests will fail... but I can probably fake it a bit to test parsing.

#346.2. 03/24/2019:
- Boom! Parsing is done... well, kinda.
- As noted yesterday, the factory isn't implemented... so I can't test it.
- Also, the error handler conditional is still needed.
- ...and the perpetual "string quote" challenge. That's like a state machine in and of itself.
- How do I know {!"hello \" world"} is complete or not? (using {} instead of '"')
- But that's for another time... for now, the main parsing body is done.

#347.2. 03/25/2019:
- Oh snap... so, this got screwed up.
- So, I didn't want to spend a lot of time as I had a lot of things to do today...
- ...and then I got sick. I really shouldn't be up right now. I feel kind of terrible.
- I got a bunch done though and set everything up with the intention that I would work on the string handler... later (I would usually be saying "I may not have a lot of time tomorrow...")
- And then the bombshell hit me: the error handler isn't a conditional... it's a modifer.
- "Oh snap... so, this got screwed up."
- So I switched things over from conditional to modifier and... I'm stopping there.
- If I get to this tomorrow, I need to re-evaluate the format because the log can have a a log-level error handler... so, do I have log-level modifiers? Or is this something that's unique?
- Oh snap... (round two). As I typed that, I realized "my parser goes through as if there's a log-level conditional... but it's really a log-level modifier." This is a can of worms I didn't expect to open...
- For another day...

#348.2. 03/26/2019:
- So, what was not mentioned in yesterday's log: I got really sick and was barely functioning
- So I decided to look at the problem discovered... and my mind is too out of it to do anything
- The best I thought of is "have (log) conditional, then (log) modifier, then start attributes"
- The benefit of that is we can still have conditionals, get the modifier parts that would apply to logs, and it allow a minor (but not perfect) fix for "what if the log has a conditional and the attribute has a conditional?"
- I think the solution for the double conditional would be (since I have the count till marker) to count till a marker, and say "stop at the first one" and then just make sure the conditionals are unique (when processing logs).
- Attribute conditionals: I'm content with there being duplicates, as we fix that when finalizing the conditional.
- Something to hopefully plan out tomorrow...

#349.2. 03/27/2019:
- Well, I did plan to do something...
- Problem is, I bit off a bit more then I could chew and it's now time for me to go (joy of remenents of sickness), and I haven't done anything
- Next couple days will be like this, because I am busy. Hopefully by the weekend, we'll be good again

#350.2. 03/28/2019:
- Ok, I decided to go with what was mentioned in #348.2
- Basically:
-- check for conditionals
--- if found, add
--- if duplicate; check if raw, if so then move to normal execution, if only conditionals are followed by an attribute, then move to normal execution, else, error
--- if not conditional, move to modifiers
-- check for modifiers
--- if found, add
--- if duplicate; check if raw, if so then move to normal execution, else, error
--- if not modifier, move to normal execution
-- normal execution...
- This should result in log-level conditionals and modifiers and handling cases where conditionals are next to each other
- Note: there was a 2.5h gap between when I wrote "Ok, I decided to..." and when I wrote the single line above...
- As such, I'm going to (plan to) review that "Basically" writeup (which I redid like 3 times over the course of that 2.5h gap + distractions) to ensure it's sane
- Also, I need to update/redo a few unit tests... joy
- Bonus: I realized I could probably have an optimization stage somewhere.
- Think: the log will only run with valid logs... so all attributes that will only print with invalid logs, remove. All attributes that will only print with valid logs, remove that check as it's not needed.

#351.2. 03/29/2019:
- So I'm half asleep right now, but I did get a chance to look at the format design...
- It works, though there are edge cases (if we get an attribute conditional, do we go right to "normal execution" or throw an exception if an attribute isn't there?)
- I also realized that the attribute format has an issue in my implementation: once in an attribute format, we read until we hit '}'... well "{Message|Something {} isn't right}" is gonna say the format is "Something {" instead of "Something {} isn't right"
- So besides implementing the updated format, fixing the attribute format, and adding unit tests... I still need to implement the error handler
- Bonus: I realized all my examples for the place holder in the attribute format is "{}" (quotes included). I never say if quotes are needed... and I can't focus enough to make a decision now

#352.2. 03/30/2019:
- Ok, I actually have the time to work on this... but I have a couple more pressing things that I have also been procrastinating and should work on.
- In addition, I'm running a program in the background that happens to be making programs like Visual Studio lag when typing... which is bothering me.
- (Hopefully) tomorrow!

#353.2. 03/31/2019:
- And... it's not happening today.
- I spend the day being extremely casual, and that's not changing now.
- I know nothing has been done for this project that has much of a "code" change, but it's mainly been because I was busy with other tasks.
- But doing a ton of stuff sometimes leaves you... I just want to veg today. So I did.

#354.2. 04/01/2019:
- So I got to this late, again, and will have to skip tonight. Tomorrow...
- April Fools!
- I actually managed to do one planned and one unplanned task today.
- Planned: fixed the state machine so it now will properly handle conditionals, modifiers, etc. for log and attribute.
- Unplanned: while working on that, I noticed I didn't have some states correct (ex. count till marker is invoked and then returns on "done", but it would always go to Part instead of whatever invoked it).
- Fixed that and a number of other state issues. That probably saved future-me a bit of time debugging.
- Still need to do the attribute format fix and unit tests.
- That's all today.

#355.2. 04/02/2019:
- I wanted to do something quick, but I didn't get to this until late and I need to be up early.
- So I will skip for today...

#356.2. 04/03/2019:
- This was a weird day... basically, I planned to do one thing, and a quick day of code.
- Instead, I did something completely different, and it's too late now.

#357.2. 04/04/2019:
- Ended up crashing today and didn't get work done...

#358.2. 04/05/2019:
- It's late, but I still wanted to do something... except, I can't.
- I've been running an application in the background for most of the evening, and it's been causing my computer to freeze for ~5 sec, every 30 sec or so.
- It's infuriating... I would rather not have the computer freeze while I'm coding, but I also can't pause the program.
- So... tomorrow.

#359.2. 04/06/2019:
- I determined that "{}" would not require quotes
- While I didn't get to code it, I think my plan is to have the count till marker have an extra parameter of a skip-list of sorts.
- Something that I can say "skip the first n of particular marker"
- Not 100% sure how well it would work, and how well I can modify the count* state to handle "overloading", but that is for tomorrow.

#360.2. 04/07/2019:
- Day 360. 360 days of continuious logging... I went back and counted how many actually had code, and it was ?? <todo later... :P>.
- I was hoping to say "the state machine, except for the error handler, unit tests, and the factory... is done" but upon implementing my skip list, I realized an issue
- I didn't think it was right to have "skip every one of these chars" because a naive implementation would then never find the terminating chars...
- So I made it into a count. Skip no more then n chars. But upon writing it, I realized that the first one is better.
- It may be a "don't skip, skip n, and skip all", but also need to actually keep track of the ones skipped.
- Perhaps... skip implies "LastMarker" flag, because instead of going "we will give you the char and, because it has a raw, we will give you the last one"...
- ...it instead becomes "we will follow skip + raw..." (which needs to be implemented) "...but then the last non-raw we find, we're marking that as the last one once skips are taken into account"
- It will require some work, but it's an idea to implement... another time.
- I have one dead computer, and it will prevent me from being able to do this project when I'm not at my computer... so I may skip the next few days so I can try to actually fix it.

#361.2. 04/08/2019:
- As stated, have to skip today and maybe the next couple, until I can get my computer working again.

#362.2. 04/09/2019:
- See #361.2

#363.2. 04/10/2019:
- See #361.2

#364.2. 04/11/2019:
- See #361.2

#365.2. 04/12/2019:
- Still...
- See #361.2

#366.2. 04/13/2019:
- Minor update/PSA: I had some "challenges" a few days ago. If you ever feel in life that you're overwhelmed and can't cope, reach out to someone... and just "stop" doing things.
- You can always recover from "doing nothing", you can't recover from feeling of control unless you let go of what you think you are in control of. If that makes sense (it's late for me... so it's not the most sensical time for me)
- I had some challenges, talked to people, stopped doing things for a couple days, felt better, needed to do "1 more thing" before I could work on my computer... slept instead.
- Went "1 more thing..." did it (mostly), and the event that went along with it... I couldn't make it. The person I was going with got sick and we skipped the whole thing.
- I took advantage of the day and did a bunch of small things... and slept some more.
- I've said I "crash" sometimes, and that's usually just going to sleep when I least expect to. That happened again, so I still didn't work on the computer today... tomorrow I hope to work on it.
- See #361.2

#367.2. 04/14/2019:
- See #361.2

#368.2. 04/15/2019:
- See #361.2

#369.2. 04/16/2019:
- See #361.2

#370.2. 04/17/2019:
- See #361.2

#371.2. 04/18/2019:
- See #361.2

#372.2. 04/19/2019:
- I'm at the point where I got my files back and am now arguing with UEFI because it doesn't want to start the installer (it's actually taken a few hours to do. I've never had that happen before and it's very frustrating)
- See #361.2

#373.2. 04/20/2019:
- See #361.2

#374.2. 04/21/2019:
- See #361.2

#375.2. 04/22/2019:
- So... I purchased the parts I needed and was told it would arrive today. Meaning I could work on it today and tomorrow...
- They never arrived. >:(
- Means that I'll be working on the computer tomorrow instead...
- See #361.2

#376.2. 04/23/2019:
- Drive came in... and I get to be "old guy yells at cloud" because they decided to use the metric system for measurement and go "1GB = 1000MB" while every computer an electronic system knows "1GB = 1024MB" because of this Base 2 stuff...
- End result, what I expected to be "run Clonezilla to clone from drive A to drive B" became "Clonezilla and other programs won't go near it with a 10 ft pole"
- Joy
- See #361.2

#377.2. 04/24/2019:
- Clone: success!
- I will be starting on the computer in a bit...
- See #361.2

#378.2. 04/25/2019:
- Computer now has an OS... though I need to do a bunch work to set it up
- See #361.2

379.2. 04/26/2019:
- Computer is on and being setup!
- See #361.2

380.2. 04/27/2019:
- See #361.2

381.2. 04/28/2019:
- Still need to do some work on the computer (it's been slow going)
- Tomorrow and the following day will be busy and won't have anything done either
- ...maybe after that
- See #361.2

382.2. 04/29/2019:
- See #361.2

383.2. 04/30/2019:
- See #361.2

384.2. 05/01/2019:
- Still need a bit more time...
- See #361.2

385.2. 05/02/2019:
- See #361.2

386.2. 05/03/2019:
- I planned to do a "hey, I did something!" moment... but weekend plans got messed up, so it's not happening
- But I will stop referencing #361.2 because, while the computer is not back to it's original state, it's usable again

387.2. 05/04/2019:
- I also planned to do something, but I ran into an issue: what the heck was I doing last?
- So I'm just going to go through what I was doing and maybe I can do work tomorrow...

388.2. 05/05/2019:
- Sleep in + unplanned shopping trips + this week requires me to be very on time into the office = I don't have time tonight
- I also might not have time for a couple days
- There might also be an unexpected event (personal thing... but there's a feeling it will happen)
- TL:DR - can't work on it tonight and might be tough to work on it other days...

389.2. 05/06/2019:
- So I wanted to at least do some thinking about this...
- I did, and I went "ah, I remember where I was": I needed to support the error handler
- Then I did some reading and found out "um, yes... but also no"
- So I do need the error handler, but I also need unit tests, and factory implementation.
- Then I saw that I had an "issue" with my skip count, especially with the new "skip-list" system.
- I will have to do more reading, but I'm catching up...

390.2. 05/07/2019:
- Slight delay...
- Was going to do this today but realized I need to do something "really late" and plan to go to sleep early so I can do it.

391.2. 05/08/2019:
- I looked at the count-till code and the skip-list.
- My mind blanked... and I started reading about tumeric.
- So... let me try again tomorrow.

392.2. 05/09/2019:
- ERROR: Tomorrow not found. Retry tomorrow...

393.2. 05/10/2019:
- ERROR: Timeout detected. Retry tomorrow...

394.2. 05/11/2019:
- Fell asleep before I was able to get to this.
- It's been a wacky couple days recently...

395.2. 05/12/2019:
- Let's see if I don't ramble...
- So I thought about the count-till code. There's a primary flaw with how this is to be done: text parsing is hard.
- "yea... others do it though" Do they? I've read a number of documents over the years about how text processing is done, and the most common solution is strict formatting.
- This is where I'm thinking: I specified a generally strict parsing, but also had something akin to recursive code: my_code = "the_code = \"some_code = \\\"this_is_a_pain = 10;\\\";\";"
- Now, the good news is that each of those is seperatable.
- The bad news is that it introduces state.
- Get a count wrong or do something wrong and, because of state, you end up messing things up.
- The best solution I could come up with was to know a handful of special chars and count them so I know when they start and stop.
- What chars in particular? Quotes.
- "Wait, isn't that StringQuote?" yep!
- So the idea I'm running with, and hope to implement (so long as I don't suddenly end up with crazy-wacky life events occuring):
-- Specify chars to count till (no per-char counters)
-- Count until I hit one...
-- If I find a quote, run the QuoteString state (so it should return the raw string and not process it).
-- At the end of the quote, I can count the chars it found and skip that amount... and continue counting.
- This would allow me to ignore any char if it's in a quote.
- So instead of "oh no, I need to find a '{', but there's a quote... so I need to say "ignore the next 5 '{'" and find out that the quote ended after 2 '{' and I'm now screwed up..."
- It becomes "find '{', there's a quote... ok, on the other side of the quote is a '{', so continue processing"
- I'm hoping it works...
- The one thing, as noted in #360.2, is that I still need to take "raws" into account.
- Now those only apply to special chars, and not quotes, but it still is something to note.

396.2. 05/13/2019:
- Too late today (needed to stop distracting myself and do something else, ate of time to work on this)
- Will have to skip tomorrow do to other plans

397.2. 05/14/2019:
- As stated, skipping today

398.2. 05/15/2019:
- I ran out of time today, but I wanted to at least double check my plans.
- So the one thing I wondered: "what if there is only one quote?
- The answer to that question is "do I care?"
- The only spots it matters is when there's a plain text.
- ...
- Actually, hold that thought. My (tired) mind just casually went "quotes don't mean anything in plane text... only for the error conditional. Everything else is just a char"
- Darn you mind...
- Ok, I will have to think this over again tomorrow. It may simplify some work, but not sure yet

399.2. 05/16/2019:
- I distracted myself until I realized I still didn't get anything done and should be done for the day
- So I'm going to have to skip until tomorrow

400.2. 05/17/2019:
- I own a 3D printer.
- This is important because I often print stuff.
- Today, by the time I got to working on this, I opened up files and was about to do some reading...
- ...and the printer started to have issues.
- An hour later, the printer is running again... but I now don't have the time to work on this. Tomorrow...
- Pity, because I really wanted to be like "day 400... I did something!"

401.2. 05/18/2019:
- And punt again...
- Trying to bring my sleep back in line, one hour at a time...

402.2. 05/19/2019:
- I am well past when I should be up, but I wanted to do something quick and it didn't go quick
- I looked into what the counter needs to do and broke it down to two key types of counting:
-- Raw: Unless it's a term char, keep reading. If the term char is "special", then we need to count chars (and determine if we stop on start or end)
-- Attribute Reference: No special chars allowed. Stop on term char.
- This can be turned into a set of flags: IgnoreSpecialChars (otherwise it's default to pay attention to them), StopOnStart, StopOnEnd
- The idea is that just iterate over everything. If it's a terminal char, then stop.
- But, if "IgnoreSpecialChars" is not there, and the terminal char found is a special char, then start counting them to determine if actually a raw char or not.
- For "special char is not raw" cases, then StopOnStart and StopOnEnd are usable flags.
- Basically: ^^^ = the raw ^ and a special char ^.
- If StopOnEnd, then the order is "raw" followed by "special char"
- If StopOnStart, then the order is "special char" followed by "raw".
- Since the terminal char is a special char, it would change where it stops and if there's a "raw" in the count.
- The only open question I have is for "Attribute Format" where it's a "raw"... but there's a "replace {} with the attribute".
- The question: is {} written as is? Or does it follow "raw" rules and has to be written as "{{}}"?
- I like consistancy, which would indicate "{{}}" but as a dev/user, I'd prefer "{}".
- Perhaps the answer is "both"... but then I need for the counter to "know" about this...
- It's late. For tomorrow.

403.2. 05/20/2019:
- Code!
- I changed the state machine prototype for count till marker...
- ...but don't have the time to do the implementation.
- Tomorrow may be busy, but we'll see.

404.2. 05/21/2019:
- I thought "maybe I can do something" but I'm very tired from the day and from getting some poor sleep yesterday.
- Also, this is a little more work/brain power then I can muster right now.

405.2. 05/22/2019:
- I procrastinated too much today and didn't get to this.
- I have more time tomorrow and should be able to get something done then.

406.2. 05/23/2019:
- Well, I did have more time... and then about an hour vaporized, the week took a toll (I'm not usually tired by this time), and I bought shelves of such a specific size that I thought I would need to build them myself
- I'm now so relieved to have found those shelves (maybe it's just me being tired), that I'm gonna push this to tomorrow where I most certainly have time...

407.2. 05/24/2019:
- Code!
- I reverted the CountTillMarker main call to pre-skipList.
- I went to review it and the only thing I needed to do was make sure we read the flags right.
- I did one more mental review and found one issue: observed special chars + last marker flags would fail
- Looking into it, because we would say "nah, we want the last char" we would say we didn't find the end and wait for the next count iteration to get to us...
- Instead, the next iteration would move us an index further and we wouldn't even hit the char.
- I thought it would be an east fix, but it quickly became a "you have to repeat a if statement with 2 elements (||/&&/==/etc.) flipped" and there were already 2-5 elements.
- So, I abstracted it a small amount to a variable and mentially checked it and this time it worked out.
- Good thing I didn't work on it some of the other days I was tired...
- So now.. looking at 389.2, I can now say "this piece is done" and move onto: error handler (+ quote reader), unit tests, and factory impl.
- I think I will do unit tests next.
- It's a pain and "not fun", but while I have my "a}b", "a}}b", "a}}b}", "a}}}b" test on my mind (which is the mental check I went through) and because I kinda put it off for a bit, it would be good to have.
- Plus, I think doing the factory impl. after that would be good... because then I can run tests, and the only tests that should fail are the ones that use the error handler.
- With test passing (sans error handler), I can then do the error handler and, what I expect to be painful..., the quote reader.
- But... put it in the books: parser (sans error handler) is done.

408.2. 05/25/2019:
- Had an unexpectedly long day and need to be up early tomorrow, so push back till tomorrow.

409.2. 05/26/2019:
- Ok, didn't do much, but I at least took the couple test cases from 407.2 and turned them into a TODO comment.
- I want to review the existing tests (do things need to be updated/modified? Are they named correctly?)
- Then I want to fill in the missing tests

410.2. 05/27/2019:
- Some issues occured today and I spent a lot of time doing some things I didn't plan for... now it's late and I need to go

411.2. 05/28/2019:
- So, checking the unit tests was actually not too bad
- Basiclly:
-- Raw/terminator tests
-- Log + attribute tests
-- Ensuring that "general" formats are correct for what they're supposed to be.
- I'm delayed on a couple tasks I need to complete, so I'm doing very small chunks...
- Tomorrow, unless things go wrong, I should be able to figure out the general formats and hopefully start on the raw/terminator tests.

412.2. 05/29/2019:
- First thing: the general formats are fine and don't need modification.
- So we know about the tests (see 411.2) but there was one set I was concerned about: log attributes.
- So valid (+)/invalid (-) conditionals are valid on logs AND attributes.
- So how do we know if a validity conditional is for a log or for an attribute?
- Check for disputes.
- Huh? Think of this: if we say "@+{Message}" and it applies to the log, then message is printed only for valid logs. But the same happens if applied to the attribute.
- What about "@+{Message}+{Timestamp}"? Same.
- What about "@+{Message}-{Timestamp}"? See, here we have a conflict. This would be at the attribute level so they don't remove the whole log.
- I'm wondering if there should be a post process step where this can be evaluated (combine multiple raws next to each other, remove empty attributes and raws, swap log and attribute conditionals, etc.)
- One worry is how to deal with weirder cases...
-- "@+{Message} {Timestamp}" - Oh, it's an attribute conditional. "Correct"
-- "@-+{Message} {Timestamp}" - Wait... that's not valid. "Correct"
-- "@++{Message} {Timestamp}" - Uh... I see a raw "+" and then the attributes. "See... is that what we want? Or should it evalute to a log conditional and a attribute conditional?"
- I will have to do more thinking of the weird cases... maybe something to escape it?
- Bonus: realized that we may want a bit of some additional check before switching to a new "part"
-- "@{Message} - {Timestamp}" - Is this an invalid format, or valid and simply has a "raw" in the middle? Right now, we'd saw "raw ' ', start of an attribute... but it's invalid because there's no#############
- Please ignore the bonus: "-" is a special char, so it needs to be escaped before it will be seen as a "raw".
- Carry on... will see what happens tomorrow.

413.2. 05/30/2019:
- I needed to finish some work, so that took up my "coding" time.

414.2. 05/31/2019:
- So I'm behind on a project that I really want done...
- ...and spent the past 2 hours reading about (and trying to wrap my head around) Boost Spirit (Qi).
- I'm not using it... but an app I use was, and I needed to figure out how to get some of my settings to work.
- Let me tell you: just because you can, doesn't mean you should.
- Code should be understandable and not require hours of research to understand.
- I want to try and keep mine as simple as I can, even with something as complex as a parser-state machine.
- Hopefully that's the case, but I'm the person writing it... so I don't know if it's the case.
- If I have the time, I will be enumerating all the tests I want to write tomorrow. Either then or later, I'll implement them.

415.2. 06/01/2019:
- <crashed>

416.2. 06/02/2019:
- I'm back with another delay... I was out for a long time today, and spent the rest of the day relaxing and doing something completely unrelated to programming...
- So I'll push back today, just so I can continue to relax :P

417.2. 06/03/2019:
- ...and, who didn't see this coming, this didn't work.
- I took a look at the unit tests and then went "wait, I have like 20 other things I need to do" and now it's late and I can't do things today
- Didn't help that I'm an hour later to things then I planned.
- *sigh*

418.2. 06/04/2019:
- Wrote up the test cases for char. counting.
- Might look into the log-level tests... but can't think to well right now. So will figure that out tomorrow.

419.2. 06/05/2019:
- Timing... though, one "nifty" thing is I have been told that if I can get a working demo of this, my company may let me work on this full time.
- ...at least for a bit. But, let me get this working first.

420.2. 06/06/2019:
- More poor timing. Was hoping to do something...

421.2. 06/07/2019:
- Wrote a set of log level tests (todo)
- But... I'm tired, so I didn't write what the result should be. Oops.
- Tomorrow...

422.2. 06/08/2019:
- I wrote out some expected results... but I'm iffy on them.
- I want consistancy in format. I don't want "well, in this specific arrangement, do X"
- In addition, it's very tempting to look at what I implemented and go "so this is what will happen"
- No... I want to look at the format, the docs, and say "this is what happens" and then fix the code if it doesn't do that
- But I'm struggling. These are weird edge cases that, if given a consistent format, people will be able to do some crazy things with.
- But if special cases are done, it hardcodes what is supposed to occur.
- It makes me think "Perhaps, log and part format elements should be different"
- I may go with that, but not today. I want to consult some friends first.

423.2. 06/09/2019:
- I did not get to talk with anyone, and instead worked on a different program for most of the day.
- For another time.

424.2. 06/10/2019:
- Still didn't talk with people yet.
- More importantly: I've said a few times "don't kill yourself with code".
- You can also say "Don't kill yourself..."
- In my case, I tend to get poor sleep. Not because I can't stay asleep, but because I stay up so late.
- Generally, it just meant I was tired... but I started to worry.
- Fast forward: between many of the real world events, family events, work, and poor sleep. I've been becoming depressed and increasingly unable to cope with... the world.
- I realized: the best thing I can do to try and "fix" this is get better sleep.
- It's not the only thing that can be done, but it's one that probably sets a good foundation for everything else.
- As such... today I was late with doing a lot of stuff, realized the sleep thing, and went "err... sleep is higher priority"
- Tomorrow will be busy in general, so unlikely

425.2. 06/11/2019:
- Never got to chat with the friend. Tried to, but they were distracted...
- Wasn't gonna have time today to work on this anyway.

426.2. 06/12/2019:
- I sent messages to friend, who responded.
- But I still need to discuss with them for a bit first.
- So nothing today...

427.2. 06/13/2019:
- So, I went through the comments and responded.
- This time, they were busy and didn't respond back. :P
- I think my plan is to leave the special char escaping, and just change the value to be something different.
- I don't want to use up tons of special chars, but it's also a weird and wacky mix of scenarios that comes to a head with valid/invalid conditionals
- So hopefully, it won't be many additional chars
- I'm still going to wait for a response before going off to do it (and I'm distracted/busy)

428.2. 06/14/2019:
- Busy/lazy day...

429.2. 06/15/2019:
- I had a long conversation with my friend
- Basically: my 2 options are
-- switch from repeating char escape to using a special escape char. Think \x -> x, \\ -> \, etc.
-- change the log-level chars to be something else (don't share special chars for similar functionality)
- I opted for the latter
- Reasons:
-- Most of the repeating char escaping code is done already
-- Faster key-presses for the dev since repeating chars means your finger is already over the key
-- Doing a special escape char uses a _new_ special char
-- The log-specific special char only apply to conditionals AND only exist for the duration of the log-conditional segment
- So, the last one was an "oh yea" moment
- The instant the log parsing moves from "log conditional" to "log modifier" or "raw" or "attribute", those chars become free to be used by anyone again
- So, it doesn't _use_ additional chars, reduces dev work (both for me and the person writing the format), and prevents the weird "how do I handle this combo of conditionals?"
- Now, tomorrow may be busy, so I may not be able to do too much, but we'll see.

430.2. 06/16/2019:
- Yea, I was too busy today... tomorrow (hopefully)

431.2. 06/17/2019:
- Was on time... and then ran over time very quickly

432.2. 06/18/2019:
- I crashed last night...

433.2. 06/19/2019:
- Crashed again... not a good habit to get into, but it is getting me sleep...

434.2. 06/20/2019:
- I didn't crash! But I am tired... so let me see if I can keep this short
- So I picked 'v' to replace '+' and 'i' to replace '-'.
- "But... those are normal chars. How are we supposed to know when it's no longer a special char?"
- Well, right now, I'm planning on it being a special char until one of 4 things happens:
-- A modifier is found
-- An attribute is found
-- A char that isn't a log entry conditional is found
-- The char is escaped
- That should mean the instant anything that is not a 'v' or an 'i' will instantly revert the chars back to normal and no more thought needs to be applied
- I don't think 'v' will cause problems, but I do have a bit of concern about 'i'...
- If I want to specify an invalid log only, and then say "incorrect parameters in log:", it would have to be written "@iiincorrect parameters in log: ..." which is a little wacky.
- I haven't decided (and won't, for tonight) if I want it to be "@iiincorrect parameters in log: ..." or "@iiincorrect parameters iin log: ..."
- The former would be an "exit ASAP" case, while the latter is "consistancy until we switch what we're parsing"
- I'm worried that both cases aren't ideal.
- I like consistancy, but I'd like to reduce the amount of time someone (and the parser) needs to know what is a special char.
- But this is the most I can muster at this point... something to think about tomorrow.

435.2. 06/21/2019:
- Ok, bad time managament and a collection of cooking videos later, it's late for me to do too much
- I thought about the issue from yesterday, and I think the best option is to do the first escape of the conditional instead of waiting until we reach an attribute.
- This keeps parsing and "what do I need to escape" to a minimal.
- That's all I have for now.
- Tomorrow I'd like to update tests, general formats, and the parser code... we'll see how far I can get.

436.2. 06/22/2019:
- I intended to do stuff earlier, but never got around to it
- The most I did today is update the general formats
- I don't have the mental capacity right now to come up with new/alt tests (which are todos right now)
- Using it, it does seem a bit weird. I'm iffy on it... but my challenge is I want complimentry symbols and can easily mean good/bad, and most/all of them are already used for normal conditionals... which can't conflict with the log conditionals

437.2. 06/23/2019:
- Err... I had the time. Then I got into discussing desserts with people and catching up on E3...
- Tomorrow...

438.2. 06/24/2019:
- Couple unexected events today... and was a bit late.
- I rewrote the test cases (all todos) for the log-level tests
- This week will be a (more then a) little wacky, so I may not be able to do things for a few days (not that it really matters, since I seem to do one or two non-status updates a week at this point)
- But, we'll see

439.2. 06/25/2019:
- Skipping today

440.2. 06/26/2019:
- Skipping today

441.2. 06/27/2019:
- (still) Skipping today

442.2. 06/28/2019:
- (still) Skipping today

443.2. 06/29/2019:
- Hopefully the last "skip" of this week. We'll see

444.2. 06/30/2019:
- And see we did... One task for the day took about 4x longer then planned, and now I don't have time

445.2. 07/01/2019:
- This is a weird one: I got half way through the parser work, but I'm also half asleep.
- So, since I don't want commit a half-finished change, I will simply commit the log and leave the rest of the code for tomorrow.

446.2. 07/02/2019:
- I didn't finish due to a couple questions/issues that need to be addressed:
-- Conditionals vs. raw is a bit weird at the log level, so the "what do we do if we already have that log conditional" needs to be updated
-- Are the values incremented properly
-- I realized that any of the states that support re-entry may never function or may loop because the expected re-entry trigger doesn't exist
- I will hopefully finish tomorrow
- I did answer a couple test questions (what is the result of this input?)

447.2. 07/03/2019:
- Long weekend... and I'm already exhausted.
- This is a good thing, because I've gotten bad sleep for a while and having a lot of "wake up early" moments has knocked my bio-clock to "hey, it's late" and I'd like to keep it that way
- Tomorrow will be a casual day, so I should be able to do something

448.2. 07/04/2019:
- I have a time commitment to finish something else tomorrow. I've been working on it all day.
- Hopefully tomorrow I can answer the questions and do something

449.2. 07/05/2019:
- Err... I didn't get to this today

450.2. 07/06/2019:
- I forgot to say yesterday that I was going to be busy today and wouldn't be able to get this today.

451.2. 07/07/2019:
- ...and today was bad timing.
- When am I going to finish this code change? It's been days since I started it...

452.2. 07/08/2019:
- More joys of timing... and tomorrow will be weird so I may not get to this tomorrow.
- I'd like too... but can't right now.

453.2. 07/09/2019:
- Yea, today was weird.
- I technically have time... but it's been a weird couple days for me and I needed to take some time off from work, so I'd rather keep it casual today.

454.2. 07/10/2019:
- Fun fact... I realized I actually commited the code I was working on a few days ago, when I commited the wrong file. Well... it's half there then :P
- I started off with "I will do this!"m
- And I could barely stay awake...
- I thought at least a bit and decided to re-write main section of the function.
- Otherwise, need to review #446.2 after doing that work.

455.2. 07/11/2019:
- I crashed... so nothing got done

456.2. 07/12/2019:
- ...and recovery!
- I have finished the conditional code!
- It's there. Code. I actually wrote code again.
- Yes, I've had longer stretches of "not writing code", but this was particularly frustrating...
- It took a bit to figure out, and then I started and... didn't finish.
- Half-finished work doesn't make me happy.
- Now I'm happy.
- Now, not everything is rosey... I still need to implement support for re-entry
- But that... is for later.

457.2. 07/13/2019:
- Got distracted reading about the internals of "Stateless" (the state machine we use)
- Tomorrow...

458.2. 07/14/2019:
- Fixed re-entry and updated dependencies
- Also, found a bug!
- "Um... ok?"
- I wanted to see how a couple formats would go through everything, and ended up picking the one test where I got a false positive.
- Expected (completed code): parse the format, run through the element factory, check the created elements and... EXCEPTION! (valid and invalid format conditions at the same time)
- Expected (code in current state): parse the format, run through the element factory, EXCEPTION! (element factory isn't implemented)
- Actual (code in current state): parse the form... EXCEPTION! (state machine could not unbox a specific argument for the next state)
- What was funny is that it showed up as a passing test, because both the failed unboxing and the "final" code would produce the same exception.
- That's all for now...

459.2. 07/15/2019:
- So, this wasn't what I was expecting...
- So I debugged the issue and found what was happening: it's an issue (in my mind) with Stateless (the state machine library we're using)
- Basically: I expected the issue was that I finish checking the log modifier, I go to tell the state machine to do a "count till marker" and it unboxed the enum wrong to an `int`.
-- Note: I have both done, and seen, dynamic argument handling/boxing/unboxing try to get the internal representation of the type and end up saying an enum is an `int` or some other numeric type. Usually depends on how the enum was written, but could happen... I think...
- Reality: I finish checking the log modifier, I go to tell the state machine to do a "count till marker", then I return from telling that to fire... and Stateless tries to trigger the doneIntTrigger (having previously finished doneTrigger) and it says "hey, there's no int as needed by this trigger"
- Turns out, paramaterized triggers don't really matter for entry/exit from actions. They are simply invoked if the underlying trigger matches.
- This is an issue for me... see. https://github.com/dotnet-state-machine/stateless/issues/64
- Could I change my code to have different underlying triggers? Yes.
- Could I re-write states so they only have one entry/exit per-underlying trigger? Yes.
- But there is nothing that says I can't have multiple underlying triggers... in fact, it could be a useful feature to be able to say "I have a trigger for an entry/exit that updates a display, and another for the same trigger that updates statistics, etc."
- But I don't get an error for having multiple with the same underlying trigger, there are no docs that say I can't, and I don't know how popular the library is... but nobody seems to have tried besides the one other person in the thread I replied to.
- Long story short: I'm not changing my code.
- So... what to do?
- I've worked with OSS code before. I will see what/if someone replies to my question/request with.
- My 2 expected responses:
-- Nope, not supporting that
-- If you'd like to contribute the change, please do
- If they say "actually, yea... give me a week" I'd be suprised.
- But each has a reaction:
-- "Nope": then please either implement an exception, docs, etc. to make this known or I can do it
-- "Please contribute": Ok, I'll start working on that
-- "Yea": sweet... I'm gonna take some time off while they work on that (and probably write the tests)
- But for now... we wait.
- Helps, because, I'm busy tomorrow and probably won't be able to do anything anyway.

460.2. 07/16/2019:
- Yea, not getting anything done today
- No responses on the ticket either (experience with OSS tells me I may not get a response for days to months)

461.2. 07/17/2019:
- Started opening files in Stateless prep for doing my "fix"
- Might be busy tomorrow, but not sure yet

462.2. 07/18/2019:
- Yea, ran out of time today

463.2. 07/19/2019:
- I forked the stateless repo (https://github.com/rcmaniac25/stateless) and setup the files
- Everything (untouched) compiles and tests pass...
- First up:
-- Q: where do I put tests for this?
-- A: No idea.
- All the areas that I found OnEntry getting used (and thus, assumed "this is one of/the OnEntry test(s)") was really testing something else.
- I will have to look and see where to put tests, make sure everything except my tests pass and then... I can work on the fix
- Tomorrow I should be able to do something, but as a precaution, I'll say "maybe"

464.2. 07/20/2019:
- Good thing I said "maybe"
- Had an event that I expected to take 2-3 hours
- It took 6-7 hours
- I'm tired and it's late. Tomorrow

465.2. 07/21/2019:
<stateless library>
- I didn't really have time to do things, but I wanted to at least find where I could write the tests I need
- I'm not sure... but StateMachineFixture seems good...
- I pause because "this tests the StateMachine" and the thing I need to test would probably be the StateRepresentation.
- But, this is the weird part: will that be where the change occurs?
- Right now, StateRepresentation goes through each entry/exit action and simply executes it.
- I want it to only execute the ones that it supports
- "But wait, so it isn't really the StateRepresentation, but the Entry/ExitActionBehaviors"
- Yes! Or is it? What if this is actually a validator (not related to their existing validator) for Triggers?
- StateMachine? StateRepresentation?, *ActionHehaviors?, What if it's somewhere else?
- It's possible I won't know until after I do the work...
- I'll double check again tomorrow, but worse case, I write them in StateMachineFixture and move it to/create the correct test fixture

466.2. 07/22/2019:
- I instead went to bed early and didn't get anything I wanted to get done, in any subject, done last night

467.2. 07/23/2019:
- First, I wrote the unit tests
- Second, unit tests save the day (again)... because it uncovered something I didn't expect
- So when I first started working with Stateless, which was a while ago, the method you made a parameterized trigger was as follows: "new StateMachine<State, Trigger>.TriggerWithParameters<P1, P2, P3>(Trigger.Thing);"
- Either it wasn't documented, I missed it, used a different source, or it was introduced after I started using stateless... but this is the new way you do it: "sm.SetTriggerParameters<P1, P2, P3>(Trigger.Thing);"
- I'm fine with either, though I wanted a static trigger (so I could have external functions that invoked triggers).
- But I learned 2 benefits of the other/new method:
-- 1. It means parameter validation will occur so if you do my trigger creation, but one is generic (object) and one is specific (not-object) for the same trigger, and configure the specific one while using the generic one, it will validate it's a value that can be unboxed for the trigger.
-- 2. It makes sure that you only have one trigger (enum) per trigger (TriggerWithParameters)
- Now, that may work for some automated state machine creation, but if you are doing something similar to me, where you say "Done (string)" and "Done (int)" and ... then you have an issue.
- Looking at the code a bit, I need to do a bit of work so both methods of trigger creation work.
- So for now, just unit tests.

468.2. 07/24/2019:
- So... I don't really have time today...
- ...but I did stare at the code for a bit.
- I'm a little stumped on how to handle multiple triggers with the same underlying trigger, but different parameters.
- Their code isn't terribly complex, so I'd rather not make it complex with Dictionary<Trigger, List<??>> where ?? is some value type.
- "That's not complex", well... experience tells me it still doubles the amount of code that is needed due to boilerplate.
- Alt. is making some special key-type that takes parameters into account...
- All this is before even pointing out that the internal parameter list for TriggerWithParameters is private and would have to be exposed somehow.
- This also all assumes the devs won't just go "meh, we have no interest in this" (again, OSS is done as a hobby usually and doesn't necessarily get full on attention. You want an OSS devs attention, pay them. Bonus: responding to a closed issue makes it even more unlikely to get a response)
- At least while I'm half-asleep, I do question if I should just try to re-write my SM creation... but that is for less-tired me to figure out

469.2. 07/25/2019:
- Took a much needed nap...
- ...and ran out of time today

470.2. 07/26/2019:
- Err... no time today
- I'm busy with a lot of things.
- When something doesn't go right, I'm usually unable to do other tasks/projects <-- Happened a few times today
- In addition to that, I planned to go out for a few hours today... and then ended up adding a few more on top of that.
- Not on purpose, mind you.
- Result: it's later then I desire and can't do anything today.
- I'll still post my usual "not today" posts, but I need to catch up on things and don't know when I'll get back to this.
- Especially since the next big task is "is it worth changing stateless? Or should I just change how I do my state machine?"

471.2. 07/27/2019:
- So, changing my state machine is indeed easier...
- But I still think it should be supported in Stateless
- Result: "why not both"
- Basically, I'll #if the code so it's "the nice way" and then "the working way".
- Then I'll work on Stateless for a while to try and support multiple triggers.
- I'll open a PR and move on.
- If they eventually merge it, I'll update and switch back to "the nice way"

472.2. 07/28/2019:
- Ran out of time today, maybe tomorrow

473.2. 07/29/2019:
- Still no time...

474.2. 07/30/2019:
- Forgot to say the usual weekly "won't be able to do it tomorrow" in reference to today
- Might be busy this week in general...

475.2. 07/31/2019:
- Today was simply exhausting... I didn't actually start doing things until maybe right before I wrote this.
- Basic/expected thing: no time tonight

476.2. 08/01/2019:
- No time today

477.2. 08/02/2019:
- Again, no time.
- Might not have time for a few more days

478.2. 08/03/2019:
- Again, no time.

479.2. 08/04/2019:
- Again, no time.

480.2. 08/05/2019:
- Did the "temp fix" in the parser.
- I started to test but ran into various real-world tasks that needed to be completed...
- ...and that the element factory isn't implemented yet.
- So I need to write a mock or implement it (mock would probably be faster...)
- Another time (maybe tomorrow)

481.2. 08/06/2019:
- ...no time today. Might not have time tomorrow either

482.2. 08/07/2019:
- What's this? Code?
- Yea, it hasn't been too long, but it still feels like it's been a lot longer.
- So the main thing I did was figure out how to pipe the element factory into the tests.
- Then I implemented a mock for the main test I was working on and tested it.
- Function worked! (test failed, but that was expected)
- So next up would be to implement the...
- So, probably more tests... but as I had to (temporarily) add a mock, it made me realize I need "something" to get the tests to run.
- So next thing I'd like to implement is the element factory.
- Comically, I don't think I need to implement the elements themselves... just the factory.
- It will fail upon execution, but my goal is to test the parsing first and foremost.
- If it fails to parse, it's gonna give me the wrong printout anyway.
- This should lead to finishing the parser.
- Then I can implement the elements themselves... and see if everything passes.
- Finally... finally! We could move onto doing some logic with the elements that have been found and try to make this be "smart"

483.2. 08/08/2019:
- Forgot my original plan was, once the swap out occured, to work on stateless :P
- Also, no time today

484.2. 08/09/2019:
- Still no time today

485.2. 08/10/2019:
- Started to do work on stateless
- I'm already worried... I have little positive opinion that this would get considered for merger
- It may require a larger re-work then I originally intended
- Originally: change from using the ITrigger value as a key for things to using some composite key so that different Type array arguments would produce a different key
- Reality: I did that... and then I was reminded that getting the hash code of an array is a pain.
- GetHashCode on an array will return a unique ID that represents the array object internally to the GC (IIRC).
- As such, arr1.GetHashCode() == arr1.GetHashCode(), but creating an identical deep copy of arr1 and doing arr1.GetHashCode() == arr2.GetHashCode() will be false.
- So, that's one bug I encountered (didn't know about the unit test that ensured only 1 target existed, updated it to take arguments into account... and it didn't fail... so I knew I had a code bug)
- The other issue is what came next: state representation and entry action
- The basics, and this is the most I'll say, is unlike StateMachine and TriggerWithParameters... the other types have public functions with these triggers.
- So... I'll either need to publicize the composite key, make a generic key-type, or rewrite a fair amount of components to make this all work.
- Joy...

486.2. 08/11/2019:
- As a programmer/software engineer, a common action is to go "this isn't right" and to try and fix whatever isn't working
- In my case, a website I use has a utility that isn't working and the offline version (open source) has a bug.
- As I can't get the website to work, it's quite frustrating and I will put this project off to fix it so I can have sanity again
- Spending hours trying to get something to work that isn't is one of the biggest time wastes I can handle...
- Another time...

487.2. 08/12/2019:
- Again, skipping

488.2. 08/13/2019:
- Again, skipping

489.2. 08/14/2019:
- Again, skipping (this is gonna keep happening)

490.2. 08/15/2019:
- Again, skipping

491.2. 08/16/2019:
- Again, skipping

492.2. 08/17/2019:
- Again, skipping

493.2. 08/18/2019:
- Again, skipping

494.2. 08/19/2019:
- Again, skipping
- And I'm busy tomorrow
- Why is that important if I'm skipping?
- Because I got "far enough" with the fix in a utility I was working on
- So I go back to this!

495.2. 08/20/2019:
- Yep, no time today

496.2. 08/21/2019:
- Ended up staying out later then planned... now no time

497.2. 08/22/2019:
- And... today was one of the most relaxing days I've had in a long time.
- But time passed by and now I'm tired.
- It's tiring to do nothing :P
- Hopefully tomorrow

498.2. 08/23/2019:
- And tomorrow never came... like, nearly a reality
- "uh..." I slept nearly to the next day
- I'm now up and doing some things... and ironically, I'm tired
- I'm probably going to go BACK to sleep and try to get sleep schedule back in order

499.2. 08/24/2019:
- "Ok! Let's do this"
- <looks at code>
- I have... very little interest in the amount of work needed to do this change
- Not sure right now if it's just because I have a bunch of other things I'm interested in, or I'm just like "this isn't my code... I don't want to spend weeks and weeks on this"
- As such, I'm pushing this off again...

500.2. 08/25/2019:
- I said to myself "#500 log! I need to do something for this!"
- Ran out of time and said "at least let me look at the code..."
- I like Stateless, but it's a bit messy*
- *now, it's not bad. I've seen worse, and the issue stems more from the templates.
- But as with most code, this happens over time
- They probably started out with just something basic, probably no "trigger with parameters". So just a "here is an enum key" and went from there
- Later, trigger with parameters appeared and they went "well... it's a lot of work to replace that single enum key, so we'll just have something that encapsulates the parameters and whatnot... and can expose the trigger enum key"
- That works, but by relying on that enum, little ole me is now looking at that legacy and saying "well... it's a lot of work to replace that single enum key"
- And the solution I'm looking at is "...so we'll just have something that encapsulates the key and whatnot"
- This is a bit grand, and a lot of work. More then I want...
- So as a heads up (to myself and for anyone that has actually found this project and is reading it in the blog-post style I've been writing)...
- ...the next 2 weeks will be wacky and I may not be able to do any work on things
- I probably "can" do work, but my head will be elsewhere.
- During that time, I will probably look at this and go "I should revisit 471.2" where I decide between "is it worth it?"
- The thing is, I kinda want to do the work on stateless... but I also have so many other projects, my inner-manager (who keeps yelling at me to go to bed) is like "the goal is to get Steth working, not spend the next month on Stateless" and it's true
- So I need to probably decide "can I make this work quickly", "is it worth the time spent?", or "let me do more work on Steth before doing work on stateless"

501.2. 08/26/2019:
- I'm very out of it right now
- I can't even get some of my simple tasks done...
- So, skipping tonight. Probably tomorrow too

502.2. 08/27/2019:
- Skipping today

503.2. 08/28/2019:
- Won't have the time today

504.2. 08/29/2019:
- Skipping today for more time-sensitive stuff

505.2. 08/30/2019:
- Yes I keep skipping... but I've had some time sensative things to complete
- I have to skip today...
- And after tonight, I may not go to sleep for 36 hours... so I'm certently not doing it tomorrow

506.2. 08/31/2019:
- Skipping today as foretold...

507.2. 09/01/2019:
- Uh... well this is a little more info then I intend, but it's interesting none the less...
- I'm evacuating my residence right now, so I will be busy and unable to work on this and probably won't be able to do it tomorrow either

508.2. 09/02/2019:
- Well... this is a weird cituation to be in...
- I'm not sure I'll get to work on this at all this week
- I'll have to see later in the week

509.2. 09/03/2019:
- And the twists keep coming...
- Skipping today

510.2. 09/04/2019:
- Well, I'm no longer in the wacky places I was before...
- ...but I don't have time today and may skip the rest of the week to recover

511.2. 09/05/2019:
- Skipping today

512.2. 09/06/2019:
- Still skipping

513.2. 09/07/2019:
- Yea, still skipping
- Trying to get a lot of things in order

514.2. 09/08/2019:
- I was thinking "maybe today" but ended up going in every direction to do something else
- I then thought "maybe tomorrow" but I screwed up my backup software a couple days ago, and I need to get it working
- *it's open source, so there's no support outside of a forum and doing it yourself... and the forum isn't helping right now

515.2. 09/09/2019:
- Still skipping
- Bit of wacky busy-ness, and need to fix the backup software first
- Will be skipping tomorrow too

516.2. 09/10/2019:
- Skipping

517.2. 09/11/2019:
- Skipping again

518.2. 09/12/2019:
- Still working on other things, so skipping today

519.2. 09/13/2019:
- Still skipping

520.2. 09/14/2019:
- Still skipping

521.2. 09/15/2019:
- Nother day
- Nother skip

522.2. 09/16/2019:
- Skip

523.2. 09/17/2019:
- Skip

524.2. 09/18/2019:
- Skip

525.2. 09/19/2019:
- Skip

526.2. 09/20/2019:
- Skip

527.2. 09/21/2019:
- Skip

528.2. 09/22/2019:
- Skip
- Been very busy and just need to get through some things that are taking forever to finish...

529.2. 09/23/2019:
- Skip

530.2. 09/24/2019:
- Skip

531.2. 09/25/2019:
- Skip

532.2. 09/26/2019:
- Skip

533.2. 09/27/2019:
- Skip

534.2. 09/28/2019:
- Skip

535.2. 09/29/2019:
- Skip

536.2. 09/30/2019:
- Skip
- So many skips...

537.2. 10/01/2019:
- Skip

538.2. 10/02/2019:
- Skip

539.2. 10/03/2019:
- Skip

540.2. 10/04/2019:
- Skip

541.2. 10/05/2019:
- Skip

542.2. 10/06/2019:
- Skip

543.2. 10/07/2019:
- Skip

544.2. 10/08/2019:
- Skip

545.2. 10/09/2019:
- Skip

546.2. 10/10/2019:
- Skip
- So... I've been doing a lot of skips
- Life and work have just been really wacky... and I shot my sleep schedule and it's been very hard to get back to something good
- On top of that, the next week or so is going to be even more busy, so getting to this is going to be quite low priority right now
- Would like to do something, but can't right now

547.2. 10/11/2019:
- Skip

548.2. 10/12/2019:
- Skip

549.2. 10/13/2019:
- Skip

550.2. 10/14/2019:
- Skip

551.2. 10/15/2019:
- Skip

552.2. 10/16/2019:
- Skip

553.2. 10/17/2019:
- Skip

554.2. 10/18/2019:
- Skip

555.2. 10/19/2019:
- Skip

556.2. 10/20/2019:
- Skip

557.2. 10/21/2019:
- Skip

558.2. 10/22/2019:
- Skip

559.2. 10/23/2019:
- Skip

560.2. 10/24/2019:
- Skip

561.2. 10/25/2019:
- Skip

562.2. 10/26/2019:
- Skip

563.2. 10/27/2019:
- Skip

564.2. 10/28/2019:
- Skip

565.2. 10/29/2019:
- Skip

566.2. 10/30/2019:
- Skip

567.2. 10/31/2019:
- Skip

568.2. 11/01/2019:
- Skip

569.2. 11/02/2019:
- Skip

570.2. 11/03/2019:
- Skip

571.2. 11/04/2019:
- Skip

572.2. 11/05/2019:
- Skip

573.2. 11/06/2019:
- Skip

574.2. 11/07/2019:
- Skip

575.2. 11/08/2019:
- Skip

576.2. 11/09/2019:
- Skip

577.2. 11/10/2019:
- Skip

578.2. 11/11/2019:
- Skip

579.2. 11/12/2019:
- Skip

580.2. 11/13/2019:
- Skip

581.2. 11/14/2019:
- Skip

582.2. 11/15/2019:
- Skip

583.2. 11/16/2019:
- Skip

584.2. 11/17/2019:
- Skip

585.2. 11/18/2019:
- Skip

586.2. 11/19/2019:
- Skip

587.2. 11/20/2019:
- Skip

588.2. 11/21/2019:
- Skip

589.2. 11/22/2019:
- Skip

590.2. 11/23/2019:
- Yea... still on hiatus...
- Skip

591.2. 11/24/2019:
- Skip

592.2. 11/25/2019:
- Skip

593.2. 11/26/2019:
- Skip

594.2. 11/27/2019:
- Skip

595.2. 11/28/2019:
- Skip

596.2. 11/29/2019:
- Skip

597.2. 11/30/2019:
- Skip

598.2. 12/01/2019:
- Skip

599.2. 12/02/2019:
- Skip

600.2. 12/03/2019:
- So... I wanted to do something so "day 600" wasn't just another skip
- I only really upgraded dependencies
- I actually hit an issue with this, as moving from Microsoft.NET.Test.Sdk 16.2.0 -> 16.4.0 resulted in "testhost.dll" not being found
- From everything I saw, people's response was "well, you have to install Microsoft.NET.Test.Sdk"
- Um... literally, that changing was what have me issues
- "Make sure you have <*Unit Visual Stufio adapters> install"
- Yep...
- Ah, the issue was I didn't run xunit
- Uh... I'm not running xunit. Anyone with NUnit?
- Nope...
- My solution for now was to downgrade back to 16.2.0
- So, while I'm here... basically: I took a break because I had a project not realted to this, and it had a deadline
- While working on the project, the equipment I was using broke.
- While fixing the equipment, I got more responsability at work
- While fixing the equipment and spending more time at work, I started learning a couple new programs
- While doing all that, I aquired a whole bunch of new devices/materials for various projects
- While this happened, holidays, vacation, various other things came up
- While... I went "how long is it gonna take to get back up to speed?"
- I bit off more then I could chew. I'm trying to work my way backwards...
- And the biggest part: I'm trying to get on a more regular sleep schedule (not doing well, but trying)
- All of this means the project is still on hold... I may try to do a PoC thing again
- Basically: let me skip the formality and just try to make something work
- It may not happen, but one todo list at a time...

601.2. 12/04/2019:
- Skip

602.2. 12/05/2019:
- Skip

603.2. 12/06/2019:
- Skip

604.2. 12/07/2019:
- Skip

605.2. 12/08/2019:
- Skip

606.2. 12/09/2019:
- Skip

607.2. 12/10/2019:
- Skip

608.2. 12/11/2019:
- Skip

609.2. 12/12/2019:
- Skip

610.2. 12/13/2019:
- Skip

611.2. 12/14/2019:
- Skip

612.2. 12/15/2019:
- Skip

613.2. 12/16/2019:
- Skip

614.2. 12/17/2019:
- Skip

615.2. 12/18/2019:
- Skip

616.2. 12/19/2019:
- Skip

617.2. 12/20/2019:
- Skip

618.2. 12/21/2019:
- Skip

619.2. 12/22/2019:
- Skip

620.2. 12/23/2019:
- Skip

621.2. 12/24/2019:
- Skip

622.2. 12/25/2019:
- Merry Christmas and Happy Holidays
- Skip

623.2. 12/26/2019:
- Skip

624.2. 12/27/2019:
- Skip

625.2. 12/28/2019:
- Skip

626.2. 12/29/2019:
- Skip

627.2. 12/30/2019:
- Skip

628.2. 12/31/2019:
- Skip

629.2. 01/01/2020:
- Happy New Year!
- Skip

630.2. 01/02/2020:
- Skip

631.2. 01/03/2020:
- Skip

632.2. 01/04/2020:
- Skip

633.2. 01/05/2020:
- Skip

634.2. 01/06/2020:
- Skip

635.2. 01/07/2020:
- Skip

636.2. 01/08/2020:
- Skip

637.2. 01/09/2020:
- Skip

638.2. 01/10/2020:
- Skip

639.2. 01/11/2020:
- Skip

640.2. 01/12/2020:
- Skip

641.2. 01/13/2020:
- Skip

642.2. 01/14/2020:
- Skip

643.2. 01/15/2020:
- Skip

644.2. 01/16/2020:
- Skip

645.2. 01/17/2020:
- Skip

646.2. 01/18/2020:
- Skip

647.2. 01/19/2020:
- Skip

648.2. 01/20/2020:
- Skip

649.2. 01/21/2020:
- Skip

650.2. 01/22/2020:
- Skip

651.2. 01/23/2020:
- Skip

652.2. 01/24/2020:
- Skip

653.2. 01/25/2020:
- Skip

654.2. 01/26/2020:
- Skip

655.2. 01/27/2020:
- Skip

656.2. 01/28/2020:
- Skip

657.2. 01/29/2020:
- Skip

658.2. 01/30/2020:
- Skip

658.2. 01/31/2020:
- Skip

659.2. 02/01/2020:
- Skip

660.2. 02/02/2020:
- Skip

661.2. 02/03/2020:
- Skip

662.2. 02/04/2020:
- Skip

663.2. 02/05/2020:
- Skip

664.2. 02/06/2020:
- Skip

665.2. 02/07/2020:
- Skip

666.2. 02/08/2020:
- Skip

667.2. 02/09/2020:
- Skip

668.2. 02/10/2020:
- Skip

669.2. 02/11/2020:
- Skip

670.2. 02/12/2020:
- Skip

671.2. 02/13/2020:
- Skip

672.2. 02/14/2020:
- Skip

673.2. 02/15/2020:
- Skip

674.2. 02/16/2020:
- Skip

675.2. 02/17/2020:
- Skip

676.2. 02/18/2020:
- Skip

677.2. 02/19/2020:
- Skip

678.2. 02/20/2020:
- Skip

679.2. 02/21/2020:
- Skip

680.2. 02/22/2020:
- Skip

681.2. 02/23/2020:
- Skip

682.2. 02/24/2020:
- Skip

683.2. 02/25/2020:
- Skip

684.2. 02/26/2020:
- Skip

685.2. 02/27/2020:
- Skip

686.2. 02/28/2020:
- Skip

687.2. 02/29/2020:
- Leap day!
- Skip

688.2. 03/01/2020:
- Skip

689.2. 03/02/2020:
- Skip

690.2. 03/03/2020:
- Skip

691.2. 03/04/2020:
- Skip

692.2. 03/05/2020:
- Skip

693.2. 03/06/2020:
- Skip

694.2. 03/07/2020:
- Skip

695.2. 03/08/2020:
- Skip

696.2. 03/09/2020:
- Skip

697.2. 03/10/2020:
- Skip

698.2. 03/11/2020:
- Suprise!
- I fixed one line of code.
- I was looking around and noticed that I had space-delimited key-value pairs, so I ensured ' ' was a value

699.2. 03/12/2020:
- Skip

700.2. 03/13/2020:
- Skip

701.2. 03/14/2020:
- Skip

702.2. 03/15/2020:
- Skip

703.2. 03/16/2020:
- Skip

704.2. 03/17/2020:
- Skip

705.2. 03/18/2020:
- Skip

706.2. 03/19/2020:
- Skip

707.2. 03/20/2020:
- Skip

708.2. 03/21/2020:
- Skip

709.2. 03/22/2020:
- Skip

710.2. 03/23/2020:
- Skip

711.2. 03/24/2020:
- Skip

712.2. 03/25/2020:
- Skip

713.2. 03/26/2020:
- Skip

714.2. 03/27/2020:
- Skip

715.2. 03/28/2020:
- Skip

716.2. 03/29/2020:
- Skip

717.2. 03/30/2020:
- Skip

718.2. 03/31/2020:
- Skip

719.2. 04/01/2020:
- Skip

720.2. 04/02/2020:
- Skip

721.2. 04/03/2020:
- Skip

722.2. 04/04/2020:
- Skip

723.2. 04/05/2020:
- Skip

724.2. 04/06/2020:
- Skip

725.2. 04/07/2020:
- Skip

726.2. 04/08/2020:
- Skip

727.2. 04/09/2020:
- Skip

728.2. 04/10/2020:
- Skip

729.2. 04/11/2020:
- Skip

730.2. 04/12/2020:
- Skip

731.2. 04/13/2020:
- Skip

732.2. 04/14/2020:
- Skip

733.2. 04/15/2020:
- Skip

734.2. 04/16/2020:
- Skip

735.2. 04/17/2020:
- Skip

736.2. 04/18/2020:
- Skip

737.2. 04/19/2020:
- Skip

738.2. 04/20/2020:
- Skip

739.2. 04/21/2020:
- Skip

740.2. 04/22/2020:
- Skip

741.2. 04/23/2020:
- Skip

742.2. 04/24/2020:
- Skip

743.2. 04/25/2020:
- Skip

744.2. 04/26/2020:
- Skip

745.2. 04/27/2020:
- Skip

746.2. 04/28/2020:
- Skip

747.2. 04/29/2020:
- Skip

748.2. 04/30/2020:
- Skip

749.2. 05/01/2020:
- Skip

750.2. 05/02/2020:
- Skip

751.2. 05/03/2020:
- Skip

752.2. 05/04/2020:
- Skip

753.2. 05/05/2020:
- Skip

754.2. 05/06/2020:
- Skip

755.2. 05/07/2020:
- Skip

756.2. 05/08/2020:
- Skip

757.2. 05/09/2020:
- Skip

758.2. 05/10/2020:
- Skip

759.2. 05/11/2020:
- Skip

760.2. 05/12/2020:
- Skip

761.2. 05/13/2020:
- Skip

762.2. 05/14/2020:
- Skip

763.2. 05/15/2020:
- Skip

764.2. 05/16/2020:
- Skip

765.2. 05/17/2020:
- Skip

766.2. 05/18/2020:
- Skip

767.2. 05/19/2020:
- Skip

768.2. 05/20/2020:
- Skip

769.2. 05/21/2020:
- Skip

770.2. 05/22/2020:
- Skip

771.2. 05/23/2020:
- Skip

772.2. 05/24/2020:
- Skip

773.2. 05/25/2020:
- Skip

774.2. 05/26/2020:
- Skip

775.2. 05/27/2020:
- Skip

776.2. 05/28/2020:
- Skip

777.2. 05/29/2020:
- Skip

778.2. 05/30/2020:
- Skip

779.2. 05/31/2020:
- Skip

780.2. 06/01/2020:
- Skip

781.2. 06/02/2020:
- Skip

782.2. 06/03/2020:
- Skip

783.2. 06/04/2020:
- Skip

784.2. 06/05/2020:
- Skip

785.2. 06/06/2020:
- Skip

786.2. 06/07/2020:
- Skip

787.2. 06/08/2020:
- Skip

788.2. 06/09/2020:
- Skip

789.2. 06/10/2020:
- Skip

790.2. 06/11/2020:
- Skip

791.2. 06/12/2020:
- Skip

792.2. 06/13/2020:
- Skip

793.2. 06/14/2020:
- Skip

794.2. 06/15/2020:
- Skip

795.2. 06/16/2020:
- Skip

796.2. 06/17/2020:
- Skip

797.2. 06/18/2020:
- Skip

798.2. 06/19/2020:
- Skip

799.2. 06/20/2020:
- Skip

800.2. 06/21/2020:
- Skip

801.2. 06/22/2020:
- Skip

802.2. 06/23/2020:
- Skip

803.2. 06/24/2020:
- Skip

804.2. 06/25/2020:
- Skip

805.2. 06/26/2020:
- Skip

806.2. 06/27/2020:
- Skip

807.2. 06/28/2020:
- Skip

808.2. 06/29/2020:
- Skip

809.2. 06/30/2020:
- Skip

810.2. 07/01/2020:
- Skip

811.2. 07/02/2020:
- Skip

812.2. 07/03/2020:
-What's this? Code? Oh my...
-Ok, not really any content, but something. So what is it?
-For some: a welcome change. For other: PC BS
-It's namely name and word changes that have been created, gained, been slandered, etc. by history. The easiest to cover: master.
-"It's the source, the original, the controlling item/device/service, etc." yea, and while there are many definitions of it, think about how we often use it in programming...
-In almost every usage (top of head: master list, master/slave) either come to reference the aftermentioned master/slave context or have been since redefined in the context of it
-It's easy to brush it aside because that's not what comes to mind when you say it, but here's the thing... that's privilege.
-Maybe someone reads this comment 20 years from now and goes "this was a waste of time" or "I still can't believe people thought this naming was something to defend"
-But right now, a vast majority of this industry is white. I am white. I have been able to do things that others could not or were steered away reom.
-A company of "yes men" usually sinks the company.
-A group of people who all think the same can create something amazing... and then it encounters the world at large and the Picasso was found to be a sheet of paper with some spilled wine on it
-Meanwhile, the greatest monuments society have ever created, from the extended historical background that led to it's creation and the decisions, rules, and mental mindset that led to it were never singular thoughts
-You need an outside view, some discomfort, variety, and diversity to make something that is not only goood, but great and will stand the test of time.
-Real talk for a moment: the world is on fire and the "this is fine" meme is very applicable.
-Those who get annoyed at this stuff: get over yourself.
-Every action has a reaction, and unlike physics, some reactions are not equal to the action taken.
-Society isn't a singular experience.
-You created "it", but what shaped you is the society you were raised in.
-The one I was raised in lacked variety and diversity.
-But that's not entierly true, my schooling had lots of variety (and a bit diversity).
-It's then that I realized the discomfort I had when everything was the same.
-When things were too clean, too basic, too organized, it was ripe for change.
-I dislike the status quo, people who always say yes to some boss of theirs all the time, people who are self-centered or narcissistic.
-Seeing that in the world today makes my blood boil.
-So when people complain about "seriously, changing master to main?" and these little terms? Guess what: there's a status quo that's ripe for change...
-As I read recently... "Replacing loaded words in codebases might not change much, but opposing those changes speaks volumes."
-Grow up, be a bigger person, put on your mask first before assisting others... but do help others, especially if they need it.
-We don't speak "old English" anymore, we've invented and redefined words just within the last 5 years, society changes.
-Black Lives Matter, be kind, wear your mask (for goodness sake...)
-It's time to make a stand and I can do it in 100 small ways (such as this) that make a big impact even if not seen that way by some.
-<mic drop>
-Oh, but really: wear a mask. It's not to prevent you from getting sick, it's to prevent you from getting others sick if you happen to be sick. Don't go out if you don't have to (drinks with friends aren't required)
-Peace and "do better"

813.2. 07/04/2020:
- Skip

814.2. 07/05/2020:
- Skip

815.2. 07/06/2020:
- Skip

816.2. 07/07/2020:
- Skip

817.2. 07/08/2020:
- Skip

818.2. 07/09/2020:
- Skip

819.2. 07/10/2020:
- Skip

820.2. 07/11/2020:
- Skip

821.2. 07/12/2020:
- Skip

822.2. 07/13/2020:
- Skip

823.2. 07/14/2020:
- Skip

824.2. 07/15/2020:
- Skip

825.2. 07/16/2020:
- Skip

826.2. 07/17/2020:
- Skip

827.2. 07/18/2020:
- Skip

828.2. 07/19/2020:
- Skip

829.2. 07/20/2020:
- Skip

830.2. 07/21/2020:
- Skip

831.2. 07/22/2020:
- Skip

832.2. 07/23/2020:
- Skip

833.2. 07/24/2020:
- Skip

834.2. 07/25/2020:
- Skip

835.2. 07/26/2020:
- Skip

836.2. 07/27/2020:
- Skip

837.2. 07/28/2020:
- Skip

838.2. 07/29/2020:
- Skip

839.2. 07/30/2020:
- Skip

840.2. 07/31/2020:
- Skip

841.2. 08/01/2020:
- Skip

842.2. 08/02/2020:
- Skip

843.2. 08/03/2020:
- Skip

844.2. 08/04/2020:
- Skip

845.2. 08/05/2020:
- Skip

846.2. 08/06/2020:
- Skip

847.2. 08/07/2020:
- Skip

848.2. 08/08/2020:
- Skip

849.2. 08/09/2020:
- Skip

850.2. 08/10/2020:
- Skip

851.2. 08/11/2020:
- Skip

852.2. 08/12/2020:
- Skip

853.2. 08/13/2020:
- Skip

854.2. 08/14/2020:
- Skip

855.2. 08/15/2020:
- Skip

856.2. 08/16/2020:
- What's this? Something?
- Ok, not much
- Basically, many of the projects I have an interest on contributing to are requiring VS2019...
- ...so I finally upgraded.
- I'm generally behind on VS versions.
- I found some IDE/compiler people to follow on Twitter and they always post the bugs/issues they run into when new VS versions come out
- ...but they never say when things look good
- So having multiple projects switching to it is probably a sign it's stable enough.
- To the point, I updated StethLib to .Net Standard 2.1 and the tests/Tracker to .Net Core 3.1.
- I also updated all dependencies except Stateless (to it's lates. I did update it a minor)
- Apparently Stateless made a breaking change, so I need to make sure my code will handle it properly/won't break before I go and upgrade it

857.2. 08/17/2020:
- More upgrades!
- Today's goal was C# 8 default interface implementation (tomorrow is hopefully going to be Stateless)
- So the benefit of "C# 8 default interface implementation" or default impl.:
-- You want to keep a minimal number of functions
-- You want to keep a minimal amount of boilerplate
-- Combine the two and you end up with a handful of functions that do exactly what they are expected to do and don't duplicate functionality
-- Bonus (issue): default arguments cannot be instance values (string a = "hello" <-- fine, IDictionary<string, int> a = new Dictionary... <- error)
-- Instead of needing to add additional functions, extension functions, or boilerplate, a default impl. can be added
- So I went to edit my two cases (ILogParser + BaseLogParser (which handled boilerplate), IPrinter + BasePriner) and everything seemed peachy...
- ...until the classes and tests that used them ran.
- So, I've yet to find the reason for it, but it seems like default impl. cause the methods/properties to be treated as explicit interface implementations (other's wording) of internal interfaces (my additional wording)
- Plan:
===
interface A
{
    void DoSomething();
    void Dance();
}

abstract class BaseA : A
{
    public virtual void DoSomething()
    {
        Dance(); // For now, we dance
    }

    public abstract void Dance();
}

class Bard : BaseA
{
    public override void DoSomething() // Note to self: not needed... remove when upgrading to default impl.
    {
        Sing();
    }

    public override void Dance()
    {
        Sing();
    }

    public void Sing()
    {
        //...
    }
}

class MusicTroupe
{
    public void DoSomething()
    {
        var bard = new Bard();
        bard.DoSomething();
    }

    public void EntertainPeople()
    {
        var bard = new Bard();
        bard.Dance();
    }
}

|||
 v

interface A
{
    public void DoSomething()
    {
         Dance(); // For now, we dance
    }
    void Dance();
}

class Bard : A
{
    public void Dance()
    {
        Sing();
    }

    public void Sing()
    {
        //...
    }
}

class MusicTroupe
{
    public void DoSomething()
    {
        var bard = new Bard();
        bard.DoSomething();
    }

    public void EntertainPeople()
    {
        var bard = new Bard();
        bard.Dance();
    }
}
===
- Reality (just the implementation part):
===
interface A
{
    public void DoSomething()
    {
         Dance(); // For now, we dance
    }
    void Dance();
}

class Bard : A
{
    public void Dance()
    {
        Sing();
    }

    public void Sing()
    {
        //...
    }
}

class MusicTroupe
{
    public void DoSomething()
    {
        var bard = new Bard();
        bard.DoSomething(); //ERROR: what's DoSomething?
    }

    public void DoSomethingv2()
    {
        A bard = new Bard(); // Note the cast
        bard.DoSomething();
    }

    public void EntertainPeople()
    {
        var bard = new Bard();
        bard.Dance();
    }
}
===
- It's as if "A" has "DoSomething" and "Dance"...
- ...but Bard went from having "DoSomething", "Dance", and "Sing" to "Dance" and "Sing" once "DoSomething" became a default impl.
- People online said "it's more like an explicit interface" but the only time I see that occur is when a method/property gets hidden.
-- Example: List<T>.GetEnumerator():IEnumerator<T> -> IEnumerable<T>.GetEnumerator():IEnumerator<T> -> IEnumerable.GetEnumerator():IEnumerator
-- IEnumerable.GetEnumerator is hidden in by IEnumerable<T>.GetEnumerator, so you have to explicitly implement the IEnumerable.GetEnumerator if you want it
-- ...and you have to do the cast to explicitly call it.
- But this is not hiding DoSomething
- This is not creating "A" and "AWithDefaultImpl"
- This is saying "A" has a default impl. and I would like a class that implements "A" to have said function.
- I'll need to see if I hear back from anyone about it (I poked someone on Twitter. If anything, I'd like to find the conversation on the logic behind this choice)
- Until then, instead of "just" touching the interface (and removing some override keywords), I had to touch implementation (including a whole lot of test functions...)

==Design/Plan Days==
- Observable/Qbservable summary: #220.2
- Initial stages of program completion (plan): #223.2
- Random Notes #1/Current(?): #223.2
- Some thoughts on log-print formatting: #230.2
==----------------==