Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A single-file C allocator with explicit heaps and tuning knobs

github.com

Post reply on HN
Print view View original

11–20 of 48 posts

Re: A single-file C allocator with explicit heaps and tuning knobs

#11

Post by bitbasher »

tosti wrote: post #9
bitbasher wrote: post #7

Earlier quoted context omitted.

That doesn't make any sense. There's 10,000+ lines of code. There shouldn't be a single commit "Initial commit". I'm fine with squashing some commits and creating a clean history, but this isn't a clean history it's obfuscated.

I also do this. Lots of weird commit messages because fuck that, I'm busy. Commits that are just there to put some stuff aside, things like that. I don't owe it to anyone to show how messy my kitchen is.

> I don't owe it to anyone to show how messy my kitchen is.

There was once a time when sharing code had a social obligation.

This attitude you have isn't in the same spirit. GitHub (or any forge) was never meant to be a garbage dumping ground for whatever idea you cooked up at 3AM.

Re: A single-file C allocator with explicit heaps and tuning knobs

#12

Post by bitbasher »

ntoslinux wrote: post #8

What is the reason for the weird `{ code };` blocks everywhere and is the below code machine generated? ```c ((PageSize) (chunk->pageSize - ((PageSize) ((PageSize) ((PageSize) (sizeof(Page) + (sizeof(struct _Block))) + (PageSize) ((sizeof(double)) - 1u)) & ((PageSize) (~((PageSize) ((sizeof(double)) - 1u)))))) - ((PageSize) ((PageSize) ((PageSize) ((sizeof(FreeBlock) + sizeof(PageSize))) + (PageSize) (((((sizeof(doub…

There's a lot of code in the file that is questionable to say the least. There are unnecessary blocks ( { ... }; ) of code with unnecessary semicolons that don't serve any logical purpose.

My hunch tells me it may be the result of macro-expansion in C (cc -E ...), etc. So it's likely there's a larger code base with multiple files and they expanded it into a one large C file (sometimes called an amalgamation build) and called it a day.

By they, I mean the OP, a script or an AI (or all three).

Re: A single-file C allocator with explicit heaps and tuning knobs

#13

Post by drob518 »

bitbasher wrote: post #7
sebazzz wrote: post #5

Earlier quoted context omitted.

You still have things like git squash etc.

That doesn't make any sense. There's 10,000+ lines of code. There shouldn't be a single commit "Initial commit". I'm fine with squashing some commits and creating a clean history, but this isn't a clean history it's obfuscated.

It may have been released with a new repo created, losing all the previously-private history.

Re: A single-file C allocator with explicit heaps and tuning knobs

#14

Post by tosti »

bitbasher wrote: post #11
tosti wrote: post #9

Earlier quoted context omitted.

I also do this. Lots of weird commit messages because fuck that, I'm busy. Commits that are just there to put some stuff aside, things like that. I don't owe it to anyone to show how messy my kitchen is.

> I don't owe it to anyone to show how messy my kitchen is. There was once a time when sharing code had a social obligation. This attitude you have isn't in the same spirit. GitHub (or any forge) was never meant to be a garbage dumping ground for whatever idea you cooked up at 3AM.

It requires self-discipline to stay organized. A vcs is just a tool. I'm never organized, my brain just works that way. Whatever the tool, I'll create a mess with it. So as long as the project structure and its code is all good I can't care about anything else.

Re: A single-file C allocator with explicit heaps and tuning knobs

#16

Post by motbus3 »

bitbasher wrote: post #12
ntoslinux wrote: post #8

What is the reason for the weird `{ code };` blocks everywhere and is the below code machine generated? ```c ((PageSize) (chunk->pageSize - ((PageSize) ((PageSize) ((PageSize) (sizeof(Page) + (sizeof(struct _Block))) + (PageSize) ((sizeof(double)) - 1u)) & ((PageSize) (~((PageSize) ((sizeof(double)) - 1u)))))) - ((PageSize) ((PageSize) ((PageSize) ((sizeof(FreeBlock) + sizeof(PageSize))) + (PageSize) (((((sizeof(doub…

There's a lot of code in the file that is questionable to say the least. There are unnecessary blocks ( { ... }; ) of code with unnecessary semicolons that don't serve any logical purpose. My hunch tells me it may be the result of macro-expansion in C (cc -E ...), etc. So it's likely there's a larger code base with multiple files and they expanded it into a one large C file (sometimes called an amalgamation build) an…

Exactly my thought... This look like a clean room implementation situation

Re: A single-file C allocator with explicit heaps and tuning knobs

#17

Post by greenavocado »

bitbasher wrote: post #11
tosti wrote: post #9

Earlier quoted context omitted.

I also do this. Lots of weird commit messages because fuck that, I'm busy. Commits that are just there to put some stuff aside, things like that. I don't owe it to anyone to show how messy my kitchen is.

> I don't owe it to anyone to show how messy my kitchen is. There was once a time when sharing code had a social obligation. This attitude you have isn't in the same spirit. GitHub (or any forge) was never meant to be a garbage dumping ground for whatever idea you cooked up at 3AM.

Explain why you think making a single commit is related to any source code sharing obligation? You completely failed to establish why making a single commit is indicative of it being garbage. Your statements are a series of non-sequiturs so far and thus I can't take you seriously.

Re: A single-file C allocator with explicit heaps and tuning knobs

#18

Post by bitbasher »

drob518 wrote: post #13
bitbasher wrote: post #7

Earlier quoted context omitted.

That doesn't make any sense. There's 10,000+ lines of code. There shouldn't be a single commit "Initial commit". I'm fine with squashing some commits and creating a clean history, but this isn't a clean history it's obfuscated.

It may have been released with a new repo created, losing all the previously-private history.

Yes and no.

Have you looked at the code? It was clearly generated in one form or another (see the other comments).

The author created a new GitHub account and this is their first repository. It looks to be generated from another code base as a sorta amalgamation (either through code generation, ai, or another means).

We're supposed to implicitly trust this person (new GitHub account, first repository, no commit history, 10k+ lines of complicated code).

Jia Tan worked way too hard, all they had to do was upload a few files and share on HN :)

Re: A single-file C allocator with explicit heaps and tuning knobs

#19

Post by bitbasher »

greenavocado wrote: post #17
bitbasher wrote: post #11

Earlier quoted context omitted.

> I don't owe it to anyone to show how messy my kitchen is. There was once a time when sharing code had a social obligation. This attitude you have isn't in the same spirit. GitHub (or any forge) was never meant to be a garbage dumping ground for whatever idea you cooked up at 3AM.

Explain why you think making a single commit is related to any source code sharing obligation? You completely failed to establish why making a single commit is indicative of it being garbage. Your statements are a series of non-sequiturs so far and thus I can't take you seriously.

> Explain why you think making a single commit is related to any source code sharing obligation?

When you share code it's presumably for people to use. It is often useful to have commit history to establish a few things (trust in the author, see their thought process, debug issues, figure out how to use things, etc).

> You completely failed to establish why making a single commit is indicative of it being garbage.

A single commit doesn't mean it's garbage. It erodes trust in the author and the project. It makes it hard for me to use the code, which is presumably why you share code.

My garbage code response was in regards to the growing trend to code (usually with ai) some idea, slap an initial commit on it and throw it on GitHub (like using a napkin and tossing it in the rubbish bin).

Re: A single-file C allocator with explicit heaps and tuning knobs

#20

Post by throwaway27448 »

bitbasher wrote: post #18
drob518 wrote: post #13

Earlier quoted context omitted.

It may have been released with a new repo created, losing all the previously-private history.

Yes and no. Have you looked at the code? It was clearly generated in one form or another (see the other comments). The author created a new GitHub account and this is their first repository. It looks to be generated from another code base as a sorta amalgamation (either through code generation, ai, or another means). We're supposed to implicitly trust this person (new GitHub account, first repository, no commit histo…

> We're supposed to implicitly trust this person

That would be rather foolish even with a fully viewable history.

I don't understand why you're so worked up about this—nobody is forcing you to use the code.

Post reply on HN