<kazinsal>
"You know what we need? An opcode to implement sed."
<bauen1>
kazinsal: so is there even a VAX opcode that isn't turing complete
<kazinsal>
honestly the VAX ISA is one of the most amazing things
<kazinsal>
it really is the peak of CISC
_eryjus has joined #osdev
<kazinsal>
the PDP-11 ISA was already CISC as hell but VAX pushed that in some fascinating new directions
<kazinsal>
people love to point at x86 and go THIS IS WHY WE NEEDED TO REINVENT NICE THINGS but there's some absolutely phenomenally complex things in the VAX ARM
eryjus has quit [Ping timeout: 260 seconds]
<kazinsal>
variable length bitfield instructions are neat though not gonna lie
programmar has joined #osdev
<programmar>
has anyone here ever faced the situation that live usb doesn't detect internal drive through fdisk ?
<kazinsal>
nope. try parted?
biblio has joined #osdev
rustyy has quit [Quit: leaving]
<programmar>
yep, also not detected
rustyy has joined #osdev
<programmar>
so weird
biblio has quit [Quit: Leaving]
programmar has quit [Remote host closed the connection]
dude12312414 has joined #osdev
thinkpol has joined #osdev
bauen1_ has joined #osdev
rustyy has quit [Quit: leaving]
bauen1 has quit [Ping timeout: 256 seconds]
dude12312414 has quit [Remote host closed the connection]
<geist>
the inner loop there where it's called val() on the object, looks like it's the same address
<geist>
ie, since the object has no fields it's decided to not actually do a VLA on the stack, and store a bunch of overlapping objects at the same address
<geist>
so it loads into x0 (this pointer for val()) the same address for each of the elements in the array
<geist>
so i thought classes couldn't be 0 bytes long and there'd be a minimum 1 byte sizeof()
<geist>
of course if you add anything to the class to make it nonzero bytes the codegen is different and it actually does a VLA by bumping the SP down a variable amount, etc
Burgundy has quit [Ping timeout: 256 seconds]
<geist>
kazinsal: also interesting that editpc instruction must have been there early on since it has a one byte opcode 0x38
<geist>
someone on the thread mentions it was written for COBOL. probably directly maps to something there
superleaf1995 has quit [Read error: Connection reset by peer]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
_eryjus has joined #osdev
eryjus has quit [Ping timeout: 256 seconds]
ElectronApps has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
smeso has quit [Quit: smeso]
smeso has joined #osdev
sdfgsdfg has joined #osdev
_eryjus is now known as eryjus
Lugar has quit [Quit: Bye]
[itchyjunk] has quit [Ping timeout: 240 seconds]
[itchyjunk] has joined #osdev
mahmutov has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
<Jari-->
morning
<Jari-->
Is there a command like Global Memory Copy in Linux?
<Jari-->
You can through a system call copy a memory region from PID to PID ?
<Jari-->
But now thinking, that's a bit risky.
<moon-child>
well, there's shared memory
<moon-child>
there is also mremap
<moon-child>
and I think macos has a thing to 'copy' huge chunks of memory by abusing vm
<moon-child>
but not sure exactly what you're looking for
<Jari-->
moon-child: looking for ways you can do kernel - application communication
<Jari-->
Messages good?
<Jari-->
I managed to do pretty awesome things with IPC InterProcess Communication. Like postman service. Basically it provided disk access, video, audio, etc. Those services for applications.
<klange>
What do you want to communicate? Most OSes, Linux included, offer many different options for different scenarios. If sharing large blocks of memory is your goal, then you want... shared memory.
<zid>
sockets for life
<Jari-->
klange: so shared memory is same for all applications, or it is multiplied and many areas depending on PID ?
<geist>
yah direct access to another address space is a security nightmare
<klange>
Shared memory usually works by having some handle to a particular "object". There's a few different approaches even within Linux. You can map to a file that may or may not exist, you can use the POSIX shm_open stuff which has its own namespace, you can have anonymous shared mappings that you pass around through a different IPC mechanism...
heat has joined #osdev
<heat>
I was reading the log from windows and I booted into Linux just to say that Linux does have syscalls to read and write from/to another process, process_vm_readv(2) and process_vm_writev(2)
<zid>
ReadProcessMemory not good enough for you? smh
<heat>
ReadProcessMemory is for cheat devs
<zid>
...more or less :p
<geist>
we actually have somethin exactly like that in zircon but we're actively trying to removei t
<heat>
process_vm_readv is for le epic linux developer chad
<zid>
The trick to inject code into a process in windows still amuses me
<geist>
used almost exclusively by debuggers
<geist>
key is with some sort of capability like system it's at least a little nicer, because you have to be able to get ahold of the handle to the process in the first place
<klange>
ptrace offers that but the standardized version is poorly defined because it only specifies transfers in "words".
<geist>
NT included
<moon-child>
geist: didn't you tell me such a process can be used to recover from faults?
<moon-child>
LIES
<moon-child>
(thread x dies; thread y gets spawned and told about it, and sets new ip for thread x?)
<heat>
ptrace is garbage and that's a fact
<heat>
every unix-like system has a different flavor of ptrace
<bslsk05>
github.com: toaruos/ptrace.c at master · klange/toaruos · GitHub
<klange>
no, the poke will fail because there's a writable check before that
<klange>
so maybe more the inverse, COW may break it if the process itself didn't do the write; and I guess there's also a toctou bug waiting to happen, but... whatever, don't care any more
<heat>
I kind of like how the freebsd ptrace works (PT_ATTACH attaches to everything, then you can see what thread caused the stop)
<heat>
I also like the linux ptrace but it doesn't really fit into my thread model
<heat>
PTRACE_ATTACH attaches to a pid, so a single thread if its multithreaded
<heat>
apparently a thread can't attach to one of its process' threads, according to llvm
<heat>
so the issue I was imagining with the freebsd approach isn't really there
<heat>
compiler-rt & libsanitizer have a need for a StopTheWorld function (which I currently don't have implemented) so I kind of need to think about that
<heat>
but I guess either the Linux or the FreeBSD approach would require a fork()
<heat>
*both
<klange>
I didn't really put all that much thought into it, I just wanted to get something banged out to demonstrate the concept.
<heat>
(for linux they don't fork but do a clone(2) with a shared address space to avoid any sort of COW but I'm not really into that)
sdfgsdfg has quit [Quit: ZzzZ]
heat has quit [Read error: Connection reset by peer]
[itchyjunk] has quit [Remote host closed the connection]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
the_lanetly_052 has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
sdfgsdfg has joined #osdev
<sham1>
Not incorrect. I'm impressed
ElectronApps has quit [Remote host closed the connection]
zaquest has quit [Quit: Leaving]
zaquest has joined #osdev
GeDaMo has joined #osdev
rustyy has joined #osdev
Burgundy has joined #osdev
kspalaiologos has joined #osdev
biblio has joined #osdev
<junon>
Hi everyone, hopefully everyone had a good near years :)
<junon>
new*
<junon>
This question probably oversimplifies things and I know the answer will probably be "benchmark it of course" but it's worth asking anyway: is a page fault going to be faster than a sysenter?
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
<Mutabah>
Unlikely
<Mutabah>
Very unlikely
<Mutabah>
syscall/sysenter are designed to be fast
<zid>
a page fault effectively *is* a sysenter
<Mutabah>
The CPU pipeline can see the transition coming, and can mostly predict around it
<zid>
it has to do all the same things, but now you have to deal with the page fault too
<Mutabah>
While a page fault is unexpected
<clever>
Mutabah: and why cant the cpu predict the fault, because its doing load several opcodes ahead, as part of normal prefetch logic?
<clever>
it could even be pre-loading the TLB for a store, before it knows if its going to commit or not
<zid>
I don't think it predicts either
<clever>
before the data is even known, it could have pre-converted the virt->phys, and posibly set a
<clever>
"will page fault" flag on the opcode
<Mutabah>
Eh, it can probably know it'll PF...
<zid>
but a page fault means invoking the OS' page fault code, which is going to be pretty heavy in most OSs
<Mutabah>
not 100% sure, but I don't think syscall is serialising?
<zid>
they both do a ring switch
<Mutabah>
a PF quite likely is
<clever>
zid: i think the question is ignoring whatever the os is doing, and asking purely about how quickly the cpu core can switch states
<junon>
^ correct
<junon>
This is before OS logic.
<junon>
I'm actually more curious if the PF will be slower than a sysenter.
<junon>
Should have worded it that way.
<junon>
I was optimistic in thinking it'd be faster.
<junon>
But speculation would lead me to believe it's about the same.
<clever>
things like spectre also show that page faulting doesnt always work right
<clever>
basically, its ignoring the permission flags, when pre-fetching data, and acting on it
<clever>
the real result will never be visible in a register, and it would have faulted if you got that far
<clever>
but the side-effects (loading cache lines) still happen
<zid>
I would *expect* a PF to be slower
<zid>
unless you fault injected the PF in which case it's at *best* the same speed
<zid>
The PF still has more cpu logic to do
* clever
heads off to bed
<junon>
Thanks for the info clever, sleep well :)
<junon>
hmm okay.
<junon>
what do you mean by fault injected here?
<junon>
you mean artificially raise a PF?
<junon>
anyway if that's the case, then wouldn't manual page management via syscalls on a mmap'ed region (e.g. from the fs) be faster than relying on page faults upon reads/writes?
<junon>
of course way more work on the application's end, but a slight performance improvement if there's a critical path, right?
<junon>
Or is page swapping doing something more clever than using PF?
<zid>
The speedup is because almost all anonymous mapped regions never get touched
<zid>
the pf is also a small part of the latency on that
<zid>
the major part is the actual allocation, page table modifications, etc
<junon>
gotcha so it's not so drastic compared to a sysenter that it's observably different in terms of performance
<junon>
corollary, it's outweighed by the rest of the collective operation
<junon>
If PFs aren't reliable though, that means mmaped pages also aren't reliable, right?
<zid>
pardon
<junon>
> things like spectre also show that page faulting doesnt always work right
<zid>
it always works correctly
<junon>
oh
<zid>
spectre was a side channel attack by measuring the *timing* of things, to measure the state the OS internals were in
<zid>
specifically, the branch predictor of the cpu was what was being timed
<zid>
Ever seen one of those scenes in a movie where they crack the password one character at a time with tense music? that's what spectre was.
<junon>
hahah
<zid>
Rather than having to guess every byte at once, it let you measure if things were happening 'too quickly' which meant the OS knew a thing you weren't supposed to
<zid>
and grab each byte
<junon>
gotcha okay
<junon>
this is good info, thanks.
<junon>
I'm drafting up a unidirectional IPC port design without syscalls for a microkernel. I'm heeding your (collective) advice and targeting amd64 first.
<zid>
yea just send IPIs with the lapics, done
<zid>
then cry because it's shit and slow ;)
<junon>
In this case there won't be IPIs. A port will be owned by a single processor.
<junon>
Well, at a time.
<zid>
'port'
<zid>
define port
<junon>
I want to investigate using INVLPG.
<junon>
Logical IPC channel.
<junon>
has nothing to do with CPU ports or networking.
<zid>
there's a logical ipc channel the hw supports natively, called IPI
gxt has quit [Ping timeout: 276 seconds]
<junon>
I understand, I don't want to use that.
<moon-child>
junon: hmm so how do you do it? ring buffers?
<moon-child>
what if you wanna wait?
<junon>
This is on top of any single particular CPU feature. It's a ring buffer design.
<zid>
how do you intend to snoop the cache invalidation protocol from the software side of a cpu? afaik there's no exposure
<junon>
moon-child: yep
<bradd>
can I access the serial port from uefi boot services?
gxt has joined #osdev
<zid>
well nothing is stopping you
<bradd>
(by using ports)
<moon-child>
junon: so what if I wanna wait?
<junon>
moon-child: working out the details at the moment but the idea is that if the reader reads from the head but the writer hasn't committed, the #PF will schedule the task for resumption (is that a word?) when the writer has done so
<junon>
in a highly async application, they can check the head/tail cursors directly and reap those benefits
<zid>
the pf will hit *your* cpu, btw
<junon>
right yep
<junon>
the pf is just a signal to the scheduler.
<zid>
so the question is still how you do the IPC
<moon-child>
how do you figure out when the writer writes?
<moon-child>
pay a page fault there too?
<junon>
if the channel is synchronous yes.
<moon-child>
bah! Not terrible but I don't like it :)
<zid>
still needs a way to actually do the IPC..
<junon>
However both ends are of course allowed to be async and spin on the head/tail cursors
dormito has quit [Quit: WeeChat 3.3]
<junon>
zid: there's a ring buffer of messages
<zid>
when do I check it?
<junon>
either in a poll loop (async) or you simply read the next slot and pay the #PF, which will schedule you to resume when the writer writes something (or a new slot opens up, if you're backpressured)
<junon>
the latter behavior is synchronous
<zid>
so completely manually?
<junon>
what do you mean
<zid>
while(1); I just crashed your entire OS?
<junon>
no?
<junon>
does while(1) crash any other pre-emptive OS?
<zid>
process calculates pi, it's now completely locked up and cannot be talked to no matter what?
<junon>
unless it's preempted.
<junon>
I don't see that as having anything to do with the IPC mechanism though.
<junon>
If an application doesn't consume messages from a port of course it'll backpressure
<zid>
I'll stick with signals
<junon>
okay
<zid>
and I still don't know what your actual mechanism is
<zid>
to do the real IPC
<junon>
zid: ring buffers and clever scheduling
<zid>
so, shared memory?
<junon>
yes
<zid>
you're going to eat a bunch of data structure walks in that code btw
<zid>
as you figure out what the fault was and why
<junon>
Perhaps but that would happen with a syscall too.
<zid>
no because the syscall is always caused by syscall
<zid>
the PF is caused by *someone* at *some* address for *some* reason
<junon>
True
<zid>
you have to figure those three things out for every PF
<junon>
Yes but the address isn't arbitrary
<moon-child>
the overhead of the syscall/pagefault is gonna be quite significant anyway
<moon-child>
so I wouldn't worry about it
<moon-child>
and anyway hash tables are fast
<junon>
the vmem layout would have a bounds
<junon>
especially since the ports are static.
<zid>
is this a paged memory fault? a user->kernel fault so the app needs to crash, kernel->kernel so the kernel needs to crash? etc etc
<junon>
they're defined prior to execution, in a metadata section
<junon>
zid: what do you mean
<junon>
paging is enabled in this case
<zid>
the pf handler is super generic, there's a lot of logic to turn it into an actual decision about what to do, first
<junon>
yes - the first of which is to fetch the current task structure and check if the address is within the IPC region bounds
<junon>
since those are known upfront and will not change.
<junon>
(for now)
<junon>
so it's a simple bounds check.
<zid>
on every PF
<junon>
yes
<zid>
so it also slows down swap and everything else, something to note
<junon>
yes, fair.
<junon>
Might be worth checking swap first.
<zid>
but now your IPC is slow :p
<junon>
The synchronous mode isn't meant to be fast per se, but to be a sane default.
<junon>
zid: only if the IPC is operating in synchronous mode.
<junon>
if you're polling head/tail cursors then there is no #PF in a well formed application.
<zid>
oh so they're just slow in general :P
<junon>
why would that be slow
<zid>
none of my apps have to poll
<junon>
okay
<junon>
many do
<junon>
it's the basis for io_uring
<junon>
so high throughput applications use this mechanism
<junon>
can use*
<zid>
it's just santioned shared memory, afterall
<junon>
there's absolutely no kernel involvement in such a case
<junon>
so it's opt-in performance gain
<zid>
shared memory is pretty normal
<junon>
yes
* moon-child
still wants language-oriented sasos
<junon>
the fallback case is when you try to read/write to a slot that isn't current available, either via backpressure (upon a write) or a drain (upon a read) in which a #pf occurs
<moon-child>
there's no reason ipc should only be free for async
<junon>
and thus you're pre-empting yourself
<junon>
moon-child: in sync you're still paying a syscall
<junon>
otherwise how do you signal to another task that something is available
<moon-child>
not if you run everything in a single address space you don't
<junon>
moon-child: that's a non-starter in this case, it's a paged OS.
<junon>
also I don't see how a SAS system would facilitate automatic synchronous IPC?
<moon-child>
can still do paging. But you have one vm map for everyone
<moon-child>
but switchign between processes has about as much overhead as switching between coroutines on a traditional os
<junon>
but on a SAS you lose memory protection between tasks, right?
<moon-child>
yes
<moon-child>
hence 'language-oriented'
<moon-child>
do your protectio in software
<junon>
that's if you trust the other processes running on the machine
<junon>
in my case, I do not
<GeDaMo>
The whole system is written in a language which enforces protection
<moon-child>
^
<junon>
ah I see
<junon>
even against malicious actors?
<moon-child>
depends on the quality of your compiler
<moon-child>
I have a half-written response to the same question on reddit so I'ma finish that and then link it
<junon>
but I can craft a binary that sidesteps the compiler?
<GeDaMo>
How?
<moon-child>
GeDaMo: buggy compiler
<moon-child>
js jits are all buggy
<junon>
oh the payloads are running in a VM?
<GeDaMo>
There can also be hardware bugs which sidestep protection
<junon>
that's different then. I thought you meant like a language that compiles to machine code
<moon-child>
yes, language that compiles to machine code
<GeDaMo>
It can still compile to machine code but with strict limits
<junon>
and how do you enforce those limits if not at the CPU level?
<GeDaMo>
At the compiler level
<junon>
aside from trusting the code itself to play nicely
<moon-child>
take js as an example. Js is not _capable_ of expressing memory-unsafe code
<moon-child>
and js is compiled to machine code
<moon-child>
hence, a faithful rendition of a js program in machine code _can not_ be memory-unsafe
<junon>
but I can sidestep the compiler
<GeDaMo>
How?
<moon-child>
how?
<junon>
unless you're literally compiling the code on each run
<junon>
locally
<moon-child>
well, you can cache it
<junon>
moon-child: JS is at best JIT'd. That's not compilation to a machine code executable.
<moon-child>
that's transparent from a user's perspective. But the system refuses to run code it didn't compile itself
<junon>
so you're performing compilation ad-hoc on the local machine, then?
<moon-child>
yes
<junon>
okay, that's the missing piece of info lol
<junon>
sure, if you control all aspects of codegen on your machine then you can do whatever you want
<moon-child>
you may compile from an intermediate representation (cf jvm bytecode), which will go much faster
<junon>
that's not my case for the IPC and thus I have to have memory protection and thus can't do SAS etc.
<junon>
Neat idea though :)
<moon-child>
so you are binary-compatible with an existing os?
<junon>
moon-child: nope
<junon>
maybe in the future I'll support something like syscall emulation modes since so far no syscalls are needed to interact with the system (on paper).
<junon>
but that's just wishful thinking.
<moon-child>
then why can you not force all programs targeting your os to be distributed in a memory-safe format?
<junon>
Because that limits languages that can be used.
<junon>
An explicit non-goal.
<moon-child>
ok
<moon-child>
(imo it is irresponsible to write in memory-unsafe languages. But I am still writing in c soooo I can't really say anything :P)
<junon>
I think it also increases surface area
<junon>
for exploits and whatnot.
<moon-child>
I have a compelling argument against that
<moon-child>
copy-pasting from the reddit comment:
<junon>
If another CPU vulnerability comes out at least it'll have a much higher mitigation priority since it affects nearly everyone. The same cannot be said for a proprietary engine.
<moon-child>
Given pervasive, expressive IPC (borne, of course, by the language-oriented SASOS), how much more likely will application developers be to architect their applications as clusters of communicating processes, each of which may have its own capabilities? Original post asked about microkernels. Currently, such designes are pursued only by the extreme (I mentioned djb) because they are slow, clunky,
<moon-child>
and annoying. (Surprise, surprise: unix failed, pipes suck. And erlang was a great success.)
<sham1>
"pipes suck" that's brave
<junon>
Erlang is successful because of its abstractions.
<junon>
I very much disagree with "pipes suck"
<moon-child>
pipes are completely void of inherent structure
<junon>
They alone improved performance in a number of dist-sys designs.
<moon-child>
any that you project onto them must be completely ad-hoc
<kazinsal>
erlang is successful because it was used to develop massively successful infrastructure when it was a proprietary language
<moon-child>
and they necessitate copying
<sham1>
moon-child: I'd also argue that it's their strength
<geist>
well, no because they are void of structure doesn't make them intrinsically bad
<moon-child>
so they do not scale. That's why shared memory exists
<sham1>
That you *can* project your own structure on them
<geist>
ipc and shared mem can work together
<junon>
moon-child: then by proxy UNIX sucks, because pipes were one of the first things put into UNIX and strictly follow the "everything is a file" philosophy.
<moon-child>
yes, unix socks
<geist>
hard to have a solid pro-con discussion when people start throwing out thigs like * sucks
<kazinsal>
all computers suck. sand was not meant to think
<GeDaMo>
Yes, asterisks suck! :P
<moon-child>
geist: fair enough
<geist>
yeah it quickly devolves to repeat ad adfinium
<junon>
I think that's a rather broad dismissal of unix...
<junon>
also, hi geist
<geist>
hola
<moon-child>
'That you *can* project your own structure on them' that is a valid argument. I think that there is definitely value in common data structures, but that pipes just don't give you enough to work with
<GeDaMo>
Do kids still say things "suck" or is that just old people projecting? :P
<moon-child>
and would contrast them with apl's multi-dimensional arrays, which _do_ have enough structure (imo) to be useful
<junon>
they do
<geist>
they probably compare them to a can of beans
<geist>
and yell PETER
<geist>
gen z humor is on some other plane
<junon>
ayo unix pipes aint it no cap
* junon
dabs ironically
<GeDaMo>
I still don't know what "dabbing" is :|
<kazinsal>
despite only being a couple years older than the oldest zoomers I do not understand like 90% of what people younger than me post on the internet
<geist>
is that the hand motion with one hand pointing up?
<moon-child>
another criticism I have of unix is that it is stratified. The compiler is a file, and the executables it generates are files; but the internal data structures that the compiler uses are not files, and it would be impractical to write a compiler that did use files. Contrast with lisp, where the compiler is a first-class object, the code it compiles is a first-class object, and the internal data
<moon-child>
structures it uses are also first-class objects
<junon>
doing this pose, usually in very quick succession
<sham1>
I mean, pipes allow me to do something like this: tar -czf - file1 file2 fileN | ssh target-machine 'cat > backup.tar.gz' and other such assorted tricks. Of course you'd actually use rsync for this, but think about it. Pipes and SSH and such are these dumb things that you can only carry bytes through
<junon>
borne out of a rap video. was cool for about 10 minutes then it's done ironically now
<GeDaMo>
That looks like he's sneezing into his shoulder :|
<sham1>
moon-child: I'd say that Smalltalk does thateven more
<junon>
GeDaMo: aha, that's applying logic to a pop trend. don't do that.
<kazinsal>
gen z twitter is like, Weird Twitter filtered through a combined haze of anxiety, neo-cold-war-existentialism, and research chemicals
x88x88x has joined #osdev
<moon-child>
sham1: smalltalk is cool, though I have not used it so I can not say anything about it
<geist>
dlang. dicuss.
<junon>
geist: great idea, poor execution
<junon>
not terrible, just poor
<sham1>
I like the GC idea
<sham1>
But other than that, D is a bit too C++ for me
<moon-child>
geist: good implementation of c++, but why would you want any implementation of c++ at all?
<geist>
yah i honestly have no opinion, but someone was asking me about it today
<kazinsal>
great idea but by the time it was potentially a thing that could have caught on mozilla showed up with rust
<geist>
yah i assume rust has sucked whatever air out of that room
<junon>
D was way before Rust FWIW
<moon-child>
I don't like rust. Affine types are counterproductive imo
<junon>
but the D maintainers held some philosophies and made some breaking changes that pissed a lot of its community off.
<junon>
That's a crude history in a nutshell.
<moon-child>
junon: yeah but it wasn't completely opensource until more recently
<kazinsal>
yeah but people didn't really seem to *want* that kind of safe multi-paradigm systems programming language until whenever it was rust showed up
<geist>
i'm not sure they want it now but they're being mindwashed into thinking so
* geist
dabs
<kazinsal>
boom
<junon>
haha
<moon-child>
rust had really good marketing, and an ocaml type system
<sham1>
kazinsal: that's because Rust has a marketing budget, yeah
<junon>
the rust shills alone turn me off from it
<moon-child>
most people who are using rust would probably do better to use ocaml
<junon>
I've seen people legitimately argue that Rust code is completely bug-free
<sham1>
Meh, that's people just being overly enthusiastic
<moon-child>
ada has been around since way WAY before rust too, fwiw
<kazinsal>
if rustc just emits a blank file when you feed it a blank file that might be considered bug-free code
<sham1>
Also, as was already mentioned, lisps
<geist>
i generally just see that sort of thing as pretty standard newish/junior/inexperienced programmer stuff
<geist>
the assumtion that new tool/paradigm/style/language/feature is going to fix all the prior problems is inexperience
<junon>
cc -o/dev/null
<junon>
bug free C
<geist>
doesn't mean new things *arent* good. but they never fix all the problems
<junon>
guaranteed
<kazinsal>
yeah
<geist>
and it's dangerous to rely too much on it
<GeDaMo>
I think your command has a bug :P
<kazinsal>
some things stick around. some things don't
<junon>
Plus Rust slows down development tenfold
<junon>
"but that's a feature!" not really
<kazinsal>
it'll be interesting to see if rust/swift/go/other new hotness here continues to be mainstream in 2030
<sham1>
rustc relies too much on llvm for optimisation
<junon>
I refuse to touch swift until it has a solid cross-platform story.
<junon>
I don't want another gnustep.
<moon-child>
sham1: my understanding is rust relies a lot _less_ on llvm for optimizations, compared with other languages that target it
<kazinsal>
I've given up on the hope of the python/pip ecosystem dying
<moon-child>
junon: haha
<kazinsal>
I have personal syntactical grievances with python but I'm okay with it existing
<kazinsal>
I'm not okay with pip.
<sham1>
moon-child: well it's more that Rust emits somewhat "poor" LLVM IR, and that's part of the reason why the compilation takes an eon, since LLVM is then trying to optimize it
<junon>
I'm tired of people using python for web applications
<moon-child>
kazinsal: haven't used python seriously, what's wrong with it?
<moon-child>
sham1: I see
<junon>
I was on a django project and wanted to die. It made me feel stupid.
<kazinsal>
syntactically I really dislike significant whitespace
<moon-child>
same
<sham1>
Yah. Not a fan
<junon>
I like it, personally. If it's done right.
<moon-child>
(what I really want is structural editing. But considering the reception my views on pipes got, I will not say any more :)
<kazinsal>
the language is designed under a philosophy of "if the code looks good it's good code"
<j`ey>
moon-child: im not sure why affine types are bad, that's what Clone is for in rust, to not have affine types
<sham1>
Indentation is good. But mandatory indentation for semantics? Nah
<junon>
moon-child: I actually agree with you.
<junon>
But good luck getting editor support.
<junon>
with structural editing, syntax wars go away
<junon>
linting goes away
<sham1>
moon-child: well I agree with you on structural editing. Paredit and such are nice, although I've never gotten used to them even when doing Lisp stuff
<moon-child>
j`ey: you should not be required to copy things
<kazinsal>
the typing system is also... questionable, enough so that there are about half a dozen different implementations of static type analysis systems
<junon>
weird syntax-related bugs go away
<moon-child>
junon: yeah, have to ditch editors. But, look at how much effort was expended on visual studio and intellij. Bet a really good structural editor would be just as good and orders of magnitude less work
<j`ey>
moon-child: not be required to copy things.. when?
<moon-child>
j`ey: when you want to share them
<junon>
the problem is editor support and version control. Text-based diffing goes out the window unless you use a text-based storage format.
<j`ey>
moon-child: you dont have to copy them in that case
<j`ey>
you can give a reference
<sham1>
Well you could diff on the AST
<moon-child>
junon: ah, yeah, diffing is a problem. Solvable, though. I saw a paper about it recently
<kazinsal>
and then we have the issue of pip, which largely has the same issue that you see in npm
<junon>
to be clear, structural diffing isn't the issue. It's how you store it in your VCS.
<junon>
e.g. Git would be ill-suited for it.
<moon-child>
j`ey: rust has some syntactic sugar thattaways, but you can not share an object mutably, and you have to _think_ about lifetimes even if you write non-mutating code; have to know when to write clone
<junon>
Unless you modified git's behavior to understand the diffs somehow.
<moon-child>
junon: I think git has a pluggable storage layer, though I may be wronga bout that
<sham1>
Of course, I don't know if I'd be comfortable for example doing lisp programming with a visual editor. Like for example Scratch might be the most popular language that is mainly used with actual structural editing, and that's terrifying
<junon>
Otherwise it might do some weird shit to your encoded source files and corrupt them.
<junon>
(We went down this path at Vercel once upon a time)
<moon-child>
vercel?
<kazinsal>
there are a number of things git is ill suited for but people shove all kinds of magical things into it
<sham1>
git-lfs
dormito has joined #osdev
<junon>
moon-child: unfortunately not.
<junon>
well, depends on what you mean
<junon>
custom object types = no.
<junon>
Just tried that the other day.
<moon-child>
sham1: scratch is a strawman. Look at e.g. hazel, fructure
<junon>
You can do it locally but good luck getting e.g. Github, Gitlab, etc. to accept a push.
<moon-child>
junon: I see
<moon-child>
sham1: even hazel and fructure I think do not show the full power of structured editing. Imagine structured search-and-replace (or just search) with wildcard ast patterns
<junon>
I wanted to implement git-based task management using custom objects within the trees. Git didn't like it.
<junon>
like attaching TODOs to things. Just as a prototype. was DOA.
<moon-child>
see, this is because unix is insufficiently composable, because files lack structure
<moon-child>
:)
<sham1>
I'd rather just have a tool that scrapes the source files for TODO comments
<junon>
sham1: tried that, it gets too messy trying to have things like threads, or linking to them with UIDs
<junon>
also inter-task dependencies was a feature I wanted (needed) and that's not possible with TODOs either
<junon>
what do you use? tuple of filename/line number? what if you change the line number? everything has to update
<junon>
manually put in an ID? that's messy and prone to human error
<junon>
etc.
<moon-child>
I also want some sort of weak pointer system. Basically what hypertext promised. Imagine linking to some part of the documentation or specification, and seeing what else links there too
<junon>
yeah
<sham1>
/ TODO (#id): Foo bar baz
<sham1>
You can have a tool generate the ID
<moon-child>
Should be able to just put in a reference to the spec, and the editor shows you that section when you ask
<junon>
sham1: and the human has to remember to run the tool
<junon>
has to have the tool available on the PATH, which means the tool needs to be available for their platform.
<sham1>
Well sure, but they can then automate it further by making it part of a standard TODO snippet thing
<junon>
what standard snippet thing?
<sham1>
This is mostly a social issue, not a technical issue
<sham1>
Well the snippet tool isn't universal, but like a project-specific template
<junon>
right, which means huge barrier to entry for cross-team interop
<moon-child>
it's a social issue in that you have to get everyone to use whatever environment you set up
<junon>
participating in the system means you have all the pre-reqs and understand the workflow
<moon-child>
but it's a technical issue in that you have to actually set up such an environment
<moon-child>
and such an environment does not already exist
<sham1>
Emacs
<junon>
hahahah
<junon>
no thanks
<junon>
:D
<moon-child>
emacs is good but it has no pointers
<junon>
no hate to emacs users, but I am not one of them
<sham1>
Sure it does. It has hyperlinks
<junon>
I still want to be able to use my pinky finger when I'm older
<moon-child>
including backlinks?
<moon-child>
and a mechanism for canonicalization and sharing?
<sham1>
Yeah
<moon-child>
junon: get a kinesis. All the modifiers on the thumbs :)
<junon>
I already have a....
* junon
forgot the name
<junon>
some other split kb with a bunch of meta-modes
<junon>
I'll stick with vim
<junon>
:D
<moon-child>
I use vim too
<moon-child>
BUT emacs is cool
<sham1>
I sometimes use Vim
* moon-child
has ctrl alt super shift compose space enter delete backspace on thumbs
<moon-child>
oh and esc
<junon>
which reminds me, I still need to get a tenting kit.
<moon-child>
should probably replace delete actually I don't use it that often
<junon>
in other news, lolbitcoin
<moon-child>
oh?
<moon-child>
did it crash?
<junon>
yes
<junon>
well, it's trending on twitter at least
wand has quit [Ping timeout: 276 seconds]
<junon>
I stay well enough away from all that these days but it always amuses me when people are surprised when they're reminded that cryptocurrencies are a volatile thing
<moon-child>
meh looking at 6-month price graph it looks pretty stable
<moon-child>
but yeah fuck cryptocurrency
<geist>
This year I’ll finally put something over the arrow keys on the keyboard and fully embrace using jkl; for navigation
<moon-child>
they stole the 'crypto' moniker. AND they're mainly used by fascists. AND they're a dumb use of power
<junon>
yeah
<moon-child>
I mean there are some interesting technological ideas, but they ... Do Not Work Out
<GeDaMo>
I think Kazakhstan banned bitcoin mining
<junon>
geist: hjkl
<junon>
not jkl;
<junon>
at least, I hope...
<moon-child>
geist can jkl; a little, as a treat
<junon>
we're talking vim bindings right?
<geist>
Yeah i was thinking that myself, on an ipad right now can’t visualize where it is
<geist>
But yeah those
<geist>
Plus the damn thing keeps wanting to autocorrect it
<junon>
I feel the pain, took me a while too when I first started.
<moon-child>
weird thing is I would feel crippled with any editor other than vim. But I don't use vi-mode in my shell
<sham1>
Working on Zirchon clearly makes you do unorthodox choices, like removing .. and using jkl;
<junon>
takes about a week to get used to, but you miss it when it's not there.
<geist>
I can use them okay, but i just don’t reach for it when trying to navigate
<moon-child>
so I also know all the readline^Wzle bindings
<geist>
My instinct is to still reach over for the arrow keys
<zid>
readline implements about as much vi as I actually know
<junon>
if you configure it to, yeah
<sham1>
readline^Wzle^Wemacs
<geist>
But last year, for example, i made a concerted effort to start using both shifts and both caps locks, as appropriate
<zid>
you can configure readline?
<sham1>
Yeah
<geist>
Prior to that i always favored one or the other
<junon>
though IME it's really hit or miss whether or not the readline implementation for a particular application really hoors it
<zid>
where at?
<junon>
zid: yeah
<junon>
sec
<junon>
.inputrc
<moon-child>
sham1: zle has some different behaviour (by default at least). Notably ^U deletes the whole line, not the part that precedes the cursor
<geist>
And i feel like a boss when I out of the blue use the best possible combination
<bslsk05>
'How China Conquered The Keyboard' by Johnny Harris (00:21:06)
<junon>
I think you can just type hiragana/katakana (probably katakana) and it'll allow you to replace things with kanji where necessary
<junon>
klange would know
<sham1>
The parts are not all called radicals in Japanese either
<zid>
I type english
<zid>
and it suggests kanji/hiragana/etc
<moon-child>
sometimes I feel like I'm the only person here who doesn't know japanese
<zid>
space to open a 'I want something else' box
<junon>
zid: do you know japanese?
<zid>
a bit
<junon>
oh neat
<sham1>
I don't know Japanese. I just happen to vaguely know how Chinese characters work
<zid>
If you watch a japanese person type, they often use the english conversion, rather than actual japanese
<junon>
I feel bad for trying to learn since I actually need to learn German
<zid>
which does exist
<junon>
since I... you know, moved here
<moon-child>
I wanna learn german too
<zid>
meh, germans all speak english
<moon-child>
oh I didn't move to germany lol
<junon>
moon-child: no you don't
<junon>
don't do it
<sham1>
zid: no they don't
<zid>
be one of those annoying immigrants who refuses to speak the local language
<junon>
zid: in berlin, yes. Not elsewhere
<moon-child>
junon: but one of my favourite authors writes in german
<zid>
sham1: anyone worth talking to does
<moon-child>
and I wanna read his stuff in the original
<moon-child>
two of them actually
<geist>
Not bold. Bold
<junon>
zid: every american ever >.>
<sham1>
zid: TIL airport staff isn't worth talking to
<zid>
they all know english
<zid>
They just refuse to talk to you in it
<geist>
Italic
<geist>
Underlined
<junon>
german is a language of 1000 rules and infinite exceptions
<junon>
to the point there's almost no point in the rules
<zid>
which makes it vastly simpler than english ;)
<moon-child>
wondering whether it's weechat, tmux, or xterm that's not rendering the bolds
<geist>
Germans like rules
<moon-child>
I think tmux
<junon>
yes but equally nonsensical
<sham1>
Something about Ordingun
<moon-child>
hm no, guess it's weechat
<moon-child>
(|ncurses)
<moon-child>
s/bold/italic/
<geist>
Oh interesting,the formatting actually came through?
<GeDaMo>
Some channels filter it out
<geist>
Now I’m curious how that got flattened to utf8
<moon-child>
underline and bold did
<ThinkT510>
bold rendered here in weechat
<geist>
I’m using IRCCloud app on ipad
<sham1>
Welp, time for my hot take since we talk about stuff like underlines and the inability to render them: I hate terminals. Shells? Good. Terminals? Nah
<junon>
"Mir ist heiss" = I am feeling hot. "Ich bin heiss" = I am attractive. Not a single German can explain to me why it's this way. It's just one of those things you accept.
<zid>
bold italic underline are just escape sequences in the irc proto
<moon-child>
utf8 doesn't have anything to do with it. It's low-range unprintable chars
<moon-child>
same things with actions
* moon-child
does x
<moon-child>
is sent as \x01ACTIONdoes x\x01
<zid>
yea CTCP is all \1
<junon>
sham1: I use wezterm on windows right now and it's probably the best I've used on any platform.
<geist>
Ah like colors. Good to know
<moon-child>
zid: that is not ctcp
<moon-child>
ctcp is client-to-client protocol
<geist>
Didn’t know irc had those
<geist>
Red
<moon-child>
yep red
<sham1>
geist: yeah
<junon>
geist: I think they're more like ansi escapes where they're not formally specified but are agreed upon by most clients
<junon>
and weirdly enough, it works on element (matrix client)
<junon>
neat
<sham1>
They are not ANSI escapes, but they were originally an mIRC thing that was just picked up by everyone else
<junon>
that's just utf-8 though so shouldn't be surprising
<geist>
I think those are just straight utf7
<sham1>
But yeah. The colour code of IRC is 0x03
<geist>
8yeah
<junon>
feels dirty to see emojis in irc...
<sham1>
Or ^C for colour
<junon>
that's like saying "alt-f4 for color" for irssi users
<zid>
/quit and /part were riding in a boat, /part got out, who was left in the boat?
<sham1>
/quit
<junon>
/quit
* junon
laughs in matrix
<junon>
DCC SEND 0 0 0 0
<junon>
that used to be a thing I saw
<junon>
would crash a lot of peoples' clients or something
<sham1>
Wait, people still do DCC?
<junon>
no
<junon>
at least I hope not
<junon>
trashfire from a security perspective
<geist>
Haha that’s awesome
<sham1>
Mmhm
<geist>
The quit/part thing
<junon>
most networks block it now
<zid>
I prefer
<geist>
Also don’t forget
<geist>
+++ATH
<zid>
omg the network blocks it
<zid>
I physically cannot send the string I want to send
<geist>
And the one modem somewhere some time that used to hang people up on the remote end
<zid>
X 5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
<sham1>
One thing I could see would be that with modern IRCv3 features like batches, one could define a modern file sharing sub protocol for IRC
<zid>
remove the space after the first X.. used to make norton boot people off irc
<moon-child>
junon: ^C is colour in irssi though
<sham1>
Just encode the files as base-64 and send them as a bunch of PRIVMSGs within a certain batch
<moon-child>
try ^C4hi^C0
<geist>
See if irc was as good as zmodem, you could upload *and* download *and* talk to the sysop at the same time!
<geist>
True multitasking!
<moon-child>
;o
<sham1>
:O
<sham1>
Modern ZModem revival when
<junon>
moon-child: oh
<zid>
discord has you beat, you can barely send messages at all
<sham1>
The end-game of Discord: To send messages you need to buy nitro
<junon>
Sorry you've reached the 2000 character limit. Please pay us ungodly amounts of money monthly to sent more bytes to your friend.
<geist>
But it can inline embed 50MB 3 second GIF videos
<geist>
So it’s all good
<junon>
geist: only if you pay ungodly amounts
<junon>
otherwise it only allowed 8mb
<sham1>
Discord is the zoomer IRC and it's annoying
<zid>
You guys are allowed to send messages?
<geist>
Haha
<geist>
I just type on it, hoping some day someone answers me
<moon-child>
I feel like there are some cool people that are only on discord, but the stn ratio is much worse, and I don't have the bandwidth for more than one chat service
<moon-child>
already have to use slack for work...
<zid>
mine goes "nope, greyed out text. 10 seconds later, red text"
<junon>
I got random CP DMed to me from a bot account I had no mutual servers with. I messaged discord about it multiple times with absolutely zero response.
<junon>
Dumpster fire of a service.
<zid>
because discord is ENTERPRISE
<sham1>
Remember when we had PMs, as in "Private Messages" Nowadays we have DMs, as in "Direct Messages". Really makes you think 🤔
<moon-child>
not so private any more :P
<zid>
anyone who uses discord with allow private messages from randos enabled is wrong
<sham1>
Mmhm
<geist>
But random are the spice of life
<geist>
You grind them up with a pestle
<junon>
zid: you can't get messages from randos
<sham1>
I use random unsolicited messages as a way to seed my RNG
<junon>
discord doesn't allow it
<geist>
Randos, damnit you autocorrect!
<zid>
you can if you allow it
<junon>
the only setting is if you share a server with them
<junon>
no you can't
<junon>
I'm looking at my settings right now
<geist>
NITRO
<zid>
server privacy defaults
<geist>
Pay monies for more randos
<junon>
zid: and the only two options there are "Allow direct messages from *server members*" and "Allow access to NSFW servers on iOS"
xenos1984 has quit [Read error: Connection reset by peer]
<zid>
yea, don't allow the former
<junon>
the bot that messaged me had no mutual servers
<sham1>
Also one thing that annoys me about Discord is how the rooms are called "servers" and the subrooms "channels"
<junon>
that was my point
<geist>
Oh i do that, i just don’t join servers where people are going to DM me garbage
<junon>
per discord's rules, they shouldn't have been allowed to message me
<junon>
at all
<geist>
Usually i join servers where i’d actually not mind talking to someone if they wanted to
<sham1>
Maybe they paid Discord a fat sack of cash
<zid>
most of the servers I am in require you to pay to join ngl
<sham1>
To be able to harass junon with unsolicited DMs
<junon>
to send highly illegal CSAM to random people?
<junon>
CP here = child pr0n
<geist>
sham1: yah it really tweaks me a bit too that it’s called a server
<moon-child>
what's a prawn
<geist>
It’s… not a server
<junon>
moon-child: adolescant shrimp
<junon>
(jk please don't actually make me spell it out)
<junon>
( inference, people)
<geist>
And on that bombshell
<junon>
geist: it's the cloud, so ofc it's a server
<junon>
just not yours
<moon-child>
well, it's part of a server
<moon-child>
or possibly multiple servers, depending on how many people are on it
<sham1>
Pornography depicting minors
* junon
sighs
<sham1>
I said it, not you
<junon>
anyway yeah discord refused to acknowledge it
<junon>
still upsets me
<junon>
also they never responded to my application years ago so still miffed about that
<junon>
not that I want to work there anymore anyway, but still
<sham1>
I see /u/spez of Reddit has upgraded in the world and apparently also does stuff with Discord considering the apparent inaction for CP
<junon>
spez shouldn't be doing anything on the internet
<junon>
aaron schwartz would cry if he saw what spez did to reddit
<sham1>
I think he does
<junon>
spez is also married to that one super famous tennis player
<junon>
in a weird marriage of worlds.
<junon>
almost as weird as the grimes/musk crossover
<sham1>
Wild
<junon>
yes
<junon>
anyway I'm all socialized out, these energy drinks aren't doing anything for my screwed up sleep schedule. I should nap.
* junon
waves goodbye and fades into the distance
<moon-child>
somebody asks: 'How do you create a graphics/widgets library like Qt?' And it's weird cuz I know how, but I haven't the faintest idea where I got this knowledge or what I could tell somebody that would be useful
<GeDaMo>
It involves boxes :|
<moon-child>
hey constraints are viable! Definitely!
kspalaiologos has quit [Quit: Leaving]
<sham1>
Nested boxes
<moon-child>
agh!!
<moon-child>
you mean a box
<moon-child>
inside of another box
<GeDaMo>
It's a tree of boxes!
<moon-child>
it's just not right!
<moon-child>
I respect people's right to put boxes wherever they like, but Not in front of my children!
* moon-child
tired, loopy
<sham1>
One thing I've semi seriously been thinking about is something like JSX but for C, wherein you can do things like widgets with a descriptive XML stuff and then embed C code, and have the XML embedded in the C code as well
<junon>
sham1: went down this path
<junon>
it's a lot of effort.
<junon>
also getting the syntax to not conflict is tricky, esp. for C++
<sham1>
I can imagine
<junon>
since there is an alternative lambda syntax that will make it hard to tokenize the jsx
<junon>
sec
<moon-child>
hmm, haven't actually touched jsx but
<moon-child>
I did a templating language with _really_ seamless lisp integration recently
<bslsk05>
stackoverflow.com: c++ - Is there any case, barring strings or macro invocations, where `(<` is a valid stream of characters? - Stack Overflow
<junon>
I asked that in the same JSX-in-C context.
<zid>
\*(<
<moon-child>
c++ :<
<zid>
//(<
<junon>
moon-child: if you want my opinion, use custom attributes.
<junon>
zid: that would get dropped by most parsers
<zid>
there were contraints? title just says C++ is there any case except x
<junon>
comments are not tokens
<moon-child>
junon: custom attributes?
<zid>
title doesn't say tokens
<sham1>
Although this is C++, and not C
<junon>
zid: > Assuming the translation unit has been pre-processed and no macros exist.
<junon>
pre-processed here implies no comments
<zid>
yes
<zid>
It just doesn't sayu that, I'm not incapable of reading I just didn't :P
<junon>
sham1: both languages have custom attributions
<junon>
attributes*
<junon>
C starting in C11
<moon-child>
oh the [[things]]
<junon>
c++ starting in... 14? I think? maybe 17.
<junon>
yeah.
<moon-child>
no c didn't get those until c2x
pretty_dumm_guy has joined #osdev
<moon-child>
which hasn't been standardised yet
<junon>
oh
xenos1984 has joined #osdev
<junon>
oh right yeah
<moon-child>
also I don't like them. Ugly :<
<junon>
Meh then don't use C
<moon-child>
I mean
<moon-child>
__attribute__
<junon>
no
<junon>
[[attribute]]
<junon>
the attribute is non-standard syntax
<sham1>
How does [[attribute]] make parsing XML not possible I wonder
<moon-child>
gcc should be enough for everybody
<junon>
GCC-specific
<junon>
sham1: it is possible
<zid>
/* fallthrough */ is my favourite non-standard but accepted syntax with semantic meaning
<junon>
custom attributes allow any stream of characters as long as parens match up
<sham1>
Oh good
<moon-child>
zid: yeah that's pretty good
<junon>
zid: new one is [[fallthrough]]
<moon-child>
zid: though I usually #define fallthrough __attribute__((fallthrough)) and undef it for non-gcc if I care ot
<sham1>
The only thing would be to somehow hook into the compiler to find the custom attributes, because they might be behind the preprocessor
<zid>
why do you keep trying to teach me C :(
<junon>
sham1: [[jsx(you can put anything here)]] jsx_t SomeElement;
<junon>
err, SomeElement();
<sham1>
Why would you do ()
<moon-child>
zid: because I'm a sadist
<zid>
not you, junon
<junon>
then if you don't pre-process them, worst case you get undefined linker errors
<junon>
sham1: elements are typically functions
<moon-child>
well, junon apparently is a sadist too
<zid>
ah
<sham1>
Hm, true
<junon>
functional components at least, not that react class-based shit.
<sham1>
I forgot about that
<junon>
plus you don't get undefined errors if you don't properly pre-process
<junon>
if you make them variable declarations
<junon>
(I've thought way too much about this fwiw)
<sham1>
One other way of doing this would be to do something like what yacc and lex do
sdfgsdfg has quit [Quit: ZzzZ]
<sham1>
So you make it a custom language instead
<junon>
don't do what yacc or lex do, they're awful
<junon>
:D
<moon-child>
^
<sham1>
I smell heresy
<moon-child>
raku has the _only_ good implementation of parser generators I have yet encountered
<junon>
raku appears to be a scripting language for perl
<junon>
does it output C parsers?
<sham1>
Raku is a separate language from Perl
<moon-child>
raku is perl 6
<moon-child>
but semantically it's much closer to ruby and common lis
<moon-child>
p
<junon>
It just looks like a generic BNF parser
<moon-child>
but it keeps its text-processing roots and improves on them, unlike everybody else who just clones pcre or posix re
<junon>
sham1: if you want a good one that integrates with C, use re2c
<moon-child>
junon: it's _very_ well-integrated with the language
<sham1>
Perl regexes were already absolutely disgusting with all the backtracks and such, and Raku just made it more
<moon-child>
and unlike say re2c or lex/yacc, doesn't require a separate build stage
<junon>
but it still requires perl
<moon-child>
not perl. raku
<sham1>
And when I said lex/yacc, I didn't mean using those but more just how those languages embed snippets of C code
<junon>
so... still requires a build stage.
<junon>
kinda.
<moon-child>
no
<sham1>
Well it's all integrated in the language
<sham1>
You dynamically change the language
<sham1>
Well you can do that anyway
<junon>
how did I get roped back here, I'm supposed to be napping
* junon
waves goodbye again
<moon-child>
night
* moon-child
is chronically incapable of napping. Really wish I could
<sham1>
You don't
<moon-child>
why?
<sham1>
Makes it harder to sleep at night
<zid>
moon-child has never slept
<zid>
he's better than us
<moon-child>
sham1: I have enough trouble getting to sleep at night as is, I don't think it can possibly get any worse
ZetItUp has joined #osdev
ElectronApps has joined #osdev
kaitsh has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ahalaney has joined #osdev
bauen1_ is now known as bauen1
wootehfoot has joined #osdev
nyah has joined #osdev
wootehfoot has quit [Quit: Leaving]
vdamewood has quit [Read error: Connection reset by peer]
sdfgsdfg has joined #osdev
vdamewood has joined #osdev
dennis95 has joined #osdev
srjek has joined #osdev
ElectronApps has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
ElectronApps has quit [Remote host closed the connection]
cln has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
wgrant has quit [Ping timeout: 240 seconds]
the_lanetly_052_ has joined #osdev
[itchyjunk] has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
xenos1984 has joined #osdev
dormito has quit [Ping timeout: 256 seconds]
mahmutov has joined #osdev
wgrant has joined #osdev
[itchyjunk] has quit [Ping timeout: 256 seconds]
gog has joined #osdev
[itchyjunk] has joined #osdev
Lugar has joined #osdev
heat has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 240 seconds]
dormito has joined #osdev
dennis95 has quit [Quit: Leaving]
epony has quit [Ping timeout: 240 seconds]
epony has joined #osdev
Oli has joined #osdev
heat has quit [Ping timeout: 252 seconds]
dude12312414 has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
ahalaney has quit [Quit: Leaving]
ahalaney has joined #osdev
Teukka has quit [Read error: Connection reset by peer]
<Oli>
gog! *I give you a hug* I am feeling content to see you around! *I inhale deeply once* Hello, and good day, fellows connected at this Internet relay chat channel!
<Oli>
Talking about fellows connected at this Internet relay chat channel, I find myself pondering about how doug16k is.
Teukka has joined #osdev
<Oli>
A wonderfully skilled, kind and assisting being who used to share by.
<GeDaMo>
Looks like Doug's last github activity was September
<gog>
hi Oli
<moon-child>
he was active for a bit after he disappeared from irc though. So that doesn't _necessarily_ signify anything
kaitsh has quit [Quit: WeeChat 3.3]
<GeDaMo>
Yeah, looks like he was on stackoverflow more recently
<GeDaMo>
I'm not a stalker, honest :P
<kazinsal>
he was eaten by a yeti in the frigid canadian wastes
<moon-child>
can confirm, am yeti
* gog
pets moon-child
Oli has quit [Quit: leaving]
* moon-child
grunts and screeches
GeDaMo has quit [Remote host closed the connection]