<heat>
geist, do you think decoupling address spaces from processes is useful?
<heat>
having a AddressSpace *currentAspace; and a Process *currentProcess; and Process would only have a pointer to the one it is using (or maybe not even that)
<heat>
Right now my address spaces are tied down to either a single process or the kernel_address_space global
<heat>
this stops me from having vfork, fancy clone() stuff, and an address space for EFI
<heat>
I'm imagining a way to have an address space that's completely decoupled from everything else - could also even just create one with a syscall, and get a handle, and then switch them on the fly
freakazoid333 has quit [Ping timeout: 255 seconds]
<geist>
yah i did that in a previous design and hadn't found too much use for it
<geist>
but it is a natural thing to decompose
<heat>
i've noticed each thread has its own aspace in zircon
<geist>
yah. that's mostly to avoid an unnecessary indirection at context switch time, since local_thread is basically a lock free lookup
<geist>
but the initial idea was something like what you're thinking about
<geist>
i did it in a previous (unreleased) µkernel i wrote. something like handle = create_aspace(); handle2 = create_process(); bind(process handle, aspace handle);
<geist>
or even per thread, since hypothetically the kernel doesn't care really
<geist>
it was kina mostly to keep the api clean: creating a thing returns a handle, and if something can be decoupled, do so
<geist>
so in this case aspaces, processes, and threads were all separate concepts. the process itself is just a collection of threads with a shared aspace
<geist>
(and a shared handle table)
<heat>
yeah
<heat>
its hard to see the usefulness I guess
<heat>
maybe in really particular instances
<heat>
or if you wanted to implement low level vm concepts like clone()/vfork() in user space
<geist>
so i suppose you could decouple it to: process holds { threads, handles }. threads belong to process, threads are bound to an aspace
<geist>
and now process and aspace aren't really related, except that processes have a thread
<bslsk05>
en.wikipedia.org: Doors (computing) - Wikipedia
<heat>
hahahahahahahaha
<geist>
flip side is any thing you decouple like that you always have to think about all the possible ramifications since it tends to create more edges in the graphs of possibilities
<geist>
so i think for zircon we talked about it for like 15 minutes but couldn't find a good reason at the time to add the complexity
<moon-child>
(in that a process is a security domain, and an address space is one crucial component of a security domain, not useful to decouple them; doors can decouple processes from _threads_)
<heat>
after all the memeing done with doors and solaris this week, I'm glad I can finish it on doors as well
frkzoid has joined #osdev
<heat>
geist, have you tried out a linux-ish approach to things? where processes are just collections of "processes" with related tables, address space, etc?
<heat>
or unix-ish I guess, most UNIX oses seem to have gone that route
<geist>
well, not for zircon, but maybe
<geist>
what i dont fully understand is all the permutations in clone() that linux actually accepts
<geist>
it seems like you can build some exotic stuff, but i also dunno if all of those a valid
<heat>
yes I think so
<heat>
it's cray-cray
<heat>
zombocom everything is possible style
Vercas67 has joined #osdev
<gog>
the only limit is yourself
Vercas6 has quit [Remote host closed the connection]
Vercas67 is now known as Vercas6
gog has quit [Quit: byee]
carbonfiber has joined #osdev
<kof123>
everytime you say cray-cray i think "sweet, cray!"
ecs has quit [Remote host closed the connection]
ecs has joined #osdev
nur has joined #osdev
qubasa has quit [Remote host closed the connection]
qubasa has joined #osdev
gdd1 has quit [Ping timeout: 268 seconds]
gdd1 has joined #osdev
sikkiladho has quit [Quit: Connection closed for inactivity]
vdamewood has joined #osdev
vinleod has joined #osdev
vdamewood is now known as Guest4879
Guest4879 has quit [Killed (lead.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
[itchyjunk] has quit [Read error: Connection reset by peer]
vai has joined #osdev
<vai>
morning all professors
<vai>
I am 42 years old, and my neighbours call me a professor ;-P
<vai>
kids, like 3 or 4 years old
<geist>
yeah that happens
srjek has quit [Ping timeout: 244 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<clever>
geist: youve mentioned before how the shared irq's in the bcm2711 GIC kinda ruin a microkernel, why cant you just implement shared irq handling, where 1 irq wakes multiple processes, and they each check their own PL011 status?
gildasio has quit [Ping timeout: 268 seconds]
gildasio has joined #osdev
jstoker has quit [*.net *.split]
junon has quit [*.net *.split]
HeTo has quit [*.net *.split]
thaumavorio has quit [*.net *.split]
Reinhilde has quit [*.net *.split]
seds has quit [*.net *.split]
Benjojo has quit [*.net *.split]
opios2 has quit [*.net *.split]
V has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
Amanieu has quit [*.net *.split]
seds has joined #osdev
Benjojo has joined #osdev
Amanieu has joined #osdev
V has joined #osdev
SanchayanMaity has joined #osdev
thaumavorio has joined #osdev
jstoker has joined #osdev
junon has joined #osdev
<heat>
whew, good progress today
<heat>
refactored the way I created address spaces and how they existed
<heat>
now they're all independent from the struct process itself and can be shared
<heat>
added vfork() as a PoC
Ellenor has joined #osdev
<clever>
heat: no-mmu linux is also vfork only, the lack of an mmu makes true fork impossible
gildasio has quit [Remote host closed the connection]
cultpony has quit [*.net *.split]
les has quit [*.net *.split]
nickster has quit [*.net *.split]
buffet has quit [*.net *.split]
Bitweasil has quit [*.net *.split]
colona has quit [*.net *.split]
cultpony has joined #osdev
les has joined #osdev
colona has joined #osdev
Bitweasil has joined #osdev
nickster has joined #osdev
buffet has joined #osdev
gildasio has joined #osdev
opal has quit [Remote host closed the connection]
<heat>
clever, yup
<heat>
although that's not something I'm aiming towards lol
opal has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
opal has quit [Ping timeout: 268 seconds]
opal has joined #osdev
<jjuran>
MacRelix doesn't use an MMU, but it has fork()
carbonfiber has quit [Quit: Connection closed for inactivity]
chartreuse has quit [Ping timeout: 268 seconds]
<mrvn>
heat: do you forward fork and vfork to clone?
<heat>
i have a clone right now but its not really clone so I'm forwarding fork and vfork in the kernel to a fork_internal that takes flags
gildasio has quit [Ping timeout: 268 seconds]
heat has quit [Ping timeout: 244 seconds]
gildasio has joined #osdev
<geist>
clever: you can, but it sucks
<geist>
also in that particular case it's situation where the kernel and user space have to share an irq
<geist>
so it's ucks to have to build all that infrastructure in for this one stupid case
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 252 seconds]
<clever>
geist: yeah
<clever>
the only other case that springs to mind, is legacy pci
<clever>
where you basically have just 4 irq's shared across all pci slots
<clever>
but, are you really going to make a microkernel, for such an old system?
<geist>
well, again, sharing pci would be unforunate, but as i say it's mostly because of sharing kernel and user that is extra trick
<geist>
sharing multiple user irqs is annoying, but already a thing you do
<geist>
user + kernel gets into some tricky 'kernel is stuck waiting for user to respond' kinda nonsense that is probably doable, but seems fairly complicated on the surface
<clever>
and if the kernel is writing to a PL011, yeah
<geist>
exactly
<clever>
the PL011 is fairly standard, and if the kernel needs one for the debug console, you might as well make the PL011 a kernel driver, not a user driver?
<clever>
so you can drive all of them from kernel?
<geist>
like you'd have to plan on user space taking it's time, or context switching overhead or whatnot, and make sure the kernel can make forward progress, etc
<geist>
that's exactly what i'm talking about
<clever>
but you still need to taint your kernel with platform specific irq detection, or do shared irq's
<geist>
a kernel driver sharing an irq with a user driver
<geist>
again probably doable, just something i'd *really* like to avoid fucking around with
<clever>
but if you already have a PL011 driver in kernel for the debug console, why make userland PL011 drivers?
<geist>
because user space may want to talk to another device over serial
<clever>
just spawn more instances of the kernel PL011, and expose it as a pipe to userland
<geist>
if only it were just that simple
<clever>
can the kernel not expose the same api as a userland serial driver?
<geist>
well, are you writing a microkernel or not?
<geist>
so now the kernel has *some* drivers that i has a driver api for?
<geist>
why draw the line at serial.
<geist>
seems like storage would work in the kernel too
<geist>
or how about usb, now yo ucan do kernel debugging over usb!
<clever>
because you already have serial debug console in the kernel?
<clever>
and yeah, it all depends on how you define micro
<geist>
sure, but why stop there?
<geist>
also i should point out that th eneeds of the kernel to drive serial are very limited
<geist>
vs what a full user driver might want to do
<geist>
(DMA, fast throughput, etc etc)
<clever>
yeah
<clever>
what if you just made it more micro, no PL011 from the kernel?
<geist>
and?
<clever>
now your not sharing an irq between kernel and user
<geist>
sorry i'm being obtuse here, it's late and i'm in like 3 conversations at once
<geist>
the answer is 'it's a pain in the ass, and i'd rather not discuss it ad nauseum'
<clever>
sure
<geist>
yes it can be done, its a series of challenges no matter how you slice it
<geist>
so it's a matter of finding the least worse design and going with it
<geist>
which is frankly, just no fun
<geist>
hence the 'ugh' factor going on here
<clever>
yeah, makes sense
<mrvn>
if you are making a mikrokernel why would the kernel take any IRQs?
Mutabah has quit [Ping timeout: 268 seconds]
<clever>
mrvn: is the cpu even capable of routing an irq to a specific userland process? isnt the kernel required to at least partially respond to the irq, and then context switch to that process?
<geist>
mrvn: timers, perhaps serial data for kernel loggic
<geist>
mrvn: inter processor interrupts
<mrvn>
clever: yes, entry.S would be kernel and then forward to userspace
<clever>
pre-emption timer and ipi are 2 cases you basically cant implement in userland
<mrvn>
that's the 2 cases I have too but I don't see them getting shared with user space like an UART
<geist>
bingo. this is why i was bitching about this whole damn thing
<geist>
the stupid braodcomm chip puts multiple devices on the same IRQ because they were lazy
<geist>
and it just so happens one of the IRQs the kernel will want to use is also shared by something else in user space
<geist>
so now you have to muddy the whole kernel design to deal with this *one* case
<mrvn>
pre GIC you have that big 2x 32bit IRQ mask that you have to check to decode what interrupt happened.
<mrvn>
plus another 32bit register. So 96 bit overall
<clever>
mrvn: and you still have 64 hardware irq's, fed into the GIC, 1 of those 64 is shared across all of the PL011's
<clever>
and you have to read a non-standard register to know which PL011 caused the irq
<geist>
right, so the instant the kernel wants to use one of the serial ports, either it has to run it in polled mode (ugh) or if user space wants to use a serial line too (actually pretty common) then you have to invent some scheme to deal with irq sharing between the two
<geist>
and thus an annoying new stupid kernel feature has to be born for this one lazy case
<clever>
or implement that non-standard register, so you can split the irq up into virtual irq's
<clever>
and then route it properly
<geist>
right, and what clever just said already means 'custom irq driver in the kernel for this'
<geist>
ughhhhhh
<mrvn>
maybe I'm missing something but I already have that custom irq driver to handle the VCs interrupts on RPis.
<clever>
mrvn: when using the GIC, i believe you can ignore the VC irq controller entirely
<mrvn>
except for uart aparently
<clever>
so you can just use a standard GIC driver on every arm board
<clever>
yeah
<clever>
so your "micro" kernel gains a bit of rpi specific bloat
<mrvn>
I use the VC timers so that's already a big RPi specific kernel driver.
<geist>
i'm trying to avoid that, but *again* this is doable
<mrvn>
(for the scheduler)
<geist>
just ugh. can we please quit beating this dead horse?
<geist>
or whatever. i'm just frustrated
<clever>
mrvn: on pi0/pi1, the VC timers are the only option, but the VC itself is using some channels, so the arm only has 1 channel available
<mrvn>
geist: you use some timer in the GIC, right?
<mrvn>
clever: 2 channels
<geist>
there is no timer in the gic
<clever>
mrvn: pi2 has 4 arm cores, so how do you set a unique timer on each core?
<clever>
but pi2 and up (including pi4 with gic), has the standard arm generic timer
<clever>
and that generates core-local irq's, that can go thru the GIC
<mrvn>
clever: I need to work on that one. Currently I have some ugly code so the timer is shared between cores
<geist>
anwyway, this is acase where the microkernel stuff works against you
<geist>
for LK, for example, all of this doesn't matter at all
<geist>
would jsut write some code that's like 'yolo i know how this irq controller works, get it done'
<geist>
already have somewhere, i think
<clever>
platform/bcm28xx/interrupt.c in your main LK i believe
<clever>
it also supports IPI's for SMP mode
<geist>
honeslty it's been years since i booted one. i think i ended up putting all my rpis to use somewhere so haven't had one floating around to hack on
<mrvn>
for me all that is purely a kernel problem. I don't have that "call the IRQ in user mode" thing geist mentioned. Don't thing ARMv6/7 can do that.
<clever>
yeah, and RPF had broken LK in that time
<geist>
clever: feel free to roll changes back
<clever>
by starting the kernel in HYP mode, when your code assumed SVC mode
<mrvn>
s/thing/think/
<clever>
i believe you already merged the PR fixing that
<geist>
on which rpi?
<clever>
any 32bit capable model
<clever>
so all of them i believe
<geist>
ah, except armv6 becaus ei dont have support for that in mainline
<geist>
so rpi3-32 rpi3-64 and rpi4-64
<geist>
er wait not. rpi2 is armv7. never mind
<geist>
it's rpi1 that i wont support anymore, because armv6
<mrvn>
That rolls over in 584542 years, I think you can forget the rollover there. Unless you ment that ST_CLO can rollover which makes your time jump back 20 minutes.
<mrvn>
You have to read ST_CHI and then loop reading ST_CLO + ST_CHI till ST_CHI doesn't change
<clever>
mrvn: yeah, the whole lk-overlay is for running LK on the VPU, both in .bin and .elf forms
<clever>
ST_CLO rolls over every ~72minutes, there is an un-accounted issue here, where reading CLO and CHI at once, they may be out of sync
<clever>
the CLO read may happen before the rollover, but the CHI after the rollover
<clever>
depending on the order, it can basically return one of the following 4 values, 0x00, 0x0ff, 0x100 or 0x1ff
<clever>
this problem happens any time you expose a 64bit counter as 2 32bit registers
<clever>
some platforms are documented well and will latch the other half, if you read it in the right order
bauen1 has quit [Ping timeout: 268 seconds]
bauen1 has joined #osdev
justache has joined #osdev
woky_ has quit [Quit: Nothing in this world is hopeless!]
woky has joined #osdev
woky has quit [Client Quit]
woky has joined #osdev
Mutabah has joined #osdev
<mrvn>
clever: hence the need to read HI, LO, HI and see if HI changed.
<clever>
yeah, thats one solution, for when you can assume nothing is latching
<clever>
and thats what the comment is in reference to
<mrvn>
The way your code is now you can get 0x0fe .. 0x0ff ... 0x000 ... 0x101
<clever>
it also depends on what order the compiler decides to do the 2 loads
<mrvn>
I assume the REG macro has them volatile and then it's left to right
<mrvn>
iirc
<clever>
ah
<mrvn>
at least in c++ the infix operators have a specified order.
<mrvn>
(and not all the same which you can use with template packs)
<clever>
haskell also lets you define any arbitrary function as being infix, so you can declare that `f` should be used as `1 f 2`, rather then `f 1 2`
<clever>
but you can also use 1 `f` 2, to turn normal functions into infix functions
<mrvn>
In ocaml any function starting with an infix operator as prefix is an infix operator.
<mrvn>
I find that much more readable than having random functions be infix all of a sudden
<clever>
haskell also lets you define your own priority, so if you do `1 f 2 x 3`, it can parse as either `(1 f 2) x 3` or `1 f (2 x 3)`
<clever>
depending on the priority assigned to both f and x
<clever>
and yes, such power must be used with care, so as to not make the code totally unreadable
<clever>
same as pointers in c, the language offers more features, some of which can be used to shoot your own foot off
<kof123>
"enough rope to shoot yourself in the foot" -- title of an old c book
<clever>
`HM.lookup key fcfApiKeys` this chunk of code takes a key, and a hashmap, and then returns the element at that key
<clever>
case (key `HM.lookup` (fcfApiKeys fsConfig)) of
<kazinsal>
I once heard C++ described as "a language for constructing byzantine footguns"
<clever>
this also does the same thing, with the same map, but i randomly decided to use the infix version
sikkiladho has joined #osdev
<kazinsal>
Ah, no, other way around. C++ is a language composed of byzantine footguns, and by extension, C is a language for constructing them.
<mrvn>
In ocaml it's mainly fgor operator overloading I think. You can't overload + for different types but you have + for int, +. for floats and you can define +< for saturating add for example or any other thing that starts with + with the same precedence, pirority, associativity, ... as +
<clever>
ah, here it is, every heap object in haskell has a header and a payload, in a non-profiled build, the header is just a single pointer to an info structure, that describes the type
<mrvn>
similar in ocaml except it's a single word containing all the info
<clever>
that info structure, then defines the layout (where pointers to other heap objects are in the payload, for GC tracing), the closure type, an SRT bitmap (more gc stuff?) and then is followed by some executable code
<mrvn>
and it's the p[-1] to get the header
<mrvn>
if the GC has that info structure that says which fields are pointers then why are ints 30 bit?
<mrvn>
Doesn't sound like the int should have need for any extra tag bits.
<clever>
yeah, thats why i'm confused
<clever>
i believe a large chunk of the type-safety stuff is compile-time only
<clever>
so a function is only ever called with the right type, and a lot of template style action is going on, compiling the code differently, depending on the type passed in
<clever>
so you might define a function as `double :: Num a => a -> a` and `double x = x * 2`
<clever>
and that doesnt directly create native code
<clever>
only when you run the function on something like a Word16, or an Int, does it compile it to call the type specific implementation of *
<clever>
and also cast the literal 2, to the right same type
<dminuoso>
clever: No?
<clever>
dminuoso: to which part?
<dminuoso>
clever: The last few parts
<dminuoso>
Outside of specialization rules, this is implemented as dictionary passing. So `double` *has* native code that ends up calling a method of a dictionary that, at runtime, will be passed to it.
<clever>
ahh
<dminuoso>
It's very much comparable to vtables in C++
<clever>
but might it optimize more later on?
<dminuoso>
Not quite "later on"
<dminuoso>
It has to this ahead of time, in fact.
<clever>
i still havent learned all of the ghc internals
<dminuoso>
So under some circumstances GHC can generate multiple implementations of double, one that is the generally polymorphic one, and then a few other implementations specialized to say Int
<dminuoso>
All these will be included in the object files, and their presence is indicated in the interface files.
<dminuoso>
So GHC can then generate optimized versions of `double` for say Int (and then even include their definitions in the interface file for cross-module linining), but they would only be picked if a call to `double` at type Int was found
<clever>
ah
<clever>
what about a case like this?
<clever>
handleStaticFile :: Text -> Servant.Handler Text
<clever>
handleStaticFile = pure
<clever>
dminuoso: what would this compile into?
<dminuoso>
clever: It will most likely inline the pure method of the Applicative instance of Handler (or generate a call to it)
<dminuoso>
That's why the instance has to be in scope
<clever>
yeah, and also why it complains about orhpaned instances
<clever>
so force you to put them all in an easy to find place
<dminuoso>
Well, not as much as "making them easy to find"
<dminuoso>
If you have orphan instances, it would allow for situations where you might have 2 different instances for a given type - but instead of erroring out with a conflicting instance, you could have situations where two separate parts of the program might be using these different instances
<clever>
eek!
<clever>
and you also confuse users, because instances only work if you import an "unrelated" module
<dminuoso>
Or worse, work differently. :-)
<dminuoso>
By the way, whats fairly cool about the specialization rules above, is that it facilitates whole-program optimizations at a high level
<dminuoso>
You get the combined benefits of polymorphic code across modules, but with the performance potential of specialized in-module code
<clever>
yeah, thats what i was expecting from all of that polymorphic code
<mrvn>
clever: The problem is that a function might get a "Num a" argument or from some data structure and call another function with it. Then it just passes the dictionary through. Only when the compiler can deduce what the actual type is can it call the optimized function.
<mrvn>
Not sure how it works with data structures. Is the dictionary part of the type info pointed to by the header?
<dminuoso>
mrvn: The dictionary becomes a proper function argument.
<dminuoso>
You can read `Num a => ...` as another parameter if you wish, its fairly close to the core representation
<mrvn>
but where does it get the dictionary from when you get the Num a from a data structure?
<dminuoso>
mrvn: the caller site has to supply it
<mrvn>
could be from a global
<dminuoso>
Can you elaborate on "when you get the Num a from a data structure"?
<mrvn>
let all_my_nums = [] to create a Num list
<mrvn>
or a tree or dictionary or something
<dminuoso>
You mean a polymorphic list of type `Num a => [a]`?
<mrvn>
more an universal list
<dminuoso>
What do you mean by universal list?
<mrvn>
A list containing a mixture of things that have the type class Num a
<dminuoso>
Ah, that would be an existential type
<dminuoso>
Yes, we can have that too
<mrvn>
I think existential would have all items in the list the same type
<dminuoso>
Nope
<mrvn>
either way you somehow have to store the dictionary of the Num a methods along with the value.
<dminuoso>
mrvn: Yeah, the constructor essentially contains a pointer to the dictionary.
<dminuoso>
But thats only the case for existential types (or GADTs)
<dminuoso>
In general, data structures do not have pointers to such dictionaries - the dictionary is just in scope (its a global variable that the compiler can only see)
<mrvn>
That's something ocaml lacks. GADTs only have tagged unions but no pointer to a module implementing the types methods.
<mrvn>
If you need it you have to include that by hand
<mrvn>
manual type classes
justache has quit [Remote host closed the connection]
foudfou_ has joined #osdev
justache has joined #osdev
<dminuoso>
In general Im not too happy with the state of typeclasses in Haskell.
foudfou has quit [Ping timeout: 268 seconds]
gildasio has quit [Ping timeout: 268 seconds]
frkzoid has quit [Ping timeout: 268 seconds]
justache has quit [Remote host closed the connection]
justache has joined #osdev
justache has quit [Remote host closed the connection]
justache has joined #osdev
justache has quit [Remote host closed the connection]
justache has joined #osdev
<mjg>
sup
<mjg>
some time ago i mentioned how polish tv plays non-native movies et al
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
Ellenor is now known as Reinhilde
srjek has joined #osdev
HeTo has joined #osdev
terminalpusher has joined #osdev
justache has quit [Remote host closed the connection]
justache has joined #osdev
zid has quit [Ping timeout: 268 seconds]
the_lanetly_052 has quit [Ping timeout: 248 seconds]
zid has joined #osdev
mimmy has joined #osdev
zid has quit [Read error: Connection reset by peer]
zid has joined #osdev
<mrvn>
When I run "ypcat passwd" I see users but "getent passwd user" gives no entry. Any idea what could be wrong there?
<GeDaMo>
You don't have a user called user?
<mrvn>
the user shows up in ypcat
<GeDaMo>
does getent passwd show all the names?
<mrvn>
everything but nis. But I found it: libnss-nis wasn't installed. Seems that's no longer a dependency (of nis?) in jammy and needs to be installed manually.
<mrvn>
back to on topic discussion. :)
chartreuse has joined #osdev
mimmy has quit [Ping timeout: 256 seconds]
mimmy has joined #osdev
mimmy has quit [Client Quit]
sikkiladho has quit [Quit: Connection closed for inactivity]
heat has joined #osdev
ghee has joined #osdev
ghee has quit [Remote host closed the connection]
muffin has joined #osdev
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
nyah has joined #osdev
muffin has quit [Quit: WeeChat 3.5]
sikkiladho has joined #osdev
terminalpusher has quit [Remote host closed the connection]
<mrvn>
c++ ranting: Why isn't `a.foo` equivalent to `[&a] (int i) { return a.foo(i); };`?
<mrvn>
where is the type for a bound member function?
frkzoid has joined #osdev
<immibis>
because it's c++
<immibis>
also it could be overloaded - which one?
CaCode has joined #osdev
<mrvn>
immibis: all of them
<mrvn>
wouldn't it be cool if you could assign a template to a variable and have the compiler deduce the set of function by how it gets used later?
CaCode_ has joined #osdev
CaCode has quit [Ping timeout: 256 seconds]
CaCode- has joined #osdev
CaCode_ has quit [Ping timeout: 268 seconds]
<immibis>
How many bytes would the variable occupy?
<mrvn>
immibis: function pointer * prototypes
<immibis>
so the type is different for each function?
<mrvn>
nothing new, lambda has that already
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
* geist
yawns
<geist>
morning everyone
* gog`
slides a bagel to geist
<geist>
om nom
<zid>
That'll be $50
<zid>
(for the antidote)
<gog`>
i have an antidote for 44.95
<gog`>
we will not be undersold
<zid>
Joke's on you, I am the wholesaler
<immibis>
mrvn: if you already know the function based on the type then you don't need to store the function, only the object on which you call it
<mrvn>
why would I know the function from it's type?
<immibis>
you'd have a foo_pointer type
<immibis>
since the type is different for each combination of function name and overloads
<immibis>
(there's not much point differentiating it based on overloads and not name since generally functions do have different overload sets)
gmacd_ has joined #osdev
<mrvn>
but `foo` would be an identifier, not a type. So `foo_pointer type` makes no sense
<mrvn>
Note that lambda has a unique but unspecified type
<mrvn>
you can only "auto" it.
gmacd_ has quit [Ping timeout: 248 seconds]
<mrvn>
The way c++ is going I wonder when "auto" will deduce the type from the variables usage instead of just it's initialization.
<geist>
given that rust does that now i imagine there's some amount of pressure to do that
<mrvn>
void foo(int &x) { x = 0; } auto a; foo(a);
<mrvn>
geist: functional languages have been doing that for decades.
<geist>
okay, my point is now that more people are exposed to it they'll want it
<mrvn>
I just see c++ getting more and more functional elements.
joe9 has quit [Quit: leaving]
<immibis>
"Note that lambda has a unique but unspecified type" yes so it we give it a name, your example foo lambda is a_foo_int type
nyah has quit [Quit: leaving]
SGautam has joined #osdev
wereii_ is now known as wereii
dude12312414 has joined #osdev
heat has quit [Remote host closed the connection]
gareppa has joined #osdev
heat has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
gareppa has quit [Quit: Leaving]
CaCode- is now known as CaCode
heat has quit [Remote host closed the connection]
heat has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
gildasio has quit [Ping timeout: 268 seconds]
gildasio has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 256 seconds]
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
GeDaMo has quit [Quit: A program is just a bunch of functions in a trenchcoat.]
gildasio1 has joined #osdev
gildasio has quit [Ping timeout: 268 seconds]
sikkiladho has quit [Quit: Connection closed for inactivity]