Jatin Raghav

Helloooo,

OCaml is more different then I expected and thus has a totally new mental model to it.

It is going to take some time to get this new mental model. Let's go through the OCaml Intro docs and get a sense of this different world.

But right now I can't do two separate streams every day, one for Advent of Code and one for OCaml.

So after 12 Dec I will start OCaml streams, I guess 3-4 would be fine for getting a sense of this and not a full blown comprehensive understanding. And we'll do AOC day 5 then.

I think that's cool enough.

2 weeks ago | [YT] | 5

Jatin Raghav

Yoo, I won't be streaming for a few days.

I got something important to do.

I hope you get it. Anyways, it's cool.

3 weeks ago | [YT] | 5

Jatin Raghav

Rust Memory Management.

Just 3 simple rules:

1-> Every value is accessed by a variable ( which is how all the high level languages work ), that variable is called its owner.

2-> At a given time a value can have only a single owner. ( that is, a single value can't be owned by multiple variables at the same time )

3-> When the owner goes out of scope the value is freed. ( the memory where the value was stored is freed )

That is the major chunk of it.

Inside the Rust compiler ( rustc ) we have a part inside it called the Borrow Checker, and that is the infamous thing.

Borrow Checker is the one that verifies whether everything checks out or not.

There are a few other side notes that go along with these 3 rules.

1-> By default Rust does not copy your values, it moves them.

References

References can be though of as pointers to the value they are referencing, they don't have the ownership of the value, so we are not breaking the 2nd rule with them. They are simply a way to get to the value using some other variable.

And since references are not owner of the value, the value is not freed when the reference goes out of scope.

Sometimes we just need to refer to some value and simply read it, and sometimes we want the ability to change the value. And If we don't want the ownership we can use references.

There are references for both reading ( called Immutable References ) and writing ( called Mutable References ).

Immutable References, these are used at places we don't want to update the value and just want to read it.

Mutable References, these are used at places when we also want to update ( mutate ) the value.

And regarding these references there are some rules we need to keep in mind.


Immutable references => These we can have in any amount, like any amount. But we can't have even a single one if there is a mutable reference in the same scope.

This is because Immutable reference reads value, and if we have a Mutable reference also in the same scope then the Mutable reference could change the value whenever it wants and we are cooked.

So, any amount of Immutable reference to throw around unless we have a Mutable reference in scope.

Mutable references => These can only be present one at a time. Since we don't want two variables to be able to update a value at the same time, that's kinda like breaking the second law. And if we do have one Mutable reference we can't have any Immutable Reference.

Skip the Carousel

1 2 3

1 month ago | [YT] | 9

Jatin Raghav

Yoo...

I gotta say I am pausing the streams.

And that doesn't mean I am not learning, I am learning way more stuff now, compared to when I started streaming.

The streaming format is not really working out for learning these more difficult stuff. I just want to sit and read and ponder and not say I word and just play in me head.

And I don't want to stream just for the sake of it.

This is simply a pause from streaming and when the time comes ( maybe a few months or would be crazy if it were in years ) I will know when to start streaming.

Let's goooo....
and learn about all these crazy things out there.

1 month ago | [YT] | 17

Jatin Raghav

Kernel -> TTY -> ( Master | Slave ) -> SHELL -> Next Slaves

Yup it's kinda simple if you know what is actually happening. Let's go bottom up. ( This is just an overview, and my understanding of what is happening, please point out the flaws)

We have the kernel which is controlling the hardware, the monitor , the keyboard and even the mouse ( alas we have to use the mouse ).

We want to run some processes on the hardware and we need two things to do with the processes, we want to give input to the processes and take output from them ( this differs from process to process, we might get text or something more visually simulating ).

So how can these processes talk to the kernel to ask for some user input and give some output to the user?

There are two ways: ( These are not concrete categories, I just made them up )
1-> Graphical Processes
2-> Text Processes

1-> Graphical Processes : Here we have the processes which want to use advanced features by the kernel to flex and display their advanced qualities , we have Browsers and Games in this category.

These processes can have their own protocol for showing stuff on the screen or could use some Other Process for displaying whatever they want. The other processes which they could use are called Display Servers, Eg: Wayland.

These processes don't primarily work with text, they have more stuff to put on.

2-> Text Processes: These processes work with text, they want to take some user input in text form and display the result in text form. They don't need fancy stuff, just plain text. Eg, ls, grep, bc, vim etc...

But they also have to do the talking with the kernel, and they also have the option to write their own Display protocol but that is bad, we already have Display Processes which can be used for the Kernel talking.

These Display Processes are the root of this whole discussion, TTYs or Terminals or PTYs or Terminal Emulators ( I have many names) .

Let's go back in time. ( TENET )

Back in the day people ( Dennis Ritchie ) used to have a literal keyboard connected to a monitor which ,by hardware design, used to give whatever the user types into the keyboard to the software running. They were the original Terminals. ( I won't say more than that, cuz I don't know more )

What we have now are not Terminals in the technical sense, they are Terminal Emulators. I can't get into the technicals as to what are the exact differences between a real Terminal and a Terminal Emulator. ( I don't know them )

Let's see what a Terminal Emulator does ( also called PTY, Pseudo TTY, and TTY stands for TeleTyper ). I am going to refer to Terminal Emulators as Terminals ( concise ).

