<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 ;)
<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>
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: https://github.com/ziglang/zig/issues/5921 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
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 repl.it 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 repl.it 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>
"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
<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.
<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:
<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.
<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>
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
<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. https://godbolt.org/ 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.
<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)