Sigh, Ruby. I just wanted to write a blog post, I didn't want to have to reinstall all of the Ruby dependencies because the installed gems no longer work with my system Ruby, and then discover that the new ones don't compile.
EDIT: It looks as if no gems that have native things can build with the latest Ruby in Homebrew for macOS because it ships a complete nonsense header that tries to include a non-existent system header, but which has the same name as the header that it includes (but included with #include not #include_next). You can comment out that line and make it work but I have no idea how that made it past code review or testing.
#MAME 0.285 compiles on #HaikuOS after adding a small upstream patch (a missing #include).
If you're struggling to compile the latest version of MAME (I bet #FreeBSD and #NetBSD probably have the same issue), give this a go: https://github.com/mamedev/mame/commit/ffde4d3920ae99d2730db83982ffa9f8fbd8abd2
Anyway, there's a PR on HaikuPorts for the update, so it should be with you lovely people in the next few days.
#MAME 0.285 compiles on #HaikuOS after adding a small upstream patch (a missing #include).
If you're struggling to compile the latest version of MAME (I bet #FreeBSD and #NetBSD probably have the same issue), give this a go: https://github.com/mamedev/mame/commit/ffde4d3920ae99d2730db83982ffa9f8fbd8abd2
Anyway, there's a PR on HaikuPorts for the update, so it should be with you lovely people in the next few days.
Huh weird, just noticed that in #DesmetC I can just keep redeclaring a local variable by the same name and it works. My test suite was doing this by accident, with seemingly no problems.
int n = f1();
printf("%d\n", n);
int n = f2();
printf("%d\n", n);
This isn't even a c99 compiler, so declaring a variable other than at the start of a function should be illegal besides.
$ cat cmp.c
#include <stdio.h>
int main()
{
int i = -1;
unsigned j = 1;
printf("%d\n", i < j);
return 0;
}
$ gcc cmp.c
$ ./a.out
0
Hmm, at some point I probably knew this is how the comparison would turn out in C. I was expecting it to coerce both operands to the smallest common type that could represent both of them, (which would have been long), then compare. Instead, we get twos-complement funny business.
d@nny disc@ mc²
boosted
thinking of the namespace proposal for c, and, i wonder if, we couldn’t have namespaces done in the preprocessor, like:
/* lib.h */
#namespace lib lib_
void lib::foo(); /* declares lib_foo as a function name */
/* app.c */
#include <lib.h>
#using lib::foo
#using lib::foo as nya
#using lib as MyApi
int main(void) {
/* all of those would be pre-processed to lib_foo() */
lib::foo();
foo();
nya();
MyApi::foo();
}
works with macros, and identifiers, basically anywhere a #define would also work
and could be backwards compatible, e.g. if i were to use it in openrc:
/* rc.h */
#ifdef _HAS_NAMESPACE
#namespace rc rc_
#namespace RC RC_
#endif
now older c programs can still use rc_service_resolve, and newer ones can use rc::service_resolve (as well as #using directives)
including whole namespace, like #using lib, could work but it’d be a pain to implement i think, since the preprocessor would need to keep track of all lib_ it sees since #namespace was declared, and forward-replace them
but with or without whole-namespace-inclusion, this has really simple semantics and imo predictable errors, as namespacing conflicts can be reported the same way “redefinition” of macro names are
thinking of the namespace proposal for c, and, i wonder if, we couldn’t have namespaces done in the preprocessor, like:
/* lib.h */
#namespace lib lib_
void lib::foo(); /* declares lib_foo as a function name */
/* app.c */
#include <lib.h>
#using lib::foo
#using lib::foo as nya
#using lib as MyApi
int main(void) {
/* all of those would be pre-processed to lib_foo() */
lib::foo();
foo();
nya();
MyApi::foo();
}
works with macros, and identifiers, basically anywhere a #define would also work
and could be backwards compatible, e.g. if i were to use it in openrc:
/* rc.h */
#ifdef _HAS_NAMESPACE
#namespace rc rc_
#namespace RC RC_
#endif
now older c programs can still use rc_service_resolve, and newer ones can use rc::service_resolve (as well as #using directives)
including whole namespace, like #using lib, could work but it’d be a pain to implement i think, since the preprocessor would need to keep track of all lib_ it sees since #namespace was declared, and forward-replace them
but with or without whole-namespace-inclusion, this has really simple semantics and imo predictable errors, as namespacing conflicts can be reported the same way “redefinition” of macro names are
Ben Ramsey
boosted
The best static site generator is actually just one line of shell and available on any GNU system.
for filename in src/**/*.html; do; cpp -EwP "$filename" > "out/$filename"; done
This works with:
- snippets/shortcodes (e.g. #include "_header.html")
- file metadata (e.g. #define TITLE My Awesome Post)
- conditional inclusion (with #ifdef)
add -finput-charset=utf-8 and -fexec-charset=utf-8 if you'd like to use non-ASCII text.
Enjoy :P
The best static site generator is actually just one line of shell and available on any GNU system.
for filename in src/**/*.html; do; cpp -EwP "$filename" > "out/$filename"; done
This works with:
- snippets/shortcodes (e.g. #include "_header.html")
- file metadata (e.g. #define TITLE My Awesome Post)
- conditional inclusion (with #ifdef)
add -finput-charset=utf-8 and -fexec-charset=utf-8 if you'd like to use non-ASCII text.
Enjoy :P
To get this number, we count how many lines of code we have added up to a point in time, ignore how many we removed, and then divide with the number of lines of code still there.
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.
I have an (yet another) understanding issue with #nix X) , I think I've a functional (sic) understanding of what a flake.nix is (or at least, does / provides), but on the other hand I've no idea what "regular" nix files are used for / how they are different. I have the feeling that I can split my flake.nix file into several nix files + small flake.nix "importing" them (how?), and I'm also under the impression this is not their only use, nor their main one 😊 . If someone has pointers for me <3
@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.
#développement
J'aime beaucoup cette idée - qui se fait généralement cracher à la gueule par la vaste majorité des développeurs - qu'un logiciel puisse être "terminé".
https://sebsauvage.net/links/?nhyv5A
i had missed this file that actually implemented the regex engine https://github.com/python/cpython/blob/main/Modules/_sre/sre_lib.h that looks much more familiar. the case statement doing what it was made for
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
super underrated benefit of m4sh in autoconf is that you get to write @%:@include
most shells will be fine with #include in heredocs these days but i'm not gonna pass up an excuse for a quadrigraph
(Multiple posts because character limit)
Right, what I was getting at is that when I link to a stream/video, I'm usually already explaining what the video/stream is in the post text, and I'm just including the thumbnail for visual reasons (looks better than letting it auto embed a preview card from the link). So in that case I guess just using an alt text of "video thumbnail" is maybe enough so people know they aren't missing out on much? In this particular case the thumbnail just reads "I hacked macOS!" with a root shell and a "Whoooa" speech bubble, with me and Cyan on the left, so it's not really adding much information over the post text. It's the same thing with stream announcements, I always have some text going along with it that is mostly redundant with the image.
I was not expecting the emulator to crash so hard! It's actually a very simple HTML view. There's a few buttons along the top for operations, a main text window showing the exploit source, a table to the right listing every register and its value, and a two-element table under the text view listing the two virtual "micro sequence registers". Clicking the "Mode" button replaces the text view and two registers with two text columns, one with the source and the other with the firmware disassembly. The emulator itself is all text and layout, no graphics (though it does use color for highlighting and to convey changed values).
@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)
alcinnz
boosted
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/?