I think our memories are rooted in time and space. "Which years did we go on our family holiday to Scotland? Can I see all my videos from when my kids were toddlers? Let's see that specific photo of sunset at the Grand Canyon, I think around 2021? What was the cafe we stopped at on our road trip? How did my flower garden change since I bought my house?"
(I put in a timeline (histogram) of photos, and keyword search, to serve these kinds of needs.)
My team has a large ocaml codebase and a dual build system (buck2 and dune). The two have roughly similar: dune faster at the raw speed of invoking ocaml build tools, buck2 winning out when a lot of stuff has to be rebuilt and it uses distributed build system.
The major pain point is LSP integration, which has to be closely tied to the build system, since it's only by building that the LSP server can know a file's dependencies. Everything is all neatly available with dune. We've cobbled something together a bit with buck2 but it's not as nice.
In my web-scraping I've gravitated towards the "cheerio" library for javascript.
I kind of don't want to use DOMParser because it's browser-only... my web-scrapers have to evolve every few years as the underlying web pages change, so I really want CI tests, so it's easiest to have something that works in node.
I presume it means things like "does cross-file go-to-def and find-all-references work instantly after opening a file?" In most IDEs these things take seconds or minutes to become available, depending on project size
That's a good example because it leads to truth that NO up-front tagging will ever anticipate all the searches you might make in future. There are so many possible searches.
I figure that a combination of wetware and software is the current sweet spot. My brain usually has enough associations and context to turn every photo search into a time or place filter - "I think it was downtown last year" or "some time in summer at home" or "it had my wife in it". The photo storage system need only provide search/filter on date and place to narrow it down to a few hundred thumbnails, plus machine-learning to tag people. Which is basically what iOS provides, no more, no less.
Any other up-front categorization or tagging is basically wasted effort.
For me, I wrote a bulk tool that renames my photo file names by reverse geocoding the GPS information via Open Street Maps. That way I can do text search for place, as well as 2d map search. It's at https://unto.me
I got into ultramarathon swimming because of that movie. I've since done numerous unaccompanied 12mile swims in nearby Lake Washington (Seattle), several accompanied sea crossings, and one 24mile swim. On every swim I think of Vincent and that phrase.
How it started -- I was swimming along the shore of the lake, figured that if I saved nothing for the journey back then the worst that could happen is I run out of energy and have to haul myself into someone's back yard and ask them for help. That wouldn't be too bad, so I might as well. It's amazing how much I can trick my brain+body into going further than it otherwise would.
What does it mean to open-source or MIT-license a "file format"?
The MIT license is a license about copyrighted software, allowing people to use/modify/publish that software. But a file format isn't a piece of software.
Are you open-sourcing the specification document for the file format? (people are still free to write software that reads+writes the file format even if the specification document isn't open-sourced).
Are you open-sourcing your particular library for reading the file format? (I'm confused here, because you stressed that the file format was so simple, so I'd have expected it easy and maybe even desirable for many people to come up with libraries for reading+writing the file foramt?)
Anyone is free to write software that modifies a file - there is no copyright law protecting that. This is one of the reasons why many large corporations are pushing hard towards cloud - they can protect the format AND the platform then monetize it at will. End users lose control.
I will give them points for putting it in a readable file format. But placing it under an MIT license and "open sourcing" it, doesn't do anything - and they know that. It's just fluff to market their new features.
Edit: Re-reading what I posted, In case it's taken the wrong way, I am not disparaging the team at Obsidian in any way:
I think they do good work and make great software.
IANAL
> The file itself is considered instead to be an idea or a system and is therefore not protected by the laws of copyright. So the description of a file format is copyrightable, but the format as it exists in its medium is not.
I wish I could edit my post to simply say open format for now. The MIT license currently refers to the spec and the documentation. Over time it will also include any tooling we open source (e.g. validator, linter, migration tools). The intention here is to work towards a shared format for this type of relational+spatial data, and we're hoping to collaborate with other members of the ecosystem to make something that can have interoperability and longevity.
I wrote https://github.com/ljw1004/seaoflogs - an interactive filtering tool, for similar ends to what's described here. I wrote it because my team was struggling to analyze LSP logs (that's the protocol used by VSCode to communicate with language servers). But I made it general-purpose able to analyze more log formats too - for instance, we want to correlate LSP logs with server logs and other traffic logs.
(1) I wanted something where colleagues could easily share links in workplace chat with each other, so we could cooperatively investigate bugs.
(2) For LSP we're often concerned with responsiveness, and I thought the best way to indicate times when viewing a log is with whitespace gaps between log messages in proportion to their time gap.
(3) For LSP we have lots of interleaved activity going on, and I wanted to have visual "threads" connecting related logs.
(4) As the post and lnav say, interactivity is everything. I tried to take it a step further with (1) javascript, (2) playground-style updates as you type, (3) autocomplete which "learns" what fields are available from structured logs.
My tool runs all in the browser. (I spent effort figuring out how people can distribute it safely and use it for their own confidential logs too). It's fast enough up to about 10k lines of logs.
Those numbers are easy to find on google! Iowa 14-18" average topsoil depth in 1900, 6-8" in 2000. I'm not sure anyone could tell acceleration/deceleration over this timescale.
(I put in a timeline (histogram) of photos, and keyword search, to serve these kinds of needs.)