tup VS logseq

Whenever looking at one these, I think back to the obscure but interesting "tup":

“How is it so awesome? In a typical build system, the dependency arrows go down. Although this is the way they would naturally go due to gravity, it is unfortunately also where the enemy's gate is. This makes it very inefficient and unfriendly. In tup, the arrows go up.”

https://gittup.org/tup/

Once upon a time, you could roll your own of this using `tup` which might have my favorite "how it works" in the readme:

How is it so awesome?

In a typical build system, the dependency arrows go down. Although this is the way they would naturally go due to gravity, it is unfortunately also where the enemy's gate is. This makes it very inefficient and unfriendly. In tup, the arrows go up. This is obviously true because it rhymes. See how the dependencies differ in make and tup:

[ Make vs. Tup ]

See the difference? The arrows go up. This makes it very fast.

https://gittup.org/tup/

Also has a whitepaper: https://gittup.org/tup/build_system_rules_and_algorithms.pdf

Ten years ago, I used reStructuredText and its support for LaTeX math and syntax highlighting. I used tup (tup monitor -a -f) to take care of running rst2html on save.

I might be showing my ignorance here, but this just sounds like Tup? https://gittup.org/tup/

I agree. While I like the idea of tup (https://gittup.org/tup/ -- the first "forward" build system I remember hearing of), writing a makefile is easy enough that thinking about the problem upside-down doesn't offer a compelling reason to switch.

Ptrace is one option for tracing dependencies, but it comes with a performance hit. A low-level alternative would be ftrace (https://lwn.net/Articles/608497/) or dtrace (https://en.wikipedia.org/wiki/DTrace).

Tup uses LD_PRELOAD (or equivalent) to intercept calls to C file i/o functions. On OSX it looks DYLD_INSERT_LIBRARIES would be the equivalent.

* order-only prerequisites - X must happen before Y if it's happening but a change in X doesn't trigger Y

This is just a small selection and there are missing things (like how to handle rules that affect multiple targets).

It's all horrible and complex because like a lot of languages there's a manual listing the features but not much in the way of motivations for how or why you'd use them so you have to find that out by painful experience.

It's also very difficult to address the warts and problems in (GNU) make because it's so critical to the build systems of so many packages that any breaking change could end up being a disaster for 1000s of packages used in your favorite linux distribution or even bits of Android and so on.

So it's in a very constrained situation BECAUSE of it's "popularity".

Make is also not a good way to logically describe your build/work - something like Meson would be better - where you can describe on the one hand what a "program" model was as a kind of class or interface and on the other an implementation of the many nasty operating system specific details of how to build an item of that class or type.

Make has so many complex possible ways of operating (sometimes not all needed) that it can be hard to think about.

The things that Make can do end up slowing it down as a parser such that for large builds the time to parse the makefile becomes significant.

Make uses a dependency tree - when builds get large one starts to want an Inverted Dependency Tree. i.e. instead of working out what the aim of the build is and therefore what subcomponents need to be checked for changes we start with what changed and that gives us a list of actions that have to be taken. This sidesteps parsing of a huge makefile with a lot of build information in it that is mostly not relevant at all to the things that have changed. TUP is the first tool I know about that used this approach and having been burned hard by make and ninja when it comes to parsing huge makefiles (ninja is better but still slow) I think TUP's answer is the best https://gittup.org/tup/

You might enjoy Tup[1] if you've not checked it out before.

[1]: https://gittup.org/tup/

Logseq support via our Logseq Plugin

Sorry, but _what exactly_ «it seems to do» from your point of view?

My «second brain» now is almost 300Mb of text, pictures, sound files, PDF and other stuff. As I already mentioned, it contains tables, mathematical formulae, sheet music, cross-references, code samples, UML diagrams and graphs in Graphviz format. It is versioned, indexed by local search engine, analyzed by AI assistant and shared between many computers and mobile devices. And (last but not least) it works: it allows me to solve my tasks way more faster than with the assistant of external, non-personalized tools (like ChatGPT, StackExchange or Google).

I know no tools for all this tasks except org-mode. Well, maybe Evernote in the 2010-s was something similar — but with less features, with more bugs and with worse interface.

Personal note-taking _is_ a complex task per se (well, at least for someone like typical HN visitor). I've seen many note-taking tools, that were ridiculously featureless, stupid and inconvenient because they were _not_ complex enough.

> Sure if one wants to do emacs-gardening it is fine.

1)You can use org-mode outside Emacs. See for example Logseq (https://logseq.com/), organice (https://organice.200ok.ch/) or EasyOrg.

2)Org-mode works in Emacs out of the box, you don't need any «emacs-gardening» to use org-mode.

3)The term «Emacs-gardening» itself sound a bit like hate-speech for me. The complexity of Emacs customization is overrated, mostly due to opinions of people who never used Emacs or used it in the previous millennium.

Obsidian is great.

For those looking for an open source alternative (or don't want to pay the Obsidian fees for professional usage) check out Logseq: https://logseq.com/

For an opensource alternative to Obsidian checkout Logseq (1). I spent a while thinking obsidian was opensource out of my own ignorance and was disappointed when I learned it was not.

1: https://logseq.com/

I use logseq to keep journal of my daily work.

While Emacs and Org mode can certainly be used for this (and, when they can't, you can always inject little python/js scripts in your emacs config to take care of specific things), I'd also recommend you take a look at Logseq.