<rooke>
So I need to pass a formatted string to a c library, currently what I'm doing looks like this: create a fixed buffer stream, use that with fmt.format to format the string, use cstr.addNullByte to turn it into a cstring, then pass it across. Is this the way to do this?
daurnimator has joined #zig
<forgot-password>
Is there an std function to create a slice from a pointer and a given length?
<ifreund>
rooke: you can just add a \0 to the end of your format string instead of cstr.addNullByte to avoid an allocation
<ifreund>
rooke: also, you might want to look at std.fmt.bufPrint or std.fmt.allocPrint0
<ifreund>
forgot-password: not to my knowledge, I've always just set the ptr and len fields manually
<forgot-password>
Oh, well, that does the job
<rooke>
ifreund, format complained about an invalid character when I added `\0`. I'll look into those two functions.
<forgot-password>
I didn't know you could do that
<ifreund>
rooke: hmm, \x00 would work if \0 doesn't
<rooke>
The allocation was what made me ask, it felt wrong that I needed that
gruebite has joined #zig
<rooke>
hah turns out I misunderstood the compiler complaint, just needed to get the ptr out of the slice :x
<ifreund>
you can do something like buffer[0..buffer.len-1:0] to turn it in into a [*:0]
<ifreund>
well, that turns it into a [:0] which coerces to [*:0] to be precise
<daurnimator>
leeward: I recommended AWS to a client recently... because there were no other options: no one else has an Australian data centre with a managed kubernetes offering.
<ifreund>
anyone know a robust way to waitpid(2) with a timeout?
<ifreund>
there's a hack where I could fork twice and have one of the process sleep then wait(null) and see which one exits first
<ifreund>
but that seems like, well, a hack
<daurnimator>
ifreund: use W_NOHANG
<ifreund>
ah nice, so just sleep(2) -> wait with NOHANG
<daurnimator>
and then sleep until SIGCHLD
<daurnimator>
ifreund: huh?
<daurnimator>
oh I guess you can sleep and actually respond to a signal
<daurnimator>
I'm too used to signalfd :P
<ifreund>
heh
<daurnimator>
ifreund: though modern linux has pidfd; which is better.
<ifreund>
hmm, I have never used pidfd
<daurnimator>
its quite new
aerona has joined #zig
<daurnimator>
> pidfd_open() first appeared in Linux 5.3.
<ifreund>
aye, quite new then :D
<ifreund>
I'd rather keep BSD support if possible so I'll probably pass
<daurnimator>
ifreund: but yeah; essentially W_NOHANG in a loop with a sleep/read in it somewhere
<daurnimator>
ifreund: if you know the child process is sane, you can wait for it to finish by waiting for it to e.g. close a file descriptor
<shachaf>
I poll on signalfd (and other fds) and wait with WNOHANG.
<ifreund>
I don't know it's sane sadly, hence the need for a timeout
<shachaf>
And preferably just wait with -1 and handle all the child events.
<shachaf>
pidfd is nice but I don't think you actually need it for correctness here (unlike a lot of cases?).
<ifreund>
hmm, if I used signalfd I could select(2) no?
<daurnimator>
ifreund: sane in that it doesn't randomly decide to unset O_CLOEXEC on a file descriptor it didn't open itself
<daurnimator>
ifreund: yep. (or poll/epoll)
<shachaf>
poll is approximately just a better version of select
<daurnimator>
ifreund: or hell: even just block in a read()
<daurnimator>
shachaf: exactly
<shachaf>
Or just read if it's your only fd, sure.
<shachaf>
The loop polls on a signalfd and inotify fd, and when it wakes up it does waitpid(-1, WNOHANG)
<shachaf>
daurnimator: Because I want people to be able to compile and run it.
<shachaf>
I can barely compile Zig myself.
<ifreund>
seems like the signalfd is the robust way I was looking for, thanks y'all
<shachaf>
Other than signalfd, you could do what I was doing before, set up a signal handler that ppoll unblocks, so that you wake up on EINTR.
<leeward>
daurnimator: It's a thing. People have good reasons for using it.
kristoff_it has quit [Ping timeout: 272 seconds]
<ifreund>
for context, river now supports tiling layouts generated by arbitrary user-provided executables
<ifreund>
which gives a ton of flexibility, but also means I have to handle things properly when they do strange things
ur5us has quit [Ping timeout: 244 seconds]
<ifreund>
neat, I just found sigtimedwait(2)
<ifreund>
that simplifies things a bit
CommunistWolf has quit [Ping timeout: 256 seconds]
<shachaf>
Ah, I didn't know about that.
<ifreund>
zig doesn't have it in the std yet though :(
<shachaf>
Though I feel like most programs are going to want to wait for multiple kinds of things anyway, so you want to structure your loop with poll/epoll anyway.
aerona has quit [Read error: Connection reset by peer]
<ifreund>
yeah, this is a somewhat special case where there is only one thing I want to wait for
<ifreund>
not part of my event loop at all
CommunistWolf has joined #zig
<ifreund>
why is it called rt_sigtimedwait in the SYS enum in bits.zig?
dddddd has quit [Ping timeout: 265 seconds]
<shachaf>
Because that's the system call.
CommunistWolf has quit [Ping timeout: 244 seconds]
<ifreund>
oh I see, there's some legacy stuff going on there
ur5us has joined #zig
CommunistWolf has joined #zig
<forgot-password>
What can prevent a shared library from being closed after a dlclose call? dlopen always gives me the same handle afterwards
aerona has joined #zig
<andrewrk>
same handle as in, same pointer address?
<forgot-password>
Yes
<andrewrk>
it might just be a coincidence. if you unmap() then map(), linux for example gives you the same pages back
<andrewrk>
which is likely how dlopen/dlclose are implemented
<forgot-password>
When i call a function in that library it always references the version from the first dlopen call. I can recompile the library as many times as I want, but it only changes after I restart the host (which calls dlopen)
<andrewrk>
I'm out of ideas
<forgot-password>
No worries, thanks anyways :)
forgot-p1ssword has joined #zig
forgot-p1ssword has quit [Client Quit]
forgot-password has quit [Ping timeout: 246 seconds]
<daurnimator>
dlclose is a no-op in musl
<shakesoda>
don't some other platforms behave that way in general too?
<shakesoda>
i swear i remember windows will do that too when you load a library
craigo has quit [Ping timeout: 246 seconds]
traviss_ has quit [Remote host closed the connection]
diginet_ has joined #zig
diginet has quit [Read error: Connection reset by peer]
waleee-cl has quit [Quit: Connection closed for inactivity]
<daurnimator>
andrewrk: I've encountered that before and its resulted in having to add non-const things all over the place, just to support .deinit()
<andrewrk>
deinit() is a mutation, it makes sense that you can't do it on a const object
<daurnimator>
not when the .deinit() only does e.g. a `close` syscall
<andrewrk>
in this case it would have an `fd` field which should get set to `undefined`
<daurnimator>
yes we used to have that. but then that bubbled all the way up
<daurnimator>
--> the only reason to do `var foo = blah.init()` instead of `const foo = blah.init()` was so that the .deinit later would work
<daurnimator>
which bubbled up again to another object needing to have a `*T` instead of what should have been a `*const T`.... which bubbled further.....
<daurnimator>
to a function up the stack that had to take a `*T` instead of a `T`
<daurnimator>
which reminds me; I once got in a different conundrum when working on my allocator: my deinit() was setting fields to undefined, but they were in a read-only page so things worked in release-fast but not debug
<shachaf>
This sounds like the arguments about free taking a const pointer, which it should, but maybe deinit isn't quite the same situation?
aerona has quit [Quit: Leaving]
<leeward>
Can't you just var foo = blah.init(); defer foo.deInit(); const bar = &foo; and use the const pointer?
<andrewrk>
I don't see any problem with those things bubbling, it's all correctly modeling mutability
<daurnimator>
andrewrk: but you're *not* mutating anything in memory though
<andrewrk>
yeah you're setting fd = undefined
<daurnimator>
what if I want to store a `T` on a read-only page?
<andrewrk>
that's a good counter example use case
<andrewrk>
best argument I've heard so far
<daurnimator>
I'd rather we rely on the allocator interface setting things to `undefined` on free + perhaps writing out `undefined` when popping from the stack?
<daurnimator>
writing `undefined` when popping the stack would also make issues with escaped stack references more obvious
<andrewrk>
the plan (in safe modes) is to detect which possible stack variables might escape, heap-allocate them instead using an allocator that detects use-after-free, and then free them automatically at the end of the stack frame
<andrewrk>
this will work similar to the panic function, in that it can be overridden but there is a default implementation which is different depending on OS
<andrewrk>
or it can be disabled altogether, no funny business with stack allocations. but the default, at the very least in debug mode, will be to do this
ur5us has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
<daurnimator>
andrewrk: why *not* just clear the stack as part of each function epilogue?
dermetfan has joined #zig
redj_ has joined #zig
redj has quit [Ping timeout: 260 seconds]
_Vi has joined #zig
<andrewrk>
daurnimator, it's a good partial measure - it works for "leaf" functions, but as soon as another function call happens the memory gets reused, so use-after-free could be dangerous (rather than well defined behavior causing a crash) due to the aliasing
<andrewrk>
the point of lifting potentially problematic variables out of the stack is to detect invalid use-after-free without wild pointer aliasing
<andrewrk>
of course in the unsafe build modes, this would not happen, everything would be in the stack frame
<daurnimator>
I think its a cool idea to try out. Though I'm a little worried the extra mmap/mprotect calls and dead regions might have deleterious effects. will have to see
<andrewrk>
yeah there's always the case that it's too much overhead and we have to ditch it
<andrewrk>
if it works though, the neat thing is it would also be available in freestanding, just like everything else - if you put a little work into the glue code, then you get the benefits
Kingsquee has joined #zig
<daurnimator>
andrewrk: maybe debug mode but not release-safe?
<andrewrk>
my hunch is that it would be enabled for both by default
<daurnimator>
its a bit of a funny one too. we could be unintentionally be protecting people from e.g. pointer hash collisions
<andrewrk>
if it works well, and once we have a safe general purpose heap allocator that panics on use-after-free and double-free, then it would be reasonable to call zig a "safe" language. or at least "safe capable"
<andrewrk>
of course you could always use an arena allocator or use @intToPtr
<stripedpajamas>
is there anything special needed to get recursion working ? inside a struct method i get "function not fully analyzed yet"
<andrewrk>
stripedpajamas, does it have to do with the inferred error set? you can give it an explicit error set
<andrewrk>
if you start with an empty error set (`error{}`) the compiler will tell you which ones are missing
<stripedpajamas>
ahhh
<stripedpajamas>
thanks andrewrk
_Vi has quit [Ping timeout: 244 seconds]
ikskuh has quit [Quit: Winke winke!]
mq32 has joined #zig
Kingsquee has quit [Ping timeout: 244 seconds]
stripedpajamas has quit [Quit: sleeping...]
dermetfan has quit [Ping timeout: 272 seconds]
mq32 is now known as ikskuh
ur5us has joined #zig
allan0 has joined #zig
daurnimator has quit [Ping timeout: 272 seconds]
daurnimator has joined #zig
haliucinas has quit [Ping timeout: 246 seconds]
haliucinas has joined #zig
_Vi has joined #zig
dermetfan has joined #zig
dddddd has joined #zig
dermetfan has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 244 seconds]
dermetfan has joined #zig
<ifreund>
so uh, std.os.waitpid doesn't seem capable of handling WNOHANG properly with the current api
<pixelherodev>
Anyone here have an older GCC they can test something with for me? :P
<pixelherodev>
older meaning "anything before 10" :P
<pixelherodev>
(hand written, before anyone gets too excited; I'm just making sure my test is correct :)
<pixelherodev>
It works with GCC 10, but I want to make sure it works further back
<ifreund>
yep, seems to work
<ifreund>
the binary shouldn't produce any output right?
<pixelherodev>
Nothing except for an exit code ;P
<pixelherodev>
`./blah ; echo $?` should give 103
<pixelherodev>
But yeah, that's expected
<pixelherodev>
I'm 100% confident it'll work if it compiles like that
<pixelherodev>
Thanks :)
<pixelherodev>
Ned to see if I can find a livedisk with an older GCC or something
<ifreund>
yep, exit code is 103
craigo has joined #zig
<pixelherodev>
Toldja ;)
<pixelherodev>
That's perfect, thanks :)
<ifreund>
no problem
<WilhelmVonWeiner>
say I'm writing an event queue for a game, and I register a function against event type "SOMETHING_HAPPENED"... what's the best type to represent the "SOMETHING_HAPPENED" event?
<daurnimator>
enum ?
<WilhelmVonWeiner>
In my js version i'm just using strings because it's JS, should I just write a big enum somewhere?
<WilhelmVonWeiner>
it just sounds a bit cumbersome, in that you have to go add a new event type to this enum
<pixelherodev>
You *could* use a string hashmap
<pixelherodev>
but enums are the best bet performance wise
<daurnimator>
WilhelmVonWeiner: it would give you a few bonuses like: `switch(someevent) { .FOO => {}, .BAR => {}, }` and being an error if you didn't handle them all
<WilhelmVonWeiner>
can one instantiate a hash map at compile time?
<daurnimator>
or that you typoed an event somewhere (and referenced a non-existant one)
<WilhelmVonWeiner>
daurnimator: that is true
<pixelherodev>
WilhelmVonWeiner: you *could* do it using strings, but... seriously, not worth it
<WilhelmVonWeiner>
cheers.
<ikskuh>
pixelherodev: you can use godbolt for that!
<pixelherodev>
True!
<ikskuh>
WilhelmVonWeiner: you usually want to store some data with the event
<ikskuh>
so using a tagged union would be my solution:
<pixelherodev>
Ugh, the Scope-type interface is nice and clean but so tedious to implement
waleee-cl has joined #zig
stripedpajamas has joined #zig
<leeward>
oh, pixelherodev, a problem for C backends: see if you can translate this Zig function `fn unsigned(static: i32) bool { const case = static >= 0; return case; }`
daurnimator has quit [Ping timeout: 244 seconds]
<stripedpajamas>
is there an idiomatic way to check that an optional isn't present? right now i'm doing `if (opt) |_| {} else { // stuff }`
<fengb>
`if (opt != null)`
<fengb>
Er... `if (opt == null)`
<fengb>
One of those. I can't think
daurnimator has joined #zig
<stripedpajamas>
oh right
<stripedpajamas>
forgot that it was val or null
<stripedpajamas>
thanks
<pixelherodev>
leeward: this'll probably be a subset of Zig
<pixelherodev>
99.9% of it, but a subset nonetheless
<leeward>
So you'll just reject identifiers that conflict with C keywords?
<ifreund>
can't you just rename them?
<pixelherodev>
Potentially, but keep in mind that people are meant to read this code
<pixelherodev>
So e.g. `__renamed_static` can be annoying
<pixelherodev>
But this isn't what I was referring to
<ifreund>
I don't think there's another solution really
<pixelherodev>
There's some things that *can't* be translated, even with cute tricks like that
<pixelherodev>
e.g. some builtins
<pixelherodev>
setRuntimeSafety should be doable (since we'll generate the checks as C code)
<pixelherodev>
but e.g. optimizeFor?
<pixelherodev>
Some of them just can't be done in a sane manner
<ifreund>
how are frames/async going to work?
<ifreund>
or will they work?
<pixelherodev>
No clue
<pixelherodev>
I'm probably not going to be the one to touch that :P
<pixelherodev>
Those don't work with normal codegen yet either
<pixelherodev>
So I'll keep an eye out
<pixelherodev>
When it's implemented for normal codegen, I'll look at how it works and see if I can't replicate it for C
<ifreund>
yeah makes sense
<pixelherodev>
Ugh
<pixelherodev>
boilerplate
<pixelherodev>
Some sort of @reify magic for this would be awesome
xackus has joined #zig
Mulugruntz has quit [Quit: ZZZzzz…]
Akuli has joined #zig
frmdstryr has joined #zig
cole-h has joined #zig
traviss_ has quit [Remote host closed the connection]
<andrewrk>
as a dvorak typist, I agree with leeward, it's not worth the switch
<companion_cube>
right, I mean, there's msgpack right?
<blinghound>
I'm typing on a single row, 26 character keyboard in alphabetical order
<andrewrk>
lol
<leeward>
Yeah, I say that having been using dvorak for...20 years.
<blinghound>
the sad thing is I only have 25 fingers
<shakesoda>
blinghound: you lack power; i programmed a chorded keyboard that uses thumbsticks for input
<leeward>
Switched in december of 1999.
<blinghound>
so one finger gets a dual key job
<shakesoda>
ordered by letter frequency of common words in english
<andrewrk>
leeward, damn, you been typing dvorak since before I learned VB6
<shakesoda>
joking aside, i actually did do this: i use it for chat in my vr game
<blinghound>
just joking though, I enter unicode text through the medium of dance via a modded Kinect
<fraktor>
I've been thinking of maybe DVORAK or COLEMAK, why is it not worth the switch? Just because it's incompatible with most keyboards?
<shakesoda>
it's also got dictionary prediction and some other conveniences because typing everything out that way sucks
<blinghound>
andrewrk ayyy VB6 was my first language
<xackus>
I've never considered switching, because English is not my primary language so the benefits would be questionable
<leeward>
I kinda wish I knew how to use chorded keyboards. It would make being a cyborg much cooler.
<fraktor>
I wish there were more plover-compatible keyboards. Most of the ones that are available are a little out of date.
<andrewrk>
fraktor, colemak is a half measure, what's the point? dvorak is more comfortable than qwerty, but there's a cost to using non defaults, and it's not *that* much better
<andrewrk>
that's my take on it
<Sahnvour>
I'm interested in how people who learnt vim before, handled the layout switch
<fraktor>
What do you mean when you say it's a half measure
<shakesoda>
my understanding is qwerty was designed for mechanical needs, dvorak for human ones
<fraktor>
That's another issue: I'm a big Vim user.
<leeward>
fraktor: It's very inconvenient to use anyone else's keyboard, it's very inconvenient for anyone else to use your keyboard, and your speed and error rate will get very bad for a while (and every time you switch)
<andrewrk>
it's like they wanted to do dvorak, but chickened out because they didn't want ctrl+x, ctrl+c, ctrl+z, ctrl+v to be in different positions
<leeward>
qwerty is actually designed to alternate hands for most words, which is not a bad thing.
<fraktor>
leeward: That makes sense. I've switched my escape and caps lock keys, and that alone is enough to throw me off of most other computers.
<xackus>
yeah, there is a popular misconception that qwerty was designed to slow down typing
<shakesoda>
it wasn't designed to slow down typing, wasn't it to avoid jamming typewriters?
<xackus>
it yes
<xackus>
*yes
<shakesoda>
the alternating is a result of that, which is also handy, but afaik dvorak succeeds better at that
<leeward>
Yep
<fraktor>
So the idea was to make consecutive keys far apart, yes? that would prevent some of the jams
<xackus>
exactly
<fraktor>
Maybe I should be a real hipster and go with workman
wootehfoot has quit [Read error: Connection reset by peer]
<leeward>
dvorak does require less finger movement, but I don't think it alternates hands better; though I have no data on that one.
<fengb>
Dvorak puts vowels all together. That'd be pretty hard to maintain on physical typewriters
<shakesoda>
at some point i put in the effort to learn dvorak, but it just wasn't worth the friction
<shakesoda>
typing on it was fine
<fengb>
Of course, I and O are right next to each other so it's not like qwerty solved everything correctly
<shakesoda>
but remapped inputs behave differently in every program, switching to anything else sucks, etc
<leeward>
But typewriter salesmen can type "typewriter" all on the top row!
<shakesoda>
input remapping is especially nasty in games
<shakesoda>
so many of them botch this
<fengb>
Just use default keys in dvorak
<fengb>
Hard mode activated
<leeward>
The worst is when games let you remap some but not all the keys.
<xackus>
vowels grouped together would actually work pretty well in Polish when it comes to jamming
<fraktor>
shakesoda: Preach. In factorio they use the keycode for escape, which means that every time I have to use it, it toggles caps for me.
<shakesoda>
yuck
<xackus>
W Szczebrzeszynie chrząszcz brzmi w trzcinie
* leeward
uses a ridiculous keyboard that's mapped to dvorak in hardware.
<fraktor>
That's what I was thinking would be the way to go.
<fraktor>
Unfortunately that means that "WASD" is going to really suck.
<shakesoda>
leeward: that doesn't fix remapping problems though
<fengb>
I can't tell if you're making fun of Polish or if those are actual words
<xackus>
they are actual words
<shakesoda>
it does mean it's consistently remapped, at least
<shakesoda>
so that's nice.
<shakesoda>
fengb: that's how you know it's really polish
<xackus>
that form a proper sentence
<xackus>
although this sentence uses many digraphs
<xackus>
sz, cz, rz are one sound
<xackus>
still a tongue twister
<leeward>
xackus: Way too many Zs to be comfortable to type. Right pinky bottom row is awkward to reach.
<leeward>
also, sz are adjacent (right pinky home/bottom)
<xackus>
I don't type how you are supposed to anyway
<fraktor>
That reminds me of this weird Polish movie clip where a guy says his name is Grzegorz Brzynszyczykiewicz
<shakesoda>
what layout does polish usually use
<xackus>
standard qwerty
<fraktor>
Ooh that's rough
<shakesoda>
so z is inconveniently in the corner still huh
<shakesoda>
rough
<xackus>
with right alt for ąćęółśżźćń
<shakesoda>
given the amount of them i'd have guessed something more like azerty
<xackus>
fraktor: a classic
<fengb>
Shouldn't dvorak layout be renamed ',.pyf
<leeward>
or aoeuid
<shakesoda>
how much overhead does async suspend/resume have anyways
<xackus>
it annoys me to no end that ź and ż are under the same letter on mobile keyboards. in standard keyboards ż is alt+z and ź is alt+x
<xackus>
you have to long press and select the right letter
st4ll11 has joined #zig
<xackus>
instead of just long pressing
<leeward>
Sounds way more discoverable.
<xackus>
if you never used a keyboard, yes
<fengb>
Is there not a chorded keyboard for this?
<xackus>
what is a chorded keyboard?
<fengb>
You hit multiple keys to represent one letter
<xackus>
on physical keyboards you press right alt
<fengb>
So it'd be something like •+z or ´+z
<fengb>
I mean for mobile
<xackus>
i found one but it sucked in other ways
<fengb>
Mobile keyboards for Chinese are so much better than desktop because someone actually gave it thought and made chorded keyboards or stroke detection
st4ll11 has left #zig [#zig]
<shakesoda>
fengb: how does it work on desktop? similar to japanese?
<waleee-cl>
pinyin-based dictionary-lookup with candidate selection (on windows at least)
<shakesoda>
sounds very much similar
<fengb>
Yeah, desktop keyboards are typically pinyin. It's really bad
<fengb>
(Of course, I can't use anything else because I'm barely literate... but still)
<xackus>
thank god for pokemon. at a certain age it taught me more English than anything else
KubaSO has joined #zig
blinghound has quit [Remote host closed the connection]
<fengb>
No Polish localization?
<ifreund>
andrewrk: I don't think colemak is a half measure, in fact its design is more data-driven than dvorak due to being more modern and is arguable superior
<KubaSO>
TL;DR: want to implement LLVM backend, tired of C++, zig looks beautiful. Does zig offer any starting points for developing using LLVM libraries - specifically the backend?
<ifreund>
the stuff about not moving zxcv is more of a nice side benefit and doesn't hold the layout back imo
<xackus>
most people played on pc because nobody had money for a console
<ifreund>
dvorak has the L on the top row pinky which kinda sucks, no layout is perfect though
<fraktor>
andrewrk: Does the stage2 compiler use an LLVM backend?
<ifreund>
fraktor: not yet, but it's planned to have llvm as an option
<ifreund>
stage2 is purely self-hosted currently
<KubaSO>
In absence of any premade interfaces between LLVM APIs usable for backend development (e.g. IR ingest), is the only way to extend LLVM-C with to expose LLVM to C, and then build a zig API on top?
<fraktor>
Most likely. I've found that C interop works pretty well for the most part, with a couple of exceptions due to enum abuse.
<ifreund>
and will always remain purely self-hosted for debug builds as I understand it. Can't make incremental compilation work through llvm
<andrewrk>
KubaSO, if your project needs access to all of LLVM and not just a simplified legacy API, you might need to make your own C API on top of the LLVM C++ API. the C API LLVM provides is lacking
<fraktor>
Is that the eventual plan for stage2?
<KubaSO>
Ahem, so what sort of infrastructure is there within zig for code generation/backend (I didn't look yet)? I'm not married to LLVM, I was (apparently incorrectly) assuming that getting zig to produce target output implied writing an LLVM backend.
<andrewrk>
zig is not currently (and probably won't be) a general purpose compiler backend
<KubaSO>
But zig does generate LLVM IR, correct?
<pixelherodev>
Hopefully stage2 won't actually end up needing LLVM at all
<andrewrk>
KubaSO, correct
<andrewrk>
what are you working on?
<pixelherodev>
e.g. translate-c could be implemented using the standard library's C parser instead of needing Clang for it
<fraktor>
pixelherodev: This might be a naive question, but why not? It seems like interfacing with LLVM is a good way to get lots of platform-specific tricks and improvements.
<andrewrk>
pixelherodev, clang is pulling a lot of weight in translate-c. it's also doing semantic analysis and type checking
<KubaSO>
I want to tackle Parallax Propeller 2. It's essentially a miniature 32-bit NUMA with 8 cores and two levels of memory.
<andrewrk>
neat
<leeward>
Someone in here was talking about that chip. mq32?
<andrewrk>
and when you say tackle, can you elaborate? what's the goal here?
<ikskuh>
leeward: correct!
<ikskuh>
Propeller Coders Assemble!
<leeward>
I remember looking over its datasheet.
<ikskuh>
P2 is a crazy architecture
<ikskuh>
P1 was nice and based
<ikskuh>
but P2 is whack.
<ikskuh>
round-robin memory scheduling with 1-cycle-latency for well optimized code
<ikskuh>
also, uniform memory areas with all registers accessible as memory mapping
<KubaSO>
I like P2 more :) Obviously it is way faster, and can support USB FS natively, and both USB HS and 100BASE-TX using external PHY. But I'm tired of the C++ ecosystem, so I'm really happy to find a cool language with wide-open future that could be used to implement it.
<KubaSO>
Especially that I'm **not** going to use the underdocumented abomination known as LLVM's tablegen. It looks like zig can do all the tablegen at compile time, and may actually wrap some LLVM backend constructs nicer than C++.
<KubaSO>
P2 is very much register-less 2-level NUMA, even though they call level 1 memory "registers". It also is not all that different from P1 in terms of general architecture: there's still level 2 memory, shared round-robin (the hub), and level 1 memory on each code (the cogs). It all got lots of overhaul, but it's fundamentally the same idea, and
<KubaSO>
probably a P2 code generator could share a lot with P1 code generator in terms of code transformations, since the hub-cog split drives everything.
ur5us has joined #zig
<ikskuh>
KubaSO: yeah, true
<ikskuh>
i really love P2 architecture, it's a great extension of the first one
<ikskuh>
having a P1/P2 backend in zig would be rad
<ikskuh>
and would make the stage2 more versatile
<andrewrk>
KubaSO, this use case is spot on for zig, however, you might need to dial down your expectations a bit for the status quo of the project. it might be a few months before this use case can really be tackled well by the zig project
<andrewrk>
by all means experiment with it and see where it takes you :) just don't want to over promise here
<ifreund>
you're totally right though that the future is wide open and looks very promising though :D
<KubaSO>
Zig looks like what I wanted nim to be :)
* andrewrk
is really feeling the pressure to get self-hosted operational
<ifreund>
andrewrk: I am sending encouraging thoughts your way <3
<KubaSO>
My interest is in platforms that probably won't host a compiler - at least it
<ikskuh>
andrewrk: please feel the pressure, but don't let it stress you!
<ikskuh>
Take aaaaaaaall the time you need
<pixelherodev>
Okays, got the CBE skeleton done!
<ifreund>
yeah, avoid those pesky local maximums, we'll all thank you in 10 years
<KubaSO>
's not my immediate need. P2 doesn't have enough memory to do all the build steps needed for something the size of zig. Maybe I'm wrong.
<ifreund>
we'll see, i've heard vague plans of compiling self hosted to C using itself, and self hosted has quite optimial memory usage so far
<ifreund>
that's quite a ways down the line though
<andrewrk>
yeah right now stage1 is a memory gobbler
<pixelherodev>
Self hosted also has zero memory leaks so far
<pixelherodev>
Which we know because tests are always run using the leak checking allocator ;)
<leeward>
stage1 triggered oomkiller on my rpi
<ikskuh>
testing allocator is a great idea
<KubaSO>
P2 has 512kb of level 2 memory (hub/shared), and 2kb of level 1 memory (cog/dedicated per-core) 😂 It's, let's say, not very likely to host zig. At least not with LLVM in the picture - the C++ dependency kills everything in terms of size.
<ikskuh>
and the planned GPA will make memory leaks or errors in zig really unlikely
<leeward>
Yeah, I wouldn't expect to run the compiler on a propeller anyway. Better to cross compile for it with something beefy and fast.
<pixelherodev>
`Generating function 'start' of type 'fn() void', targeting C11` Here we go...
<KubaSO>
So my use case is only cross-compilation from PC to microcontrollers. I have been messing about (internal prototypes only at this point) with 8-bit backends for LLVM and I just don't like writing that stuff in C++, for some reason. This is entirely my taste and aesthetics, of course. Nothing wrong with modern C++.
<xackus>
stage1 made oomkiller kill ssh on a vm with 5 GB of
<xackus>
ram
<ikskuh>
KubaSO: Yeah i want to bootstrap a bluepill with zig as well
<leeward>
KubaSO: For certain values of nothing, sure. I can sum up what's wrong with modern C++ pretty easily: less-than-modern C++.
<KubaSO>
Aaaaah, yes. Well, let's not go there :)
<leeward>
I did manage to get Zig code to run on an AVR.
<pixelherodev>
Hmm, should I pay attention to calling conventions?
<pixelherodev>
I think that should be dependent on features, potentially
<pixelherodev>
e.g. ignore it by default, but if targeting GNU extensions, use them
<leeward>
They matter for .Signal and .Interrupt.
<leeward>
Probably some others too.
<leeward>
As a user, I'd rather it fail noisily if it can't translate something.
<pixelherodev>
True
<pixelherodev>
I think some of them should error
<pixelherodev>
But e.g. fastcc should just lower to ccc
<pixelherodev>
Now for some instruction translation :)
<pixelherodev>
... what's EBADF?
<pixelherodev>
Ahh, I see
<pixelherodev>
Double-closed a file :P
Akuli has quit [Quit: Leaving]
<KubaSO>
Also, it looks like zig took that C++ lightweight error handling paper (p0709) and actually delivered it ahead of time :) (it's not exactly the same thing, but I like it anyway)
<pixelherodev>
... you know that feeling when you accidentally kill your WM locally instead of over SSH, and then you can't relaunch Wayland *or* X11 because DRM isn't happy you killed the graphical controller without warning?
<pixelherodev>
Bug report while I'm stuck in a TTY: multiline strings after normal comments receive the wrong level of indentation for the first line
<pixelherodev>
Or perhaps, it's to do more with the context?
<pixelherodev>
Meh, I'll open a proper ticket later
cole-h has joined #zig
<pixelherodev>
no-arg function calls with no return value working
<pixelherodev>
Just need to reorder function outputs
<pixelherodev>
(lazy eval means that start is detected before main even if main is defined first, so we need to declare all functions that get called at the top of the output)
betawaffle has quit [Ping timeout: 240 seconds]
betawaffle has joined #zig
gonz_ has quit [Ping timeout: 260 seconds]
guan has quit [Ping timeout: 246 seconds]
yrashk has quit [Ping timeout: 244 seconds]
daex has joined #zig
wjlroe has quit [Ping timeout: 240 seconds]
jzelinskie has quit [Ping timeout: 244 seconds]
shakesoda has quit [Ping timeout: 272 seconds]
backwhack has quit [Ping timeout: 260 seconds]
nikki93 has quit [Ping timeout: 256 seconds]
matti has quit [Ping timeout: 244 seconds]
eddyb[legacy] has quit [Ping timeout: 244 seconds]