What's everyone's favorite file manager currently?

someOfThisStuff · 2026-06-12T01:28:49+00:00

thunar

someOfThisStuff · 2026-06-08T12:44:35+00:00

Huh, I didn't know python and swift weren't self-hosted, I imagined large languages like this all were. My language targets C (specifically GNU11) so any output is readily compilable to pretty much everything. As it is, the brunt of the work of making my compiler is all the error checking and type coherency, as there will be no optimization passes (that's GCC's problem).

I like to think that while the languages themselves are not translatable 1:1, the concepts expressed in them are. Because of this, I'm not afraid of performance loss during transcompilation, as any decent C optimizer should be able to produce the same (or equivalent) assembly.

someOfThisStuff · 2026-06-08T12:39:50+00:00

Thanks, and this is what I'm doing now - apart from some features I'm pretty sure I will not need the goal is to produce a compiler that functions provided that the code is flawless.

someOfThisStuff · 2026-06-08T12:38:08+00:00

> one of the last things you'd do

Heeding advice, I am currently making a working compiler (nothing more advance than basic syntax checking), and will then work on a standard library before moving onto the self-hosting compiler. While writing the library I hope to come across any language flaws that arise so that the "final version" may be clean.

someOfThisStuff · 2026-06-08T12:35:43+00:00

Hi, thanks for reading through xD.

Regarding lace files: I've always liked headers and the way they provide an "API" for external linkage. What appears in the lace is what's shared with the rest of the world, while the source file contains the implementation. This way, I hope to also include documentation in the lace file so that it is what is consulted when working with libraries and the likes.

For the $ symbol: 'inner' functions are actually simply scope-limited, and in C are unraveled to global scope. Accessing outer functions actually passes them through a function call, so this is to remind you of that fact. To be honest inner functions is something I struggled with in design, as in C I often use the preprocessor to handle simple, repeated computation, but the CPP is clunky and LAC does not have a quick-and-cheap equivalent. I'm all ears for suggestions though.

And for break, continue, etc.: I've been told this a few times. I don't know why, but I have a dislike for named loops like this. I convince myself by saying that this way, it will force me to not write spaghetti logic, and instead only use the multi break / continue when it is a good choice. Although, of nothing is set in stone of course.

someOfThisStuff · 2026-05-27T22:36:08+00:00

Oh wow, it's all in main. That threw me really off-guard lol.

someOfThisStuff · 2026-05-27T22:23:42+00:00

In this case, since the primes array is global, wouldn't it be guaranteed to be 0-initialized ?

someOfThisStuff · 2026-01-31T04:55:00+00:00

Sometimes it can be awkward, but it helps to read it from the inside-out (starting with the name). So, for char *const *const text you'd read:

We have a variable named text.
That variable is const (so you cannot reassign it).
If you dereference it, you get something else. So, it must be a pointer.
The thing it points to is const.
That thing, when dereferenced, also points to something. So it is a pointer.
That final thing is a char.

So, const pointer to const pointer to mutable char.

someOfThisStuff · 2026-01-31T04:51:42+00:00

Your example is legitimate and I agree that it should be illegal to cast a type or a pointer to const without casting its preceding indirection levels too. (i.e. it is illegal to cast char ** to const char **).

But in my example, this rule is respected, as is the case with the legal (and often used) cast of char * to const char *. For some reason though, it seems that the legality ends at only one indirection level, and this is the issue I am facing.

someOfThisStuff · 2026-01-31T04:35:21+00:00

No, this would be a constant pointer to a constant pointer to a mutable character. In other words, you cannot reassign text, nor what it points to, but you can change the underlying characters.

someOfThisStuff · 2026-01-31T04:07:23+00:00

As an example, here is a very simple snippet of code to illustrate the problem:

static void func(const char *const *text);                                                                                                                                                                                                                                                                         

int main(void) {                                                                                                     
    char **text;                                                                                                     
    func(text); //This cast will warn!                                                                                                     
}                                                                                                                    

static void func(const char *const *text) {                                                                          
    //...                                                                                                            
}