We have the Kernel, and we want to run processes like grep and give in text input and get text output. The Terminal ( Ghotty, Kitty, iterm, console ... etc ) it's whole job is the create Slaves.

There are different instances of Terminals running, like whenever we open another window in a Terminal or launch a new Terminal instance we create a new Master Slave pair, which is managed by the Kernel.

This Master Slave dynamic is like this, the Terminal acts as the Master and the Processes using the terminal to display their text output and take text input are called it's Slaves.

The first Slave Process is always a Shell.

This Shell Process is like any another Process which we might use, like ls or grep, having it's own binary ( usually /bin/bash or /bin/zsh ). This is just the default slave which runs first. This Shell Process prints the first line we see on the Terminal screen ( User@Host:pwd$ ).

At it's core the Shell Process is an interpreter which takes the text user puts in ( using the Terminal ) and parses it and processes it.

Since Shell is an interpreter which is running, it's can have two kinds of commands, first ones are built in commands and second ones are where the Shell is going to start another Process.

Some built in Shell commands are 'echo' , 'cd' ... etc. For running these Shell doesn't need to start some another Process these are built into the Shell binary.

Another type of commands are external ones like 'ls' , 'grep'.. etc. For running these commands the Shell, creates a clone process and the clone process gets converted to the External Process which needs to be run ( like ls, or grep ).

In Linux this is the way to create a new process, the current process creates a clone of itself ( using fork() ) and the clone converts and runs the binary for the target process.

The new process thus created ( this is a totally new process with it's own PCB and memory and every thing and not a simple thread created by the Shell ) handles the input output interaction by the user. This new Process is also a slave to the same master Terminal which the running Shell is associated to.

Thus when we do 'ls' it's not that the Shell runs the 'ls' and passes arguments to the 'ls' binary and takes output by the 'ls' and displays it to the Terminal screen. Nope, 'ls' was simply launched by the Shell with the given arguments but printing output to the screen ( through Terminal ) is handled by 'ls' itself.

Now we know that there are Masters and Slaves, And each Terminal acts as a new Master with it's own Slaves. And the Shell is just the first Slave and is used to create more Slaves. These Slaves do their text based I/O with the user through their Master Terminal. ( that is the official terminology )

Now how does the I/O actually happen?

Kernel.

The Kernel keeps track of who is a Slave to who. In /dev/tty/ we have multiple files depicting the so called Pairs of Master Slaves and each Master Slave pair gets it's own stdout, stdin and stderr instance. And even though a single Master can have multiple Slaves, they all share the same stdio streams.

And to go more into the specifics these 3 stdio modes, stdin , stdout and stderr, are represented by File Descriptors with id's 0,1 and 2 respectively, and internally functions like printf , scanf and perror, call read() and write() on these File Descriptors.

While this external function like 'ls' is doing the I/O stuff the Shell stops and waits for the external process to end and when the process ends the Shell prints the prompt again tempting the user for another command. And on we goo again ( Eternal Recurrence ).

That is all pretty cool and makes sense now, We have Terminal Emulators which act as Masters and have Slaves, Shell is the First Slave and takes user input and based on the user input runs some External Process, this External Process is a new Slave, and handles it's own with the Terminal and does the inputting and the outputting, and while that is going on the Shell awaits it's return, the New Slaves ends and the Shell once again takes control, and the user enters the next command.

ngl. That's kinda Dope.

2 months ago | [YT] | 10

Jatin Raghav

I feel a bit overwhelmed with competitive programming at the moment, so I have decided to take a little break from it for a few days.

And in that time we can get our hands dirty with other amazing things, please tell which thing you would like to get into.

2 months ago | [YT] | 9

Jatin Raghav

This is cool.

There is a thing which came in c++ 17 called Class Template Argument Detection ( CTAD ), which is a new ability of the compiler, where it detects what the arguments for a class template should be based on the arguments provided for the initialisation.

This is cool because we don't have to write the full arguments for a template and is specially helpful when the datatypes are not primitives but classes themselves. Like in a vector matrix.

2 months ago | [YT] | 16

Jatin Raghav

There two things are really cool.

If we have an unsigned int smaller than or equal to 2^31, we can use these constant time functions to find the ceiling and the floor of a number with regard to powers of 2.

Like we can find the greatest power of 2 that is smaller or equal to x.

And the smallest power of 2 that is equal or greater than x.

And these take only about 12 assembly instruction ( if we were to write the equivalent code in assembly ).

There is this cool book which has all this amazing binary stuff, it's called "Hacker's Delight" by Henry Warren.

2 months ago | [YT] | 7

Jatin Raghav

Tomorrow will be the 200th stream, there is nothing special about that.

But what is special is we will understand Tmux in much more detail or as much as we can manage in one sitting.

Main reference is going to be this: leanpub.com/the-tao-of-tmux/read

And if the opportunity arises, then let's also get our hands dirty with zsh and bash.

2 months ago | [YT] | 8

Jatin Raghav

Now, we will be stepping into Graphs.

The main theory material is going to be from Competitive Programming Handbook.

And for Problems we have CSES.

We got this. ; |

2 months ago | [YT] | 10