refactor
This commit is contained in:
parent
846bce9480
commit
60aea94006
32 changed files with 328 additions and 278 deletions
|
|
@ -196,7 +196,7 @@ Count-Pairs($l_1$, $l_2$, $r_1$, $r_2$, $k$):
|
|||
|
||||
Each value of $n$ corresponds to a line with slope $k^n$ because $y/x=k^n\leftrightarrow y=x\cdot k^n$. The problem can be visualized as follows:
|
||||
|
||||
|
||||
|
||||
|
||||
It is sufficient to count the number of ordered $(x,y)$ pairs for all valid $n$. Because $y=x\cdot k^n\leftrightarrow n=log_k(y/x)$, $n\in [log_k(l_2/r_1), log_k(r_2/l_1)]$.
|
||||
|
||||
|
|
@ -47,7 +47,7 @@ The Qt Framework is quite complex and beyond the scope of this post. Big picture
|
|||
|
||||
How do we optimize this? It is necessary to take a step back and observe the structure of the entire application:
|
||||
|
||||
|
||||
|
||||
|
||||
Many flaws are now clear:
|
||||
|
||||
|
|
@ -68,7 +68,7 @@ First, let's pin down what exactly can be parallelized.
|
|||
|
||||
This lead me to the follow structure:
|
||||
|
||||
|
||||
|
||||
|
||||
- Three callback groups are triggered at differing intervals according to their urgency on the GUI node
|
||||
- A thread-safe queue[^2] processes all ingested data for each callback group
|
||||
|
|
@ -101,7 +101,7 @@ Considering each element of the state machine, I simplified it into the followin
|
|||
|
||||
Since we only have $N\ll 32$ vehicle flags and $M\ll 32$ track flags, all of this information (all of the state flags) can be encoded in a `uint32_t`:
|
||||
|
||||
|
||||
|
||||
|
||||
The state must also store a few other relevant details:
|
||||
|
||||
|
|
@ -1,36 +1,17 @@
|
|||
import { defineCollection, z } from "astro:content";
|
||||
|
||||
const postsCollection = defineCollection({
|
||||
type: "content",
|
||||
schema: z.object({
|
||||
title: z.string(),
|
||||
description: z.string().optional(),
|
||||
date: z.string().optional(),
|
||||
useKatex: z.boolean().optional().default(false),
|
||||
useD3: z.boolean().optional().default(false),
|
||||
scripts: z.array(z.string()).optional(),
|
||||
}),
|
||||
});
|
||||
|
||||
const gistsCollection = defineCollection({
|
||||
type: "content",
|
||||
schema: z.object({
|
||||
title: z.string(),
|
||||
description: z.string().optional(),
|
||||
date: z.string().optional(),
|
||||
}),
|
||||
});
|
||||
|
||||
const gitsCollection = defineCollection({
|
||||
type: "content",
|
||||
schema: z.object({
|
||||
title: z.string(),
|
||||
date: z.string().optional(),
|
||||
}),
|
||||
const base = z.object({
|
||||
title: z.string(),
|
||||
description: z.string().optional(),
|
||||
date: z.string().optional(),
|
||||
});
|
||||
|
||||
export const collections = {
|
||||
posts: postsCollection,
|
||||
gists: gistsCollection,
|
||||
git: gitsCollection,
|
||||
algorithms: defineCollection({ type: "content", schema: base }),
|
||||
software: defineCollection({ type: "content", schema: base }),
|
||||
meditations: defineCollection({ type: "content", schema: base }),
|
||||
"autonomous-racing": defineCollection({ type: "content", schema: base }),
|
||||
|
||||
git: defineCollection({ type: "content", schema: base }),
|
||||
gists: defineCollection({ type: "content", schema: base }),
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "git-server.git"
|
||||
title: "git-server"
|
||||
date: "08/10/2025"
|
||||
---
|
||||
|
||||
the code for my git python server, hosted on [lightsail](https://aws.amazon.com/lightsail/)
|
||||
the code for my git python server hosted with [lightsail](https://aws.amazon.com/lightsail/)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "wp.git"
|
||||
title: "wp"
|
||||
date: "07/10/2025"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ But I did not actually _need_ any of them to make this site look decent.
|
|||
|
||||
## what i've learned
|
||||
|
||||
Of course, most people build simple websites like these to learn a new technology or framework, not to use an optimal tool. That's actually why I [hosted this website on AWS](/posts/software/from-github-pages-to-aws.html).
|
||||
Of course, most people build simple websites like these to learn a new technology or framework, not to use an optimal tool. That's actually why I [hosted this website on AWS](/software/from-github-pages-to-aws.html).
|
||||
|
||||
Building this website with truly bare-bones technologies has made me appreciate _why_ these web frameworks have emerged.
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ A user request can be modelled as follows:
|
|||
4. CloudFront checks its edge caches for the requested content. If the content is stale or not cached, CloudFront fetches the content from S3. Otherwise, it uses the cached content from an edge server.
|
||||
5. CloudFront returns the content to the user's browser.
|
||||
|
||||
|
||||
|
||||
|
||||
## difficulties
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ That's it. The `makefile` relies on some scripts that compile code and run the c
|
|||
|
||||
# neovim integration
|
||||
|
||||
|
||||
|
||||
|
||||
Leveraging [LuaSnip](https://github.com/L3MON4D3/LuaSnip), a custom `CP` user command, and some scripting for window management and asynchronous jobs, I'm able to:
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue