@mhoye

#include tiredMongoDbJoke.h

#include

#include

Solved! Trial-and-error indicates that you have to #define USE_KERNEL before using any system includes like #include <stdio.h>, as it appears they check for it. If you neglect to do this, you get cryptic "unresolved reference to __main" errors even when trying to build a library.

My program still doesn't work (one module is raising hundreds of "too far for size-two reloc" linker errors) but I think that's because the module is >64K and needs to be split up more, which is my own fault and a problem for tomorrow.

#ti92 #ticalc

@corpsmoderne
I'm not exactly an expert either, so take with a pinch of salt, but: regular nix files are just nix expressions that can you import/evaluate (a bit like a C file you can #include) - the flakes stuff is a relatively new additional layer basically built on top. It allows you to define dependencies on other flakes, and pin their versions in a lock file like npm or go do.

@sebsauvage

#include <stdio.h>

void main()
{
printf("Hello world\n");
}

Fini, pas besoin de révision

this part in particular is fucking............it's really cool actually

/* generate 8-bit version */

#define SRE_CHAR Py_UCS1
#define SIZEOF_SRE_CHAR 1
#define SRE(F) sre_ucs1_##F
#include "sre_lib.h"

/* generate 16-bit unicode version */

#define SRE_CHAR Py_UCS2
#define SIZEOF_SRE_CHAR 2
#define SRE(F) sre_ucs2_##F
#include "sre_lib.h"

/* generate 32-bit unicode version */

#define SRE_CHAR Py_UCS4
#define SIZEOF_SRE_CHAR 4
#define SRE(F) sre_ucs4_##F
#include "sre_lib.h"

what does this mean?

/* This file is included three times, with different character settings */

that's right. they just did compile time polymorphism in 12 lines of standard C

most shells will be fine with #include in heredocs these days but i'm not gonna pass up an excuse for a quadrigraph

@esoteric_programmer The emulator itself is a giant blob of JS, but that shouldn't affect a screen reader. I'm surprised it went so poorly, I was just expecting it to not be very useful to actually use. The exploit source is loaded in its entirely and scrolled to the current line, but that's just a few hundred lines of code. I'd guessed the screen reader probably doesn't know where to start reading, but if that were all it'd had started with ' #include' and I'm sure you'd at least have known what it's doing. Meanwhile the assembly is just the current screenful of code (dynamically recomputed as it steps) so other than excessive context, it shouldn't have broken or overloaded anything.

It's really weird that it went *that* wrong. Maybe the syntax highlighting spans confused it? Or maybe reveal.js, the slides framework I use, is itself not accessible? I don't know... (The link has an anchor taking you to the last slide, but you can navigate to other slides with the arrow keys, in a sort 2D columns-of-slides pattern, space key to go to the next slide in logical order)

GLSL, OpenGL's standard language for programs ran on the GPU, includes what closely resembles C's preprocessor. So how'd we reimplement this for our risc32cfimv?

Incidentally GLSL specifically excludes #include, so (using the hardware I introduced the other day) we could run on this on a ROM-bank without filesystem routines. But #include sounds handy so I'm tempted to suggest that I'd implement it anyways!

In which case I'd love #line to be handled later, & even synthesize new ones.

1/?

#define would extract the identifier & parse the following optional argument list & body removing (escaped) newlines to load into a "macro" table.

Non-preprocessor lines would be scanned for these macros' identifiers to perform a find & replace, recursing to handle substitute in parameters.

2/3?

#define would extract the identifier & parse the following optional argument list & body removing (escaped) newlines to load into a "macro" table.

Non-preprocessor lines would be scanned for these macros' identifiers to perform a find & replace, recursing to handle substitute in parameters.

2/3?

GLSL, OpenGL's standard language for programs ran on the GPU, includes what closely resembles C's preprocessor. So how'd we reimplement this for our risc32cfimv?

Incidentally GLSL specifically excludes #include, so (using the hardware I introduced the other day) we could run on this on a ROM-bank without filesystem routines. But #include sounds handy so I'm tempted to suggest that I'd implement it anyways!

In which case I'd love #line to be handled later, & even synthesize new ones.

1/?

Have you seen the new code? It's on malloc. It's literally on volatile.

It's on #define with side effects. It's literally on long long.

You can probably find it on attribute((packed)). Dude it's on restrict.

It's a static inline original. It's on extern. You can #include .

You can go to extern and fopen("extern","r"). Compile onto extern right now.

Go to extern. Dive into extern. You can extern it. It's on extern.

extern has it for you. extern has it for you.

Have you seen the new code? It's on malloc. It's literally on volatile.

It's on #define with side effects. It's literally on long long.

You can probably find it on attribute((packed)). Dude it's on restrict.

It's a static inline original. It's on extern. You can #include .

You can go to extern and fopen("extern","r"). Compile onto extern right now.

Go to extern. Dive into extern. You can extern it. It's on extern.

extern has it for you. extern has it for you.

// [my name here as an author]
// [my birthdate] - [my deathdate]

#include <stdio.h>

main() {
printf("Goodbye world!\n");
}

// [my name here as an author]
// [my birthdate] - [my deathdate]

#include <stdio.h>

main() {
printf("Goodbye world!\n");
}

https://eel.is/c++draft/defns.impl.defined
https://eel.is/c++draft/defns.unspecified

(so e.g. where the standard says that the details of searching for a header file for an ` #include` are implementation-defined, that means the compiler vendor needs to document its rules for header searching (otherwise it's not a conforming implementation).)

https://eel.is/c++draft/defns.impl.defined
https://eel.is/c++draft/defns.unspecified

(so e.g. where the standard says that the details of searching for a header file for an ` #include` are implementation-defined, that means the compiler vendor needs to document its rules for header searching (otherwise it's not a conforming implementation).)

Linux kernel quiz: Why is this program so slow and takes around 50ms to run?
What line do you have to add to make it run in 3ms instead without interfering with what this program does?

user@debian12:/test$ cat > slow.c
#include 
#include 
#include 
#include 

static void open_sockets(void) {
 for (int i=0; i<256; i++) {
 int sock = socket(AF_INET, SOCK_STREAM, 0);
 if (sock == -1)
 err(1, "socket");
 }
}

static void *thread_fn(void *dummy) {
 open_sockets();
 return NULL;
}

int main(void) {
 pthread_t thread;
 if (pthread_create(&thread, NULL, thread_fn, NULL))
 errx(1, "pthread_create");
 open_sockets();
 if (pthread_join(thread, NULL))
 errx(1, "pthread_join");
 return 0;
}
user@debian12:/test$ gcc -O2 -o slow slow.c -Wall
user@debian12:/test$ time ./slow

real 0m0.041s
user 0m0.003s
sys 0m0.000s
user@debian12:/test$ time ./slow

real 0m0.053s
user 0m0.003s
sys 0m0.000s
user@debian12:/test$