Pagwin/new_blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

fixed layout fuckup which messed up mobile

Browse source
This commit is contained in:
Pagwin 2025-08-25 22:27:31 -04:00
parent 2c0b439366
commit 858237af66
2 changed files with 9 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
posts/fractions_sidequest.md
View file

@ -72,7 +72,7 @@ impl Add for Frac{
This code feels bad even from a code quality point of view but idk why, regardless it's hilariously bad performance wise. This code feels bad even from a code quality point of view but idk why, regardless it's hilariously bad performance wise.
<video width="700" height="400" controls src="/static/video/frac_gen_v1.mp4"></video> <video controls src="/static/video/frac_gen_v1.mp4"></video>
Considering that we're "only" doing addition this is incredibly slow. Slower than addition in (insert butt of the joke language of this week here). All that in mind something is definitely up and if you read the code above and think about it enough you'll probably see it. Considering that we're "only" doing addition this is incredibly slow. Slower than addition in (insert butt of the joke language of this week here). All that in mind something is definitely up and if you read the code above and think about it enough you'll probably see it.
@ -154,7 +154,7 @@ async fn recurse(f1:Frac,f2:Frac, remaining:u64)->Vec<Frac>{
looks good at first glance(actual version code quality is bad but blog version seems alright). What happens when we run it? looks good at first glance(actual version code quality is bad but blog version seems alright). What happens when we run it?
<video width="700" height="400" controls src="/static/video/frac_gen_v2.mp4"></video> <video controls src="/static/video/frac_gen_v2.mp4"></video>
Oh... we run out of memory... or well we run out of 30 gigabytes of memory because I set a limit to avoid affecting the other stuff running on the server(because it isn't mine). But why? Doing the math if all we had to deal with was the fractions we'd be using about `17501876*4/1000**3 ~ 0.07 GB`, if we include the overhead of all the Vecs we make and are pretty agressive with how much memory they use maybe 0.21 GB which is a difference of over 142x. So what's the rest of the memory? Oh... we run out of memory... or well we run out of 30 gigabytes of memory because I set a limit to avoid affecting the other stuff running on the server(because it isn't mine). But why? Doing the math if all we had to deal with was the fractions we'd be using about `17501876*4/1000**3 ~ 0.07 GB`, if we include the overhead of all the Vecs we make and are pretty agressive with how much memory they use maybe 0.21 GB which is a difference of over 142x. So what's the rest of the memory?
@ -196,7 +196,7 @@ fn recurse(f1:Frac,f2:Frac, remaining:u64)->Vec<Frac>{
This solves the whole running out of memory thing. A funny side effect is that now it's even faster(even though it's 1 thread). This solves the whole running out of memory thing. A funny side effect is that now it's even faster(even though it's 1 thread).
<video width="700" height="400" controls src="/static/video/frac_gen_v3.mp4"></video> <video controls src="/static/video/frac_gen_v3.mp4"></video>
So that was fun going through and making all this work out well, now I can generate gigabytes upon gigabytes of fractions with ease. So that was fun going through and making all this work out well, now I can generate gigabytes upon gigabytes of fractions with ease.

7
static/css/layout.css
View file

@ -145,8 +145,13 @@ header#header {
padding: 0.5em 1em; padding: 0.5em 1em;
} }
article { article {
max-width: 66ch; max-width: min(66ch, 100vw);
width: 100%; width: 100%;
padding: 1rem;
}
video, img {
max-width: -moz-available;
max-width: fill-available;
} }
main { main {
box-sizing: border-box; box-sizing: border-box;