Search logs:

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present


http://bespin.org/~qz/search/?view=1&c=osdev2&y=23&m=1&d=26

Thursday, 26 January 2023

00:04:00 <c2a1> murderers live on irc
00:15:00 <moon-child> why do they call it oven when you of in the cold food of out hot eat the food?
00:17:00 <Mutabah> moon-child: what did my brain do to you?
00:19:00 <moon-child> every thing
00:32:00 <mrvn> it should be called pizza finisher
01:06:00 <kaichiuchi> someone explain this to me, like I'm 5
01:06:00 <kaichiuchi> why do I need to define _POSIX_C_SOURCE just because -std=c90?
01:07:00 <kaichiuchi> I cannot understand the reasoning behind that at all
01:08:00 <kaichiuchi> that... seems to be a POSIX requirement
01:08:00 <kaichiuchi> I don't get it
01:14:00 <mrvn> you don't. What gave you that idea?
01:14:00 <mrvn> why would you even want such an outdated C standard?
01:16:00 <kaichiuchi> "If you compile your programs using ‘gcc -ansi’, you get only the ISO C library features, unless you explicitly request additional features by defining one or more of the feature macros. See GNU CC Command Options in The GNU CC Manual, for more information about GCC options. "
01:16:00 <kaichiuchi> you need _POSIX_C_SOURCE to be defined to get any of the fancy POSIX calls
01:16:00 <kaichiuchi> and that gets defined if you use every goddamn -std flag other than c90/ansi
01:16:00 <klange> Feature test macros are a standard thing. The default configuration of GCC uses a non-standard standard that predefines _POSIX_C_SOURCE (*depending on the target platform)
01:17:00 <mrvn> yes. But a) you don't need those fancy functions and b) as you saw that problem exists without -std=c90
01:17:00 <kaichiuchi> i do need those fancy functions
01:17:00 <kaichiuchi> because I need clock_gettime
01:17:00 <kaichiuchi> can't use clock_gettime without it
01:18:00 <kaichiuchi> and maybe I want to use -ansi for this project
01:18:00 <klange> Actually, _POSIX_C_SOURCE should not be enabled by default in any configuration?
01:18:00 <mrvn> kaichiuchi: that's your choice but not a requirement.
01:19:00 <kaichiuchi> klange: i don't understand
01:19:00 <mrvn> and if you define it you need to define it to some date
01:19:00 <kaichiuchi> what you're telling me is everyone and their mother defines _POSIX_C_SOURCE even if -std=gnu17?
01:19:00 <klange> I believe there's a specific header somewhere that does it based on certain configurations.
01:20:00 <mrvn> kaichiuchi: gnu17 is new enough I believe to have all your fancy posix functions
01:20:00 <klange> But yes, you should not give a rats ass what -std is, you should define what you need.
01:21:00 <kaichiuchi> so you're saying I should just -D_POSIX_C_SOURCE=200809L and be done with it
01:21:00 <kaichiuchi> because that's what I'm doing now
01:21:00 <mrvn> kaichiuchi: that's a possibility. But what I'm saying is that you should use a modern C standard where you don't need that.
01:21:00 <mrvn> where possible
01:21:00 <kaichiuchi> can't
01:21:00 <klange> under the -std=gnu options, there are some default defines that will be picked up _by glibc's headers_ and enable _POSIX_C_SOURCE by default.
01:21:00 <kaichiuchi> vomit inducing
01:22:00 <kaichiuchi> you can't tell the compiler to enforce standards compliance *and* allow POSIX calls
01:22:00 <klange> https://man7.org/linux/man-pages/man7/feature_test_macros.7.html
01:22:00 <bslsk05> ​man7.org: feature_test_macros(7) - Linux manual page
01:22:00 <mrvn> kaichiuchi: gnu17 is standard + extras
01:22:00 <kaichiuchi> I get that part at least
01:23:00 <kaichiuchi> but it strikes me as madness that I need to jump through hoops just because I disabled the GNU mode
01:23:00 <kaichiuchi> .
01:23:00 <mrvn> kaichiuchi: what do you expect when you tell it top disable all the extras?
01:23:00 <klange> you have this backwards
01:23:00 <kaichiuchi> how the fuck is this an extra thing?
01:23:00 <kaichiuchi> this is "i'm on a system that has glibc please expose everything to me"
01:23:00 <klange> gcc/glibc has helpfully saved you the trouble of having to muck up your code with extra defines
01:24:00 <mrvn> kaichiuchi: -std=c90 says to disable all the modern and extra stuff
01:24:00 <klange> the normal behavior is you absolutely need them full stop
01:24:00 <kaichiuchi> holy crap, so what I'm hearing is I absolutely need to enable C_EXTENSIONS for this in CMake, or otherwise pass a bunch of extra defines
01:24:00 <klange> POSIX says if you want those functions you need to define _POSIX_C_SOURCE to the appropriate value to get them.
01:25:00 <klange> And if your complaint is POSIX is insane, well, welcome to the club.
01:25:00 <klange> We almost called this channel #posix-is-insane when migrating to Libera.
01:26:00 <kaichiuchi> to the worst, get_target_property in CMake is pure garbage
01:26:00 <mrvn> kaichiuchi: I would just go with _GNU_SOURCE. That's pretty much a catch all.
01:26:00 <kaichiuchi> ah
01:26:00 <kaichiuchi> okay
01:26:00 <kaichiuchi> that makes me a little more calm
01:26:00 <mrvn> kaichiuchi: https://man7.org/linux/man-pages/man7/feature_test_macros.7.html
01:26:00 <klange> _DEFAULT_SOURCE may be fine as well.
01:26:00 <mrvn> kaichiuchi: it explains all the defines you can do and what their values mean.
01:27:00 <klange> that's "whatever the platform is supposed to have by default, just give me that, none of this _POSIX_C or _GNU or _BSD bullshit I have to deal with otherwise"
01:27:00 <klange> I linked that already!
01:27:00 <kaichiuchi> klange: that's PERFECT
01:29:00 <mrvn> klange: It's best to remmeber that POSIX is documentation of existing insanity. :)
01:29:00 <klange> half that, half "the existing insanity is too insane, so here's new insanity you can strive for to replace it"
01:30:00 <klange> (there's plenty of stuff in POSIX that was designed just for the standard and _then_ implemented)
05:58:00 <Jari--_> morning all
07:22:00 <gorgonical> I just played with the ggtags emacs frontend to global and it's really good
07:22:00 <gorgonical> I have been using cscope for years
07:28:00 <gorgonical> is there a better way to associate sdcards with /dev/* identifiers? I get fear everytime I write images to sdcards because I'm worried Linux has re-assigned the drive letters without telling me and I'm about to nuke something
07:29:00 <gorgonical> I compulsively check dmesg to see what the sdcard registers as
07:58:00 <ddevault> I just do dmesg | tail when I hotplug a storage device, gorgonical
08:02:00 <gorgonical> Yeah
08:03:00 <gorgonical> I've tried some kind of rules for fstab but they aren't as reliable as I'd like
08:03:00 <ddevault> maybe use UUIDs
08:03:00 <ddevault> /dev/disk/by-uuid if you have (e)udev going
08:05:00 <klange> Depending on your configuration, there's also alias that go by hardware in 'by-path'.
08:06:00 <klange> so you can see like pci-xxxx:xx:xx.x-usb-x:x:x.x-scsi-x:x:x:x or wahtever.
08:08:00 <kazinsal_> we had to deal with a weird hypervisor/LVM issue recently that involved SCSI LUNs changing out from underneath us, and the solution involved an extremely early bootup script before LVM started to parse /dev/disk/by-uuid and change the LVM metadata cache
08:08:00 <kazinsal_> fucking acropolis
16:52:00 <mrvn> kazinsal_: I find anything but disks UUID is fragile.
16:53:00 <mrvn> if the NIC breaks all your by-path can change
17:03:00 <clever> mrvn: similar for NIC names, i find mapping eth0 to a given mac far more reliable
17:03:00 <clever> my nas is nasty, and the "predictable" inteface names change if i add a sas card
17:08:00 <ghostbuster> nasty nas would be a good rapper name
18:26:00 <raggi> i map my network devices by mac to meaningful names, so on my router i have `internet` and `lan` and `backup` and so on, and no 0 suffixes because i can always add a suffix if i ever add a duplicate of something
20:37:00 <ddevault> arguing with a dimwit in a local hackerspace channel over how "disruptive" ChatGPT will be
20:37:00 <ddevault> told him to pose it a problem I recently dealt with and see how it fares
20:37:00 <ddevault> you may find the results amusing
20:37:00 <ddevault> https://imgur.com/a/TcPV70T https://imgur.com/ao1cL7o https://imgur.com/slvQddw
20:37:00 <bslsk05> ​imgur.com: Imgur: The magic of the Internet
20:37:00 <bslsk05> ​imgur.com: Imgur: The magic of the Internet
20:37:00 <bslsk05> ​imgur.com: Imgur: The magic of the Internet
21:20:00 <heat> lol
21:22:00 <Ermine> ddevault: I was once advised to post direct links to .jpgs
21:22:00 <zid`> it's a bit fucky for chatgpt cus ther's no permalink
21:22:00 <zid`> but you should post real links not gallery links
21:23:00 <zid`> at least a jpeg is a jpeg, and not a fucking website running 20MB of javascript, with a jpeg on it
21:23:00 <zid`> remember imageshack.us? *shudders*
21:25:00 <FireFly> tbh imageshack was less bad than imgur is these days :p
21:25:00 <FireFly> or at least they seem equally bad
21:29:00 <Bitweasil> I still don't know how to get imgur to work with Javascript blocking. :/
21:30:00 <Bitweasil> In any case... that's about right.
21:30:00 <Bitweasil> You have to know the correct answer and how to do things to get ChatGPT to generate something useful.
21:30:00 <Bitweasil> If you don't know the space, you can't tell the difference between a right answer and a confidently wrong answer.
21:31:00 <FireFly> for links to a single image, you can rewrite e.g. https://imgur.com/ao1cL7o to https://i.imgur.com/ao1cL7o.jpg
21:32:00 <FireFly> (even though the latter was a png it seems, lol, either way it works)
21:33:00 <Bitweasil> Oh, neat, that's good to know. Thanks!
21:37:00 <kof123> that's good, it means the art has advanced over the centuries. "pray, if i put the wrong figures in, will the right answer come out?" <face palm> "i am unable to comprehend what would lead to this line of reasoning" </face palm> (babbage paraphrase)
21:51:00 <x8dcc> hello, I added and IDT and keyboard interrupts to my kernel, and now I can read keys when they are pressed. I wanted to add a simple getchar function but I am not sure what's the best way. Any ideas or resources?
21:51:00 <geist> yay. well generally the simple idea is build some sort of queue of N chars
21:52:00 <x8dcc> I can share the repo link in case anyone is interested, but for now it only displays the chars being received
21:52:00 <zid`> yea make it read a dude from the buffer
21:52:00 <geist> and have teh interrupt handler put new keys in the queue, and getkey reads out of the queue
21:52:00 <zid`> the 'edge' case is empty buffer, where you 'wait'
21:52:00 <geist> obviously you can run out of space, etc, but functionally that's what happens when yo uhave a device that you can't apply back pressure to (ie, can't stop the user from typing)
21:52:00 <zid`> if(empty()) hlt(); or whatever if you've not got multiple tasks yet else yield()
21:52:00 <x8dcc> well I thought about that, but I would need 2 buffers, right? fill the getchar buffer when the user presses return
21:53:00 <zid`> getchar doesn't care about \n
21:53:00 <zid`> if you're used to thinking it does, that's because you're playing around in line buffered terminals
21:54:00 <x8dcc> what I mean is that when a program calls getchar, the program waits for input until the user sends return
21:54:00 <zid`> that's get..string
21:54:00 <x8dcc> the program doesnt wait, but you know what I mean
21:54:00 <zid`> line
21:54:00 <geist> or you can call it something else (keyboard_get_char()) or something and layer some sort of buffering on top of it
21:54:00 <geist> but the gist is the lowest level is keyboard puts keys in a queue, something else reads from it
21:54:00 <geist> if you want to add more layers, that's fine, but the basic mechanism is the same
21:54:00 <x8dcc> I dont mean that, zid`
21:55:00 <x8dcc> when you call getchar from a c program, and type from the terminal, the program doesnt receive the first key press of the user, it receives the first char that the user typed once the user ends the line with return
21:56:00 <x8dcc> afaik thats not related to the program but to the terminal or something like that
21:56:00 <geist> yeah, but that's because of higher level line buffering. you'll eventually want to do that
21:56:00 <zid`> yes exactly like I mentioned
21:56:00 <zid`> getchar() does't care about \n, if you're used to experiencing it as though it does, it's because you're using line buffered terminals
21:56:00 <geist> but i'd take it one step at a time, the first step is to queue the keyboard events
21:57:00 <x8dcc> hmmm I see
21:57:00 <x8dcc> I might be getting ahead of myself
21:58:00 <x8dcc> I just wanted to add it this way for consistency, so I can use the getchar I am used to
21:58:00 <geist> that line buffering stuff (and line editing capability) is the terminal emulation ish layer. it's complicated, so a bit hard to describe in one line, but it's basically 'user space'
21:58:00 <heat> or kernel space in unix
21:58:00 <geist> yeah, for right now that's a lot more work than you probably want, so you'll most likely have to deal with not having any of that line buffering, but you can at least buffer the kernel
21:58:00 <x8dcc> I didn't want to add line editing, but I see what you mean
21:58:00 <heat> praise be the TTY
21:58:00 <geist> heat: yeah that's why i put it in quotes, so as not to confuse. idea is it's 'user space' in the sense that it's in the service of user programs
21:59:00 <x8dcc> well I also made other functions for getting held keys, disable character output, etc. so I am pretty happy for now
21:59:00 <heat> cool
21:59:00 <geist> x8dcc: yeah basically think of line editing (handing backspaces, etc) as part of the same mechanism that usually the tty/pty/etc subsystems handles
21:59:00 <x8dcc> I will try to add the simple queue system and then I will worry about line buffering
21:59:00 <x8dcc> which by the way I didn't know it was its own concept, so thank you
21:59:00 <geist> x8dcc: if you dont want to confuse, i'd start by calling it not getchar() like, keyboard_getc() and then you can build your getchar() queue on top of it later
22:00:00 <x8dcc> yeah, I already wanted to do that
22:00:00 <x8dcc> It's how I did my malloc and free
22:00:00 <x8dcc> just simple wrappers for the kernel stuff
22:00:00 <zid`> super distantly eventually mega not-now you will eventually convert it to a file
22:00:00 <x8dcc> what do you mean?
22:00:00 <zid`> getchar is a macro for fgetc(stdin)
22:00:00 <x8dcc> oh yeah, add stdin
22:01:00 <x8dcc> I am scared of that, obviously
22:01:00 <geist> sounds good, yeah thats a good way to think. a common problem folks bump into when they first get started is trying to accomplish user sace level things they're used to in one layer
22:01:00 <heat> getchar is not a macro
22:01:00 <zid`> Description
22:01:00 <zid`> 2
22:01:00 <zid`> The getchar function is equivalent to getc with the argument stdin.
22:01:00 <x8dcc> geist: yeah, although I try to not get ahead of myself, I also want to add a lot of stuff :)
22:01:00 <heat> that is not a macro
22:01:00 <zid`> yes it is
22:01:00 <heat> it is not
22:01:00 <zid`> not a literal C macro, but it's still a macro
22:01:00 <heat> it is a function
22:02:00 <heat> you can't legally implement functions as macros
22:02:00 <zid`> okay?
22:02:00 <zid`> now read what I just said
22:02:00 <heat> ok
22:02:00 <geist> it's kinda an important distinction, especialyl when talkig around folks that want to implement it
22:02:00 <x8dcc> heat: can you explain that? what do you mean by implementing functions as macros?
22:02:00 <heat> x8dcc, #define getchar() fgetc(stdin) is illegal
22:02:00 <zid`> C has macros, you can make function like macros
22:02:00 <x8dcc> I know about C macros
22:02:00 <heat> because then e.g &getchar makes no sense and errors out
22:03:00 <x8dcc> but I didn't know what heat just said was ilegal
22:03:00 <x8dcc> oh, I didn't think about that...
22:03:00 <zid`> half the floating point functions *are* macros though afaik
22:03:00 <x8dcc> I probably used that define method for simple wrappers in the past and I didn't think about that
22:03:00 <geist> in general it's illegal, because if it's a function someone may want a function pointer to it, but there are a few exceptions where X is traditionally implemented as a macro, and so can be implemented that way
22:03:00 <x8dcc> not for this os project, tho
22:03:00 <zid`> and afaik it's legal but you *also* have to provide a function
22:04:00 <x8dcc> geist: I see now, thanks
22:04:00 <geist> i forgot the obvious example. is it printf? puts? there was one of them that *was* implemented as a macro back in the day, and thus tends to get mentioned in man pages as 'can be implemented as macro si not valid to take an address of'
22:04:00 <zid`> and you can suppress with (f)
22:04:00 <x8dcc> I wanted to add a simple piano program that reads key states to play with the pc speaker frequencies :^)
22:04:00 <zid`> &(f) gives you the function, f gives you the macro
22:04:00 <x8dcc> the real osdev spirit if you ask me
22:05:00 <zid`> so yes, both is a macro, and it's also legal for it to be a macro :P
22:05:00 <heat> does qemu even emulate the pc speaker?
22:05:00 <zid`> in C terms
22:05:00 <x8dcc> yes, heat
22:05:00 <x8dcc> you might have to do some tweaking if you don't use pulseaudio, but it's just a line in my makefile
22:06:00 <zid`> spec even talks about doing #undef abs and stuff
22:06:00 <zid`> and whether function-like macros are allowed to different in sequence pointing wrt real functions
22:06:00 <x8dcc> heat: https://github.com/fs-os/fs-os/blob/main/Makefile#L16-L17
22:06:00 <bslsk05> ​github.com: fs-os/Makefile at main · fs-os/fs-os · GitHub
22:07:00 <zid`> https://pbs.twimg.com/media/FnV6RkQWYAEKsUx.png my link
22:08:00 <x8dcc> I don't get it
22:08:00 <zid`> It's pretty self explanatory
22:08:00 <x8dcc> heat: I also have a sexy IBM ThinkPad X31 that runs my kernel pretty nice and has a soft and sweet pc speaker
22:08:00 <heat> cool cool
22:09:00 <heat> void free(void* ptr) __attribute__((nonnull));
22:10:00 <heat> ❌
22:10:00 <zid`> why
22:10:00 <x8dcc> I cant see the last char
22:10:00 <zid`> me either, it's a big red cross
22:10:00 <heat> you need a better irc client or font
22:10:00 <x8dcc> and I don't know what you mean, is something wrong?
22:11:00 <heat> yes
22:11:00 <zid`> yes
22:11:00 <heat> free(NULL) is entirely defined as a no-op
22:11:00 <zid`> If ptr is a null pointer, no action occurs.
22:11:00 <sortie> ����, ����?
22:11:00 <x8dcc> sortie: totally agree with the squares
22:11:00 <zid`> those are egyptian penises or something?
22:11:00 <zid`> I get weird diamonds with question marks inside
22:11:00 <heat> morn𓂺ng
22:11:00 <zid`> I think it just fails to even decode
22:11:00 <x8dcc> zid`: I knew that, I just thought it was better to not allow null pointers
22:12:00 <zid`> but the spec says they are allowed
22:12:00 <heat> that's silly
22:12:00 <x8dcc> if you say its better to allow it, I trust you all, idk
22:12:00 <zid`> Violating the spec means you wrote some other language, not C
22:12:00 <heat> instead of doing free(ptr), you now do if (ptr) free(ptr)
22:13:00 <heat> we keep winnin
22:13:00 <x8dcc> I don't get it
22:13:00 <zid`> I assume it'd be very hard to actually break
22:13:00 <zid`> Normally that check would explode because of UB optimization stuff, but it.. doesn't cause UB
22:13:00 <x8dcc> isn't that attribute something related to compilation?
22:13:00 <moon-child> I'm more irked by the placement of the *
22:13:00 <zid`> same tbh
22:13:00 <x8dcc> moon-child: I ain't changing that
22:13:00 <moon-child> null free ub, null free well defined, who cares?
22:14:00 <heat> void abort(const char* func, unsigned int line, const char* fmt, ...); "/* abort: panic" <-- so you mean void panic(const char *func, unsinged int line, ...)
22:14:00 <heat> x8dcc, do you not know what nonnull does?
22:14:00 <x8dcc> I thought so, now I think I was wrong
22:14:00 <heat> what do you think it does
22:14:00 <zid`> Informs the compiler it will never be null, so it can make overly optimistic guesses about whether if(p) paths can ever be false or not
22:14:00 <x8dcc> afaik it produced a compile time warning when calling that func with null
22:14:00 <heat> it does
22:15:00 <x8dcc> but does it change anything else?
22:15:00 <heat> such as "void *ptr = NULL; free(ptr)"
22:15:00 <heat> yes. it's UB to call that function with a null arg, ubsan will choke on it, your if (!ptr) will get optimized out
22:16:00 <x8dcc> hmm, I see
22:16:00 <x8dcc> I don't really understand what you said about my abort function, why would you remove the fmt arg?
22:17:00 <heat> https://godbolt.org/z/h1f39zefG
22:17:00 <bslsk05> ​godbolt.org: Compiler Explorer
22:17:00 <heat> x8dcc, that was not the point
22:17:00 <zid`> He un-singed it too btw, so it's recovered from its nasty burns
22:18:00 <geist> also realloc can take a null
22:18:00 <heat> the point is that abort is void abort(void); and your thing is a panic function and not abort
22:18:00 <geist> suggestion: when doing low level bringup and starting to implement things that are C standard lib, either follow them to a T, or use a different name. mostly because compilers like to do builtin stuff
22:19:00 <geist> which is basically what heat is saying
22:19:00 <x8dcc> yeah, I don't know why I forgot about that
22:19:00 <geist> i prefer, panic(str, ...) personally
22:19:00 <x8dcc> I forgot that abort is it's own thing outside my os
22:20:00 <x8dcc> I should add a separate panic, I agree
22:20:00 <geist> one that bit me early on, for example, was puts() and printf()
22:20:00 <x8dcc> I know my printf probably sucks but please don't bully me
22:20:00 <geist> since compilers know about puts they like to replace printf calls with puts if what your printing is simple, etc
22:21:00 <geist> so then you find out that puts() sticks a \n at the end, because.
22:21:00 <heat> yeah, all these names are reserved for the impl and the toolchain can safely assume its behavior
22:21:00 <geist> obviously you can (and maybe should) compile with -fno-builtins, but then that can leave some performance on the table
22:21:00 <heat> -fno-builtin* btw
22:21:00 <heat> I disagree. -fbuiltin is universally good
22:22:00 <gog> explain
22:22:00 <heat> else the compiler can't even assume memset, memcpy, memmove are sane
22:22:00 <gog> o
22:22:00 <x8dcc> I feel like I am being judged by the old shamans of the tribe
22:22:00 <geist> agreed. my point was when you first get started you might want to do -fno-builtin, but then probably want to eventually make sure your stuff is safe
22:22:00 <gog> but then it wasn't invented here
22:22:00 <x8dcc> isn't puts supposed to add a newline? :((
22:23:00 <geist> it does, so for example compiler can replace printf("what what\n"); with puts("what what")
22:23:00 <x8dcc> oh, okay okay
22:23:00 <heat> also fwiw memset, memcpy, memmove and some other are explicitly required to be sane and with standard semantics by gcc/clang
22:23:00 <acidx> it saves a byte in the .rodata section, look at that!
22:23:00 <geist> a winnar is you!
22:23:00 <geist> everyone gets a winrar
22:23:00 <x8dcc> heat: I don't know what you are saying but I am sorry D:
22:24:00 <heat> acidx, the big win is that you avoid going through printf machinery
22:24:00 <acidx> heat: I know :)
22:24:00 <geist> x8dcc: you'll want to implement at least unoptimzed memset/memcpy/memove routines fairly soon, but when you do they're super implrtant you get absolutely correct
22:25:00 <geist> including things like the memcpy/memmove overlap semantics, etc
22:25:00 <heat> oooh TIL __builtin_clear_padding
22:25:00 <acidx> implement memmove() correctly and alias memcpy() to it
22:25:00 <acidx> worry about perf later
22:25:00 <geist> right, that's an example of implementing it correctly
22:26:00 <heat> x8dcc, " GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp. Finally, if __builtin_trap is used, and the target does not implement the trap pattern, then GCC emits a call to abort. "
22:26:00 <x8dcc> mand I just wanted a piano this is depressing me slowly lol
22:26:00 <x8dcc> heat: thanks I will do my best
22:26:00 <gog> there are short public domain implementations in the libgcc source
22:26:00 <geist> x8dcc: aww, no we're saying this cause we're excited for you
22:27:00 <geist> seems like you're making good progress so it's exciting to see someone else join the club
22:27:00 <x8dcc> I know, I was *kinda* joking
22:27:00 <x8dcc> I rather know my mistakes, obviously
22:28:00 <kof123> " and type from the terminal, the program doesnt receive the first key press of the user" yes, this buffering is explained in a unix manual as a gnome, deep in the system, takes your characters and stores them in a safe place
22:29:00 <x8dcc> yeah, is what I have been thinkng about, but I didn't exactly know how to implement this line buffer system
22:29:00 <x8dcc> as geist said, I need to focus on doing whats important first
22:29:00 <x8dcc> (which is obviously the pc speaker piano)
22:30:00 <clever> https://man7.org/linux/man-pages/man3/setbuf.3.html
22:30:00 <bslsk05> ​man7.org: setbuf(3) - Linux manual page
22:30:00 * geist banishes setbuf
22:30:00 <clever> x8dcc: at least on POSIX systems, the setbuf() call configures how buffering happens on a FILE*
22:30:00 <geist> do yo uneed line buffers?
22:30:00 <x8dcc> clever: oh that's interesting, I didn't even know that existed
22:30:00 <clever> i think thats implemented within glibc
22:30:00 <zid`> setvbuf null blah blah
22:31:00 <clever> where it will read() too much data from the kernel, into a large buffer
22:31:00 <clever> and then feed lines back to the program
22:31:00 <zid`> the hard part is tricking isatty
22:31:00 <clever> yeah, tty's have their own kernel-side buffering and line editing
22:31:00 <clever> and depending on the smart terminal (emulator), it might be line-editing on the other end of the uart
22:32:00 <clever> but a lot of things (readline) just turn that off, to have better control
22:33:00 <x8dcc> very interesting
22:33:00 <heat> it is interesting
22:33:00 <heat> but it alo sucks
22:34:00 <heat> also*
22:34:00 <aoei> ttys are cursed
22:34:00 <clever> i dont think arrow keys work on the kernel tty buffering
22:34:00 <clever> but it echos the arrows back to the client, so it may look like it worked
22:34:00 <heat> implementing tty and vterm semantics is the least fun i've had doing this shit
22:34:00 <heat> clever, arrow keys just output cursor up/down/left/right
22:34:00 <x8dcc> yeah, I thought arrow keys and shifting the buffer and all that would be a mess
22:34:00 <x8dcc> well at least I don't think thats so important for me atm
22:35:00 <clever> i think the kernel buffering only supports backspace
22:35:00 <clever> and when you hit enter, the final line is send to userland, as one read()
22:35:00 <heat> yes
22:35:00 <clever> but for readline to implement something better, it turns that buffering off, so read() returns every single key
22:36:00 <heat> x8dcc, anyway we're being strict because kernel development requires strictness and you don't seem clueless
22:36:00 <heat> if you were clueless we wouldn't blabber about "hurr durr must not be macro"
22:36:00 <x8dcc> I always wondered how ncurses stuff worked for example, like raw() and noecho(), guess its something like clever just said
22:37:00 <x8dcc> heat: I understand, thank you
22:37:00 <clever> x8dcc: run `stty -a`, that will print every flag you can set on a tty, and the current settings
22:37:00 <heat> geist, oh yeah btw have you folks tried to get something like user pointer tagging with the compiler itself?
22:37:00 <clever> ncurses, readline, modify a lot of those flags
22:37:00 <zid`> WHAT why is there a mosquito in here, it's been in the negatives all week and it's winter
22:37:00 <zid`> where the hell did it hatch from
22:38:00 <clever> and a common problem, is for them to not be restored if you -9 vim
22:38:00 <heat> geist, like linux's "void foo(char * __user buf)"
22:38:00 <corecode> hi
22:38:00 <clever> which leaves the terminal in a weird state
22:38:00 <heat> corecode, hello
22:38:00 <x8dcc> clever: didn't know about `stty -a` :o
22:38:00 <clever> c2d vm # cat /home/clever/builds/temp_daemon/c2d_fix
22:38:00 <clever> stty < /dev/ttyUSB0 raw -echo
22:39:00 <clever> x8dcc: back when i wrote my thermostat stuff, i never figured out the right syscalls, and wound up just using this to fix things
22:39:00 <heat> I know there's a standard GNU attribute noderef which /helps/, but you can still implicitly convert the pointers I think. linux's sparse adds named address spaces to stop this
22:39:00 <x8dcc> clever: yeah, killing a ncurses program without endwin()... all makes sense now
22:39:00 <corecode> every now and then i'm looking for scripting language implementations for embedding into small microcontrollers, and it's always disappointing
22:39:00 <clever> if i was to improve things more, i would just strace this cmd, and replicate what its doing
22:39:00 <heat> corecode, how small?
22:39:00 <corecode> i think it's always down to FORTH
22:40:00 <heat> lua is pretty small
22:40:00 <corecode> lua claimed 256KB flash requirement
22:40:00 <clever> zid`: i had a fly problem a few months ago, tracked it down to some wood rotting in the wall, it looked like a compost bin pouring out of the baseboard
22:40:00 <corecode> which seems outrageous
22:40:00 <clever> thats a heck of a lot of water damage!
22:40:00 <corecode> clever: yuck :)
22:42:00 <heat> oh wait noderef just works
22:42:00 <heat> sadly clang only
22:42:00 <heat> <source>:12:12: warning: casting to dereferenceable pointer removes 'noderef' attribute [-Wnoderef]
22:48:00 <zid`> clever: not american so my house is made entirely of rocks
22:48:00 <zid`> rocks, with rock floors, rock walls, rock furniture, rock carpets
22:49:00 <clever> zid`: this rotten wall was in the basement, so there is concrete behind it, but then insulation and studs over the concrete
22:49:00 <zid`> no basements either, too much rock in the way
22:49:00 <clever> just carve your basement into the rock
22:49:00 <zid`> also no studs, too much rock
22:49:00 <clever> your already making everything out of rock :P
22:50:00 <heat> isn't that just a cave
22:50:00 <zid`> that's where you live isn't it heat
22:50:00 <zid`> caves carved into rock, sand everywhere
22:51:00 <heat> absolutely
22:51:00 <heat> my cave is filled with footballs
22:51:00 <heat> as is tradition
22:51:00 <zid`> I think the only wood in my house might actually be the door frames
22:52:00 <zid`> and pencils
22:57:00 <zid`> https://cdn.discordapp.com/attachments/417023075348119556/1068303748381806672/image.png What portugal looks like in my mind's eye
22:58:00 <zid`> complete with british tourist
23:27:00 <gog> portalgull
23:28:00 <zid`> pls don't give the gulls portal guns
23:52:00 <gog> too late
23:53:00 <zid`> This sounds like a disaster for anybody's ability to eat near the ocean
23:54:00 <gog> why you'd want to do anything sanitary in sight of the ocean is beyond me
23:55:00 <zid`> I've actually touched two different seas, no oceans though
23:56:00 <zid`> or rather, no ocean that wasn't a sea
23:56:00 <zid`> that term is weird
23:56:00 <zid`> sea is just "bits of ocean we named"
23:58:00 <gog> sometimes there's demarcation
23:58:00 <zid`> cus fuck marc
23:58:00 <gog> like it falls between particular land masses and is larger than a bay or a strait or smth
23:58:00 <gog> or a sound
23:58:00 <gog> love me a sound
23:59:00 <zid`> I like an atol
23:59:00 <zid`> l
23:59:00 <gog> i prefer an archipeligo
23:59:00 <zid`> how about an oxbow
23:59:00 <gog> idk what that is