It's amazing how well tmux works as a project setup tool.
[1]: https://gavinhoward.com/2020/12/my-development-environment-a...
You have a point there; I didn't because everything I've seen is that people like the results of Bazel, but they hate writing rules, so Bazel rules seemed like something to not emulate.
But point taken.
And thank you for the explanation. It seems providers allow for multiple outputs on a target. My build system allows that, but bundling such outputs together is a good idea that I need to add.
That said, can you explain providers to me? I looked up the docs, and I'm no closer to understanding them.
I want to understand them and their uses do that my build system can have the same capabilities.
My build system will actually have a command-line option to reverse the dependency resolution. Instead of building a given target, updating its dependencies as necessary, it will build the default target(s), marking the files given on the command-line as "changed" and resolving dependents up to the default target(s).
This will mean that building the "current file" will be a simple command-line switch that can be part of the file generated for that IDE.
But yes, I'm going to put in a lot of work to make IDE's work as smoothly as possible.
Funny you should mention Bazel and Buck; I'm coming for them too! I'm also coming for Nix; I want its advantages to be easily accessible for mere mortals.
I think I can do better alone than those teams have because they have all made assumptions that weren't great. I'm learning from their mistakes.
Also, UX matters, and I'm putting a lot of effort into that.
But the other reason is that if you do Nix right, the capabilities of Bazel and Buck just appear.
Thank you for the encouragement!
I've already addressed some of this in another comment ([1]), but you bring up more points, so I'll address it here.
CMake's model forces it to generate build files for other build systems. The better model does not force the build system to, but it also does not preclude doing so.
Separately from actually running a build (and that's important), my build system will be capable of generating files for VS, XCode, and other IDE's, but the files it generates will simply tell the IDE's how to integrate with my build system by telling them how to call it with the correct build profile. And yes, it will generate multiple possible build profiles, allowing VS users to select the solution the want to build from within VS.
But this means that my build system will not only integrate better with IDE's than CMake, it will still retain full control of actual builds.
This includes using debuggers and analysis tools, by the way. I wouldn't consider my work done on IDE integration until all of that is as easy as possible, and definitely as easy as CMake.
> Isn't that exactly what an INTERFACE library is for?
Maybe? It might be enough. At first glance (and I fully acknowledge that I could be wrong here), it seems like CMake expects the "target" to be a library of some sort. That's not the sort of thing I would personally want.
I would want to be able to depend on any target for any target.
But again, I could be wrong. I've never been able to understand the CMake docs.
Here's how my build system will do it: the programmer will list default build profiles. Then the build system will generate Visual Studio or XCode files that include all of those default build profiles, but those VS or XCode files will simply call my build system with the correct build profile.
Thus, when a build is run from VS or XCode, my build system is still in full control.
In essence, instead of generating build files for use by other build systems, my build system will generate files to tell VS and XCode how to call my build system. It will tell VS and XCode how to integrate it.
I'm not impressed, for two reasons:
* Backwards compatibility for the CMake language is not desirable. It would be better to allow files to be translated to the new language completely. Sure, CMake could support having files in the old language and files in the new language, but the CMake language is so bad that a break from it is the best path forward.
* The CMake language is not the only drawback to CMake, unlike the claims in the presentation. CMake's model is hamstrung as well, in several ways.
Here are some ways in which the CMake model is hamstrung:
* Generating a build file for another build system. This means that CMake always gives up control of the build. It can only tell the other build system the dependency graph and then sit back and watch. It can't regulate the build itself.
* No dynamic dependencies. If you need dynamic dependencies, you need to call into CMake to generate a new and separate build file for the second build system and then call that. And because the two build files that CMake generated don't know anything about each other, it's hard to regulate the use of computing resources between them; you either have to complete the one and start the other, or you risk over-extending on your computing resources.
* No way to generate a target that doesn't call an outside process. More generally, the only way to generate a target (unless my CMake knowledge is old) is to have the second build system create a child process. This is strictly less powerful than having the same scripting language available during configure also available in targets. For example, LaTeX is only properly built with a loop that checks for a fixed point. If you can't loop in your target, you have to use an outside bash script or something of the sort to make up for it.
* No way to have targets that do not generate files and have other targets depend on those targets. If a target does not generate a file, CMake does not know how to make other targets depend on it (unless my CMake knowledge is old).
* The model of "configure in Turing complete language and then build" also means that configuring often has to happen more than once before a build. You see this if you use `ccmake`: you configure, and new options appear. You set the options and configure again. More options might appear. Using plain `cmake` hides this by using defaults, but that just means the user might end up with a build they didn't want because they didn't get a chance to set all of the options they might care about.
Anyway, rant over.
I'm currently working on a second implementation, mostly because I want my docs to be dependency-free, but also for standardization of djot.
> On topic, though, preceding sublists with empty lines is a complete non-starter for me.
I get it. This is my biggest complaint too. But I'm also a parser writer, and I see how this removes so much ambiguity.
This is the one thing that will stop djot adoption, and I'm okay with that. I don't think djot will be as used as Markdown, and I'm okay with that.
Personally, I care about the edge cases. I also don't care about multiple parsers because I want to write my own. (I currently depend on Sphinx, Breathe, and MyST, which are heavy dependencies.) And I don't store my code on GitHub because of Copilot and because of [1].
I decided to go all-in on djot for several reasons:
* I can write my own parser.
* djot can target any format, which means I can use the same docs to generate manpages, a docs website like [2], and perhaps PDF's if my docs include something like the Rust Book.
* djot's extension story [3] is the best of any format, and I need extensions that don't exist in any format for things like EBNF in a specification.
That said, I think you are correct that this will not take off as much as CommonMark has. I guess I was just sharing that I don't care and why.
[1]: https://gavinhoward.com/2020/04/i-am-moving-away-from-github...
No, not really. I was answering certain accusations with my opposing opinions.
Unfortunately, I can't understand where a person is coming from if I don't understand their definitions of certain terms, and I can't understand your definitions of flamewar and flamebait.
> If you get into back-and-forths with an opposing user around that kind of thing, you're perpetuating flamewar. This is clearly not curious conversation.
I guess I misunderstand the purpose of HN because this line of yours makes it seem (to me) like I cannot debate political things at all, or rather, certain topics (does "around that kind of thing" means political things?), but that doesn't seem right either.
> However, there are many ways to lower the expected value of a thread, and flamebait/flamewar is just one of them.
That's why I think putting the lowering of the expected value of a thread into the guidelines is the right choice: it covers more situations.
> I think it's important to be specific.
I have shut off the discussion you didn't like, but it would be helpful to me if you were more specific about what you see as flamebait and flamewar. If I understand what you want me to not do, I'll avoid it, but I can't avoid something I'm unclear on. I also don't like self-censoring more than necessary (that is what the posted article was about, after all).
However, I expect that you're busy and won't be able to answer me, so extra self-censoring might be what I have to do. It makes me sad, though; I felt like HN was one place where I didn't have to do that, and now, it does not.
Edit: one thing that I could consider is trying to not answer every accusation that I'm a terrible person. Ten years ago, my Christian faith would not be attacked so openly. Now, people consider me a terrible person for believing those same things, and I find myself defending my faith a lot, albeit indirectly.
I will try to do that less on HN at least. Would that be what you are doing of me?
Edit: also, I have read your comment from a long time ago about the expected value of a discussion. Perhaps that is the definition you personally use? As in, you consider any comment to be "perpetuating flamewars" once it is made in a discussion with a lower expected value than you want to accept.
I can't argue with that definition; in fact, I would accept it wholeheartedly, but (and this is just a suggestion) it might be better to make that the site guidelines, as well as to adjust your wording when you tell people to knock it off as you just did.
For example, if you came to me and said, "The expected value of this discussion is lower than the value that this site can accept, so please stop this discussion here," I think I personally would take it much better than being accused of perpetuating flamewars. And I would be more likely to obey.
You can still ban people for not obeying such requests too. I think you should.
Anyway, I hope this comment was helpful.
The community you love has done damage to the society you depend on. I have no viciousness towards any one of them except where they insist on remaking society in their image to the detriment of all others.
Ignorance through force of law would apply if the history were factual. But it's not. Preventing bad ideas from being taught is the opposite of codifying ignorance.
Again, it's entirely about their course of employment.
Also, "wokeists" have caused so much damage to this country. I don't mind fighting back.
And yes, people other than history faculty do know how to teach history better than history faculty. I don't trust academics.
And like many others, I can also look like I'm experiencing other emotions because I am. But I have a resting angry face, and it gets more extreme the more deeply I am thinking.
My wife works in a company with programmers, and they keep their webcams off during virtual meetings because, "We don't want people to see our thinking faces." Yes, that is an exact quote.
I could probably change it to use io_uring and kqueue on those platforms, but I wanted to make a POSIX-compatible version first.
I've been using HN for a while and asked to be one of those with the "unread" marker (an orange vertical line to the left of unread posts).It stopped appearing today, or maybe yesterday.Where did it go? Did I miss some sort of announcement?
A lot of what you said lines up nicely with what the other commenter said.
I'll start practicing what you suggested. I do weekly bookkeeping for my family's finances, and I wrote a script to check it for inconsistencies. However, I'll also use it as a way to learn more deeply about the balance sheet, P&L, Cash Flow, and their links.
Thank you.
There are four big reasons why:
* Atomics. These are the biggest missing feature in older C.
* Static asserts. I can't tell you how much I love being able to put in a static assert to ensure that my code doesn't compile if I forget to update things. For example, I'll often have static constant arrays tied to the values in an enum. If I update the enum, I want my code to refuse to compile until I update the array. I have 20 instances of static asserts in my current project.
* `max_align_t`. It's super useful to have a type that has the maximum alignment possible on the architecture.
* `alignof()` and friends. It's super useful to get the alignment of various types. Combined with `max_align_t`, it is actually possible to safely write allocators in C. Previously, it wasn't really possible to do safely or portably. And I have at least three allocators in my current project.
You're right that C11 doesn't have nearly the reach the ANSI C does, but it does have slightly more than Rust, much more if you consider Rust's tier 3 support to be iffy, which I do.
And it does have one HUGE advantage against Rust: compile times. On my 16-core machine, I can do a full rebuild in 2.5 seconds. If I changed one file in Rust, it might take that long just to compile that one file.
That's not to say Rust is without advantages; one of my allocators is designed to give me as much of Rust's borrow checker as possible, on top of API's designed around that fact.
tl;dr: I use modern C for a few features not found in C89, for the slightly better platform support against Rust, and for the fast compiles.
It makes more sense that I would just give an accountant my G/L (General Ledger?), and it makes sense that gross sales matter most.
It also makes sense that more input is good past a certain threshold. I'll definitely go with a firm at that point, but I admit that I don't want accountants to save me money on taxes; I want to have bulletproof accounting so that the IRS doesn't audit me or finds absolutely nothing to worry about if they do.
Thank you for the two links. I had found the first, and the second only confirmed what I thought. I think any misconceptions I have from here can be correct by an actual accountant.
I actually check my trial balance every week. (I didn't know that's what I was doing, but that's what I do.) Other than that, I'll try to leave it up to my accountant. (I can be a control freak.)
I definitely would have made the mistake of changing accounts in the middle of a year, thank you.
If banks consider old A/R's unrecoverable, that means they generally are, and that means I should not allow customers to get lax on paying them. That's a great tip, thank you.
And thank you for the encouragement and help!