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