ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
blinghound has quit [Ping timeout: 245 seconds]
blinghound has joined #zig
isolier3 has joined #zig
isolier has quit [Ping timeout: 256 seconds]
isolier3 is now known as isolier
<ronsor> DarkUranium: return if (cond) x; else y;
<ronsor> err* `return if (cond) x else y;`
reductum has joined #zig
reductum has quit [Client Quit]
xackus_ has quit [Ping timeout: 256 seconds]
stripedpajamas has quit [Quit: sleeping...]
<DarkUranium> alexnask[m], pixelherodev: Reading up on Zig's error handling, I definitely like the `catch` and the `try` and so on (except maybe the specific keywords used --- I feel like they might end up being confusing for people used to the *OTHER* try/catch approach)
<DarkUranium> Maybe I should stea^H^H^H^Hadapt this for Coyote :)
<fengb> You shoulda looked when Zig used %% instead 🙃
<DarkUranium> I've been considering using %% for remainder in Coyote.
<DarkUranium> Sorry, for modulo.
<DarkUranium> (and % for remainder, which is what it is [despite it being called "modulo"])
<torque> I think try and catch are perfectly descriptive
<ronsor> I prefer it over Go's error handling
<torque> it's also the best language-level error ecosystem I've seen (disregarding the inability to attach arbitrary data to the errors which can be worked around if necessary)
frmdstryr has quit [Ping timeout: 260 seconds]
<fengb> Yeah I also wish we had error payloads
<torque> can't count the number of bugs we've had with exceptions because there's no external indication what exceptions a function may throw
<torque> implicit error propagation Was A Mistake™
<andrewrk> DarkUranium, I'm happy with what zig ended up for that too
<andrewrk> we use `%` which is the ambiguously rem/mod operator. It's allowed when rem and mod have the same result (because the operands are unsigned)
<andrewrk> when rem/mod have different results then one is required to use @rem or @mod
<andrewrk> same deal with the `/` operator
<andrewrk> `a / b` is a compile error if the operands are signed
<fengb> Wait what’s the difference?
<DarkUranium> Huh, I thought a/b was well-defined for signed?
<DarkUranium> Or rather, unambigious.
<andrewrk> is it floored division or truncated division?
<DarkUranium> fengb, one takes the sign of the left operand; the other of the right.
<fengb> Oh right, negative rounding
<andrewrk> floored division corresponds to modulus; truncated division corresponds to remainder division
<DarkUranium> Ah, that.
<andrewrk> zig only allows `/` when truncated division and floored division would have the same result
<andrewrk> if not: pick one!
<gruebite> there are a lot of languages that don't have a solid solution to that
<fengb> We could add %+ and %- operators. That wouldn’t be confusing at all
<DarkUranium> Yeah, my solution is to just pick one option and go with it.
<DarkUranium> Though keep in mind that familiarity (at least to some extent) is an explicit design goal of Coyote. Otherwise, it would've looked ... quite a lot different.
<andrewrk> in this case my suggestion would be to follow python's choice (modulus, floored division)
<DarkUranium> Yeah, maybe. Well, I'll see.
<DarkUranium> andrewrk, one reason why I prefer truncated division is because of C. Remember that this is an embedded language.
<DarkUranium> (basically, keeping in line with C semantics makes things simpler)
<DarkUranium> That doesn't mean there aren't good arguments for floored division, though.
<DarkUranium> In particular, having modulus is great. For example, you can do `arr[(i - 1) % len]`
<DarkUranium> (instead of `arr[(i - 1 + len) % len]`)
<andrewrk> yeah I mean I maintain my stance that zig got this right and anything else is sub-par :)
<DarkUranium> hehe
<keegans> andrewrk: before i keep sinking my time into adding sanitizer support and libFuzzer to zig, are you interested in having official support for this in the compiler ?
<keegans> well, i should rephrase, I don't see it as a time sink ;)
<andrewrk> keegans, I see ASAN and as competing with each other, and ASAN as the inferior option because it has a dependency on LLVM libs and the LLVM backend
<keegans> i no doubt believe the zig gpa is a better alternative to asan, but the zig gpa doesn't exist _today_ and as I see it as a zig developer, I really want memory corruption sanitizers and leak sanitizers
<keegans> needless to say, asan in zig doesn't exist _today_ other, so that's not my argument
<keegans> *either
<andrewrk> this is kinda what I mean about avoiding local maximums
<andrewrk> I'd rather see the effort spent on polishing up the general purpose debug allocator
<andrewrk> which, btw, is also the key to the plan for solving UAF and other memory safety of function-local variables
<andrewrk> keegans, I do think there is room for this feature if done carefully
<keegans> hmm. yeah. for what it's worth, adding ASan to zig required 35 line changes. but i agree that doesn't merit itself a place in the compiler just by that metric
nvmd has quit [Quit: Later nerds.]
<andrewrk> 35 lines? doesn't it depend on a library?
<keegans> llvm has got yer back
<keegans> it needs compiler_rt for asan of course, but that's just a linker flag
<andrewrk> nah see that's the thing, we don't have any system dependencies, and this adds one
<keegans> ah- this feature requires libc, yeah
<keegans> it would be an error to attempt to enable sanitizers without libc
<andrewrk> it requires compiler_rt to have ASAN functions and other stuff, which zig's compiler_rt currently doesn't have
<keegans> but of course they wouldn't be useful if they _didn't_ depend on libc becaues LeakSan requires malloc&free
<andrewrk> again I do think there is room for this feature, but I think it may be a bit more involved than you are estimating
<andrewrk> because we would need to do it the zig way, and that would mean zig would have to provide the library support (in compiler_rt or whatever else)
<andrewrk> I'm kinda confused how you got this to work at all, didn't you get linker errors?
<keegans> if we would need to do it the Zig way, then yes this is a complete waste of time
<keegans> but I didn't think that we operated that way, I assumed having a hard dependency on libc for an optional feature was a worthwhile tradeoff
<andrewrk> does glibc have the ASAN support functions in it already?
<keegans> I believe glibc also implements the asan runtime as well
<andrewrk> ok that solves my confusion
<andrewrk> it also changes things a little bit
<keegans> i don't know what you mean by linker errors, this works right now
<keegans> I link against the static bin shipped with clang for the asan compiler_rt
<andrewrk> ahh there we go. that's what I'm talking about. the asan support library
<andrewrk> see this is a system dependency. you would be introducing the very first system dependency into the zig compiler. you can see why I would be reluctant to do that
blinghound has quit [Remote host closed the connection]
<keegans> I am confused, we depend on libc in the same way we depend on the asan support library, optionally.
<andrewrk> that's not actually true :)
<andrewrk> try this: `zig build-exe hello.zig -target aarch64-linux-gnu` and then consider that you don't actually have aarch64 glibc installed
<andrewrk> oops, throw a `-lc` on there.
dimenus has quit [Quit: WeeChat 2.9]
<keegans> hmm, if this is really a concern, we copy-paste glibc into the zig source tree, what's stopping us from doing that with the asan runtime
<andrewrk> nothing. that's what I meant by zig would have to provide the library support (in compiler_rt or whatever else)
<andrewrk> it's not as trivial as copy pasting into the zig source tree tho
<keegans> yeah for sure, I just stated it like that to make sure I'm understanding
<andrewrk> I think I misrepresented my position here as a bit more negative than I really intend to be. I mainly wanted to clarify what it would look like to implement this according to the zig vision
<andrewrk> ...which would mean it would even work for cross compiling zig for all the supported targets (where possible)
<andrewrk> there are some sanity checks to do though. I'm not sure what the maintenance burden or installation size burden would be of taking on the sanitizers
<andrewrk> anyway point being this is something that is quite possibly in scope, however there are considerations
<keegans> I didn't forsee the maintenance burden because as I was hacking away on it I thought "no problem, we link against the system-provided compile_rt for asan"
<keegans> so yeah, I saw sanitizers as a very, very special case
<andrewrk> there's no ssytem provided compiler_rt on freestanding or on windows, or on many posix operating systems
<andrewrk> we avoid so many problems by providing a consistent compiler_rt lib
<keegans> sorry, I mean the asan compiler_rt, regardless it's not free-standing, it requires libstdc++ and libc
<keegans> truth be told my "master plan" adding fuzzing support to Zig. and the fastpath to that was adding ASan and then jumping directly into libFuzzer
<keegans> and we can achieve the fuzzing goal without using ASan
<keegans> so I have to re-evaluate this work. thank you for discussing and clarifying
<andrewrk> no problem, and thanks for the interest in improving this. certainly sanitization and fuzzing are important and in-scope use cases
<keegans> while I have you here, I also want to solve an issue with Android support since static compilation is currently broken on ndk 20. the solution as far as I can tell requires some sort of allocation primitive in compiler_rt. details here: but tl;dr you need to dynamically expand and contract a TLS table.
<keegans> the reason why I don't just figure it out is that as far as I can tell allocating things in the compiler_rt is a no-go, so I am not sure what the best way to do this is
<keegans> this doesn't have to be solved right this minute I just got stuck and don't know who to talk to about it
<andrewrk> keegans, as a work around you could link against the static libgcc file from the NDK
<keegans> ah, I'd prefer to fix it "properly" so noone else has to deal with that
<keegans> well I guess as of right now the NDK is a requirement anyway...
<andrewrk> I'm sure we can get to the point where that is not the case
<andrewrk> just requires the work to be put in
<andrewrk> ikskuh has been looking into this recently
<keegans> yeah I have really, really tried to rip bionic out of the android jungle so it can be built independently, but i've given up each time
<keegans> I did at one point get a partial build for just the featureset that I required, but I didn't get the whole nine yards
<andrewrk> well rest assured at some point after I rewrite Groove Basin in zig, I'm going to want an android client for it :)
<keegans> yeah I definitely want bionic in Zig, such that way can do away with env vars in libc.txt as well, but I'm not ready to jump back into that just yet
<keegans> *we
<andrewrk> I think android is a little rough because non of the main zig contributors (and especially me) have really pioneered that path yet
<andrewrk> so it's definitely doable, it's just not, you know, a path well trodden yet
<andrewrk> shame though, because zig has some unique things to offer to that use case
<keegans> yep. I think that zig has the potential to be an excellent choice for android native development
factormystic has joined #zig
<gruebite> google backing zig?
<gruebite> :P
<keegans> who says we need Google's approval? ;)
<gruebite> my android experience is also extremely limitd
<gruebite> just the basic libgdx, unity, and cordova stuff
<ronsor> I have discovered a bug in the compiler
<torque> I would guess it's pretty unlikely that you were the first to discover it
<ronsor> I did a search
stripedpajamas has joined #zig
<ronsor> and now it's filed
frett27_ has joined #zig
frett27_ has quit [Ping timeout: 246 seconds]
craigo has quit [Ping timeout: 240 seconds]
cole-h has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk> thanks ronsor
pmwhite has quit [Ping timeout: 260 seconds]
casaca has quit [Remote host closed the connection]
CodeSpelunker has joined #zig
CodeSpelunker has quit [Quit: CodeSpelunker]
ur5us has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
marnix has joined #zig
casaca has joined #zig
craigo has joined #zig
ur5us has quit [Ping timeout: 244 seconds]
stripedpajamas has quit [Quit: sleeping...]
cole-h has quit [Quit: Goodbye]
ur5us has joined #zig
stripedpajamas has joined #zig
traviss has quit [Quit: Leaving]
traviss has joined #zig
craigo has quit [Ping timeout: 246 seconds]
stripedpajamas has quit [Quit: sleeping...]
decentpenguin has quit [Quit: ZNC crashed or something]
decentpenguin has joined #zig
<gruebite> if i wanted the zig equivalent to a void pointer, it would be `*@Type(.Opaque)`?
<gruebite> of a*
<scientes> gruebite, *c_void
<gruebite> c_void is defined as @Type(.Opaque). would it be more idiomatic to do my own typedef? `const MyType = @Type(.Opaque);` and then `*MyType`
<scientes> yes
<scientes> well, I think there is a built in for opaque types
<scientes> but the point then is then you have a unique type, unlike c_void
marnix has quit [Ping timeout: 246 seconds]
ur5us has quit [Ping timeout: 244 seconds]
_whitelogger has joined #zig
<leeward> @Type(.Opaque) replaces @OpaqueType.
<gruebite> yeah
dermetfan has joined #zig
Ashpool has joined #zig
riba has joined #zig
<Snektron> The C equivalent of `const A = @Type(.Opaque);` is `struct A;`
Kingsquee has joined #zig
<DarkUranium> alexnask[m], pixelherodev: So, on yesterday's topic. I'm not quite sure I understand how empty types in Zig can have the same meaning as `noreturn`?
<DarkUranium> (I ask because it sounds more like a unit type to me, than a bottom type)
nikita` has joined #zig
KKRT has joined #zig
xackus_ has joined #zig
riba has quit [Ping timeout: 246 seconds]
euandreh has joined #zig
euandreh has quit [Remote host closed the connection]
euandreh has joined #zig
<scientes> yeah that doesn't make any sense
<scientes> 'noreturn' is a procedural thing
<alexnask[m]> DarkUranium: They dont
<alexnask[m]> zig has noreturn
nmeum has joined #zig
marnix has joined #zig
<DarkUranium> alexnask[m], noreturn as a type?
<DarkUranium> Someone mentioned it yesterday, let me try to figure out who.
<DarkUranium> Or what exactly they said.
<DarkUranium> Oh. Apparently it wasn't in here. My bad.
<alexnask[m]> I think it was I believe I saw it too
<alexnask[m]> But yeah I guess it depends on what "bottom type" means exactly
<DarkUranium> It means it's a type that both:
<alexnask[m]> noreturn is the type of control flow expressions and infinite loops in zig
<DarkUranium> 1) has no value whatsoever (this implies that it cannot ever be evaluated, e.g. functions "returning" this type cannot ever actually return)
<DarkUranium> 2) can be implicitly converted to any other type (the conversion itself is undefined, but that's okay: it'll never happen because of #1 anyways)
<DarkUranium> This does have implications, some ugly. E.g. you can do `int x = abort();`
<DarkUranium> But OTOH, it's useful: `int x = y ? 1 : abort();`
<alexnask[m]> Right, noreturn in zig fits but not empty types
<alexnask[m]> or rather, zero bit types
Kingsquee has quit []
<DarkUranium> Yes, that's what I figured.
<DarkUranium> alexnask[m], hm, Zig has compile-time evaluation, right?
<alexnask[m]> Yes
<alexnask[m]> I personally feel like its one of the best designs around (this is what drew me into zig in the first place)
<alexnask[m]> Especially the whole types-as-values thing which eliminates the need for an extra setg fo features for generic programming
<DarkUranium> Yeah, I've been toying with that idea for Coyote, too (with a simple generics syntax that's basically a conveniency wrapper)
<DarkUranium> Question #2. Can CTFE open files (at compile-time, ofc)
<alexnask[m]> You can open files with the builtin @embedFile but in general all syscalls are not allowed
<DarkUranium> Okay. I'm asking because, uh. I have a stupid idea :P
<alexnask[m]> Well, to be precise inline assembly and calls into dynamic libraries are not allowed
<DarkUranium> (maybe Zig does it already)
<DarkUranium> Basically, a compile-time parseCHeader(@embedFile("foo.h")) :P
<alexnask[m]> Right, this would be achievable in zig userland if we had reification for structs
<alexnask[m]> Which is not out of the picture
<alexnask[m]> But not yet implemented and probably a 50/50 thing
<alexnask[m]> We do have a language feature for it currently though
<alexnask[m]> (@cImport)
<DarkUranium> Oh, nice.
<DarkUranium> That reminds me, I'm kinda considering going for deterministic compilation with Coyote.
<alexnask[m]> what do you plan to compile down to?
<DarkUranium> The bytecode format I have in mind would already be deterministic, regardless of order of inputs or such (basically: symbols would be alphabetically sorted, to allow for binary search)
<DarkUranium> Bytecode. So that makes it easier IMO.
<DarkUranium> There are reasons to want compilation date & time in there, though, but that could be limited to a single header field (and treated as a non-constant for the sake of determinism)
<alexnask[m]> I see, yeah sounds achievable. Are you gonna jit compile this? (only asking since pixelhero is involved and I assume he would want to :P)
<DarkUranium> I don't even know *why* I'd want something like that --- I just feel like it would be beneficial. (for example, for testing)
<DarkUranium> The plan is to interpret for now. But even before pixelherodev came on board, the plan was to have a bytecode format that was amenable to JITting (as opposed to interpreting).
<alexnask[m]> Its a nice guarantee even if it doesnt add much practical value afaict
<DarkUranium> Basically, I intend for my bytecode to be in SSI form.
<DarkUranium> (because it's 2020, and there's little point in *not* doing that anymore)
<DarkUranium> One way to handle compilation date/time would be to just use current datetime by default, but provide a flag to override, I guess?
<DarkUranium> (I like having date/time in there for debugging reasons ... it's poor man's automatic versioning)
<alexnask[m]> Yeah this sounds good for testing
<alexnask[m]> I assume you are writing this in C?
<DarkUranium> That's the plan :)
<DarkUranium> Would've used Zig, but doesn't support it (yet?)
<DarkUranium> (apparently, you can make a pull request?)
<DarkUranium> Well, pixelherodev would've used Zig for the JIT, that is.
<DarkUranium> But I don't think we need a JIT for the jam.
<alexnask[m]> Havent looked into at all
<DarkUranium> It's just a online editor+compiler thingie. Nothing fancy.
<alexnask[m]> Yeah they pretty much only judge language design and not the implementation itself right?
<alexnask[m]> They just want something that works afaict
<DarkUranium> for more info, but tl;dr:
<DarkUranium> "Today, we're announcing the programming language jam and a $10,000 grant to a team that designs and prototypes a new language with emphasis on fresh and possibly wild ideas"
<alexnask[m]> TFW some weird functional thing will win
<DarkUranium> I'm almost positive that's what's gonna happen, yes.
<DarkUranium> Or some very niche DSL.
<DarkUranium> One of the ideas I discussed w/ pixelherodev *was* a niche DSL, by the way.
<DarkUranium> A brand new relational language (same problem space as SQL, but way different).
Ashpool_ has joined #zig
<ikskuh> ouh, that sounds funny
<DarkUranium> ikskuh, in what sense?
<ikskuh> the language jam itself :D
<DarkUranium> Oh :D
<DarkUranium> Thought you meant the DSL.
<ikskuh> > The hackathon starts on August 10th and runs until August 31st.
* ikskuh is tempted to participate
<alexnask[m]> I think some language with comptime evaluation taken to the extreme would have a chance even if the runtime stuff is vanilla
craigo has joined #zig
<alexnask[m]> I was tempted too but I dont think Ill have much time
Ashpool has quit [Ping timeout: 256 seconds]
<ikskuh> but i think i have enough projects already, including "moving to a new flat"
<DarkUranium> alexnask[m], Coyote would be a good candidate for adding comptime evaluation. I'll already have a VM, and the compiler will depend on it.
<DarkUranium> All I'd need, really, would be syntax for compile-time eval, and an API to manipulate the program "one level deeper".
<DarkUranium> Then you could even layer compile-time eval *inside of* compile-time eval :D
<DarkUranium> BTW, sneak peek of that DSL I mentioned (just for fun): σ{id,display_name} Π{email=$email} users
<DarkUranium> Because words are too obvious :D
<DarkUranium> (I'm only semi-joking: they'll be \selection and \projection, respectively)
<alexnask[m]> ς <- best sigma
Ashpool_ is now known as Ashpool
<pixelherodev> alexnask[m]: lol I see my reputation precedes me now
<DarkUranium> Hey there! :)
<pixelherodev> Hi!
<pixelherodev> I'd say good morning but I'm an idiot and I didn't sleep
<ifreund> heh
<pixelherodev> Bright side, I realized why I've had trouble sleeping this past week
<DarkUranium> ouch
* pixelherodev has been accidentally consuming caffeinated tea not realizing it was caffeinated
* pixelherodev is an idiot.
<ifreund> yeah, that'd do it
<ifreund> I just stick to herbal tea
<DarkUranium> Funny thing is, caffeinated tea makes me *sleepy*.
<pixelherodev> Other bright side, I've gone running five out of the last six days, and a linear regression on my weight for the last week shows that my predictions are accurate and it's going down rapidly :)
<pixelherodev> Also I finally found an excuse to use GNUPlot again :P
<pixelherodev> Anywho, time for me to rebase and split that PR
<ifreund> good for you man, running is literally the fastest way to get fit
<ifreund> it also greatly improves sleep quality for me at least (assuming you don't negate it with caffine :P)
<pixelherodev> lol, yeah
<pixelherodev> Whoa
<pixelherodev> #5964 looks neat
<ifreund> hmm, should std.Childprocess clear the signal mask of children?
dermetfan has quit [Ping timeout: 260 seconds]
<ifreund> It also leaks an fd currently on linux which a user of river just discovered
<ifreund> I'm just going to replace it with fork/execve in my code for now
waleee-cl has joined #zig
<pixelherodev> :(
<ifreund> I guess it should maybe call setsid as well, not really sure what best practice is here
<ifreund> eh, probably not. Wouldn't really be a child then
ur5us has joined #zig
KoljaKube has joined #zig
xackus_ has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 260 seconds]
eleanor-nb has joined #zig
<eleanor-nb> pixelherodev Discord PM'd you my notes.
<pixelherodev> Thanks!
eleanor-nb has quit [Remote host closed the connection]
halbeno_ has joined #zig
halbeno has quit [Ping timeout: 256 seconds]
marnix has quit [Ping timeout: 240 seconds]
<pixelherodev> ... i think it's good enough now
<pixelherodev> publishing shortly
<Cadey> did something happen to std.os.mode_t?
<ifreund> don't think so, i still see it in e.g. lib/std/os/bits/linux/x86_64.zig
euandreh has quit [Ping timeout: 246 seconds]
pmwhite has joined #zig
<Cadey> did std.Buffer change names in 0.6?
<ifreund> \o/
<pixelherodev> gah css is off slightly
<DarkUranium> pixelherodev, obligatory:
<Sahnvour> pixelherodev: typo where you advocate for Kristall ? seems like a bit of sentence is missing
<SyrupThinker> Ye, it probably should say something like "... allows that with its outline feature)" Also code blocks overflow on my phone and I can't scroll to read the rest.
<SyrupThinker> (of the overflowing part)
<scientes> DarkUranium, nice gif
<danyspin97> << and @shrExact complains about value 13 that cannot be coerced to u3
<ifreund> danyspin97: what's the type of class/data?
<danyspin97> integer
<danyspin97> both `int` in C
<pixelherodev> Sahnvour: whoops
<ifreund> what size? sounds like you're using 8 bits from the "u3"
<danyspin97> I have `const IOPRIO_CLASS_SHIFT : u8 = 13;`
<ifreund> not asking about C but about your code
<danyspin97> the C code is just `int`
<ifreund> what about class though?
<danyspin97> and yea
<danyspin97> i8
<ifreund> yeah, you can't do that
<danyspin97> i see, I should use i32
<ifreund> i8 has 8 bits, you can't shift left 13 bits
<danyspin97> you're right, thanks for the explanation
<ifreund> no problem
<DarkUranium> I wonder. Does Zig have a way of specifying saturating arithmetic for a specific expression?
<alexnask[m]> Nope, there is a proposal open for this though
<alexnask[m]> (accepted)
<DarkUranium> It is something I miss quite often in C. It's very useful for signal processing (including image processing, which is just a fancy type of signal anyways)
JayceAndTheNews has joined #zig
JayceAndTheNews has left #zig [#zig]
<pixelherodev> DarkUranium: lol exactly (the gif)
<DarkUranium> Web technologies are such a mess.
<DarkUranium> pixelherodev, did you know that they wanted to put file uploads *and* raw sockets into SVG 1.2?
<DarkUranium> Yes, the graphics format.
<pixelherodev> What the actual fuck?!
<KoljaKube> Now I'm intrigued :D
<pixelherodev> Whoever proposed that should be shot into the sun!
<DarkUranium> They finally got to their senses at some point (which is why the "newest version" link doesn't have it), but:
<SyrupThinker> Sockets Via Graphics
<DarkUranium> lol SyrupThinker
<pixelherodev> Hahaha
<DarkUranium> And don't get me started on WebUSB ...
<pixelherodev> Or webserial
<alexnask[m]> TIL
<DarkUranium> pixelherodev, wtf.
<pixelherodev> You didn't know about that one?
<DarkUranium> Nope.
<pixelherodev> Haha
* pixelherodev sobs
<pixelherodev> Yeah it's awful
<DarkUranium> Here's a fun read:
<DarkUranium> (I may have lied about the "fun" part)
<DarkUranium> Just see first two code blocks.
<SyrupThinker> Web* make sense for the web as an application platform, but not for the web as a document system
<DarkUranium> SyrupThinker, it doesn't, though.
<DarkUranium> Oh, you mean all the WebFoo things ... I guess?
<DarkUranium> But WebUSB is just plain dangerous.
<SyrupThinker> Sadly browser vendors (or at least their PR people) think Permissions are evil and should be avoided at all costs
<SyrupThinker> Although that's the one thing that redeems the web as a platform for me
<DarkUranium> IETF also had their share of blunders.
<DarkUranium> The most frustrating one for me is libopus.
<ifreund> WebAssembly seems to be the only reasonably WebFoo thing
<pixelherodev> Eh
<pixelherodev> I disagree there
<DarkUranium> ifreund, I've looked into it. The idea is reasonable.
<pixelherodev> I like WebAsm
<DarkUranium> WebAssembly itself is a *horrible mess*.
<pixelherodev> I don't think it's a good fit for the web
<DarkUranium> pixelherodev, it's a mess. I outright don't want to use it because they fucked up so badly :|
<pixelherodev> ^ that's probably a better way to put it
<DarkUranium> (but I'll probably be forced to)
<pixelherodev> The idea of web-as-application-platform is anathema to me
<pixelherodev> If I can get away with it, I'll be nuking qutebrowser soon
<pixelherodev> And using kristall only :P
<fengb> Wasm is fine
<alexnask[m]> Fight
<fengb> Interfacing with it and web apis kinda blows
<Nypsie[m]> It's really not that strange of an idea if you look in the enterprise industry. It is so much easier to support enterprises with a web app than some desktop application.
<alexnask[m]> Yeah all the JS glue >.>
<fengb> Despite its name, it’s actually kinda lousy for the web
<fengb> And pretty good as a stand-alone vm setup
<Nypsie[m]> (Altho, companies who still use IE can burn)
<DarkUranium> fengb, are you aware of what mess they made with their representation?
<DarkUranium> They fucked up so badly that their locals can't be optimized properly.
<DarkUranium> And they're seemingly unaware of the fact that you can verify code that's in SSA form (because that's their argument for not allowing normal block-based control flow).
<DarkUranium> There's a thread about the lack of goto, it's a dumpster fire.
<Sahnvour> webasm is peak "local maximum"
<DarkUranium> It's not even a local maximum. In hype & usage, maybe.
<Sahnvour> make that quotes tiples, but you get the idea
<Sahnvour> the very idea of making the web the universal platform is a (very) local maximum because web browsers are ubiquitous, but meh
<fengb> Wasm isn’t designed for the web
<DarkUranium> fengb, my issue with wasm isn't with wasm on the web.
<DarkUranium> My issue with wasm is in its internal representation.
<fengb> Trying to use it on the web and it’s pretty clear it doesn’t map well at all
<Sahnvour> isn't it part of the trend to make web browsers into VMs ?
<DarkUranium> And it definitely was designed for the web --- the main *actual* reason it doesn't have goto is a combination of idiocy and V8-related politics.
<fengb> I’m actually fine with no gotos
<DarkUranium> Well, it wasn't designed for the web in the sense that it was designed for V8.
<SyrupThinker> Control flow analysis no?
<DarkUranium> fengb, I'm not. Internal representation of compilers nowadays uses basic blocks.
<fengb> It’s not designed to be instruction based low level
<fengb> At least not machine level
<DarkUranium> You end up deoptimizing anything that's not. LLVM emits while(__label__) switch(__label__) for irreducible control flow (this shows up a *LOT* in async code, BTW)
<DarkUranium> They also fucked up the locals, where you can't actually allocate registers as effectively as with SSA, or as easily as with stack-based machines.
<DarkUranium> It's just a dumpster fire of bad design, really.
<DarkUranium> here you go, for the locals issue
<danyspin97> how can i get the errno of syscall?
<DarkUranium> fengb, relevant portion: "[...] This essentially makes WebAssembly a register machine without liveness analysis, but not only that, it’s a register machine that isn’t even in SSA form - both of the tools at our disposal to do optimisation are unavailable. [...]"
<danyspin97> I have tried os.errno(result) with result the return value of the syscall
<fengb> Feels kinda like 2 camps just yelling at each other
<fengb> Which I’m sure it probably has flaws. But we’ve never had a cross platform VM that’s this low level
CodeSpelunker has joined #zig
<pixelherodev> fengb: that's nonsense
<pixelherodev> We've had plenty
<pixelherodev> People just haven't used them for this kinda thing
<pixelherodev> Almost literally every emulator ever supports most common platforms
<pixelherodev> With 100% consistency between them
<ifreund> DarkUranium: re that post, it looks like the proposal referenced that solves the problem was merged a couple months ago
cole-h has joined #zig
<DarkUranium> ifreund, took them long enough =\
craigo has quit [Ping timeout: 256 seconds]
swills has quit [Quit: swills]
CodeSpelunker has quit [Quit: CodeSpelunker]
<pixelherodev> Woot!
<pixelherodev> #5964 merged!
<pixelherodev> :D
<Ristovski> hmm, am I dumb? I can't get cimgui to work. Keep throws "note: unknown type name 'IMGUI_IMPL_API'" no matter if I define it to be 'extern "C"' or not
<ifreund> man, zig fmt won't let me put a switch on one line, even if I remove the trailing comma
<fengb> zig fmt does not make friends, only judgements
metasyntactic has joined #zig
<ifreund> I made it an if so I can do it on one line, but the switch was more readable if a little longer
<pixelherodev> ifreund: fmt: off /)
<pixelherodev> ;)
<leeward> Ristovski: If you give us some sample code we might be able to figure out what's going wrong. has Zig support.
<Ristovski> Let me try debugging thi
<Ristovski> s
marnix has joined #zig
<DarkUranium> Ristovski, sounds like a missing #define?
<Ristovski> DarkUranium: ah, I had it badly escaped :/
<DarkUranium> *_API is typically stuff that defined the calling convention.
<DarkUranium> s/defined/defines/
<Ristovski> yup, had an extra set of "" around the -DIMGUI_IMPL_API
xackus_ has joined #zig
cole-h has quit [Quit: Goodbye]
metasyntactic has quit [Ping timeout: 265 seconds]
<gruebite> quick way to zero initialize a struct instead of undefined?
<alexnask[m]> std.mem.zeroes
<alexnask[m]> (or zeroInit which initializes to default or zero)
<Ristovski> How can I 1) format a string 2) pass it to a C function
<Ristovski> I looked at fmt.zig but its not immediately obvious
<gruebite> nice, thanks
<ifreund> Ristovski: you migh want std.fmt.allocPrint0()
<ifreund> this will allocate memory and format a string, adding a null terminator which the C function probably needs
<ifreund> If you don't want to allocate, there's a version taking a buffer as well iirc
<alexnask[m]> Looks like there isnt a bufPrint zero terminated variant
<Ristovski> yeah I just noticed
craigo has joined #zig
<alexnask[m]> But you can just explicily add a zero terminator in the format string
<ronsor> ^
metasyntactic has joined #zig
CodeSpelunker has joined #zig
<Ristovski> alexnask[m]: Can I not set the buffer to be 0 initialized?
<alexnask[m]> Sure this would work too
<alexnask[m]> You will be writing over N bytes twice though but I dont think its a huge deal :shrug:
<Ristovski> Oh hmm, I see
<Ristovski> thanks!
swills has joined #zig
<ifreund> so, wasm doesn't use elf. Guess I've got a good bit of infrastucture to build
<pixelherodev> Going to need a new link.File type
<ifreund> yep
<alexnask[m]> Ah are you adding wasm to stage2? Cool! Im working on PE myself, reading docs and code rn and will start writing code soon
<ifreund> alexnask[m]: yeah, that's my goal
<ifreund> wait, what's PE?
<pixelherodev> ... okay I really need to rush my PRs through now :P
<pixelherodev> ifreund: Windows.
<alexnask[m]> ifreund: windows executables
<pixelherodev> Nice to see interest taking off now :)
<ifreund> ah lol
<Nypsie[m]> I should work on another stage 2 PR 🤔
<ifreund> I guess incremental compilation needs to be implemented independantly for each container format
<pixelherodev> Nope
<pixelherodev> Well, sorta
<pixelherodev> You need to implement some parts of it, but the majority of it is before the linker
<pixelherodev> Linker should use an offset table, codegen needs to use that instead of directly calling functions
<pixelherodev> Linker needs to track where symbols are in the output so it can update them, and it needs to track their offset table entries
<ifreund> yeah, so I need to figure out how that works for wasm
<alexnask[m]> updateDecl, allocateDeclIndexes, updateDeclExports is what you need per format afaict
<ifreund> yup, found those
<pixelherodev> This is awesome :)
<ifreund> gotta say, the stage2 code has been surprisingly easy to follow so far for someone who has never worked on a compiler before
<ifreund> it does help that it's written in zig :)
<Nypsie[m]> The general structure is really clear imo
<pixelherodev> Okay, removed p16 and improved the way 16-bit ELF is handled a bi
<pixelherodev> bit*
<pixelherodev> And tests still pass, so...
<ronsor> crazy idea incoming: is it possible that I could add support for targeting MS-DOS DJGPP?
<pixelherodev> What's DJGPP?
Kingsquee has joined #zig
<ronsor> "DJGPP is a complete 32-bit C/C++ development system for Intel 80386 (and higher) PCs running DOS. It includes ports of many GNU development utilities. The development tools require a 80386 or newer computer to run, as do the programs they produce. In most cases, the programs it produces can be sold commercially without license or royalties. "
<pixelherodev> C compiler?
<pixelherodev> Does it support C89?
<ronsor> yes, it's a port of GCC to DOS
<pixelherodev> Then you don't need to do anything ;)
<pixelherodev> I've already started working on a C89 backend
<pixelherodev> It's not fully up to date, but I'm going to be expanding it tomorrow morning :D
<ronsor> C89 backend? wow
<pixelherodev> Yep
CodeSpelunker has quit [Quit: CodeSpelunker]
<leeward> Does anything not support C89? I feel like that's the least common denominator for generated code.
<pixelherodev> That's why we're targeting it
<pixelherodev> We use the preprocessor to add better e.g. noreturn support depending on available standard
<DarkUranium> leeward, uuh ... the C# compiler doesn't!
<DarkUranium> (it supports C#!)
<DarkUranium> :P
* pixelherodev facepalms
<pixelherodev> while grinning a bit :P
<DarkUranium> Thank you, I'll be here all week.
<ronsor> a C# backend would be interesting
<leeward> DarkUranium: Thank you. Your pedantry has been noted.
<ronsor> and strange
<leeward> Welcome to the list.
<DarkUranium> lol
<DarkUranium> Am I getting coal for christmas now?
<leeward> Ask phd. He's the charter member of the list.
<pixelherodev> Nah, sorry, I don't know that stuff
<leeward> ronsor: A CLI (because Microsoft is happy to alias TLAs) backend might actually be useful to some people.
<pixelherodev> ... I think my zig fmt is broken???
<pixelherodev> Yeah.
<pixelherodev> Crap.
<pixelherodev> ... oh wait nvm
<pixelherodev> `zig fmt: off` at the top
<leeward> hah
<DarkUranium> leeward, isn't it called CLR nowadays?
<pixelherodev> Huh neat, Kristall can look at GitHub Issues without Issues ;)
<DarkUranium> And I think CLR is a bit of a bag of worms, because then people expect to be able to use the entirety of .NET from the language ...
<DarkUranium> pixelherodev, I wonder how it'd work with Gitea.
<leeward> DarkUranium: Maybe? I haven't paid any attention to it.
<DarkUranium> I've used it briefly at univ and a tiny bit at work ... but I really dislike .NET, so I try to avoid it whenever I can.
<ronsor> I prefer .NET to Java
<leeward> .NET came out when I was in school and I wasn't a CS major so...managed to never learn any .NET languages or Java.
<Ristovski> is "-target native" the default?
<leeward> Ristovski: yep
<Ristovski> cool!
<leeward> native-native
<pixelherodev> Which also includes the equivalent of `-march=native` ;D
<pixelherodev> Okay, almost done rebasing SPU II branch...
<pixelherodev> There
CodeSpelunker has joined #zig
CodeSpelunker has quit [Remote host closed the connection]
<gruebite> trying to cast from [256]u8 to [*:0]u8
<gruebite> i would think it would be unambiguous and allowed by @as but apparently not
<fengb> The zero termination makes it ambiguous
<pixelherodev> Two PRs down... one to go?
<alexnask[m]> `text[0..len : 0]`
<fengb> Not ambiguous. Potentially buggy
<leeward> It's not obvious that your [256]u8 is terminated by a zero.
<alexnask[m]> (len doesnt include the zero byte)
<gruebite> i was looking at spanZ but i first need a sentinal
<fengb> So it won’t help you accidentally shoot yourself in the foot
<gruebite> gotcha
<gruebite> where i cast to 0 sentinal and it doesn't have a zero sentinal
<leeward> casts only reinterpret memory; they don't transform it.
Ashpool_ has joined #zig
<fengb> Easiest way is `@ptrCast([*:0]u8, &array)` but that doesn’t check the sentinel
<gruebite> okay, so how to get the length of [256]u8 where i know it has a zero terminator? :P
<gruebite> yeah, i've used that previously
<gruebite> i'm getting this block from C code
<pixelherodev> Okay, hopefully none of those PRs accidentally depend on each other...
<pixelherodev> `tests` branch passes locally...
Ashpool has quit [Ping timeout: 256 seconds]
<pixelherodev> ihex *probably* passes locally...
<pixelherodev> All three pass locally :D
<gruebite> this ended up working: mem.eql(u8, check, mem.spanZ(@ptrCast([*:0]const u8, &c_buffer)))
stripedpajamas has joined #zig
<pixelherodev> Now that more of us are working on backends, I think it's time to at least start keeping track of who's working on what so we can avoid stepping on each other's toes
<pixelherodev> Don't want to have multiple people submitting redundant work :)
<pixelherodev> Haha
<pixelherodev> I need to update my post already :P
<DarkUranium> alexnask[m], hey. I did some brainstorming with pixelherodev on the topic of LSP support.
<DarkUranium> I think I have a strategy on what to try now; I can let you know how it goes :)
<pixelherodev> I'm currently working on File.Hex (Intel HEX format), SPU II, and the C backend; alexnask[m] is working on File.PE (Windows executables); ifreund is working on File.Wasm
<DarkUranium> (though we're likely to only implement it post-jam)
<pixelherodev> Neato
marnix has quit [Ping timeout: 246 seconds]
<leeward> Heh, that's a fun bug.
KKRT has quit [Quit: KKRT]
<leeward> I think using defer in a noreturn function might cause an infinite loop in the compiler.
<leeward> Ooh, and it eats memory like a champ too.
<DarkUranium> nom nom memory
<DarkUranium> I managed to use 25GB of RAM in a single query yesterday, before postgres gave up.
<DarkUranium> Sorry, not RAM --- but disk space (it flushed to disk due to size)
<leeward> Well, this ate all my RAM and was chewing through swap by the time I killed it.
<gruebite> [_][]const u8 -> [*c]const [*c]const u8
<DarkUranium> leeward, ouch.
nikita` has quit [Quit: leaving]
<gruebite> can't seem to get this conversion right
<ifreund> well, a []cons u8 is twice the size of a [*c]const u8
<alexnask[m]> You cant do this without a separate array of pointers since a slice is a ptr len
<ifreund> so you need to do a copy there
craigo has quit [Quit: Leaving]
<gruebite> i would just duplicate it since it's internal, but i can't easily initialize [*c][*c]const u8?
<gruebite> like: [*c][*c]const u8{ "str1", "str2" };
<alexnask[m]> `var arr = [_][*c]const u8 { "str1", "str2" }; &arr;`
<ifreund> I'd recommend var arr = [_][*:c]const u8{ .. }
<ifreund> all pointers coerce to [*c]
<ifreund> whoops, meant [*:0]
<leeward> Did I accidentally slip into evented IO mode when I started using File.seekableStream()?
<leeward> My program runs to completion and hangs.
craigo has joined #zig
<alexnask[m]> ifreund: `&arr` will not coerce to [*c][*c]const u8 in that case because of the different child types
<ifreund> really? that seems odd
<leeward> ah data dependent bugs
Ashpool__ has joined #zig
Ashpool_ has quit [Ping timeout: 264 seconds]
KoljaKube has quit [Ping timeout: 244 seconds]
funnbot has joined #zig
DarkUranium has quit [Remote host closed the connection]
<ifreund> what happens as the offset table grows in size? wouldn't that require shifting the rest of the contents of the file?
DarkUranium has joined #zig
<ifreund> or are things only incrementally updated in-memory and the the file is rewritten each time?
<ifreund> or is there just a bunch of padding after the offset table?
funnbot has quit [Remote host closed the connection]
<ifreund> hmm, looks like everything is updated in the file directly
<ifreund> not quite sure how this is going to work with wasm as the spec requires the functions to be perfectly packed
<leeward> does "perfectly packed" mean align(1)?
<ifreund> yeah wasm is all align(1) afaik
<leeward> makes sense for something that's necessarily being sent over a network
<ifreund> I could add new functions to the end without removing the old versions, but re-using the space taken up by the "dead" functions can only happen if a new function has the exact same size
<fengb> Can you noop pad the function?
<alexnask[m]> ^
<ifreund> hmm, yeah I think I could
<ifreund> let me test that
<fengb> It should only take a byte so as long as it’s smaller
<ifreund> I can also pad between sections using empty custom sections
<fengb> I thought custom sections was reserved for the end
<fengb> Been a few months since I looked though
<ifreund> you can put them at the start, end, and between any section
<ifreund> yeah looks like noop padding will work wonders
<ifreund> now I just need to figure out how best to implement the offset table, probably padded with a custom section after it
<ifreund> fengb: it's sensible to just use globals to store the function indexes right?
<fengb> I thought function indexes have their own section
<ifreund> yes, but we need to have the equivalent of an offset table
<ifreund> instead of calling functions directly, one would call the function index stored in a specific global
<fengb> Oh and everything would be call indirect then?
<ifreund> yeah, we need that to make incremental work
<leeward> Incremental build only has to work in Debug, right?
<ifreund> right
<ifreund> we definetly don't want this indirection in release builds
<fengb> Maybe using the table section? Looks like global section can only store primitives
<fengb> (I actually have no clue what the table section does... was planning on figuring that out later)
<fengb> "tables may only be accessed from WebAssembly code via call_indirect;"
<fengb> Hmm, you'll need to merge the compiler jump table with the executable's table into the same section
<fengb> That's awkward :(
<ifreund> fengb: function indexes are just 32 bit integers no?
<ifreund> what's wrong with putting that in a global?
cole-h has joined #zig
<fengb> Because you can't call arbitrary numbers afaik
<fengb> They need to be loaded into a jump table
<fengb> s/jump/dispatch
stripedpajamas has quit [Quit: sleeping...]
<ifreund> hmm
<ifreund> yeah looks like you're right
blinghound has joined #zig
xackus_ has quit [Ping timeout: 256 seconds]