<Griwes>
huh, I think I'm now done with the codegen for my syscall dsl? we'll see when I actually integrate it into the build system of the kernel, but the output files look good
<Griwes>
can't wait to one day rewrite it to use std::format instead of operator<< once you can reasonably expect an average disto to have a stdlib up to current standards...
<geist>
woot?
<geist>
i mean. yes i guess std::format is nicer than operator<< but no one is forcing you to use the latter now
<Griwes>
I mean I ain't using fprintf, that's for sure ;p
<moon-child>
eh, why not?
<Griwes>
I value type safety much, much higher than I value api ergonomics
<geist>
with hyper aggressive warnings the printf stuff is pretty darn good
<geist>
type safety wise
<geist>
and a hell of a lot more efficient a lot of the times
<moon-child>
can't be beat for size
<moon-child>
(that said, if formatting is a bottleneck, ehm...)
<moon-child>
(but that is still an argument for printf--i$ pollution)
<Griwes>
also printf requires spelling out the types manually sooooo
<geist>
yah what i do value a lot is when you have it disabled it doesn't do the work
<Griwes>
_also_ also I'd need to be doing silly things like .c_str() on basically everything
<geist>
tho7ugh you can do the same thing with the ostream stuff if you wrap it in a if statement
<geist>
vs what i've seen a lot of is some sort of get_conditional_stream() << doo << some << stuff;
<Griwes>
perf is like the last thing of importance on this project
<geist>
and it returns a neutered handle if tracing is disabled, etc
<geist>
but that means the code still makes all the function calls and then discardsi t
<Griwes>
it's just a code generator, its run time will be nothing compared to subsequently running clang on all the files it spews out
<geist>
sure
<geist>
one really nice thing about ostream is you can easily serialize an object
<geist>
that is handy to have
<Griwes>
also in target code I've been just using std::format for printing and logging and oh my god it's so convenient and pleasant to use
<geist>
yah i should look at it
<Griwes>
but I can only do that because I'm also writing the stdlib for the OS
<geist>
but it's still not ratified yet so haven't seen it yet
<Griwes>
so it has the tradeoff that I needed to implement it
<geist>
we were talking about it for zircon though, maybe once c++20 is more farther along
<Griwes>
hmm? C++20 is an international standard
<Griwes>
has been for a while
<geist>
yah but for some reason std::format isn't ready or something
<Griwes>
that's just implementations being slow
<geist>
that or it's maybe just that for Some Reason we're not ready to switch to --std=c++20
<Griwes>
we're about to feature-complete C++23 ;p
<geist>
anyway
<geist>
for kernel code what i find is quite important is the ability to conditionally, compile time, or run time, disable a printf/cout/etc with it being minimal run time (or code size) when disabled
<geist>
trouble with ostream is there isn't a good way to do it except wrap the whole expression in an if statement
<geist>
whereas with printf you can at least make a macro like
<geist>
if (condition) printf(...)
<geist>
since it ends up being a single function call, the compiler can avoid doing all the work (or be elided if at compile time)
<geist>
that being said i wonder ifyou could do some crazy shit with list-initializers or whatnot that expands to a series of <<
<geist>
and then have it elide based on some template
<geist>
my_crazy_trace(foo, bar, baz) that expands to cout << foo << bar << baz << std::endl; or smoething
<geist>
also i suppose it's possible you can coax the compiler to remove the whole thing if you have some sort of fully nerfed cout stream that it then decides there's no need to emit the rest of the expression
<geist>
i've never seen that done, but most of the time when it was used it was in situations, as you have here, where performance/code size wasn't important
<Griwes>
moon-child, we must have vastly different definitions of "pretty" if you find printf pretty ;p
<geist>
moon-child: well no. that's the problem. otherwise you have to replace cout with something else
<geist>
and then it still evals all the args and discards it
<Griwes>
yeah. again, lazy arguments would do all the necessary work for you there
<moon-child>
geist: sure, assuming something like what Griwes showed where you turn it into a function
<zid>
cout is super pretty std::cout << std::hex << std::setfill('0') << std::setw(8) << x << std::dec << std::endl;
<zid>
but cin is the best
<Griwes>
but I have zero plans to try to propose them myself
<geist>
right. and prior to griwes showing it to me i didn't know of a solution
<geist>
but then the new list-initializer and this elipses stuff i do not grok yet
<zid>
while ((std::cout << "Give me your credit card number now!!") && !(std::cin >> n)) { std::cout << "Don't mess with me, I'm written in C++!!!"; std::cin.clear(); std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n'); }
* moon-child
tosses zid a %08lx
<Griwes>
std::print("{:#08x}");
<moon-child>
zid: ok in fairness scanf sucks too
<Griwes>
{:#08x} is obviously much better than %08lx ;p
<zid>
natch
<Griwes>
(because it actually works for all number types)
<moon-child>
Griwes: I find the {} stuff involves more cognitive effort to parse
<moon-child>
understand why people like it though
<Griwes>
yeah that's fair
<geist>
aww bummer the thing griwss showed cant handle like std::endl or whatnot
<geist>
since it can't template deduce it
<geist>
lemme fiddle
<Griwes>
oh, endl is a _function_, isn't it
<Griwes>
god I always forget how hacky iostreams actually is as a library
<moon-child>
wait whaaat
<moon-child>
lol
<Griwes>
oh, even better, a function template
<geist>
yah seems that std::hex works, for example
<Griwes>
> This function is thread-safe; concurrent access by multiple threads does not result in a data race. (since C++14)
<geist>
!!
<Griwes>
...that "since C++14" means that when the committee was making C++11 actually know about threads, they 100% forgot about xalloc
<Griwes>
as one should
<moon-child>
haha
<geist>
threads are for nerds lets push this through
<Griwes>
anyway, we're also getting std::format for ranges and containers in 26
the_lanetly_052_ has joined #osdev
<Griwes>
and as for sometimes not printing from a kernel, I'll worry about that when I actually have things working and other things have been optimized lol
<geist>
hah fair enough
<geist>
looks like ostream operators does work on classes with this
<Griwes>
Sidenote, you can also make this work pre-17 without fold expressions, but it's much, much less pleasant
ElectronApps has quit [Remote host closed the connection]
freakazoid343 has quit [Ping timeout: 240 seconds]
rorx has quit [Ping timeout: 240 seconds]
rorx has joined #osdev
nur has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
anon16_ has quit [Ping timeout: 256 seconds]
<zid>
gog did your printf start to print anything yet?
<jjuran>
One day, your prints will come
masoudd has joined #osdev
masoudd has quit [Max SendQ exceeded]
masoudd has joined #osdev
masoudd has quit [Max SendQ exceeded]
masoudd has joined #osdev
masoudd_ has joined #osdev
masoudd has quit [Ping timeout: 240 seconds]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
xenos1984 has quit [Read error: Connection reset by peer]
dormito has quit [Quit: WeeChat 3.3]
xenos1984 has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
sdfgsdfg has joined #osdev
dormito has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 256 seconds]
dennis95 has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
gog has quit [Quit: byee]
gog has joined #osdev
<gog>
zid: the old version is, the new one not so much yet :p
<gog>
getting there
<zid>
europe's highest railway station is underground
<zid>
I'm sure there's some kind of moral equivalence we can make
<gog>
i don't know anything about geography, only code
pretty_dumm_guy has joined #osdev
<gog>
i found a deficiency and had to back off a bit
GeDaMo has joined #osdev
masoudd_ is now known as masoudd
dude12312414 has joined #osdev
sprock has quit [Ping timeout: 250 seconds]
<klange>
haha, oops, sitting here banging my head for an hour+ over why my audio is sounding weird, tweaking all the knobs in this driver...
<blockhead>
headphones unplugged?
<klange>
turns out it was a bug in memory allocation api that wasn't being used anywhere else yet (specific to device drivers) and I was assigning all the buffers the same memory
<gog>
ooops
<klange>
anyway I committed a terrible sin and put an AC97 in an ARM box (virtually, of course, though given they _were_ available as PCI devices and there _are_ PCI ARM machines it's not completely impossible that this could happen)
<klange>
and with a bit of work on my still-in-progress interrupt management for arm, I've got sound out of Doom.
<klange>
I wanted to port the little ffmpeg-derived 'minimp3' thing I have but it wants tan()? which is still missing from my aarch64 libc
<klange>
also my virtio input devices are interrupt-driven now
<graphitemaster>
I'd make the convert_integer function return the size rather than doing strlen after it
<gog>
right, but then where do i return the pointer to the beginning of the string in the buffer?
<zid>
pointers are evil?
<gog>
pointers are based
<graphitemaster>
out param
<gog>
hm
<gog>
i'll consider your proposal
<zid>
static inline bool
<zid>
inline is just.. not a thing you need to type in C
<gog>
why not?
<zid>
Because it does nothing
<zid>
and isn't really useful as a people hint either
<graphitemaster>
Lack of `zu` means you can't print size_t *sadge*
<zid>
it's about as usful as 'register'
<graphitemaster>
All I do is print size_t :(
<zid>
actually, less, register can be used in a gnuism to specify asm overrides :P
<gog>
wait zu?
<gog>
i look for z
<zid>
sizeof's type is %zu
<graphitemaster>
Yah, uz is not a thing, it's zu
<zid>
// gotta zero the buffer
<gog>
hmmm might have to alter that
<graphitemaster>
But your code checks for uz for size_t which is weird
<zid>
is = {0} not just easier?
<gog>
zid: probably could do that instead yeah
<zid>
99/10 idea right here
<zid>
are you ready for this
<zid>
#define KSPLAT(c) kputchar((c)); count++;
<zid>
Now it's like you're playing Croc: Legend of the Gobbos
<gog>
lol
<zid>
move 337 to 347
<gog>
graphitemaster: it just checks for 'z' as a specifier alone
<gog>
and would return after that
<zid>
it annoys me the blocks above do put() count++ and that one does count++ put()
<gog>
be annoyed
<zid>
just consider there's a third type of integer other than 'long' or 'normal' basically
<zid>
%lu %zu
<graphitemaster>
I'd make print_string use something other than kputs since now it's just doing two strlens when you already got to compute strlen, or if kputs could just return the size of the puts, then I'd return thr result of kputs instead of doing a strlen there, basically stop doing unnecessary linear scans
<gog>
lemme look at the printf docs again and see if i misunderstood something then
<graphitemaster>
if there's a kputs that takes a length then do one strlen and pass it in and return it basically
<zid>
353-380 is why what the code should care about is just 'base'
<gog>
uhh lemme check the prototype of my kputs i think it actually does
<zid>
Rather than caring about this enum
<zid>
int kvprintf(const char *restrict format, va_list arguments)
<zid>
restrict * here does nothing
<zid>
L401 'current' is unused is it not?
<gog>
lemme recompile with -Wpedantic and see what's up
<zid>
-W -Wall
<zid>
should catch this
<zid>
as long as optimizations are on
<zid>
and type given you're crazy about using structs, I really would make some kind of stream struct that had a helper function that did kputchar(s->c); count++; internally
<zid>
s/ type//
<gog>
ok i'm taking all of your suggestions into consideration gimme a minute here
<zid>
Then all the kputchars end up in one place if you want to change the output method, and y ou stop having to write count++ fucking everywhere
<gog>
shut up for a minute
<gog>
:p
<zid>
I also need to keep MY thoughts together
<zid>
I think I am done though for now
<gog>
i never claimed to be a good programmer :D
<zid>
It's actually very good, I wouldn't point any of these out to most people
<zid>
"they're not ready jim"
<gog>
wow high praise from zid
<gog>
ok yeah my kputs() is not implemented correctly
<gog>
that was one of my early quick-and-dirty things
<zid>
sounds like kernel dev to me
<gog>
right
<gog>
ok back into the mess
k8yun has joined #osdev
<gog>
ok managed to get rid of the strlens by modifying kputs()
<gog>
convert_integer remains unmodified for it
<gog>
aaaaaand it's wrong lol
<gog>
but that might be my test environment
<gog>
ok
<gog>
ok the docs here are misleading though
<gog>
wrt type of size_t for printing
<gog>
it implies the length modifier follows the conversion specifier
<gog>
and that z is a length modifier
<gog>
not a type specifier
<zid>
z is a length
<gog>
then it should be uz according to the docs
<zid>
no
<zid>
length then type
<zid>
%lu
<zid>
long unsigned-int
<gog>
:|
<zid>
%zu sizeof-sized unsigned-integer
<gog>
well that explains a lot
<gog>
ok i have to just re-order the parsing then
<gog>
no biggie
<zid>
you wrote it %ul and then confused yourself when the docs for z were %zu?
<gog>
i've been doing it wrong this whole time
<gog>
my life is a lie
<gog>
fixed
<gog>
thanks y'all for helping me :D
<gog>
i actually totally misread the doc because the last thing it specifies is "conversion specifier"
* gog
giggles in blonde
[itchyjunk] has joined #osdev
<kingoffrance>
eh, isnt it just a typedef? the size_t cake is a lie!
<bslsk05>
'Nancy Sinatra - These Boots Are Made For Walkin' (1966 Original)' by Músicas de vinil (00:02:40)
<zid>
I want a crossover
<zid>
These boots are made for Walken
<zid>
Fat Boy Slim vs Nancy Sinatra (ft. Christopher Walken)
<GeDaMo>
Huh, Christopher Walken is younger than Nancy Sinatra
<GeDaMo>
78 vs 81
heat_ has joined #osdev
<zid>
I didn't even know walken was that old
<gog>
yeah i would've guessed way younger
<zid>
I thought he was like, 50 when he did weapon of choice and that was about 10 years ago, but I assume it was closer to 25 years ago and he was 55-60
<GeDaMo>
2001
<zid>
I just double all years for 'how long ago' now
<gog>
:|
<zid>
Think it was 10 years ago? say 20.
<gog>
don't be shocked at the tone of my voice but wtf
heat has quit [Ping timeout: 250 seconds]
<zid>
I'll find out if I am off by a constant +10 or off by a constant /2 at osme point
<GeDaMo>
I still occasionally feel like the 90s was 10 years ago
<GeDaMo>
I mean the whole 90s
<zid>
It was.
<gog>
same
<moon-child>
'doing some to avoid dealing with my rl problems' i feeeel that
mahmutov has joined #osdev
masoudd has joined #osdev
wootehfoot has joined #osdev
ss4 has quit [Ping timeout: 256 seconds]
mahmutov_ has joined #osdev
mahmutov has quit [Ping timeout: 240 seconds]
[itchyjunk] has quit [Remote host closed the connection]
dennis95 has quit [Quit: Leaving]
<dmh>
heat_, i know its been many years but i intend to do ext2 driver again (in c this time) for a personal project and if and when i do ill share the r/w version if you want it :p
<heat_>
no idea what you're talking about but I already have an ext2 and ext4 driver lol
<heat_>
kind of remember your nick tho
heat_ is now known as heat
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<dmh>
ah no worries, was having dumb problems w ext2 many moons ago and you helped me out
<dmh>
that was like
<dmh>
2017? lol damn
<dmh>
'eltorito
xenos1984 has quit [Read error: Connection reset by peer]
<dmh>
yea didnt realize till i thought about it :-(
<dmh>
enough time to finish two drivers :D
<heat>
:D
<heat>
kind of weird that in ~3 years I'll have 10 years of osdev
<heat>
time flies
<dmh>
im still at 0
<dmh>
just now getting around to it now that i know what im doing
<dmh>
the older you get the faster it goes too
kingoffrance has quit [Ping timeout: 240 seconds]
<dmh>
what really kills me is becoming acutely aware of how long something will take
<dmh>
versus blissfully sussing it out when you're going as you're learning and not sure of scope etc haha
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<dmh>
in other words, usb stack
<heat>
yah
<heat>
there's a big difference between doing bare bones and fleshing out a whole system
<dmh>
one is more fun than the other
<heat>
not really about age, just experience and knowledge
<dmh>
for sure
nature has joined #osdev
xenos1984 has joined #osdev
mahmutov_ is now known as mahmutov
kingoffrance has joined #osdev
<zid>
GeDaMo: Did you remember to feed your neopets?
<GeDaMo>
I never had any :|
<zid>
poor boy
<moon-child>
my grandmother plays that game
blockhead has joined #osdev
vdamewood has joined #osdev
vinleod has joined #osdev
k8yun has quit [Quit: Leaving]
vdamewood has quit [Ping timeout: 260 seconds]
biblio has joined #osdev
nomagno has joined #osdev
<nomagno>
Hello! Which version of TCP would I want to implement over IPv4 to achieve the highest possible compatibility for the lowest implementation time?.
<zid>
The same one we've used since the 70s?
<CompanionCube>
yeah, TCP isn't a versioned protocol...
<nomagno>
1981 spec?
<nomagno>
No extensions?
<zid>
You said highest compat
<zid>
So rfc 793 or whatever
<nomagno>
Well, I wouldn't have any compatibility issues with just the 81 and no congestion protocol extensions, right?
<zid>
You might, I couldn't say
<zid>
There might be some stacks out there that explode if you don't respond to various common extensions
<nomagno>
Well, that sounds like a them problem!
<nomagno>
... Nah, I'm just imementing a toy TCP/IP layer for my VM 8-byte packet network interface
<zid>
not really sure what the question was tbh
<nomagno>
I was just unsure implementing the base old version was fine nowadays
<nomagno>
And didn't really know how to ask it...
<nomagno>
or make sure of it, or whatever
<nomagno>
Thanks!
masoudd has quit [Ping timeout: 256 seconds]
<heat>
nomagno, there's an rfc which specifies the needed RFCs for compatibility
<heat>
where compatibility = full functionality + sane flow control
<heat>
you can implement 793 but that's not enough
<bslsk05>
datatracker.ietf.org: RFC 7414 - A Roadmap for Transmission Control Protocol (TCP) Specification Documents
<heat>
see the core functionality + strongly encouraged stuff
<heat>
(especially path mtu in the strongly encouraged extensions)
<heat>
you can definitely do your networking using 793 only but that's not enough for some edge cases (+ flow control)
<heat>
for example path MTU is pretty much required (in theory) for ipv6 since routers don't fragment your packets
<heat>
in practice everyone runs ethernet
<geist>
heat: oh that's good to know actually
<geist>
though of course they bailed a long time ago
<geist>
but didn't know about that rfc
ZombieChicken has joined #osdev
[itchyjunk] has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
<heat>
yeah its neat
GeDaMo has quit [Remote host closed the connection]
freakazoid333 has quit [Quit: Leaving]
freakazoid333 has joined #osdev
ZombieChicken has quit [Ping timeout: 276 seconds]
ZombieChicken has joined #osdev
<heat>
how complex can a boot memory map get?
<heat>
i'm re-designing my boot mem allocator and i'm statically allocating an array of 128 ranges of memory and I don't know if that's enough
<zid>
bug(i > 128, "Please report this to heat");
<heat>
that works if any sort of output is up, which it might not be :(
<zid>
sounds like you should get your serial console up before your memory to me
ZombieChicken has quit [Remote host closed the connection]
dormito has joined #osdev
sdfgsdfg has joined #osdev
<sortie>
Sortix is now a community project where people can commit without my involvement subject to a mandatory code review and mandatory approval from at least two trusted people
<zid>
But there is only 1 trusted person.
<sortie>
I have three (including me) :)
<moon-child>
'just a hobby, won't be big and professional like gnu'