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=24&m=4&d=16
02:14:00 <kof673> that order-pp implies that pretty much (at least when it was written) there were little to no C preprocessors that followed c89, let alone c99 ...
02:16:00 <kof673> *that strictly met the requirements
02:16:00 <kof673> if i ever get there, it will just be #pragma sections, i made no effort to use macros/etc.
02:18:00 <kof673> so i am not in their league, but i went 180 route...
02:19:00 <kof673> (i.e. on how much preprocessor to use, anyways)
02:28:00 <kof673> i assumed i would just write a shell/python/ruby/whatever script, and later (better) a c89 program to "preprocess" all the pragma stuff, totally separately from the normal preprocessor
04:42:00 <geist> OnSugma(balls::bofa());
06:38:00 <geist> interesting, grabbed a newer copy of the riscv isa spec and it's definitely looking at lot better
06:38:00 <geist> it seems to be formatted nicer and has a lot more infor than the 2019 one (200 pages to about 550)
06:41:00 <Mondenkind> still an order of magnitude below x86 and arm
06:41:00 <Mondenkind> i'm sure someday it'll grow up into a real isa
06:45:00 <Mutabah> geist: Still in Computer Modern?
10:38:00 <leg7> Are ISRs trivial enought that I can write them in NASM?
10:39:00 <leg7> I would like to make the whole thing in nasm rather than having an extra layer of indirection just to printf an error
10:43:00 <gog> ISRs are small enough that it's possible to write a direct-calling one for every interrupt if you wished
10:44:00 <gog> https://github.com/adachristine/sophia/blob/main/kc/core/cpu/exceptions.S you can easily write a macro that lets you call an arbitrary function
10:44:00 <bslsk05> github.com: sophia/kc/core/cpu/exceptions.S at main · adachristine/sophia · GitHub
10:48:00 <zid> They're just "Save interrupt number, call C function via the ABI"
10:49:00 <zid> the way heat's was was just push 0; jmp generic; push 1; jmp generic; push 2; jump generic: push 3; ... generic: push all regs; call c function; pop all regs; ret
10:49:00 <zid> roughly
10:50:00 <zid> and each IDT entry points to each push
10:54:00 <leg7> yeah but I would like to not have to switch on the interrupt number or have a lookup table
10:54:00 <leg7> I would rather the IDT point directly to the correct function that does it's job
10:54:00 <leg7> I don't mind writing assembly if the ISRs are simple
10:55:00 <leg7> but If I'm going to need to make data structures and stuff I would rather go with the less efficient C solution
10:55:00 <leg7> but since I don't know what I'm getting into idk how complex the ISRs will be
10:58:00 <zid> that is a correct function that does its job :P
10:58:00 <zid> update your idt with more relevent handlers if and when they get registered by various things
10:58:00 <zid> this is so you can print "Unhandled interrupt 47"
11:00:00 <leg7> I just want to know how complex they can get
11:00:00 <zid> it's your OS
11:00:00 <zid> they're as complex as you write them to be
11:01:00 <zid> In a random "interrupt driven embedded controller" or whatever, likely they do literall everything
11:01:00 <zid> in a desktop OS they're more likely to just add a small entry to a random queue
11:02:00 <zid> and the actual 'work' gets done later
11:02:00 <leg7> ok ty
11:53:00 <heat> leg7, you probably want a lookup table
11:53:00 <heat> hth
11:55:00 <zid> The problem with not having a generic intro is you have to have an asm stub before all your handlers *somehow*
11:55:00 <zid> do you wanna include an inline asm function dec in every .c file that takes interrupts? Probably not
11:56:00 <zid> void __attribute__((naked)) scsi_irq() { asm("push 15; push r14; ..."); }
11:57:00 <GeDaMo> http://www.makelinux.net/ldd3/chp-10-sect-4.shtml
11:57:00 <bslsk05> www.makelinux.net: 10.4. Top and Bottom Halves
12:04:00 <gog> versatile halves
12:04:00 * gog disapper
12:14:00 <mjg> yo
12:14:00 <mjg> watap
12:14:00 <mjg> is this a friendly space
12:21:00 <gog> no
12:21:00 <mjg> anyone with basic rust clue? serious question
12:22:00 <nikolapdp> how basic are we talking about
12:22:00 <zid> gog level
12:22:00 <mjg> i have chatgpt generated func with the following signature: fn compute_md5_chunked<P: AsRef<Path>>(path: P) -> io::Result<String>
12:22:00 <mjg> now i want to printf the path for debug purposes
12:23:00 <mjg> both println!("{}", path.to_string()); and dbg!(path); fail
12:23:00 <mjg> 24 | println!("{}", path.to_string()); | ^^^^^^^^^ method cannot be called on `P` due to unsatisfied trait bounds
12:23:00 <mjg> from poking around looks like taking path with AsRef is fine
12:23:00 <mjg> so what i'm doing wrong here
12:24:00 <mjg> shit
12:24:00 <mjg> it pasted wrong, lemme try again
12:24:00 <mjg> println! and dbg! fail, here is an example:
12:24:00 <mjg> 24 | println!("{}", path.to_string()); | ^^^^^^^^^ method cannot be called on `P` due to unsatisfied trait bounds
12:24:00 <mjg> 25 | dbg!(path); | ^^^^^^^^^^ `P` cannot be formatted using `{:?}` because it doesn't implement `Debug`
12:25:00 <mjg> i would like to think dumping the path, either full obj or just the name itself, should not require fucking with signatures
12:25:00 <mjg> the path thing is std::path::Path
12:25:00 <nikolapdp> try dbg!(path.as_ref());
12:26:00 <mjg> that worked, thanks
12:26:00 <mjg> albeit then i have anotgher question
12:27:00 <mjg> https://dpaste.com/3PWS9JGXD here is the full routine
12:27:00 <bslsk05> dpaste.com <no title>
12:27:00 <mjg> i had to replace File::open(path)?; with File::open(&path)?;
12:27:00 <mjg> is there a way to avoid that?
12:27:00 <nikolapdp> i don't think so
12:27:00 <nikolapdp> i am by no means an expert though
12:27:00 <mjg> is rolling with &path the standard way?
12:28:00 <nikolapdp> i think so, in the case of AsRef
12:31:00 <nikolapdp> wait i just tried without the reference and it worked fine
12:32:00 <mjg> you mean without & or as_ref
12:33:00 <mjg> i'm running rustc 1.79.0-nightly (0d8b3346a 2024-04-14)
12:33:00 <nikolapdp> without &
12:33:00 <mjg> also i know about rust as much as typical webdev knows about programming in general
12:33:00 <mjg> lemme paste the full thing
12:34:00 <mjg> https://dpaste.com/3PWS9JGXD
12:34:00 <mjg> this fails with the borrow checker thing
12:35:00 <nikolapdp> you can put the refference/borrow into the argument type
12:35:00 <nikolapdp> so &P instead of P
12:35:00 <mjg> is that how it's done idiomatically?
12:35:00 <nikolapdp> i mean it makes sense to me but i definitely don't know idiomatic rust
12:36:00 <mjg> i checked fs::File open
12:36:00 <mjg> when messing with this previously
12:36:00 <mjg> pub fn open<P: AsRef<Path>>(path: P) -> Result<File>
12:36:00 <mjg> it takes the path the same way "my" func does
12:36:00 <mjg> so i would expect this is the right way
12:37:00 <nikolapdp> well you have to make a borrow somewhere so it's your choice
12:37:00 <nikolapdp> if you want to follow File::open, then you need to do &path
12:39:00 <mjg> this may be may lack of clue in the area, but so far the lang is an absolute chore to deal with
12:39:00 <nikolapdp> oh it absolutely is
12:40:00 <nikolapdp> it's a constant fight with the borrow checker and the type system, usually for simplest of things
12:40:00 <mjg> i know it is for beginners, i don't know past that
12:40:00 <nikolapdp> i guess you learn the most common annoyances and how to deal with them
12:40:00 <nikolapdp> but it's not always simple
12:40:00 <nikolapdp> because you basically have to prove to the compiler that you know what you're doing
12:40:00 <mjg> i know of one book which gave up on some of it and literally recommended .clone() :>
12:41:00 <mjg> to dodge the problem
12:41:00 <nikolapdp> yeah that's a thing too lol
12:41:00 <mjg> ye i expect most people .clone their way out of trouble
12:42:00 <nikolapdp> at that point, what was even the point of using rust
12:42:00 <mjg> well you still don't have gc
12:42:00 <mjg> so it may be a benefit
12:43:00 <nikolapdp> you don't, but you have a lot of unnecessary mallocs and memcpys just because the language is a massive chore
12:43:00 <mjg> i totally agree with that aspect
12:43:00 <mjg> but still, insane runtimes like python probably do that even more
12:43:00 <mjg> :]
12:43:00 <mjg> even ignoring gc
12:44:00 <zid> I love the idea of a language that's like rust but isn't it
12:44:00 <zid> Like, C that won't compile if the analyzer can't prove there's no UB
12:44:00 <zid> just toss in some checked_adds and stuff done
12:44:00 <nikolapdp> so you want a ub-less c, not rust
12:44:00 <zid> yea that's what people assumed rust was *going* to be
12:45:00 <zid> but it's just turning into annoying python
12:45:00 <zid> the longer it exists
12:45:00 <nikolapdp> rust is definitely not a c killer, no matter what the hype says
12:45:00 <zid> Yea, that's why people assumed that I think, the early hype was 'C killer' idd
12:45:00 <zid> but now it's like "I couldn't use this ANYWHERE I currently use C"
12:46:00 <nikolapdp> basically
12:46:00 <nikolapdp> even if it was an enjoyable language to use, you just couldn't use it anywhere you'd want to use it
12:49:00 <gog> but rust is SAFE and SECURE
12:49:00 <sham1> From what I understand, Rust was usually framed more as a C++ killer specifically
12:50:00 <zid> unsafe { Port of all my C code }
12:50:00 <zid> SAFE AND SECURE
12:50:00 <sham1> It's just that because people think of C++ as being a C killer (It's not), it gets transitively applied
12:50:00 <mjg> how do i find where the File object is defined
12:50:00 <mjg> grepping over rust codebase gave me this:
12:50:00 <zid> yea it does seem more like a C++
12:50:00 <zid> aka annoying python
12:50:00 <mjg> pub struct File { inner: fs_imp::File,
12:50:00 <mjg> }
12:50:00 <mjg> but i'm unable to find fs_imp thing
12:50:00 <nikolapdp> you should be able to get to the source from the docs
12:51:00 <nikolapdp> yeah rust is just an awful language to use if you ask me
12:51:00 <mjg> pub struct File { /* private fields */ }
12:51:00 <mjg> are the docs
12:51:00 <sham1> Truly
12:51:00 <nikolapdp> ah right
12:51:00 <mjg> i want to check the private fields for something
12:51:00 <mjg> according to dbg! dump there is fd, path, read, write
12:51:00 <mjg> but i don't know their sizes 'n shit
12:52:00 <mjg> in particular does it keep a ref to the path, a copy or what
12:52:00 <mjg> here is sample output:
12:52:00 <mjg> [src/main.rs:24:13] file = File { fd: 4, path: "/tmp/crap/lolek", read: true, write: false,
12:52:00 <mjg> }
12:53:00 <mjg> if this was perl or python i would let it go, but for supposedly systems language i want to know
12:57:00 <nikolapdp> where the heck is use crate::sys::fs as fs_imp;
12:57:00 <mjg> that's my question mate
12:57:00 <zid> filesystem imps again!?
12:57:00 <zid> fuck
12:57:00 <zid> we just sprayed for those
12:58:00 <mjg> is there a way to rawdump the object?
12:58:00 <mjg> not using whatever debug it has, but actually dump all fields
12:58:00 <mjg> preferably recursively
12:59:00 <mjg> for example:
12:59:00 <mjg> let lulpath = Path::new("./foo/bar.txt");
12:59:00 <mjg> dbg!(size_of_val(lulpath));
12:59:00 <mjg> dbg!(lulpath);
12:59:00 <mjg> [src/main.rs:53:5] size_of_val(lulpath) = 13
12:59:00 <mjg> [src/main.rs:54:5] lulpath = "./foo/bar.txt"
13:00:00 <mjg> i would like to see the fields instead
13:01:00 <mjg> also something is very funky here. there is 13 chars in the string and sizeof also gives 13
13:01:00 <nikolapdp> one step closer https://github.com/rust-lang/rust/blob/ad18fe08de03fbb459c05475bddee22707b4f0ec/library/std/src/sys/pal/unix/fs.rs#L117
13:01:00 <bslsk05> github.com: rust/library/std/src/sys/pal/unix/fs.rs at ad18fe08de03fbb459c05475bddee22707b4f0ec · rust-lang/rust · GitHub
13:01:00 <mjg> it does not include anything about total length or the terminating null char which *is* needed on unix
13:02:00 <mjg> is it there but the above lies to me
13:02:00 <nikolapdp> mjg i think it always allocs a cstr before syscalls
13:02:00 <nikolapdp> so you want find it in objects of any kind
13:03:00 <nikolapdp> lol https://github.com/rust-lang/rust/blob/ad18fe08de03fbb459c05475bddee22707b4f0ec/library/std/src/sys/pal/unix/fd.rs#L30
13:03:00 <bslsk05> github.com: rust/library/std/src/sys/pal/unix/fd.rs at ad18fe08de03fbb459c05475bddee22707b4f0ec · rust-lang/rust · GitHub
13:03:00 <Ermine> are rust strings null terminated?
13:03:00 <nikolapdp> nope
13:03:00 <nikolapdp> ptr + size
13:04:00 <nikolapdp> also utf8 enforced i think
13:05:00 <synaps3> hello, anyone knows if firefox os has a living fork ?
13:05:00 <synaps3> not being kaios
13:06:00 <nikolapdp> mjg apparently from what i can tell, File is just a wrapper around fd
13:06:00 <nikolapdp> but this code is a mess so who knows
13:08:00 <nikolapdp> re rust cstr, https://github.com/rust-lang/rust/blob/ad18fe08de03fbb459c05475bddee22707b4f0ec/library/std/src/sys/pal/unix/fs.rs#L1173
13:08:00 <bslsk05> github.com: rust/library/std/src/sys/pal/unix/fs.rs at ad18fe08de03fbb459c05475bddee22707b4f0ec · rust-lang/rust · GitHub
13:08:00 <nikolapdp> https://github.com/rust-lang/rust/blob/ad18fe08de03fbb459c05475bddee22707b4f0ec/library/std/src/sys/pal/common/small_c_string.rs#L18
13:08:00 <bslsk05> github.com: rust/library/std/src/sys/pal/common/small_c_string.rs at ad18fe08de03fbb459c05475bddee22707b4f0ec · rust-lang/rust · GitHub
13:09:00 <mjg> so they actually make a copy at runtime just to plop 0 in it?
13:09:00 <nikolapdp> yup
13:09:00 <mjg> ...
13:09:00 <nikolapdp> with two variations based on the string len
13:10:00 <mjg> pub struct Path { inner: OsStr,
13:10:00 <mjg> }
13:10:00 <nikolapdp> one copies to a stack allocated buffer, the other mallocs
13:10:00 <mjg> ye, either stack or malloc
13:10:00 <nortti> aiui OsStr may not be utf-8, e.g. on windows it'll be wtf-16
13:10:00 <mjg> you would think fucking Path would not suffer the problem
13:10:00 <nikolapdp> yeah that's the purpose of OsStr
13:10:00 <nortti> and on linux it's a bag of bytes
13:11:00 <nikolapdp> lol so Path has OsStr which tehy could've made into a null terminated str on linux, which would save the copying and conversions
13:12:00 <nikolapdp> but they didn't do that and you will get a path copy
13:12:00 <mjg> that is my reading so far
13:12:00 <mjg> but hey, zero cost conversion
13:12:00 <nikolapdp> that's exactly what i am seeing
13:12:00 <nikolapdp> lol ignoring the memcpy
13:12:00 <mjg> or so they would call it
13:12:00 <mjg> or the alloc
13:12:00 <nikolapdp> and potentional malloc
13:12:00 <mjg> ... which can fail
13:12:00 <nikolapdp> lollers
13:13:00 <mjg> at least paths tend to be super short
13:13:00 <nikolapdp> yeah that's true
13:14:00 <nikolapdp> still a loller
13:14:00 <mjg> so Path is inner: OsStr, while whe latter is inner: Slice
13:14:00 <mjg> did that get locally optimized for a size known at compilation time?
13:15:00 <mjg> lemme construct a path from an argument
13:16:00 <Ermine> mjg: do you consider that PESSIMAL?
13:16:00 <mjg> Ermine: ofc
13:17:00 <mjg> nikolapdp: size_of_val keeps showing strlen
13:17:00 <mjg> not the actual size of the object
13:17:00 <nikolapdp> code?
13:18:00 <mjg> adding & shows 16 which looks like it does the trick?
13:18:00 <mjg> https://dpaste.com/GD7ZERKKU
13:18:00 <bslsk05> dpaste.com <no title>
13:19:00 <sham1> &path probably gives you the fat pointer to the path content
13:19:00 <mjg> for all i know & forced it to reate something which was not there
13:19:00 <mjg> sham1: so the thing is, at the bottom of it rust claims to check the length of the string
13:19:00 <mjg> which it can't do if it is not terminated (which it claims it is not) and there is no length field
13:20:00 <mjg> so far looks liek size_of_val is bullshitting me
13:20:00 <nikolapdp> there is also size_of
13:21:00 <sham1> Yeah, size_of_val is more useful for slices and the like
13:21:00 <mjg> i want an equivalent of sizeof from c
13:21:00 <Ermine> why tf pdf reader uses 922M of res memory
13:21:00 <sham1> The equivalent of sizeof is… size_of
13:22:00 <Ermine> supposedly lightweight one
13:22:00 <mjg> 6 | dbg!(mem::size_of::<Path>()); | ^^^^ doesn't have a size known at compile-time
13:22:00 <mjg> :S
13:22:00 <Ermine> that's even more than MEGABLOATED firefox tab
13:23:00 <sham1> Yeah, Path is like str
13:23:00 <nikolapdp> Ermine which one is that
13:23:00 <Ermine> zathura
13:23:00 <mjg> sham1: sho how do i find how much it eats
13:24:00 <mjg> sham1: as pointed out above, size_of_val seems to be lying about it
13:24:00 <sham1> Well, Path eats as much as its content.
13:24:00 <Ermine> it's poppler though, not mupdf, but mupdf backend is borked
13:24:00 <mjg> but then how do you explain how does it known the size
13:24:00 <mjg> when it is not terminated in any way and there is no len field
13:25:00 <sham1> Path doesn't know its own size. &Path does
13:25:00 <mjg> well &Path claims 16
13:25:00 <mjg> is that accurate
13:25:00 <mjg> for amd64
13:25:00 <sham1> Because &Path is essentially like struct { size_t len; char *data; }; although not necessarily in that order
13:25:00 <mjg> i'm guessing that's the total size for the pointer to the actual string + len
13:26:00 <mjg> right, so real total size would be that 16 + whatever they malloced
13:26:00 <sham1> It's a slice type
13:26:00 <sham1> Yeah
13:26:00 <mjg> (or stack'ed?)
13:26:00 <nikolapdp> i imagine so
13:27:00 <sham1> PathBuf is the thing that usually owns this thing, it's an object that owns the Path in the heap. Like a dynamic array
13:27:00 <mjg> for a systems language it defo makes it difficult to find out what's going on
13:27:00 <mjg> all the docs i had seen so far targeted to people who don't care, which probably is the actual real target audience
13:28:00 <nikolapdp> probably
13:28:00 <mjg> so in the funny program i linked above which uses argv
13:29:00 <mjg> for path in &args[1..] {
13:29:00 <sham1> So yeah, for AMD64 I'd expect for size_of::<&Path>() to be 16. As for if you're doing size_of_val(&path), it might be allocating the nearest power of 2, but don't quote me on that
13:29:00 <mjg> let lulpath = Path::new(path);
13:29:00 <mjg> does lulpath reuse the already existing area?
13:29:00 <mjg> or does it copy
13:29:00 <mjg> as in does lulpath point to the actual passed string
13:30:00 <sham1> > Directly wraps a string slice as a Path slice.
13:30:00 <mjg> whatever the pointer in the slice i mean
13:30:00 <sham1> So shouldn't alloc
13:30:00 <mjg> aight
13:31:00 <sham1> Lul
13:31:00 <sham1> https://doc.rust-lang.org/src/std/path.rs.html#2041
13:31:00 <bslsk05> doc.rust-lang.org: path.rs - source
13:31:00 <sham1> > &*
13:31:00 <sham1> Can't make this up
13:31:00 <nikolapdp> is that C code in my rust ???
13:31:00 <sham1> Basically yeah
13:31:00 <mjg> i'm guessing this cast away some of the borrow checker thing?
13:32:00 <mjg> for consumption within unsafe
13:32:00 <sham1> It's going from a pointer to Path to a &Path
13:32:00 <gog> god all the fucking type decoration
13:32:00 <nikolapdp> thought the while point or rust is to never need unsafe unless you're working with external things like os or libraries or whatever
13:33:00 <nikolapdp> not the actuall rust types
13:33:00 <sham1> And as the below method's SAFETY-comment clarifies, Path is just a wrapper around OsStr
13:33:00 <nikolapdp> so why isn't it directly castable or something
13:33:00 <nikolapdp> instead of being unsafe to do that
13:34:00 <sham1> I'm just guesstimating using C knowledge
13:35:00 <nikolapdp> i am just saying that there's no reason for this to be unsafe realistically
13:35:00 <mjg> i did notice any time you do anything which would normally justify the project being in c
13:35:00 <mjg> you have to unsafe around it in rust
13:35:00 <sham1> You can't deref a pointer without unsafe, even in a &* construct
13:36:00 <nikolapdp> i am not talking about this exact piece of code not needing to be unsafe
13:36:00 <sham1> Right
13:37:00 <nikolapdp> i am saying that you should be able to convert between these kinds of wrappers without unsafe
13:37:00 <mjg> meh
13:37:00 <mjg> this is probably a measure against people hacking
13:37:00 <nikolapdp> or just use c :)
13:37:00 <mjg> as in if you fuck around like this, you at least have to unsafe, and then it's your fault
13:37:00 <mjg> if shit breaks
13:38:00 <kof673> > why tf pdf reader uses 922M of res memory Ermine, http://web.archive.org/web/20010708023449/http://www.research.compaq.com/SRC/virtualpaper/summary.html that basically just pre-rendered stuff, says it ran on a 486. (not pdf, unix + modula 3...so i will try to build it again, freebsd circa 4.x should work :D anyways, modula i think did run on other systems, but that site says "porting" to "windows 95" and mac at the time was not high
13:38:00 <kof673> priority)
13:38:00 <bslsk05> web.archive.org: Virtual Paper: Summary (External )
13:38:00 <kof673> also, they were too busy killing alpha j/k
13:38:00 <kof673> digital was too busy dying, so it never took off j/k
13:40:00 <sham1> nikolapdp: exactly, but due to safety, you're better off using rust. Otherwise you might, gasp, get a buffer overflow
13:41:00 <nikolapdp> SAFETY
13:41:00 <sham1> Of course, buffer overflows are an actual problem, so I'm not sure why I'm saying this sarcastically, but you can still write safe code in C. I suppose the argument rustaceans is that writing safe C takes way too much effort while in Rust it's supposed to be the easy thing to do
13:41:00 <nikolapdp> FEARLESS CONCURRENCY
13:42:00 <nikolapdp> it doesn't need to be hard to write safe c code
13:42:00 <sham1> I do see the merit in the argument, however yeah, it needn't be difficult
13:42:00 <zid> Nobody wants to write a little buffer impl. first and hide it behind an opaque pointer
13:42:00 <zid> and do .c_str() crap
13:42:00 <zid> not that it isn't easy
13:43:00 <sham1> The thing that annoys me about rust is that you essentially can't control allocations
13:43:00 <gog> zig zig zig
13:43:00 <gog> zig is rust but you can control allocations
13:43:00 <nikolapdp> zig is not rust
13:43:00 <gog> ok it's not
13:43:00 <nikolapdp> if nothing else, it's way less of a chore
13:44:00 <gog> it's type notation resembles rust in a cursory way
13:44:00 <sham1> Well, you can, but it's kinda like C++. You either write code with raw pointers and such and get to deal with OOM, or you interact with the outside ecosystem but don't get to control how a Vec allocates, for example
13:44:00 <gog> that's an inversion of control problem
13:45:00 <sham1> At least C++ gives you exceptions on allocation failure, which you can handle. Meanwhile in Rust, you're not supposed to catch panics unless you're doing FFI or something
13:45:00 <sham1> If I wanted to deal with IoC, I'd just use Spring
13:45:00 <sham1> At least Java has a proper garbage collector
13:46:00 <nikolapdp> SAFETY
13:51:00 <zid> internet of cocks
13:52:00 <nikolapdp> lol
13:52:00 <sham1> The thing that makes me lol about rust stuff is that for example in Linux, they've decided to go with the alloc crate, which gives stuff like Vec
13:53:00 <sham1> One problem: alloc does allocations in a fallible manner, but doesn't expose the failure in return values or anything
13:54:00 <sham1> I honestly don't know how Linus OK'd that. If there's one thing you wouldn't want to OOM, it's the kernel, especially if it's a driver or whatever
13:54:00 <zid> Any sufficiently large Rust program contains an informal, ah-hoc version of C?
13:54:00 <zid> ad*
13:54:00 <sham1> Of course, kernel panics on OOM are a thing. But still
13:54:00 <nikolapdp> but you should have a choice of handling it
13:54:00 <sham1> You *should* but you don't, and that's the issue
13:55:00 <nikolapdp> it's ridiculous to have uncoditional kernel panics in drivers
13:55:00 <zid> half of common C* I should say
13:55:00 <zid> https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
13:55:00 <nikolapdp> userland is different
13:55:00 <sham1> Like okay, for userland applications, like rewriting whatever coreutil a rustacean fancies to rewrite, like ls (exa), having that crash on allocation failure is whatever. It's not ideal and it's annoying for me as a user, but I can manage
13:55:00 <sham1> The kernel on the other hand‽ Absolutely not!
13:56:00 <zid> INTEROBANG
13:56:00 <nikolapdp> !?
13:56:00 <zid> How the fuck do you even type that
13:56:00 <sham1> zid: compose key
13:56:00 <sham1> Although currently I'm doing it with my phone keyboard
13:56:00 <puck> i added interrobang to a local fork of hackerskeyboard, as well as a shorthand on my desktop keyboard, heh
13:57:00 <zid> my mono fon't can't fit it so it subs in a ttf font and downscales it to be ugly
13:57:00 <zid> grates
13:57:00 <sham1> Anyway, rust folks want to also write things like aircraft control systems and other embedded stuff in Rust, because of course it's safety-critical and Rust is safety
13:57:00 <zid> SAFETY
13:57:00 <zid> I should learn ada
13:57:00 <sham1> Ada would be a good contender
13:57:00 <zid> ada is what the f-22 was written in
13:57:00 <zid> I'm sure most other things were too
13:57:00 <zid> but I heard that one
13:58:00 <sham1> Or think about a pacemaker. That thing should *not* fail
13:58:00 <sham1> Ever
13:58:00 <zid> I can write C that doesn't fail I just need to teach my coverity or whatever to error on vlas etc
13:58:00 <zid> good luck with that in rust
13:58:00 <zid> the SAFE language
13:58:00 <gog> hi i'm ada
13:58:00 <sham1> That's why even in C you preallocate all the buffers so that you don't fail, ever
13:59:00 <nikolapdp> c is easy to write in a way that never fails compared to rust
13:59:00 <nikolapdp> especially when to common error handling in rust is .unwrap()
13:59:00 <zid> Rust has an infinite tail that starts lower
13:59:00 <zid> C has a big lump, then goes to 0
13:59:00 <zid> if that makes sense
13:59:00 <sham1> Like you can write Rust like that, but you lose a lot of the "niceties" of Rust that people also talk about, like rich data structures like Vec
13:59:00 <sham1> And yeah, the cavalier culture around error handling is another thing
14:00:00 <zid> I DREWEDE YOU A PICTURE
14:00:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/1229793591581343744/image.png?ex=6630f988&is=661e8488&hm=54fb1ec4697171369b974817912a23418639969a40cded8203ba8c889d2afea8&
14:00:00 <zid> C code is prety unsafe, then you work really hard and make it super safe
14:01:00 <zid> Rust starts safe, but the more of it you write the less sure you are that it's still safe
14:01:00 <nikolapdp> lol
14:01:00 <zid> I can write a C program that does not ever crash, pretty easily
14:02:00 <nikolapdp> int main() { for (;;) ; }
14:02:00 <nikolapdp> boom easy
14:02:00 <Mutabah> undefined behaviour
14:02:00 <zid> rust version needs you to pull in 4 crates just to return 0;
14:02:00 <nikolapdp> Mutabah, not in c
14:02:00 <nikolapdp> in cpp it is
14:02:00 <sham1> Something, somewhere, in one of your 2^69 dependencies tries to overallocate and crashes the program, killing the patient with the pacemaker because you as a rustacean thought that it'd be good to have 2^69 transitive dependencies on your pacemaker firmware because crates.io is like npm
14:02:00 <Mutabah> an infinite loop with no side-effects is UB... oh, wait C++
14:03:00 <nikolapdp> lol
14:03:00 <zid> sham1: I honestly never got past my first Rust program, after an hour I still wasn't sure how to port int main(void){ return 42; }
14:03:00 <zid> I had to learn about unboxed tuple crated bananas
14:03:00 <nikolapdp> lol
14:03:00 <Mutabah> `fn main() { ::std::process::exit(42); }`
14:04:00 <zid> def main() -> OK(Err) { OKAY(42) EXTENDS BANANAS; }
14:04:00 <zid> or some shit
14:04:00 <zid> idk
14:04:00 <mjg> Mutabah: is there an equivalent to gdb ptype for rust types
14:04:00 <mjg> Mutabah: which i could use from a rust program
14:04:00 <sham1> ptype
14:04:00 <sham1> With the appropriate gdb extension
14:04:00 <zid> returning values too complicated for rust, have to tuple it with some error class
14:04:00 <zid> and instantiate the RETURN VALUE class
14:04:00 <Mutabah> Don't know, I've never used `ptype` and I don't usually need gdb with rust code
14:04:00 <sham1> Which adds support for Rust stuff
14:04:00 <Mutabah> unless I'm doing mega evil unsafe stuff
14:05:00 <mjg> i'm not taking about using gdb
14:05:00 <mjg> i'm talking about dumping structs, finding out holes 'n shit
14:05:00 <mjg> from rust itself
14:05:00 <Mutabah> Something to dump the struct layout?
14:05:00 <mjg> ya
14:06:00 <Mutabah> Anything that can parse dwarf tables can probably get that
14:06:00 <Mutabah> but, if you care about layout - do it yourself (or trust the compiler to optimise the layout)
14:06:00 <mjg> bare minimum i want to know what it is
14:06:00 <zid> nikolapdp do you know enough rust to implement that program
14:06:00 <mjg> and if a crate turns out to be funky about it, maybe i could patch it
14:07:00 <nikolapdp> what program zid
14:07:00 <nikolapdp> int main() { return 42; }
14:07:00 <nikolapdp> ?
14:07:00 <zid> yes
14:07:00 <nikolapdp> lol well you'd need a function for exit(42) so no, not without googling that function
14:08:00 <zid> it doesn't do exit(42)
14:08:00 <zid> that's a different thing
14:08:00 <nikolapdp> how's it a different thing
14:08:00 <Mutabah> Hmm... `#[start] fn main() -> i32 { 42 }` that might work?
14:09:00 <Mutabah> `#![feature(start)] #[start] fn main(argc: isize, argv: *const *const u8) -> isize { 42 }`
14:10:00 <zid> use std:;process::ExitCode; fn main() -> ExitCode { ExitCode::from(42) } is apparently an option
14:10:00 <sham1> Yeah
14:11:00 <zid> fn main() -> Result<()> { Ok(()) } if I don't care about the vlaue, whatever the fuck any of that means
14:11:00 <sham1> Rust makes it's quite unhygienic to exit the program with an exit code
14:11:00 <zid> yea so I never got past mov eax, 42; ret
14:11:00 <sham1> Although TBF, it's not unique
14:11:00 <zid> "Note that i32 doesn't implement Termination, so you can't use Result<i32, i32> as the return type. You could use Result<ExitCode, i32>, but that would print the error i32, which you probably wouldn't want,"
14:11:00 <zid> RUST RUST RUST
14:12:00 <nikolapdp> RUST RUST RUST
14:12:00 <Mutabah> zid: That's just the same as `fn main() {}`, fyi
14:12:00 <nikolapdp> this one fn main() -> Result<()> { Ok(()) }?
14:12:00 <Mutabah> yep
14:12:00 <Mutabah> well, since it never returns an error it is
14:13:00 <nikolapdp> right yeah
14:13:00 <sham1> Such a silly language
14:14:00 <mjg> Mutabah: i ran pahole on the binary. i'm trying to find out about std::fs::File, but i don't see it anywhere
14:14:00 <Mutabah> did you use that type in your code?
14:15:00 <mjg> yes
14:15:00 <Mutabah> Huh - note, I'm guessing mostly
14:15:00 <Mutabah> precise layouts of std types don't tend to be something you care about
14:15:00 <zid> hotswap replacement of C for sure, anyway
14:15:00 <zid> 10/10 would use again for C
14:15:00 <Mutabah> there's probably a rustc `-Z` option to dump layouts
14:17:00 <Mutabah> although, I tend to see rust as a C++ replacement, less of a C replacement
14:18:00 <mjg> bummer, i noinlined a File using routine and set a breakpoint on it
14:18:00 <mjg> gdb does not see the var
14:19:00 <mjg> oh there is rust-gdb
14:19:00 <mjg> ... and no dice
14:19:00 <nikolapdp> lol
14:20:00 <nikolapdp> great language
14:20:00 <mjg> Breakpoint 1, md5summer::compute_md5_chunked<&std::path::PathBuf> (path=0x7fffffffd9e8) at src/main.rs:17
14:20:00 <mjg> 17 let mut file = File::open(&path)?;
14:20:00 <mjg> (gdb) p file
14:20:00 <mjg> No symbol 'file' in current context
14:20:00 <mjg> it does see the passed arg, so maybe i a func which takes it for no reason would do the trick
14:20:00 <nikolapdp> you've got to go to the next line
14:20:00 <mjg> i did
14:20:00 <nikolapdp> it still hasn't executed
14:20:00 <mjg> s
14:20:00 <nikolapdp> and still nothing?
14:20:00 <mjg> i did not paste it
14:21:00 <mjg> now i have to figure out how to accept a file tho :S
14:25:00 <mjg> got it
14:25:00 <nikolapdp> what got you to get into rust of all things
14:25:00 <mjg> $3 = std::fs::File {
14:25:00 <mjg> inner: std::sys::pal::unix::fs::File (
14:25:00 <mjg> std::sys::pal::unix::fd::FileDesc (
14:25:00 <mjg> std::os::fd::owned::OwnedFd {
14:25:00 <mjg> )
14:25:00 <mjg> fd: 4
14:25:00 <mjg> }
14:25:00 <mjg> )
14:25:00 <mjg> }
14:25:00 <nikolapdp> yup, wrapper around fd as expeted
14:27:00 <mjg> well then i don't understand how it produces the kind of debug it does
14:27:00 <mjg> #[inline(never)]
14:27:00 <mjg> fn lulfile(lulf: &File) { dbg!(lulf);
14:27:00 <mjg> }
14:27:00 <mjg> this shows:
14:27:00 <mjg> [src/main.rs:18:5] lulf = File { fd: 4, path: "/tmp/crap/lolek", read: true, write: false,
14:27:00 <mjg> }
14:27:00 <mjg> but only fd: 4 is accounted for in the dump above?
14:27:00 <Mutabah> look for the `Debug` impl in the source?
14:28:00 <acidx> std::fs::File probably #[derive(Debug)]
14:29:00 <mjg> yep found it
14:29:00 <acidx> impl fmt::Debug for File {
14:29:00 <acidx> fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
14:29:00 <acidx> self.inner.fmt(f)
14:29:00 <acidx> }
14:29:00 <mjg> it fetches this stuff at runtime
14:29:00 <mjg> i'm both positively and negatively surprised here
14:30:00 <mjg> for example for macos:
14:30:00 <mjg> let mut buf = vec![0; libc::PATH_MAX as usize];
14:30:00 <mjg> let n = unsafe { libc::fcntl(fd, libc::F_GETPATH, buf.as_ptr()) };
14:30:00 <mjg> given the debug stuff above i thought their File object carries the path around
14:30:00 <Mutabah> querying the kernel seems like a perfectly good approach
14:30:00 <Mutabah> if you want to debug print, it takes the time to query it
14:31:00 <mjg> it's mostly fine, the problem is path resolution is not reliable on anything but linux
14:31:00 <Mutabah> without adding the cost of keeping the rest of the details stored
14:31:00 <mjg> (as far as unixes go anyway)
14:31:00 <mjg> and by that i mean it can literally fail to do anything
15:03:00 <mjg> Mutabah: last rust q, i promise
15:03:00 * Mutabah is away (Sleep)
15:03:00 <mjg> :>
15:03:00 <mjg> #[inline(never)]
15:03:00 <mjg> fn lulfile(lulf: &File) -> u8 { return 2;
15:03:00 <mjg> }
15:04:00 <mjg> 0x0000555555562da0 <+0>: mov %rdi,-0x8(%rsp)
15:04:00 <mjg> => 0x0000555555562da5 <+5>: mov $0x2,%al
15:04:00 <mjg> 0x0000555555562da7 <+7>: ret
15:04:00 <mjg> what's up with the stack write
15:04:00 <nikolapdp> it's a stack read?
15:05:00 <mjg> it's intel syntax
15:05:00 <nikolapdp> with all of the %
15:05:00 <mjg> anyway i would just expect the store to %al and ret
15:05:00 <nikolapdp> yeah no clue
15:05:00 <nikolapdp> %rdi is the reference
15:06:00 <nikolapdp> no clue why it would need to be stored on the stack
15:07:00 <mjg> i also found it sneaks in a memset of the temp buffer
15:07:00 <mjg> let mut buffer = [0; CHUNK_SIZE]; <-- this guy
15:08:00 <zid> nikolapdp teach me PROGRAMMING
15:08:00 <nikolapdp> mjg that's what the 0 is for there
15:08:00 <nikolapdp> the initial element
15:09:00 <mjg> how do i just declare a buf?
15:09:00 <nikolapdp> if you want an uninitialized buffer, that's unsafe i think
15:09:00 <nikolapdp> zid you type code, computor runs code
15:09:00 <mjg> that's passe
15:09:00 <zid> It says "That is not a valid username"
15:09:00 <mjg> you ask chatgpt to generate code
15:09:00 <mjg> 's how i got the above!
15:10:00 <nikolapdp> zid: step 1, get a commodore 64, step 2: write code, step 3: ???, step 4: profie
15:10:00 <nikolapdp> profit
15:11:00 <zid> I wrote a lot of code in ps2
15:11:00 <zid> on
15:11:00 <nikolapdp> mjg did the first thing chatgpt give you even run
15:11:00 <nikolapdp> zid: how do you write code on ps2
15:11:00 <zid> ps2 in europe came with yabasic
15:11:00 <mjg> nikolapdp: it did not compile
15:11:00 <zid> to make it a HOME COMPUTER to dodge tax
15:11:00 <mjg> nikolapdp: after i fixed that i found it does not even work
15:12:00 <mjg> nikolapdp: that aside of stupid ideas it had
15:12:00 <nikolapdp> lol
15:12:00 <zid> https://www.youtube.com/watch?v=5JbXpFaaTyg
15:12:00 <bslsk05> 'Demoplay: YaBasic' by Xindictive (00:32:00)
15:13:00 <zid> very very fast mandelbrot at 3:10
15:15:00 <nikolapdp> very fast
15:21:00 <mjg> fuck me chatgpt is so bad
15:21:00 <mjg> https://chat.openai.com/share/2f04db83-4312-4299-b8c0-e065b0718bf2
15:21:00 <bslsk05> chat.openai.com: ChatGPT
15:41:00 <GeDaMo> zid: I don't remember getting Yabasic with my PS2 :|
15:53:00 <zid> it was on DEMO DISC
15:53:00 <zid> It had a t-rex you could change the expression of
15:58:00 <nikolapdp> lol seriously, openssl?
17:25:00 <osdev199> Hello, I'm writing a 64-bit kernel and in the UEFI boot loader, writing to frame buffer is not working after calling ExitBootServices. However it works and fills the color if called before calling the same function. Please see line #109 at https://pastebin.com/fbC6yGfu. Any suggestion? Thanks.
17:25:00 <bslsk05> pastebin.com: /* * Boot loader written using gnu-efi. */#include <efi.h>#include <efil - Pastebin.com
17:54:00 <zid> 10 min max apparently
18:00:00 <heat> mjg, why are you using chatgpt
18:00:00 <heat> are you stupid
18:02:00 <zid> does he have to answer that
18:20:00 <heat> yes, under oath
18:20:00 <heat> people using chatgpt to program is like... shit you see on linkedin part 564
18:21:00 <mjg> i was curious
18:22:00 <mjg> i found something rather peculiar though
18:22:00 <mjg> chatgpt generates shit c code, but it does process files piecemeal
18:23:00 <mjg> but if you ask for a rust equivalent, it immediately goes for slurping files upfront
18:24:00 <nikolapdp> you expect chatgpt to not be shit and to "understand" rust
18:24:00 <nikolapdp> there's your problem
18:26:00 <mjg> i don't expect chatgpt to not be shit
18:26:00 <heat> lazy IO?
18:26:00 <mjg> if anything i'm the first person to dunk on it
18:26:00 <heat> is this a haskell moment
18:26:00 <heat> no, you're not the first person to dunk on chatgpt, this is not new grounds
18:27:00 <nikolapdp> lol
18:27:00 <mjg> i did not start now mon
18:27:00 <mjg> :X
18:27:00 <heat> were you the first hater
18:27:00 <mjg> realistically only total webdevs think chatgpt is good
18:27:00 <mjg> as far i know, yes!
18:27:00 <heat> anyway
18:27:00 <heat> hGetContents hGetContents hGetContents hGetContents hGetContents hGetContents hGetContents
18:28:00 <nikolapdp> RUST RUST RUST
18:28:00 <mjg> anyhow
18:28:00 <heat> haskell evangelist strike force
18:28:00 <heat> rewrite it in haskell
18:29:00 <heat> or dont
18:29:00 <heat> your body your choice
18:29:00 <mjg> i asked it to also write php, perl and java versions
18:29:00 <mjg> it's only rust where it goes full webdev and slurps the file upfront
18:29:00 <mjg> which does line up with all rust docs btw
18:29:00 <nikolapdp> take a guess at who uses rust the most
18:29:00 <zid> THat's why I am pregante
18:29:00 <heat> does the C version use fgets with a limited line length?
18:29:00 <mjg> yes
18:30:00 <heat> wonderful lol
18:30:00 <heat> C is great
18:30:00 <zid> nikolapdp: wanna practice getting pergnat?
18:30:00 <nikolapdp> how do
18:30:00 <heat> jizz
18:30:00 <mjg> nikolapdp: the same caliber webdevs use the other languages as well, most notably php
18:30:00 <zid> hug in a special way
18:30:00 <nikolapdp> aww
18:30:00 <nikolapdp> mjg: exactly
18:30:00 <mjg> the diff is that official php docs don't tell people to just read entire files upfront
18:31:00 <heat> i'm not sure what copium everyone here is on, but rust is used in all the places C was used before
18:31:00 <heat> and C++ to a lesser extent
18:31:00 <heat> it is not a "webdev" language
18:31:00 <zid> C got used for coreutils when it probably wasn't needed
18:31:00 <zid> and rust has replaced that
18:31:00 <mjg> have you been on youtube? it's nothing but webdevs raving about it
18:31:00 <zid> but not in the systems space
18:31:00 <zid> only application
18:32:00 <mjg> this does not mean there are no non-webdev users
18:32:00 <nikolapdp> zid: technically there are rust drivers, mostly by the asahi project
18:32:00 <zid> They're drunkards though
18:32:00 <heat> i can write a rust operating system, it's been done before
18:32:00 <heat> it's only not truly a real thing because rewriting the core operating system is truly fucking hard
18:32:00 <nikolapdp> you can write an os in many different ways, doesn't make them a good idea
18:33:00 <heat> correct, one bad idea is to write one in C
18:33:00 <nikolapdp> one worse idea is to write it in rust
18:33:00 <heat> swear to god you people make me defend rust
18:33:00 <heat> fucking yuck
18:33:00 <nikolapdp> you did it to yourself
18:33:00 <nikolapdp> you rust stan
18:33:00 <mjg> relax heat
18:33:00 <mjg> heat did you know rust is embraced by oxide
18:33:00 <heat> yes
18:33:00 <heat> i like bryan cantrill
18:33:00 <mjg> the sun DIASPORA
18:34:00 <mjg> have you considered getting a job at oxide
18:34:00 <heat> yes
18:34:00 <heat> might just hack on illumos just to piss you off
18:34:00 <nikolapdp> lol do it
18:35:00 <heat> ( 9/18) Updating TeXLive format files...
18:35:00 <heat> cant, pacman's busy
18:35:00 <nikolapdp> that usually takes seconds, you're fine
18:35:00 <heat> its taking a lot this time around smh
18:35:00 <nikolapdp> lo
18:35:00 <nikolapdp> lol
18:36:00 <heat> i actually did this whole update for discord and it turns out they haven't pushed 0.50 to the arch repos yet
18:36:00 <heat> something something linux of desktop year
18:36:00 <nikolapdp> kek
18:36:00 <mjg> heat: i'm pretty sure i suggested you submit some patchen to illumos
18:36:00 <mjg> heat: and you said something strongly suggesting you are not going to
18:36:00 <heat> correct
18:37:00 <heat> i will not do it unless its to challenge your authority
18:37:00 <nikolapdp> do it then
18:37:00 <mjg> i'll be SO MAD if you do
18:37:00 <mjg> please don't
18:37:00 <mjg> :X
18:37:00 <heat> i'm going to submit patches to your dear vfs
18:37:00 <heat> to further crapify all of that shit
18:37:00 <heat> you're going to be mad and have to fix THE CRAPPERS pessiming all of it
18:38:00 <mjg> i dropped off freebsd on that front few months back, so that one i'm not even going to know about
18:38:00 <mjg> but i'll be so mad if you patch rw locks in illumos to add adaptive spinning
18:38:00 <mjg> like SO ANGRY
18:38:00 <heat> i'll patch rw locks in illumos to add adaptive sleeping
18:39:00 <mjg> illumos rw locks look like someone's *second* foray into locking primitives
19:05:00 <mjg> interestingly they copied the bad stuff into openbsd
19:13:00 <zid> noot noot
19:34:00 * geist yawns
19:38:00 * zid throws pennies
19:44:00 <gorgonical> good day for a run
19:45:00 <gorgonical> only a jaunty 5k, but still lovely weather
19:50:00 <heat> geist hai
19:50:00 <heat> how r u
19:50:00 <geist> sleepy
19:50:00 <geist> but pretty good. hacked some code yesterday
19:50:00 <geist> and even some python in the evening!
19:51:00 <geist> funny i've been fiddling with python stuff the last few weeks for one reason or another, and i'm starting to really enjoy it again
19:51:00 <geist> i hadn
19:51:00 <geist> i hadn't pythoned much in the last few years, in favor of rust or whatnot
19:51:00 <geist> but gosh it's so easy to put together pretty powerful stuff quickly in python
19:52:00 <heat> yeah but is it pythonic
19:53:00 <nikolapdp> is it IDIOMATIC
19:53:00 <heat> i write python like its C++ and i'm pretty proud of it
19:53:00 <heat> usually C but sometimes i use classes, so C++
19:54:00 <nikolapdp> do you write type annotations heat
19:54:00 <nikolapdp> do you use mypy
19:54:00 <heat> i use type annotations yeah
19:54:00 <heat> well, i try to
19:55:00 <heat> sometimes i forget, sometimes i dont care, sometimes it's non-trivial to remember how its done (dicts, lists, etc)
19:56:00 <nikolapdp> dicts and lists are simple at least
19:56:00 <nikolapdp> list[int]
19:57:00 <heat> oh yeah? do you not need to import typing or whatever that is?
19:58:00 <nikolapdp> not since python 3.9 or whatever it was
19:58:00 <heat> hmm ok thanks, good to know
19:58:00 <heat> did yall know python DOESNT SCALE
19:58:00 <heat> like WHAT THE FUCK
19:58:00 <nikolapdp> lol you're welcome
19:58:00 <nikolapdp> heat you need to use asyncio
19:59:00 <nikolapdp> ASYNC AWAIT
19:59:00 <heat> i'm going to use multiprocessing
19:59:00 <Mondenkind> heat: nuh uh
19:59:00 <heat> fork fork fork fork fork
19:59:00 <Mondenkind> they got rid of the gil
19:59:00 <Mondenkind> now it can't breathe underwater anymore😔
19:59:00 <heat> still experimental right?
19:59:00 <nikolapdp> wonder how they do it now them
19:59:00 <nikolapdp> then
20:03:00 <heat> there are whole peps and lwn articles on the issue
20:06:00 <nikolapdp> oh are there
20:06:00 <nikolapdp> wasn't even aware that was going on
20:16:00 <mjg> i almost got duped into thinking python is good
20:16:00 <mjg> because there was a book about it titled "how to think like a computer scientist" or so
20:20:00 <mjg> (i confess to not having almost any insight into the lang, it just being annoying when i had to deal with it)
20:54:00 <kof673> > yes, under oath <whispers to mjg, ask judge heat if you are swearing to tell the truth or the double truth at the scales/double hall of double truth> "nature's god" -- thomas jefferson "god of natures (plural)" -- thomas vaughan
22:52:00 <netbsduser> mjg: what winds me up about solaris is the mutex type representing both a spinlock and a sleeping mutex and being configured as such at creation time
22:52:00 <netbsduser> completely meritless but copied by at least 3 of the 5 BSDs
23:18:00 <Mutabah> mjg: Sorry, went to bed - not sure if you go the answer but... that's unoptimised code, it appears to be saving the first argument (in RDI) to the stack as part of the function prelude
23:18:00 <Mutabah> I'd assume gcc would do the same with `-O0`
23:23:00 <Ermine> lack of __MUSL__ doesn't really stop setuptools from having code for if musl
23:34:00 <heat> sugondese
23:52:00 <Ermine> bloated nuts
23:54:00 <Ermine> (but really, 18k diff between 69.2.0 and 69.5.1 !)
23:55:00 <heat> what's that?
23:58:00 <Ermine> https://github.com/pypa/setuptools/
23:58:00 <bslsk05> pypa/setuptools - Official project repository for the Setuptools build system (1133 forks/2302 stargazers/MIT)
23:58:00 <heat> oh
23:58:00 <heat> yeah i know the name, dunno what that is exactly
23:58:00 <Ermine> one of a lot of thingies to build python packages
23:59:00 <heat> i remember having /some/ issues with something similar to that in my python builds