Kernel
Kernel copied to clipboard
TheLuaOSProject
I call cap, it is 95% C
WHERE IS THE LUA. I WANTED IT TO BE 99% LUA NOT C. WHERE IS LUA CSTDLIB???/??
WHERE IS THE LUA MALLOC AND THE LUA INTERRUPTS WHERE IS THE LUA BOOTLOADER WHY ARE YOU USING VSCODE??? USE LITE-XL BRUH
Fixed, d82913c2185522739286bf05c0cf6deb491314f5, however in the future the userland (the Lua bit) will be in a seperate repo
not fixed at all, should be reopened rn honestly it's still 100% NOT lua
the userland will be (mostly), trust me. You should start working on the userland to help out!
why not the OS?? luajit's fast enough and just use C to mem-manage. ffi is decent enough to where you kind of can do it
idk if luajit's fully dependent on FS or other OSCalls to compile lua but it would be pretty nice to actually have an lua kernel.
also sorry I'm an lua noob :p
why not the OS?? luajit's fast enough and just use C to mem-manage. ffi is decent enough to where you kind of can do it
idk if luajit's fully dependent on FS or other OSCalls to compile lua but it would be pretty nice to actually have an lua kernel.
also sorry I'm an lua noob :p
Userland will be lua, the kernel will be C, its too much of a hassle to do it with Lua in kernel, and the extra speed of C is needed
Yeah but Lua OS is fake ngl, I was attracted to this project because I thought you would use Lua in the kernel smh. Like for example in some of the things I listed above.
Yeah but Lua OS is fake ngl, I was attracted to this project because I thought you would use Lua in the kernel smh. Like for example in some of the things I listed above.
no that's stupid, using Lua for the userland is reasonable
where is lua cstdlib? You see, luajit needs a cstdlib to run. So, we need to make the cstd lib in C, so that lua can run.
where is the lua malloc... LuaJIT requires a memory allocator. You can't make a malloc in lua, because you need malloc for lua to work. Also, lua is single-threaded, which doesn't work for a data structure which needs to be accessed concurrently.
... and the lua interrupts We have plans to deliver interrupts to lua code, however, in order to preemptively switch between LuaJIT contexts, we need to have interrupts.
where is the lua bootloader I'm not crazy (yet), however, maybe i'll write support for freebsd's bootloader or something idk
why are you using vscode? use lite-xl bruhh I use sublime text, not vscode. I used to use lite-xl, before i switched to sublime because it was a 10x better experience.
IIRC frityet uses CLion mostly, so there's that.
I'm not a fan of Lite-XL - it's better than vim, but that is not a very high bar to clear. But code editors are really hard to get right, so it's not super surprising that lite-xl isn't all that great.
@pitust Thank you for your replies. It makes more sense, but I feel like you can definitely include Lua in some parts of the kernel source code, not just userland. I do realize that some of my previous demands were rather outlandish. It sounds cool that you're actually using Lua to code some interrupts, but I can see how LuaJIT relying heavily on the OS can lead to very messy call structure. The more I think about it, the more I realize that a lot of things in Lua need dynamic allocation, so just leaving the cstdlib out is out of the question.
It's cool that you tried Lite-XL, I honestly switched to vscode myself for heavier projects requiring JavaScript extensions and fast code-compile-test cycles.
Initially, my impression of this project was that major parts of the kernel, userland and low level parts in the backbone of an OS would be written in Lua, as it is called the Lua OS Project. Since there are many other open source kernels, I thought there would be no point in making another one if not written in Lua, so I hoped this one would use Lua to set it apart. I felt kind of cheated when there was little Lua in the actual codebase, so maybe clarify somewhere, even with a couple sentences, that this project is focused on providing an Lua focused userland instead of focusing on being written in the language itself. I still find this project interesting though, similar to other projects like the Hiblish shell. I have never written an OS, so I apologize for the arrogant comments I made on your guys' hard work.