If we consider that the universe is a computer simulation, then random numbers are in fact pseudo-random, the results of a deterministic process. Nothing in the Universe is truly random. Have you heard of stories of incredible coincidences that should statistically be less common than they appear in real life? This is because random numbers are usually not along the normal distribution. The distribution of random numbers can be changed via prayer and manifestation to concentrate around a specific value. Terry Davis understood this, which was his quote, "God controls random numbers". And it's true, out of chaos becomes order. So we can use chaos theory to communicate with God. Just like the ancient Chinese meditated on a question, they heated bones over a fire and cracked them, the cracks resembled Chinese characters that they would then read as the answer to that question. Or various shamanic techniques such as divination on beans, and flipping coins. Just like TV/radio is static (random) until a signal comes in and changes the image, so the presence of a thought or a question changes the random number distribution into a deterministic value. So Terry Davis created a divination computer program, that generated random numbers in response to a question, and used these random numbers as an index into a lookup table containing quotes from the Bible. The computer prompts the user to enter a question, that string is then hashed into a number which is then used as the seed for the RNG. Then a sequence of random numbers are generated, which are then mapped into a sequence of strings containing quotes from the Bible. The result is a cryptic message, from God allegedly. I've written a similar program in C++. The key is to make the lookup table for the results very large, for me it's 11,000 different strings that can be chosen from. This is to keep the modulo from looping on itself, and to give it a variety. And it actually works and produces consistent answers to my questions! It doesn't work all the time, but it works much more often than conventional statistics would assume. Perhaps every 1 out of 7 times it gives me a relevant answer to the question that I posed. To improve the results the lookup table should be as long as possible, and as varied as possible, encompassing a wide variety of answers to possible questions, such as personal development, studying, encouragement, relationships, discipline, health, and lifestyle questions.
I love how Andrew Kelley (the lead of Zig) went with the same approach as you did with nob. Why have another tool (and language in case of cmake) if you already have one that can do that.
many languages did it to some degree (most famous is Kotlin&Gradle). you don't want to invent a domain-specific language, when you can just write a library for an existing language.
@TsodingDaily I don't know if it was answered, but you can compare pointers to static strings in the preprocessor because static strings are stored in the hash table. If you have two similar strings, they point to the same memory address. I'm not sure if it is a part of the standard tho; it could be a compiler-specific thing. If we use another, less popular compiler that stores strings in a different way, it will have different addresses. But works for me with clang :) Example: const char* str1 = "hello"; const char* str2 = YOUR_STRING_IN_PREP; #if str1 == str2 printf("Yes! "); #else printf("No!"); #endif
Another amazing stream with loads of ideas which will help with my own build system. I'm kicking myself for not thinking about this multi-stage bootstrap concept (eventually I fell into the "CMake" trap and now I need yet another refactoring).
It feels bad to have so much conditional compilation. Better to have multiple different build_musializer functions like build_musializer_linux() and build_musializer_macos() and so on, then choose which to call using #if. That way the compiler could always check for errors in the build script regardless of the chosen target, and we could keep the #endif on the screen as the #if.
Even beyond that, it'd be easier to create a generic platform file that had a struct with function pointers, and then a file for each platform that each included the platform layer and assigned the function pointers to that platform. This would make it a lot easier to: 1. develop at first because you'd only need to support your own platform, and thus don't need to constantly refactor code for other platforms 2. implement a new platform because it just needs a new platform file that basically does the same things as the other platform APIs do (which isn't clustered all around) 3. be sure that all cases are always covered
Just a note: I do not find it highly important to optimize making it easy to implement platforms because most times I solely support between 1 and 3 platforms (Windows/Linux/Mac). So if this structure pushes to make that easier at _enough_ opportunity cost, it's not entirely useful to me. @@Muskar2
@@Muskar2 structs with function pointers seem like an overkill. it may please some FP people, but why not just switch between platform-dependent steps in the main function, at runtime? the idea that you can first define an interface and then just implement it is a tempting one, but often leads to disasters. the approach where you have step1_win, step1_posix, step2_win, step2_posix functions and if-elses in main isn't a spectacular one, but you can eyeball it and it just works.
@@Daniel_Zhu_a6f Sure it may be overkill if you're just making something small. But it's scalable, if you need it to be. Switching between platform-dependent steps in the main function at runtime tends to become verbose and hard to keep track of, in my experience. But I agree that inlining is preferred over abstraction levels, until they become necessary. I'm not sure what disasters you're referring to in this specific case though. Creating an interface boundary between the functions that will run on every platform versus the things that need to happen uniquely on individual platforms is logical, because it's a certainty that the distinction will be necessary. Making it as easy as possible to handle platform-specific bugs or implementations is something I think makes it a lot simpler to work with. But if you're making a 10k LOC library, then it probably wont be a noticeable benefit, sure.
Only just started the video.. Musializer is one of the few projects you've done that I have learned about since discovering your channel that I have not played around with. Mainly because I don't tend to have music or anything downloaded on my PC. Now I think I'm gonna check it out and maybe rip a few mp3s off TH-cam to play around with it. 😂 Very interested in the build system. I've honestly learned an absolute ton from your videos so I'm always happy to check out a Tzozin project! 😀 Maybe some day I can even contribute but you mostly write in languages I don't know well just yet lol.
Also, in case anyone needed another reason to hate C, both gcc and msvc allow a form of main that takes the environment variables as an array of strings, int main ( int ac, char **av, char **env ), so give that a try.
That’s not a compiler extension; it’s an operating system thing. Linux and the BSDs accept a third argument but it’s optional. I’m not sure why that’s a reason to hate C? Just don’t use it, nobody does.
@@thebatchicle3429 I assumed anyone reading this would've seen my prior post and gotten that I meant "hate" sarcastically, and it was kind of a nudge towards what Tsoding said about C. However, I never referred to the environment variables argument as being a compiler extension, and it's technically a conforming implementation to provide access to the environment, even if the standard doesn't specify it be in a third argument. It could just as easily be provided in argv past argc, or even tacked onto the command line arguments with no boundary between the two, or with an empty string, as it's up to the implementation how to provide that as long as argv[argc] == NULL.
1:08:40 - out of my experience, this might be a problem. It is quite easy to leave some platforms go "stale"; or assume something just works but it explodes because the platform's compiler/libc/etc has weird compilation quirks.
C never gets outdated == Build system never gets outdated. Though, they wanna delete K&R style for functions declaration, like this ``` int foo(a, b, c) cont char *a; int b; void *c; { ... } ``` which is literally how documentation for Xlib is done. But I think you already showed that in one of the streams.
@@thebatchicle3429 foken zoomers from the committee. Why they just can't get the simplest point that k&r times were times of non-highlighted syntax? I mean yeah, I'm not using that style for the obvious comfort reason, but why to exclude it..
That whole bit in the beginning with CMake. Is exactly why I never bothered to learn CMake or build tools in general. I'd rather be a caveman basically handing a note that says type this stuff in your compiler of choice to use this shit.
i didnt know cmake exists before i found myself moving away from the arduino ide to esp-idf couple of months ago. their build system is wrapped and interlocked with cmake up to a point where i didnt see myself having a chance at all to derive a "build.sh"-type notes-file that would allow me to stay in my cave. I went for the fumble-around-till-it-works approach and never looked back up till today. So definitly no divine intellect badge for me. ¯\_(ツ)_/¯
tis highly adviced to read cursed tomes of eldrich knowledge to build a tolerance to finally read javaScript documentation lest one risks high chance of hysteria, insanity and / or severe brain damage.
My venture into C unfolds like this: I'm set on crafting my own C library. Naturally, I'll include my string functions, but they must reside in heap memory. Yet, this entails the need for subsequent deallocation. Thus, I'm inclined to construct my own malloc. The catch is, I aspire to implement a form of "garbage collection," envisaging a struct (not an object) capable of allocating to a linked list, complete with IDs. This approach would facilitate the liberation of memory in cohesive groups, perpetually and so forth. Perhaps opting for C++ might offer a more straightforward solution... I firmly believe that in C, writing elongated functions that focus on accomplishing a singular task exceptionally well is the key, as that's the essence of what I recall from my days with C.
Shouldnt there be a dependency tracking for generating config.h, i.e. if you modify nob.c to add a new config, config. H should be regenerated automatically without the need to manually delete config.h? Btw this example also shows that one should use cmake because a dedicated build system is the only guarantee that building is performed correctly and is complete..
I was left thinking what if I like interpreted config style: no need to recompile at all config file... seems at @21:37 until this point relistened this is not taken into account, eg can ship binary and config is separate file. To clarify "each developer has their own config.h" -> this means need to always recompile even in this better approach if I understood correctly. So what if can know binary is compatible but need to modify config only in client machine(eg one developer local machine whose folders and settings are a bit different, otherwise program works exact same).
I never understand this trend of hating programming languages, especially when large part of your code is written in that language. Like we don't have enough hate in this world... It is sad to see at 1:43:40 how you are twisting on the chair because it's hard to say something good about C(or any language) it's always more cool to just hate on something...
Tsoding is very close to the suckless way of programing. Many suckless programs has a file called config.def.h and after you build the program for the first time you have config.h wich you can customize.
Tsoding already done Neural Networks, which is quite OP. So I am in the wait of when he maybe tries less op machine learning techniques like Reinforcement Learning and Genetic Algorithms.
Why not build raylib in it's own stage? Stage 1: generate `config.h` Stage 2: build raylib (and possibly other deps) Stage 3: build app. Or is that too much like make?
Tsoding is wrong on the internet and let me tell you why: I'm a fan of letting the compiler do all your parsimg building a config.h header, but moving so that the build code only builds on the platform you're building on is hairy because as Mr. Tsoding demonstrated he's got a bunch of compile errors on windows and crapple, that can't be tested on Linux. Generally I try to move my preprocessor statements into the language ASAP so that it becomes normal code.
Terry Davis reference in the title, I'm really looking forward to this one
For archival purposes: the title was "Is this voodoo magic or divine intellect?"
He has left us. It is now "Better Way to Build C"
If we consider that the universe is a computer simulation, then random numbers are in fact pseudo-random, the results of a deterministic process. Nothing in the Universe is truly random. Have you heard of stories of incredible coincidences that should statistically be less common than they appear in real life? This is because random numbers are usually not along the normal distribution. The distribution of random numbers can be changed via prayer and manifestation to concentrate around a specific value. Terry Davis understood this, which was his quote, "God controls random numbers". And it's true, out of chaos becomes order. So we can use chaos theory to communicate with God. Just like the ancient Chinese meditated on a question, they heated bones over a fire and cracked them, the cracks resembled Chinese characters that they would then read as the answer to that question. Or various shamanic techniques such as divination on beans, and flipping coins. Just like TV/radio is static (random) until a signal comes in and changes the image, so the presence of a thought or a question changes the random number distribution into a deterministic value. So Terry Davis created a divination computer program, that generated random numbers in response to a question, and used these random numbers as an index into a lookup table containing quotes from the Bible. The computer prompts the user to enter a question, that string is then hashed into a number which is then used as the seed for the RNG. Then a sequence of random numbers are generated, which are then mapped into a sequence of strings containing quotes from the Bible. The result is a cryptic message, from God allegedly. I've written a similar program in C++. The key is to make the lookup table for the results very large, for me it's 11,000 different strings that can be chosen from. This is to keep the modulo from looping on itself, and to give it a variety. And it actually works and produces consistent answers to my questions! It doesn't work all the time, but it works much more often than conventional statistics would assume. Perhaps every 1 out of 7 times it gives me a relevant answer to the question that I posed. To improve the results the lookup table should be as long as possible, and as varied as possible, encompassing a wide variety of answers to possible questions, such as personal development, studying, encouragement, relationships, discipline, health, and lifestyle questions.
I love how Andrew Kelley (the lead of Zig) went with the same approach as you did with nob. Why have another tool (and language in case of cmake) if you already have one that can do that.
Odin also goes for same approach but something like this existed for over a decade now. Check out tup build system.
many languages did it to some degree (most famous is Kotlin&Gradle). you don't want to invent a domain-specific language, when you can just write a library for an existing language.
And I love how Tsoding hated it when he tried zig.
Indeed the hardest question in programming.
Hardest nob you say?
What question?
@@henrikholst7490 it is a reference to the previous title of this video: is it too much voodoo magic or is it divine intellect?
@@talhaakram I remember the quote differently
didn't know programming could be this exciting
"a nightly mode, for using application at night" xD 7:43
casually roasting crustaceans
@TsodingDaily I don't know if it was answered, but you can compare pointers to static strings in the preprocessor because static strings are stored in the hash table. If you have two similar strings, they point to the same memory address. I'm not sure if it is a part of the standard tho; it could be a compiler-specific thing. If we use another, less popular compiler that stores strings in a different way, it will have different addresses. But works for me with clang :)
Example:
const char* str1 = "hello";
const char* str2 = YOUR_STRING_IN_PREP;
#if str1 == str2
printf("Yes!
");
#else
printf("No!");
#endif
Thanks for sharing
"Nightly mode for using the application at night" 😂
I learn so much from you & your videos. Thank you making me a slightly better programmer.
This dude is hilarious why am I just finding these videos?
Another amazing stream with loads of ideas which will help with my own build system. I'm kicking myself for not thinking about this multi-stage bootstrap concept (eventually I fell into the "CMake" trap and now I need yet another refactoring).
you ask the right questions when developing. sadly missing in much of the development world
Really like where you are going with nob.
52:47 finally something I could actually recreate in my own project!
23:13 - "We will be working with sisters" monkaS
It feels bad to have so much conditional compilation. Better to have multiple different build_musializer functions like build_musializer_linux() and build_musializer_macos() and so on, then choose which to call using #if. That way the compiler could always check for errors in the build script regardless of the chosen target, and we could keep the #endif on the screen as the #if.
Even beyond that, it'd be easier to create a generic platform file that had a struct with function pointers, and then a file for each platform that each included the platform layer and assigned the function pointers to that platform. This would make it a lot easier to:
1. develop at first because you'd only need to support your own platform, and thus don't need to constantly refactor code for other platforms
2. implement a new platform because it just needs a new platform file that basically does the same things as the other platform APIs do (which isn't clustered all around)
3. be sure that all cases are always covered
Just a note: I do not find it highly important to optimize making it easy to implement platforms because most times I solely support between 1 and 3 platforms (Windows/Linux/Mac). So if this structure pushes to make that easier at _enough_ opportunity cost, it's not entirely useful to me. @@Muskar2
@@Muskar2 structs with function pointers seem like an overkill. it may please some FP people, but why not just switch between platform-dependent steps in the main function, at runtime? the idea that you can first define an interface and then just implement it is a tempting one, but often leads to disasters. the approach where you have step1_win, step1_posix, step2_win, step2_posix functions and if-elses in main isn't a spectacular one, but you can eyeball it and it just works.
@@Daniel_Zhu_a6f Sure it may be overkill if you're just making something small. But it's scalable, if you need it to be. Switching between platform-dependent steps in the main function at runtime tends to become verbose and hard to keep track of, in my experience. But I agree that inlining is preferred over abstraction levels, until they become necessary.
I'm not sure what disasters you're referring to in this specific case though. Creating an interface boundary between the functions that will run on every platform versus the things that need to happen uniquely on individual platforms is logical, because it's a certainty that the distinction will be necessary. Making it as easy as possible to handle platform-specific bugs or implementations is something I think makes it a lot simpler to work with. But if you're making a 10k LOC library, then it probably wont be a noticeable benefit, sure.
Thanks for the friendly and educative content. I wonder if there is something similar on TH-cam/Twitch but Java dedicated. Suggestions are apreciated!
Deep shit. Thx for the stream. Great pleasure.
Only just started the video.. Musializer is one of the few projects you've done that I have learned about since discovering your channel that I have not played around with. Mainly because I don't tend to have music or anything downloaded on my PC. Now I think I'm gonna check it out and maybe rip a few mp3s off TH-cam to play around with it. 😂 Very interested in the build system. I've honestly learned an absolute ton from your videos so I'm always happy to check out a Tzozin project! 😀 Maybe some day I can even contribute but you mostly write in languages I don't know well just yet lol.
Also, in case anyone needed another reason to hate C, both gcc and msvc allow a form of main that takes the environment variables as an array of strings, int main ( int ac, char **av, char **env ), so give that a try.
That’s not a compiler extension; it’s an operating system thing. Linux and the BSDs accept a third argument but it’s optional. I’m not sure why that’s a reason to hate C? Just don’t use it, nobody does.
@@thebatchicle3429 I assumed anyone reading this would've seen my prior post and gotten that I meant "hate" sarcastically, and it was kind of a nudge towards what Tsoding said about C. However, I never referred to the environment variables argument as being a compiler extension, and it's technically a conforming implementation to provide access to the environment, even if the standard doesn't specify it be in a third argument. It could just as easily be provided in argv past argc, or even tacked onto the command line arguments with no boundary between the two, or with an empty string, as it's up to the implementation how to provide that as long as argv[argc] == NULL.
1:08:40 - out of my experience, this might be a problem. It is quite easy to leave some platforms go "stale"; or assume something just works but it explodes because the platform's compiler/libc/etc has weird compilation quirks.
20:43 *vsauce music plays*
C never gets outdated == Build system never gets outdated.
Though, they wanna delete K&R style for functions declaration, like this
```
int foo(a, b, c)
cont char *a;
int b;
void *c;
{ ... }
```
which is literally how documentation for Xlib is done. But I think you already showed that in one of the streams.
They don’t _want_ to remove them, they’ve literally already removed them in C23
@@thebatchicle3429 foken zoomers from the committee. Why they just can't get the simplest point that k&r times were times of non-highlighted syntax? I mean yeah, I'm not using that style for the obvious comfort reason, but why to exclude it..
The Seperate platform files makes it simpler and shorter but more likely the code drifts
That whole bit in the beginning with CMake. Is exactly why I never bothered to learn CMake or build tools in general.
I'd rather be a caveman basically handing a note that says type this stuff in your compiler of choice to use this shit.
i didnt know cmake exists before i found myself moving away from the arduino ide to esp-idf couple of months ago. their build system is wrapped and interlocked with cmake up to a point where i didnt see myself having a chance at all to derive a "build.sh"-type notes-file that would allow me to stay in my cave. I went for the fumble-around-till-it-works approach and never looked back up till today. So definitly no divine intellect badge for me. ¯\_(ツ)_/¯
I just use regular make
@@ukyoize its technically also a build system
@@PranshuTheGamer Sure, but nearly every Linux system comes with it pre-installed. Screw Windows and Mac.
@@anon_y_mousse yea, wait until you see porteus
tis highly adviced to read cursed tomes of eldrich knowledge to build a tolerance to finally read javaScript documentation lest one risks high chance of hysteria, insanity and / or severe brain damage.
Every programming language sucks, just that C sucks the least. That's the real takeaway.
Saved for the future.
Today I understand nothing.
In future, I will.
Why not go one step further and do the build in the application itself (3 step: config -> build -> run application ... )
Could you include into the scene your live keystrokes next time? I'm wondering how you move in Emacs ( ͡° ͜ʖ ͡°)
C-n and C-p
very exciting to watch 😁
My venture into C unfolds like this: I'm set on crafting my own C library. Naturally, I'll include my string functions, but they must reside in heap memory. Yet, this entails the need for subsequent deallocation. Thus, I'm inclined to construct my own malloc. The catch is, I aspire to implement a form of "garbage collection," envisaging a struct (not an object) capable of allocating to a linked list, complete with IDs. This approach would facilitate the liberation of memory in cohesive groups, perpetually and so forth.
Perhaps opting for C++ might offer a more straightforward solution...
I firmly believe that in C, writing elongated functions that focus on accomplishing a singular task exceptionally well is the key, as that's the essence of what I recall from my days with C.
See how to build system of C program in C.
nob needs it's own repo
cool title
Shouldnt there be a dependency tracking for generating config.h, i.e. if you modify nob.c to add a new config, config. H should be regenerated automatically without the need to manually delete config.h? Btw this example also shows that one should use cmake because a dedicated build system is the only guarantee that building is performed correctly and is complete..
I was left thinking what if I like interpreted config style: no need to recompile at all config file... seems at @21:37 until this point relistened this is not taken into account, eg can ship binary and config is separate file. To clarify "each developer has their own config.h" -> this means need to always recompile even in this better approach if I understood correctly. So what if can know binary is compatible but need to modify config only in client machine(eg one developer local machine whose folders and settings are a bit different, otherwise program works exact same).
Too much voodoo or divine intellect or better way to build c
Original title was more interesting
I never understand this trend of hating programming languages, especially when large part of your code is written in that language. Like we don't have enough hate in this world... It is sad to see at 1:43:40 how you are twisting on the chair because it's hard to say something good about C(or any language) it's always more cool to just hate on something...
Nice, I like this.
Merry Christmas y'all
How do your build system know to perform config stage when you add other variables to config but an old version of config exists?
I mean if you change first stage nob.c which in turn may change a config you have to skip checking if config.h exists and straight up regenerate it
inb4 linux kernel built with nob????????
ill do it
Now what we need next is to replace Regex with C code.
wonder if you could create a script to ping people for live on twitch
Tsoding is very close to the suckless way of programing.
Many suckless programs has a file called config.def.h and after you build the program for the first time you have config.h wich you can customize.
That's not a suckless thing, it's an autoconf thing.
@@anon_y_mousse autoconf can generate c header files?
@@Vulto166 It can do a lot of things, including generate configure scripts. Check it out.
@@anon_y_mousseit’s also a Suckless thing
1:15:40 So use D as betterC instead!
So are you telling me that this feature extension will even makes the haters like nob?
Tsoding already done Neural Networks, which is quite OP. So I am in the wait of when he maybe tries less op machine learning techniques like Reinforcement Learning and Genetic Algorithms.
Red Circle 🔴
23:13 I know what he is up to
38:00 freepascal extra dangerous?
Why not build raylib in it's own stage?
Stage 1: generate `config.h`
Stage 2: build raylib (and possibly other deps)
Stage 3: build app.
Or is that too much like make?
Those who do not understand make(1) are doomed to reimplement it.
What's so special about topological sort and modification date checking?
"c is shit" - love it :D
I can definitely see a three step build process being used for extending this to cross compilation as well…
A neat hack, but so is C
not scalable but cmake is bloated
You could try to builld a bigger project using nob, for example raylib.
It literally fucking builds the entire raylib as part of the musializer build ffs
@@TsodingDaily awesome
First, azozzinnng
I agree. C is shit. But it’s fun haha.
Tsoding is wrong on the internet and let me tell you why: I'm a fan of letting the compiler do all your parsimg building a config.h header, but moving so that the build code only builds on the platform you're building on is hairy because as Mr. Tsoding demonstrated he's got a bunch of compile errors on windows and crapple, that can't be tested on Linux.
Generally I try to move my preprocessor statements into the language ASAP so that it becomes normal code.
Void main(void) {
#if LINUX
#elif MAC
#elif WIN
#endif
Defer:
Free()
Free()
Return 0;
}
Why did u copy/paste main and defer so many times.
21:12 lmao
CPP, humanity's greatest invention
The only greater invention was Free Pascal.
why do you cringe at the word 'scalable'? 😂