<andrewrk>
fraktor, std.meta.trait should be renamed to std.meta.concepts
<andrewrk>
to match the corresponding C++ terminology
casaca has quit [Remote host closed the connection]
casaca has joined #zig
Biolunar has quit [Ping timeout: 256 seconds]
Biolunar has joined #zig
ur5us has joined #zig
casaca has quit [Remote host closed the connection]
casaca has joined #zig
nephele has quit [Ping timeout: 260 seconds]
nephele_ has joined #zig
nephele_ is now known as nephele
<shakesoda>
is there a particular reason to match c++ terminology instead of rust's for it
<tdeo>
well the concept (ha) is much closer to the c++ one
<tdeo>
in that it just checks if a type fulfills some description you give
slurpie has quit [Ping timeout: 272 seconds]
aerona has joined #zig
<torque>
std.meta.ducktype
<shakesoda>
i would be all for std.meta.duck
<pixelherodev>
Agreed
<tdeo>
yeah
stripedpajamas has joined #zig
<andrewrk>
haha
stripedpajamas has quit [Quit: sleeping...]
waleee-cl has quit [Quit: Connection closed for inactivity]
poga has quit [Ping timeout: 272 seconds]
leeward has quit [Ping timeout: 256 seconds]
<andrewrk>
pixelherodev, I just merged some big stage2 improvements
<andrewrk>
* virtual address allocation scheme * dependency tracking / handling deletions and no longer referenced decls
<andrewrk>
pixelherodev, my question to you: what is it in stage2 that interests you, that you would like to work on, so that I can work towards unblocking you?
<pixelherodev>
Well, first I want to finish the current PRs
<pixelherodev>
get error_tests (#5422 IIRC) merged, and then finish implementing function calsl
<andrewrk>
right of course
<pixelherodev>
After that... hmm
<pixelherodev>
I think the most pressing concern to me is esoteric platform support
<pixelherodev>
Like, genuinely *weird* platforms
<pixelherodev>
Because if we don't support them *now*, it'll be hell to do later
<pixelherodev>
Since it'd require reworking existing backends
<pixelherodev>
Better to get the infrastructure in place now
<andrewrk>
for the error tests one, I'm actually going to update that to be merged with non-error tests. so for example, you could have some source that succeeds with some output. then you modify the source, and it has such and such error on a specific decl, then you modify the source again and now it has different output. that's an example test case for stage2
<pixelherodev>
Gotcha
<pixelherodev>
Want me to do that, since I was just working on it?
<andrewrk>
stage2 tests are really involved because they test not only one input->output but input,output,modification,output,modification,output, etc
<andrewrk>
sure!
<pixelherodev>
Then I want to work on actual codegen for something more unusual, though I'm not sure what
<pixelherodev>
What's a nice, unusual architecture?
<pixelherodev>
Z80 is one I'm familiar with, but it doesn't *quite* meet esoteric standards IMO
<pixelherodev>
I want to make sure there doesn't have to be something like SDCC for Zig
<andrewrk>
ikskuh tends to know about esoteric architectures
<pixelherodev>
Ooh, maybe something like a SUBLEQ?
<andrewrk>
how about 6502
<andrewrk>
the cpu of the NES
<pixelherodev>
That's definitely a good *target8
<pixelherodev>
*
<pixelherodev>
but it doesn't meet my standards for this, I don't think
<pixelherodev>
I'm looking for something unusual enough that it'll break our normal assumptions
<andrewrk>
hmm I think your goals aren't matching up with my short term goals
<pixelherodev>
That's because this isn't really a short term goal for me
<andrewrk>
I want to focus on common architectures right now, getting self-hosted to a working state
<pixelherodev>
It's a short term goal to ensure long term goals are achievable later on
<pixelherodev>
The thought to me is that it's relatively straightforward to do this *now*
<pixelherodev>
but it won't even be possible later
<pixelherodev>
I don't want to spend *too* much time on it
* pixelherodev
shrugs
<pixelherodev>
Eh, it's probably not that big of a deal
<pixelherodev>
Maybe I'll focus on x86?
<pixelherodev>
Just to make sure we didn't accidentally introduce any dependencies on 64-bit
<pixelherodev>
Plus, most of the backend is the same
<pixelherodev>
So it'll be useful for amd64 too
<andrewrk>
that's a good idea
<pixelherodev>
I think my short term goal is to refactor it a bit
<pixelherodev>
Anything AMD64-specific should be in backend/x86_64/something.zig and not in codegen.zig
<pixelherodev>
A way to map architectures to backend structs when the arch is only runtime known helps, but that's probably what an inline for is for
<pixelherodev>
One other idea that's been percolating for a bit is to make it easy to connect out-of-tree backends
<andrewrk>
I'm not sure I agree with that refactoring idea
<pixelherodev>
Whether that means exposing parts of stage2 in std.zir, an alternate library (`@import("zig")`, or explicitly defining a backend interface
<pixelherodev>
the thought to me is basically this
<pixelherodev>
Most of the time, if you're working on codegen, it's for a specific architecture
dimenus has quit [Quit: WeeChat 2.8]
wozeparrot has quit [Ping timeout: 256 seconds]
<pixelherodev>
You don't care how x86 implements calls if you're working on it for ARM
<andrewrk>
counterpoint: codegen.cpp is architecture-agnostic and it is 11,198 lines
<pixelherodev>
Yes, but it's also limited to LLVM architectures
<pixelherodev>
One goal of stage2 is to extend beyond that
<pixelherodev>
and, more importantly
<pixelherodev>
We can't rely on LLVM
<pixelherodev>
codegen.cpp is ~11K lines, and it can rely on an external library to do the heavy lifting
<pixelherodev>
We're effectively incorporating both the parts that LLVM does, and the LLVM implementation
<pixelherodev>
So we have more architectures, a lot of implementation, and the biggest part to me is what I was mentioning about unofficial backends
<pixelherodev>
We should make it easy to work on unofficial backends, so that it's easy to get them merged upstream later on
<pixelherodev>
If I'm working on an external backend, I don't want upstream patches to force me to rebase everything
<andrewrk>
I definitely agree with organizing the codebase to optimize for contributions to unofficial backends
<pixelherodev>
I'm not certain what the best way to do it is, I just want to make sure that it's done
<andrewrk>
humor me a little bit though, let's figure out the best way to organize the code after codegen.zig is more than just a proof of concept
<andrewrk>
once it starts to get unruly, it should be a lot clearer how to better refactor it
<pixelherodev>
Agreed
<andrewrk>
the patterns will be more clear
<pixelherodev>
It definitely doesn't matter just yet
* pixelherodev
casually reverts patches on the function_args branch
<andrewrk>
all aboard the merge train! choo choo!
<pixelherodev>
Nice :)
<pixelherodev>
andrewrk: you asked what *I'm* interested in working on; counter-question: what would be the most helpful?
<andrewrk>
that was a helpful response btw! and I agree with your goals
<pixelherodev>
Good to know :)
<pixelherodev>
Oh, relatedly then
<pixelherodev>
Should I move codegen/*.zig into codegen.zig?
<andrewrk>
anything that gets us closer to self-hosted compiler completion would be most helpful. I can try to break that down into smaller steps
<pixelherodev>
(The register definitions)
<pixelherodev>
Nah, that's good enough
<andrewrk>
nah it's fine
<pixelherodev>
Should *definitions* go in codegen/arch, and *implemenations* go in codegen itself?
<pixelherodev>
Or is it more "no need to change it" than "let's make this our organization!!!"
<andrewrk>
I'm really not too concerned with which bits go in which files at this point
<pixelherodev>
Gotcha
<pixelherodev>
Oh, a thought occurred
<pixelherodev>
Should e.g. FLAGS be defined in Register?
<andrewrk>
I just think that moving things around is pretty easy, so might as well wait until it's obvious how they should be moved around
<pixelherodev>
flags/eflags/rflags?
<pixelherodev>
I can see how they *might* be useful, though branching might be better
<pixelherodev>
(for e.g. `(a & b) != 0`)
<andrewrk>
that's another thing that I think will become obvious when we get further along towards self-hosted completion
<pixelherodev>
in other words:
<pixelherodev>
Stop obsessing over design and focus on actually being productive?
<pixelherodev>
Drats
<pixelherodev>
:)
<pixelherodev>
PR incoming shortly; extracting the REXes into a function
<pixelherodev>
So that instead of reproducing the same logic at every point, it's just `self.REX(.{ .b = true});`
<pixelherodev>
(as an example)
<andrewrk>
:)
<andrewrk>
I think obsessing over the design is useful, but we just don't have enough information yet on those particular areas of code
<andrewrk>
btw what do you think about the virtual address allocation scheme?
<pixelherodev>
Going to finish up and then take a look
<andrewrk>
it's ironic that to implement zig, a language with manual memory management, the compiler has several different ad-hoc garbage collector implementations
<pixelherodev>
Returns a u8, so it can be used in-place in a write operation and doesn't require a separate one
<andrewrk>
huh why do we need reflection?
<andrewrk>
`options: struct { B: bool }`
<pixelherodev>
Because there's four options, and in 99% of cases only one matters
<pixelherodev>
... wait
<pixelherodev>
Struct default values exist
<pixelherodev>
I keep forgetting that
<andrewrk>
you can also make REX and REX_fancy with one of them calling the other, and the other taking parameters
<pixelherodev>
?
<pixelherodev>
You mean with reflection -> parameters?
<pixelherodev>
That seems unnecessarily elaborate
<pixelherodev>
anonymous structure with default arguments seems perfectly fine to me
Stephie has quit [Quit: Fuck this shit, I'm out!]
<pixelherodev>
The only reason to even use a tuple as the argument is to avoid having to say "No, we *don't* need this; no, we *don't* need that" everywhere
<pixelherodev>
This lets us say, "here's what we want," and not, "here's what we want, here's the other things we don't"
<pixelherodev>
(Well, that and it lets us name them)
Stephie has joined #zig
<pixelherodev>
hmm, another option is to make REX `write` the value directly
<pixelherodev>
That has the advantage of simplifying codegen logic
<pixelherodev>
Instead of `if we need REX, generate it too`, it becomes `generate a REX if we need one`, which is a simple `self.REX(.{.B = reg.isExtended()});` for instance
<pixelherodev>
I wonder how much my comments in codegen will increase the line count :P
leeward has joined #zig
<pixelherodev>
andrewrk: thought; should e.g. XOR encoding also be moved into a function?
<pixelherodev>
That way, any usage of it (e.g. an actual XOR implementation) can just be `self.XOR()`
<pixelherodev>
The idea is to basically separate the low-level encoding (raw bytes) from the high-level meaning ("zero this register")
<andrewrk>
I don't really see any reason to move any codegen.zig stuff around at this point, until it's more fleshed out
<andrewrk>
remember: solve the problems that you have now. solve the problems that you will have in the future, in the future
<andrewrk>
YAGNI
<andrewrk>
we have plenty of tasks to do on self hosted
<andrewrk>
but some would be I think really helpful and would get things closer to the state where you are anticipating
<andrewrk>
for example, implementing math and other binary operations would be really helpful
<andrewrk>
function arguments and conditional branching at runtime are also good candidates
<pixelherodev>
I'll do that after function calls
<pixelherodev>
Function args is something I'm mostly done with
<andrewrk>
exciting
<pixelherodev>
How much special-casing should there be?
<pixelherodev>
I mean
<pixelherodev>
We have e.g. u8_function_no_args and such
<pixelherodev>
Should we have that for all common function types?
<andrewrk>
it's a balance between maintenance cost, code bloat, and perf improvements / memory usage reduction
<andrewrk>
probably some of those really special case ones will go away eventually. they were handy for when the type handling code was less sophisticated
<andrewrk>
generally: add additional representations when it makes some code easier to implement, or if you have a benchmark demonstrating that it saves memory or improves perf
aerona has quit [Quit: Leaving]
<pixelherodev>
Gotcha
<andrewrk>
note that if you are trying to access information about a Type or Value you should be using the accessor methods, not looking at the individual tags
<andrewrk>
e.g. use ty.zigTagType() == .Array and ty.arrayLen() and ty.elemType() rather than peeking into the guts of how the type is represented
<andrewrk>
although, obviously, exceptions can be made if it makes sense to do so
<pixelherodev>
I figured that out :)
<pixelherodev>
Mostly because I tried using the tag first and realized how annoying it was
<pixelherodev>
So I looked at other code and saw how it was done elsewhere
<andrewrk>
nice
<pixelherodev>
I'm just going to finish up the REX thing and go to sleep
<pixelherodev>
I'm mostly doing it because it's already mostly done
<pixelherodev>
I'm not going to do anything more like it until stage2's a lot further along
<andrewrk>
oh I think I see what you were hitting with the type coercion tihng
<andrewrk>
I think this is the ZIR parser emitting the wrong code
<pixelherodev>
What i saw from tracing it in gdb was that the ZIR Inst representing the function's *name* was read as an array
<pixelherodev>
within resolveConstString
<andrewrk>
check out zir.zig parseParameterInst, the part where it doesn't find it in the map
<andrewrk>
it tries to emit it as a declref but it's missing a ref there. adding it now
<pixelherodev>
That's not it
<pixelherodev>
At least
<pixelherodev>
that's not what I hit
<pixelherodev>
Because this was *without* parameters...
<pixelherodev>
wait
<pixelherodev>
...
<pixelherodev>
no yeah
<pixelherodev>
that's probably it
<pixelherodev>
been a few days and Ive already largely forgot it :P
<pixelherodev>
andrewrk: let me know when that lands
<pixelherodev>
Actually, I should finish error_tests first
<pixelherodev>
Then enable the tests using the updated harness instead
<pixelherodev>
alrighty, PRed
slurpie has joined #zig
stripedpajamas has joined #zig
<andrewrk>
thanks!
<pixelherodev>
:)
_whitelogger has joined #zig
<pixelherodev>
#5457 is good to go now
<pixelherodev>
(or at least be closed if you'd rather not merge it)
<pixelherodev>
Would be neat if we could tweak CI so that it only runs relevant tests
<pixelherodev>
e.g. if nothing in src/ changes, skip the stage1 tests
<pixelherodev>
If nothing in src-self-hosted/ changes, skip the stage2 tests
<pixelherodev>
!!!
<pixelherodev>
There's an Intel manual on machine code optimization!
ur5us has quit [Ping timeout: 260 seconds]
_whitelogger has joined #zig
knebulae has quit [Read error: Connection reset by peer]
stripedpajamas has quit [Quit: sleeping...]
slowtype1 has joined #zig
knebulae has joined #zig
<pixelherodev>
Holy freaking... `push`, `pop`, `return`, etc have effectively no cost on modern CPUs (both from Intel *and* AMD)
<pixelherodev>
The CPU just renames the stack pointer to a different internal register and keeps going
<pixelherodev>
Sorta like running the actual memory access in the background
<pixelherodev>
Faster in Ryzen than in Intel microarchs, apparently
<pixelherodev>
... probably not the right place for this :P
tdc has joined #zig
antaoiseach has joined #zig
antaoiseach has left #zig [#zig]
_Vi has joined #zig
_Vi has quit [Ping timeout: 260 seconds]
slurpie has quit [Remote host closed the connection]
slurpie_ has joined #zig
ur5us has joined #zig
_Vi has joined #zig
Stephie has quit [Quit: Fuck this shit, I'm out!]
dermetfan has joined #zig
Stephie has joined #zig
dddddd has quit [Ping timeout: 246 seconds]
<shakesoda>
pixelherodev: i'm curious about the performance properties of the arm equivalents
<pixelherodev>
?
<pixelherodev>
Ahh
<pixelherodev>
I wouldn't know
<pixelherodev>
I only know this from a microarchitectural optimization guide
<pixelherodev>
Well
<pixelherodev>
A microarchitecture analysis study that's used to provide info in a optimization guide :P
<shakesoda>
somewhat directly related: just bought myself a raspberry pi 4 (8gb model exists now!)
<shakesoda>
my arm knowledge could stand to gain a fair bit and it's a lot beefier than my other pis here
<antaoiseach>
Hello ... I am trying to print an "expression" recursively ... is this sort of thing not possible? https://paste.rs/yNs
<antaoiseach>
I get the following error - "Semantic Analysis [555/831] ./eval.zig:21:13: error: cannot resolve inferred error set '@TypeOf(show).ReturnType.ErrorSet': function 'show' not fully analyzed yet try show(d.left, stdout);
<antaoiseach>
"
<ifreund>
antaoiseach: you can't use inferred error sets with recursion
<ifreund>
if you explicitly specify the return type as `MyErrorSet!void` it should work
<ifreund>
as noted in the docs, this limitation might be overcome in the future
<antaoiseach>
ifreund: Oh... okay
<antaoiseach>
The debug.warn examples works fine ... just confirmed
<antaoiseach>
ifreund: Aha .. lemme try that and get back
<antaoiseach>
ifreund: confirmed .. it works with anyerror as well!
<antaoiseach>
Thanks!
<ifreund>
oh that's interesting
<ifreund>
no problem!
<antaoiseach>
ifreund: Another question if you don't mind
<ifreund>
fire awawy
<antaoiseach>
in the type signature for stdout that I pass into my show function
<antaoiseach>
I printed out the type of stdout explicitly and then used that as the signature
<ifreund>
i would do @TypeOf(stdout)
<antaoiseach>
What I am not clear on is this - why does std.io.OutStream not work by itself? The signature std.io.StdIn works for stdin?
<antaoiseach>
Also, I figured that std.io.OutStream itself is a function of sorts which needs those three types to become a type itself ... is this correct? Is this some sort of trait-like feature?
<ifreund>
yeah it's a comptime function returnin a type
<ifreund>
*returning
<antaoiseach>
Hmmm ... interesting!
<ifreund>
this is how generics work in zig, there's no special language feature, just the ability to use types as first class values at comptime
<antaoiseach>
I'm sorry .. how would you use that snippet - @TypeOf(stdout) ... I mean where exactly?
<antaoiseach>
ifreund: Ah, right ... I'd forgotten about that part entirely (the generics bit)
<ifreund>
@TypeOf() returns the type of a given variable at comptime
<ifreund>
i assume you're using getStdOut() or something?
<antaoiseach>
ifreund: right ... but how would I be able to simplify the function signature using that?
<antaoiseach>
yes, in the calling function..
<ifreund>
then you could do @TypeOf(getStdOut)
<ifreund>
err with the right parentheses
<antaoiseach>
ifreund: trying that like to show(stdout: @TypeOf(std.io.getStdout())) anyerror!i32 ... is that right?
<antaoiseach>
This gives me an error about constness
<ifreund>
hmm, maybe `stdout: *const @TypeOf(...` would work
<pixelherodev>
No yeah, samurai is a reimplementation :P
<pixelherodev>
Alpine prefers samurai over ninja because samurai has historically been more willing to work with distros to meet their needs
<pixelherodev>
On a different note, nooooooooooo
<pixelherodev>
All my PRs being merged!!!
<pixelherodev>
Going to need to open new ones!
<dimenus>
is anyone currently using the tcpConnect* functions in std.net?
<dimenus>
Seems like I can keep reading from the socket forever even if the underlying other end is closed
<dimenus>
i'm a bit of a linux noob still, is that expected?
<pixelherodev>
I don't think so, but I'm not certain
<pixelherodev>
The network functions are... not stable yet.
<pixelherodev>
at all
decentpenguin has joined #zig
<edr>
How many bytes do you get from the read? If 0 that means the connection was closed
<dimenus>
ah good call
<pixelherodev>
not necessarily
<pixelherodev>
The other end can just not write to it for a while
<pixelherodev>
Or the internet connection can drop for a second
<pixelherodev>
or...
<pixelherodev>
you get the point
<edr>
I am not sure exactly how the zig code implements it, but getting 0 from recv() means the other side has "gracefully disconnected"
<dimenus>
currently it calls read not recv
slurpie has joined #zig
<dimenus>
edr & pixelherodev: looks like recv returns 0 if the other end flushed 0 bytes ooooooooor it terminated
_Vi has quit [Ping timeout: 260 seconds]
<dimenus>
i take that back, the write syscall will catch the 0 byte write when SOCK_STREAM is specified and basically do nothing or return errors
<dimenus>
so checking if read() returned 0 is a valid case
dermetfan has quit [Ping timeout: 260 seconds]
dermetfan has joined #zig
* ikskuh
silently points in the direction of zig-network :D
wootehfoot has quit [Read error: Connection reset by peer]
Akuli has joined #zig
satchmo has joined #zig
<leeward>
What am I missing in fs.Dir? openFile wants an instance, but I don't see a Dir.init.
<FireFox317>
leeward, cwd()
<leeward>
FireFox317: Of course, now I remember. Thanks.
wootehfoot has joined #zig
wozeparrot_ has joined #zig
guelfey has joined #zig
wozeparrot has quit [Ping timeout: 246 seconds]
alexnask has joined #zig
<satchmo>
would anybody be interested in a Zig version of rust-vmm (a collection of common components for building VMMs/hypervisors)?
<satchmo>
been trying to find a project to do and I quite like this one
<leeward>
If it's a thing you want to do, go for it. I wouldn't use it, but that's not a reason not to build it.
<leeward>
Particularly since there exist users of other languages who would.
<gonz_>
Yeah, I think most libraries stand the highest chance of being good when someone just wants to make and use them, regardless of the outside world.
<satchmo>
trueeeeee
<leeward>
I mean, I can't use Zig at work anyway until at least 1.0. Not a reason to refrain from building libraries for it.
<gonz_>
IMO the best thing people can do for Zig before 1.0 is to write tons of code in it
<gonz_>
There's been enough armchair language designers drive-bying the repo, to be honest.
<satchmo>
^
<leeward>
Batteries included did a lot for Python. Probably not as much as not being Perl, but it's debatable.
<leeward>
Plus, the best way to find problems with a language is to use it.
<gonz_>
Indeed
data-man has quit [Quit: Konversation terminated!]
stripedpajamas has quit [Quit: sleeping...]
stripedpajamas has joined #zig
<fraktor>
I'd also say that being batteries-included helped Java, although that's a very different kind of philosophy
mokafolio has quit [Remote host closed the connection]
stripedpajamas has quit [Quit: sleeping...]
<satchmo>
what do you mean by different kind of philosophy?
<pixelherodev>
"Worse"
<pixelherodev>
Probably
<pixelherodev>
That's the general view of Java I've heard
mokafolio has joined #zig
<leeward>
Do you not have an opinion of Java, pixelherodev?
<pixelherodev>
I have a more positive opinion of it than most
mokafolio has quit [Remote host closed the connection]
<pixelherodev>
I like the JVM, and I mostly like the language, though i think the standard library is... well... "not nice" is the nicest way I can put it
<pixelherodev>
I still use it occasionally for some tasks
<fengb>
The best and worst OO patterns right here!
<pixelherodev>
I have a small Java "script" that converts a ... hold on I don't even remember how it works
<pixelherodev>
Read in a CSV and generates a C file :P
mokafolio has joined #zig
<companion_cube>
oh boy
<gonz_>
How fast is the generation? I feel like you probably spend most of your time starting the JVM(?)
<pixelherodev>
That C file was linked against by my OS game entry for the terminal game jam IIRC, which used it as a renderer demo
<pixelherodev>
No
<pixelherodev>
It ran nearly instantly
<leeward>
It's not like the JVM takes several seconds to start up on a modern computer.
<gonz_>
How short is the JVM startup nowadays? It used to be massive.
<pixelherodev>
Nearly instant
<pixelherodev>
For something this small? Milliseconds I think
<fengb>
It's a lot better. Usually sub second for Java proper
<fengb>
Um... it's still around 200 ms
<fengb>
Unless it's been warmed up
<gonz_>
It definitely used to be ridiculously high, and not because of computers being slow.
<fengb>
$ time java -- 0m0.423s
<pixelherodev>
`time java` -> 0.097 seconds
<fengb>
There's some design flaws, like needing to load all the classpaths
<companion_cube>
have you ever tried julia? that makes the jvm soooo much faster in comparison
<fengb>
You primed it by running it before
<pixelherodev>
@fengb no I didn't
mokafolio has quit [Remote host closed the connection]
<pixelherodev>
THis was a first run
<pixelherodev>
But
<pixelherodev>
It's compiled with -march=native ;)
<leeward>
It just ran a hello world in 0.338s on my system.
slurpie has quit [Ping timeout: 256 seconds]
<pixelherodev>
I don't use a binary VM
<pixelherodev>
I have a compiled from-source OpenJDK optimized with `-O2 -march=native`
<companion_cube>
oh nice.
<companion_cube>
gentoo?
<pixelherodev>
Gentoo ;)
<fengb>
A lot of Java languages are still balls slow to start, like Groovy and Clojure :(
<fengb>
OpenJDK isn't what most people consider Java though >_>
<pixelherodev>
But I'm curious now how much faster the VM startup time is with an optimized build vs a binary
<pixelherodev>
*distributed* binary, ofc
<fengb>
Hotspot is what most people refer to when talking about the VM
mokafolio has joined #zig
<leeward>
OpenJDK is what runs when I type java. I call it fair.
<fengb>
Fine!
<fengb>
"fn getA() uint8_t" I've forgotten how to write C -_-
<pixelherodev>
lol
tdc has quit [Ping timeout: 256 seconds]
<pixelherodev>
Just use translate-zig ;)
<pixelherodev>
... ohhhhhh
<pixelherodev>
I should totally make a C backend to stag2
<pixelherodev>
s/stag/stage
<leeward>
I mean, if you're running a stupid script that's going to take a few seconds at most, it doesn't make sense to run a fancy VM.
<pixelherodev>
It doesn't even take a full second IIRC
<pixelherodev>
It's subsecond
<pixelherodev>
and it's not about the VM
<pixelherodev>
It's about the language
<satchmo>
it's about sending a message
<pixelherodev>
Do you know how much easier string manipulation is in Java vs C?
<leeward>
Is hotspot a different language? I don't java.
<pixelherodev>
It took, like, 50 lines of Java
<leeward>
Oh, that. Yeah, I would have written that in Python for the same reason.
<pixelherodev>
and no mental effort
<pixelherodev>
This was before I knew python well enough to use it
<fengb>
Hotspot is the "official" VM published by Oracle
<satchmo>
how much of that was boilerplate though
<pixelherodev>
Maybe six lines?
<pixelherodev>
It's like, a single function
<pixelherodev>
Just repeated I/O
<pixelherodev>
It's actually kinda sad, honestly
<pixelherodev>
Java was the first real language I knew
<fengb>
Java has a lot of baggage :(
<pixelherodev>
Between Go, Python, C, and Zig, basically every use case I had for it is gone
<leeward>
Depending on how you define real, I think VB3 was my first real language.
<pixelherodev>
Web stuff -> Go, Low-effor one-shot string handling -> Python, literally everything else -> C and Zig
<fengb>
And its design has been behind for ~15 years. Almost no real reason to use it now that Kotlin is a thing
<pixelherodev>
Heard good things about Groovy, too
<fengb>
Although admittedly Kotlin is becoming more C++ like
<pixelherodev>
I also don't really like the OOP patterns
<pixelherodev>
It's one reason I ditched C++
<fengb>
Kotlin is more functional than Java
<fengb>
And offers less OO style defaults, like dataclasses
<pixelherodev>
I'm guessing you don't mean "It has more functionality" :P
<leeward>
There are so many reasons to ditch C++. If only more employers could see them.
<fengb>
I mean it's a lot more natural to do FP in Kotlin
<pixelherodev>
I'll take C99 over C++ anyday
<leeward>
seconded
<pixelherodev>
C99 lets you take the address of a temporary
<fengb>
Pattern matching, dataclasses, lambdas
<gonz_>
I think C++ is less of a blight on the world than people make it out to be. But perhaps you're saying you'd like your employer specifically to see the light, leeward?
<fengb>
I can't grok C++. My only knowledge was C++98, and that was already very bad
<satchmo>
it's just hard to look at imo
<leeward>
gonz_: I disagree. I've never met a significant C++ project that didn't make me feel a little squicky to look at.
<BaroqueLarouche>
Wish I was working in and on Zig
<gonz_>
I don't personally like it, but I feel like a lot of people make it out to be that the world would somehow be better if everyone switched from C++.
<pixelherodev>
Ehh nah I disagree with that idea too
<satchmo>
s/C++/Rust/
<leeward>
But in general, yes, I would like more employers that I consider to share my view on C++. It doesn't hurt me if other people write C++ code and it works.
<pixelherodev>
In the same way that I think JS is less of a problem than people think
<fengb>
orly
<pixelherodev>
The problem isn't the language
<pixelherodev>
It's the people using it
<pixelherodev>
If they switched to Zig, we'd have to deal with people trying to change the language for the worse constantly as well
<fengb>
Like me
<pixelherodev>
Nah, you're good
<fengb>
Um... JS didn't really get worse over its history
<fengb>
Honestly, the hard parts of web has very little to do with the language and more to do with the APIs
<gonz_>
I think it's fine to use a piece of software and say "This would've been of higher quality if they used X, probably", but people silently working on their own stuff elsewhere isn't a bother to me.
<fengb>
They're all terrible and we keep applying more bandaids
<leeward>
I really wish JS would embrace its role as webassembly, and fork into another language that compiles down to actual browser-code.
<fengb>
You mean wasm? It already exists :P
<leeward>
For certain values of exists.
<pixelherodev>
The web itself is the problem, not the language
<pixelherodev>
I wasn't talking about the web though
<pixelherodev>
Node.JS for instance
<pixelherodev>
Just like Rust, the problem is the community
<companion_cube>
satchmo: switch from rust to… what? :p
<gonz_>
Shots fired :D
<fengb>
Nodejs offered a niche that didn't exist at the time. Non-blocking IO wasn't really on app dev's radar
<leeward>
Wasm became a standard last year. Javascript's been around for decades, and people have been using it as wasm for at least 15 years.
<fengb>
When Java was struggling with 10k connections, and nodejs handled it out of the box
<leeward>
Erlang?
<leeward>
Erlang.
<andrewrk>
there is no "the community"
<fengb>
Hmm, why didn't Erlang get more popular?
<satchmo>
companion_cube: i was joking about gonz's statement about everyone wanting to switch to c++, it feels like everyone wants rust to me
<leeward>
fengb: I don't know, and it makes me sad.
<companion_cube>
cause it's weeeeird, fengb
<andrewrk>
that's an oversimplification
<satchmo>
if the s/c++/rust was what you're talking about that is
<companion_cube>
andrewrk: yesss, thank you
<fengb>
Fair, I didn't really look at it until Elixir
slowtyper has quit [Ping timeout: 258 seconds]
<gonz_>
fengb: Erlang was internal for a long time, then got open source when they got "banned" internally at Ericsson.
<fengb>
wat really
<leeward>
It's not that weird, it's just functional. Erlang's a tiny language with amazing library support.
<fengb>
I knew about it in 2007, but it was somewhat of a joke: "Hey here's a language more esoteric than Haskell!"
<marler8997>
hey, working on getting DNS to work on windows
<marler8997>
there's an error code ADDRFAMILY that is supported on non-windows platforms, but not on windows
<marler8997>
and dns is switching on that value....is there a way to make switch cases platform specific?
<marler8997>
not sure what the clean/right solution is here
wozeparrot_ has quit [Remote host closed the connection]
wozeparrot_ has joined #zig
<gonz_>
In 98 they open sourced it after being shut down inside of Ericsson. It was also very, very buggy for a long time and contrary to what you might believe didn't actually have SMP support for some time.
<andrewrk>
marler8997, the pattern we have for this in std is: functions that abstract across platforms have a union of error sets
<leeward>
fengb: Really? I don't think Haskell was in any real applications in 2007, whereas Erlang was in real switches with real uptime.
<andrewrk>
marler8997, and then if you know you are in a code path where some error codes do not apply, => unreachable
<gonz_>
Erlang hasn't always been rock solid and to some extent still has weird bugs and issues (specifically SSL stuff is very clowny even in recent OTPs).
<marler8997>
I'm working on getaddrinfo
<andrewrk>
in this case it will be useful to have an explicit error set, not inferred
<marler8997>
it's not abstracted
<leeward>
gonz_: Yeah, I don't think it got SMP support in beam for a while, but it did let you talk to other instances of beam running on a different processor just fine, even if the other processor was across a tcp link.
wozeparrot__ has joined #zig
<andrewrk>
marler8997, hmm I don't think I understand your question
<marler8997>
net.zig is calling os.system.getaddrinfo...is that supposed to be an abstracted wrapper around the platform specific getaddrinfo?
<fengb>
Haskell was always semi-popular in academia. Erlang just sorta existed
<companion_cube>
well, erlang also has a super weird syntax
<companion_cube>
which is why elixir is eating its cake
<fengb>
That was my view of it at least. I graduated college 2007 so it's not like I knew anything
<andrewrk>
marler8997, it's planned to rename std.os to std.posix
<andrewrk>
std.net is cross platform
<gonz_>
Erlang is more popular than Elixir and Haskell in turn is more popular than Erlang.
<andrewrk>
so if std.net is unconditionally calling into the posix apis, it means that it is missing a windows implementation
<marler8997>
right, but the windows implementation doesn't return one of the error codes
<marler8997>
so I should just add it to the enum anyway, even if windows will never return it
<leeward>
Erlang's syntax is basically prolog. I guess if prolog is weird, you're right.
<companion_cube>
prolog is definitely weird :D
<andrewrk>
marler8997, the enum of the cross platform abstraction? yes the cross platform abstraction error set is a union of all possible errors on all platforms
wozeparrot_ has quit [Ping timeout: 256 seconds]
<marler8997>
what value do I set it to?
<marler8997>
the enum that will never be returned?
<marler8997>
some random value?
<andrewrk>
are you talking about error sets?
<marler8997>
I'm talking about EAI
<andrewrk>
your goal is to get std.net.getAddressList working on windows right?
<marler8997>
with libc, yes
<marler8997>
then without libc
stripedpajamas has joined #zig
<andrewrk>
I see, you are trying to unify the code paths for if libc is linked and with or without windows
<pixelherodev>
I plan on implementing a Forth in Zig soon :)
<leeward>
That sounds like a fun short project.
Akuli has quit [Quit: Leaving]
<gonz_>
RiiR = Rewrite it in Rust?
<companion_cube>
yes
<companion_cube>
it's cliché because a lot of rust users, even the more well known ones, aren't like that
<pixelherodev>
But the ones that are never shut up
decentpenguin has quit [Quit: decentpenguin]
<marler8997>
what a minute what am I doing...windows doesn't even have libc
<pixelherodev>
lol, yes it does.
<pixelherodev>
Not a good one
<marler8997>
what happens differently on windows when libc is enabled?
<pixelherodev>
but it does
<pixelherodev>
I mean, you can use glibc on windows
<pixelherodev>
and I think msvc has a crappy one too
<marler8997>
I suppose it has to have a libc doesn' it
<marler8997>
is it those msvc...dll s?
<marler8997>
those really bad ones that you need to install separately, the versioned runtime packages, and then there's that unversioned one that can change!
bjorob_ has joined #zig
<marler8997>
goodness what a mess
bjorob_ has quit [Quit: leaving]
bjornrob1rg has joined #zig
r4pr0n has joined #zig
<gonz_>
And yet some people choose to use this method of library consumption voluntarily with system-wide shared libs.
<gonz_>
It's indeed completely braindead.
<marler8997>
I think I might abandon the windows libc support, go straight to the ws2_32 direct support
stripedpajamas has quit [Quit: sleeping...]
<pixelherodev>
You can support e.g. mingw's glibc
<andrewrk>
I think that's probably a good idea
<andrewrk>
going straight to ws2_32
<marler8997>
yeah, I'm switching to that
<marler8997>
I don't use mingw so I don't care about it's support
<andrewrk>
in my experience, windows libcs are more compatibility layers than anything useful. when implementing something from scratch like you are, better to target the actual interface rather than the compatibility layer
stripedpajamas has joined #zig
<pixelherodev>
ws2_32?
<andrewrk>
ws2_32.dll is how you do networking in windows afaik
<pixelherodev>
ahh, gotcha
<pixelherodev>
Yeah, that makes sense
<marler8997>
yeah I've found the same, I thought it was going to be some quick easy changes to get the libc route working but didn't turn out that way
<pixelherodev>
Only support the compatibility layer if you don't have time to target the direct API IMO
<andrewrk>
not relying on libc for windows builds is a pretty nice feature of zig imo
<pixelherodev>
e.g. I have a header that does some #defines to improve POSIX support with MSVC's libc
<pixelherodev>
but it's only useful because it means I don't have to bother with a second set of APIs
<andrewrk>
I wonder what rust does
<pixelherodev>
Zig is definitely nice in that I don't need either of those
<pixelherodev>
Rust links libc IIRC
<andrewrk>
on windows though, have you checked?
<pixelherodev>
By default
* pixelherodev
shrugs
<pixelherodev>
Nah
<companion_cube>
unless you use no_std, I think?
<pixelherodev>
I have more productive things to be doing
<pixelherodev>
Yeah, that sounds right
<pixelherodev>
I think Rust has libc as opt-*out* whereas we have it opt-*in*
<companion_cube>
but there are platforms where even Go gave up and linked libc for syscalls
<marler8997>
I think I recall seeing a thread on rust complaining about the msvcrt dlls
<companion_cube>
right?
<andrewrk>
man, waiting for 1 thread to do 600 compile error tests is a huge bummer
<andrewrk>
linux and windows are the only OS's I'm aware of that have a stable syscall ABI that is not libc
<marler8997>
osx system.dll though?
<marler8997>
or libsystem.so
<andrewrk>
libSystem is libc
<marler8997>
ah
FireFox317 has quit [Ping timeout: 256 seconds]
st4ll1 has joined #zig
FireFox317 has joined #zig
Invader_Bork has quit [Ping timeout: 264 seconds]
opDispatch is now known as B4s1l3
bjornrob1rg is now known as bjornroberg
B4s1l3 is now known as opDispatch
<metaterically>
I'm trying to build andrewrk/zig-vulkan-triangle
<metaterically>
and currently I'm stuck on readFileAllocAligned...
<metaterically>
It was: const vertShaderCode = try std.io.readFileAllocAligned(allocator, "shaders/vert.spv", @alignOf(u32));
<metaterically>
but that gave: error: container 'std.io' has no member called 'readFileAllocAligned'
<metaterically>
had a look in the stdlib docs, found it's moved to std.fs.Dir
<gonz_>
`readFileAllocOptions` is also available, but you shouldn't really need it...?
<gonz_>
In any case that version also takes alignment.
satchmo has quit [Ping timeout: 246 seconds]
<metaterically>
Thanks, didn't realise it was renamed and extended
FireFox317 has quit [Ping timeout: 260 seconds]
<metaterically>
Might not need it but my knowledge here is lacking, so I'm gonna go with the Options variant for now to play it safe
<metaterically>
At the moment I'm just trying to update the code to current Zig, rather than making any changes
<gonz_>
Yeah, stuff is moving fast in the standard library and friends, it's worth it to just have a tab open to it and navigate in the addressbar to the file you're interested in.
<gonz_>
there's also the interactive stdlib search but I found that less complete and possibly out of date(?)
<metaterically>
Yeah I was using the search, which shows readFileAllocAligned instead of readFileAllocOptions
<gonz_>
Right
<metaterically>
Though I notice now in the sidebar it says Zig v0.5
<metaterically>
Which is weird given that it says master in the addressbar
guelfey has quit [Ping timeout: 245 seconds]
<fengb>
Yeah those docs are manually generated
<leeward>
Yeah, replace master in the address bar with 0.6.0
<leeward>
Not the best, but at least it's usable.
wootehfoot has quit [Quit: Leaving]
metaterically has quit [Quit: Leaving]
<leeward>
Is there a way to check if an error is a member of a particular errorset? I want to handle File.OpenErrors up at a high level where other kinds of errors could also have happened.
<ifreund>
just switch on the error set? I'm probably misunderstanding