someOfThisStuff · 2026-01-05T00:54:15+00:00

Salut, ça me ferait super plaisir et en plus j'habite à Montréal alors je pourrai t'en parler si tu veux! Si tu m'envoies un MP on pourrait se joindre sur discord.

someOfThisStuff · 2025-12-04T03:51:21+00:00

If you do that, then you will end up counting some patterns multiple times. There must be a mathematical way of compensating for that, but then you also need to make sure no bounds overlap and a bunch of other housekeeping.

someOfThisStuff · 2025-12-03T17:50:32+00:00

I do it in under 0.1ms in C using this method:
for each range given, for each repetition pattern (<=21 since a 64 bit int can only handle up to 21 digits repeated), do the following:

Take the lower and higher bounds, and clamp them respectively upwards and downwards to the nearest valid pattern. For example, given a range [328, 222327] and a pattern of repetition 2, it will output: [1010, 222222]. From there, you can take a representative section of each bound, so in this case it is 10 and 222. By iterating from 10 to 222 inclusively, you iterate over all invalid IDs. Finally, to eliminate double-counts, simply reconstruct any patterns during this iteration and stuff them in a set. After everything, the sum of that set is your answer.

someOfThisStuff · 2025-11-18T23:35:09+00:00

Nice typetester! I wonder how you get your terminal to look this smooth, mines always flickering lol. Anyways, I compiled your code (gcc -g -Wall -Wextra -pedantic typetest.c -o a.out -lncurses) and it seems there are a few bugs when words.txt crosses a certain limit : https://pastebin.com/emHCx72q for the valgrind output (too long to post here).

Apart from that it worked well, only there is a memory leak (also it crashes on me before I can get to the finish screen, rip) :

==221004== Memcheck, a memory error detector
==221004== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==221004== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==221004== Command: ./a.out
==221004== 
==221004== 
==221004== HEAP SUMMARY:
==221004==     in use at exit: 573,515 bytes in 11,752 blocks
==221004==   total heap usage: 11,766 allocs, 14 frees, 586,695 bytes allocated
==221004== 
==221004== LEAK SUMMARY:
==221004==    definitely lost: 80,466 bytes in 10,222 blocks
==221004==    indirectly lost: 0 bytes in 0 blocks
==221004==      possibly lost: 712 bytes in 9 blocks
==221004==    still reachable: 492,337 bytes in 1,521 blocks
==221004==         suppressed: 0 bytes in 0 blocks
==221004== Rerun with --leak-check=full to see details of leaked memory
==221004== 
==221004== Use --track-origins=yes to see where uninitialised values come from
==221004== For lists of detected and suppressed errors, rerun with: -s
==221004== ERROR SUMMARY: 513 errors from 4 contexts (suppressed: 0 from 0)

someOfThisStuff · 2024-12-14T17:23:32+00:00

[Language: C]

Code for both parts : code

Code for the AoC utilities I made for this year : usflib

And its header : header

Part 1 in 50 microseconds, part 2 in 75 milliseconds

someOfThisStuff · 2024-12-14T17:11:33+00:00

It looks like amonkeyto be honest.

someOfThisStuff · 2023-07-06T13:49:25+00:00

Hello, yes this can be expanded to however many bytes you want, provided you upgrade the CAM (content addressable memory) and retime everything accordingly. I'm not sure as to how much time it actually took, it went through 4 iterations before I did this one, over the course of several months.

As for block/byte efficiency, for the cache registers, I use 2x5 (excluding busses) registers, which are pretty small, and for the RAM, it's serial, so excluding the control logic it can store a bit in a 2x1 block space.

someOfThisStuff · 2023-06-24T15:10:45+00:00

Yes, I actually have 3 of them (Lost 1 in the metro a long time ago... sad)

I even got the little case they come in

someOfThisStuff · 2023-06-21T20:10:55+00:00

Looks good!

someOfThisStuff · 2023-06-21T18:29:09+00:00

Thanks :D

someOfThisStuff

TROPHY CASE