• 0 Posts
  • 16 Comments
Joined 1 year ago
cake
Cake day: July 3rd, 2023

help-circle

  • Read through the Readme and it’s definitely a good tool to know about. It doesn’t fit the needs of my current problem, but I’m certain I’ll use it in the future for context sensitive searching, since grep/awk/sed/tr have definitely fallen flat for me in the past. I might also be able to study how they utilized tree-sitter CLI when I explore my own implementation.

    For my purposes, I want to take a group of similar-yet-different YAML file sets (though file type should be arbitrary), and feed them through a tool that will spit out a YAML template containing everything that is shared between multiple sets.

    Then, I want it to create a file for each YAML which defines which parts to pull from the template file and a list of variables to be inserted into holes in the templates. Basically creating a madlib that can recreate any file in the original group given the right list of variables to insert.

    For example, if I have a hundred YAML files that are mostly similar but contain different project names, have different server types provisioned, and are pulling different product versions, I would want this script to parse all hundred files and spit out a template that could be used as the basis to build any of the hundred files. The template would be combined with a hundred variable trees that would insert each unique part of each file into the right place.

    In effect, I could have a small variables file that gives only the unique portions of the equivalent YAML - in this case, it would contain only the project name, the server type, the product version. Then, these small files could be combined with the universal template to recreate the original hundred YAML files. But unlike using a simple override mechanism, I would be able to change elements of the template YAML including broad structural changes, and after some processing, the change would affect all one hundred output YAMLs.

    One could track things like environment variables that are specific to a certain project version and require that whenever a project version has a particular value to insert a particular environment variable into the output YAML. Or a centralized file could be made specifying which product versions correspond to which projects, allowing the engineer to change all product versions for a given set of projects in one go. Or one could create a universal template of IaC code that’s applicable to a broad swath of use cases and quickly build out a full set of YAML manifests and Terraform files using a small file that specifies what components will be needed and where to authenticate to the server.

    I’m not aware of any tool that does this, but I think tree-sitter gets me much of the way there. If I can use it to parse any given file into a context aware tree, I would then need to make a script that combines the shared features of many context trees and splits the unique features out into small variable files. Then a script to merge them back together as needed. And something to manage file system structure, such as whether to parse every file individually or to strategically merge some sets so you have one variable file that produces multiple output YAML.

    Sorry I’m brainstorming at you, just trying to figure out if the tool I’m envisioning is even feasible. Seems like it is, but I’ll have to figure out how to use tree-sitter CLI before I begin.


  • This is super cool. Watched the talks from Max Brunsfeld, surprised this has been around since 2018 and I haven’t heard of it.

    I actually tried some complex parsing myself lately. I had a bunch of YAML I needed to maintain for various deployments in a CI/CD system. I really wanted to have one YAML template to generate the files, plus a file for each project with unique elements to be injected into that project’s generated YAML.

    Probably was more of an indication that we needed to clean up the overrides we were putting on top of our Helm charts, but I wanted a way to generate our lengthy override files without having to manually keep track of where the differences were between projects. And maybe even stage changes to deployment files for when new product versions are released.

    This is exciting. I’m going to look into Tree Sitter more and maybe try to contact the dev. It seems like it does everything I’m looking for, just for an entirely different use case.





  • A lot of people describe the first moment of the big bang as infinitely small, dense, and hot. These descriptions may approximate that first moment of existence, but they slightly miss the mark because in the very first moment of existence, size, density, and temperature didn’t exist. There was nothing to compare anything else against.

    Instead, let’s visualize that moment as infinitely same. Erase all thoughts of violent explosions happening very quickly and instead just imagine a single point of light. Not big, because size requires multiple things. Not small because it encompasses everything. Just one infinite same.

    Now, since it’s hard for us to visualize change in an infinite void that is simultaneously nothing and everything, imagine that point of light as a magical tank engine at the front of a never-ending train. And our job as conductors of that train is to get to the caboose at the end.

    The train cars could theoretically go in any order, but because we conductors are beings of time who need them to arrive on a schedule, we must visit each car in a precise order. And before we can access a car, we must make it unique by showing it something that has never been seen before.

    For the first car, this is easy. We simply show it the tank engine at the front of the train. So, the inside of the first car transforms its interior into a copy of the tank engine it’s attached to.

    But when we arrive at the second car, things are more complicated. The cars have already seen the tank engine. So, instead, we show the second car the first car. And the second car transforms into a copy of the first car and the tank engine attached to that. And inside the copy of the first car is another copy of the tank engine.

    As you can imagine, the further down we get on this train, the more this starts to get out of hand. Copies of copies of copies abound. The magic train is powerful, but as mortal conductors of time, we worry our own powers may have limits. So, to reduce the burden on ourselves, we take some shortcuts. Instead of trying to visualize increasingly long nested copies of trains inside each new car we visit, we start to conceptualize these copies as amounts, or amplitudes. When we open the door to a new car, all of the amplitudes inside resonate and interact, becoming maybe more abstract than they are in reality. They form spatial dimensions and physical properties, as mediated by fundamental forces.

    These aren’t set in stone, but determined by the lens through which we view them. And when we look through specific lenses, we see these forces causing certain repeated amplitudes to intermingle and stabilize to the point that even though all of the train copies are further nested when we step into the next car, we can recognize and identify some of the same structures, just shifted slightly in their spatial relationships since we last witnessed them in the previous car. We call these persistent formations matter. And as their shared spatial relationships cause them to cluster and coalesce, we refer to that as gravity.

    While in the early cars, this continuum of space and matter is not impossible to conceptualize, the more cars we travel through, the more apparent it becomes that these increasingly complex objects are becoming more and more isolated from each other. At every scale of amplitude, each nested car is attached to its own tank engine. While these engines can interact with each other virtually, at the end of the day, they are all just virtual copies of the train we are on. It is entirely impossible for any one of these tank engines to travel so far that it reaches the edge of its bounding box. Because that bounding box is just a lens through which we imagine overlapping traits of increasingly many very similar objects. And the more of them we imagine, the more space is required to provide the virtual framework of this lens.

    So, when we feel like we are experiencing random events in our small subsection of the universe, those events are not truly random, but instead the result of our precise position in the the universal train we’ve been virtually sliding through for over 13 billion years. The universe has become so large that it contains every possible event that could have happened in this span of time. The events are not random but calculated, and duplicated every moment so that every time we enter a new train car, two copies of our observable universe exist at a distance so far apart it’s impossible to comprehend.

    And when we observe celestial objects apparently propelled away from each other at increasing speed, they are not really being pushed or pulled anywhere. It is simply an artifact of trying to keep track of the “same” object in rapidly advancing train cars, while each car doubles in size to contain everything the previous car had, as well as everything new that might emerge from the duplication event. The celestial objects year by year, and indeed ourselves from moment to moment, are never the same thing twice. It’s an illusion brought forth by our brains being born into a cosmic flipbook.

    Even something as simple as seeing multicolored pixels on this screen is not real, but the result of virtual “tank engines” moving into the same spatial zones occupied by our retinas, which are themselves constructed of virtual trains of varying size. The reason photons move at a set maximum speed which makes them exempt from experiencing time is because they are all just virtual copies of the real locomotive which is driving the whole train. Every photon in our universe is just a make-believe copy of the very first moment of the big bang. A specter of infinite sameness.

    So, objects in our universe aren’t moving apart as much as the space between them is increasing to account for the overhead of a universe with constantly growing entropy and uniqueness. The extra space represents a boundary which limits how far light can travel and affect matter in its realm of influence. If you’re still reading this, somewhere out there, in a part of our universe so far away that light from our known universe will never even remotely reach, there is an opposite you made of antimatter reading the exact same thing as written by an opposite me. But we are only made of matter because of a virtual compression of sameness, so that antiverse may be the exact place where the curvature of the entire universe loops back around and is overlaid upon itself. And the uncertainty of photons may arise from the fact that there are two identical universes overlapped and constantly exchanging probabilities. And this may be the compressive property which allows the fundamental forces to exist in the first place. So, say hi to yourself. You’re the reason you’re here.