scientes has quit [Read error: error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac]
slice has joined #zig
<Kingsquee>
I like the poop emoji on the current line
stripedpajamas has joined #zig
satchmo has quit [Ping timeout: 272 seconds]
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
wozeparrot__ has quit [Ping timeout: 256 seconds]
satchmo has joined #zig
satchmo_ has joined #zig
dimenus has quit [Ping timeout: 246 seconds]
satchmo has quit [Ping timeout: 260 seconds]
xackus has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
ikskuh: does zpm build or just clone?
<pixelherodev>
"FileNotFound" ugh
<pixelherodev>
Ah
<pixelherodev>
I don't have a /etc/ssl/cert.pem
stripedpajamas has quit [Quit: sleeping...]
<hspak>
It seems "openDirList" disappeared in a past few months, is there a replacement?
dddddd has quit [Ping timeout: 258 seconds]
demizer has joined #zig
<hspak>
okay, I see that openDir has changed quite a bit
stripedpajamas has joined #zig
bren077s has quit [Quit: -a- Connection Timed Out]
bren077s has joined #zig
aerona has quit [Remote host closed the connection]
<pixelherodev>
andrewrk: the args naming of inst.* is kinda confusing when it comes to functions
satchmo_ has quit [Ping timeout: 260 seconds]
<pixelherodev>
Because there's inst.args, which is just *all* the values of the specific Call inst, and then there's inst.args.args which are actual function args
<pixelherodev>
Gah, remote zigging the self-hosted work is more annoying
<pixelherodev>
Requires a constantly open terminal and custom commands, since the standard script doesn't work with the in-tree compiler
<pixelherodev>
And while static zig works locally, the self-hosted src rejects it
* pixelherodev
shrugs
<pixelherodev>
I guess I'll just keep making do
<pixelherodev>
Still easier than fixing Clang
<pixelherodev>
At least multiplexing makes it easy to manage
stripedpajamas has quit [Quit: sleeping...]
<pixelherodev>
Current time to build stage1 for me: 34 seconds
<pixelherodev>
Time to build stage2: 21
<pixelherodev>
Stage1 build is using four cores, stage2 build is using one
<pixelherodev>
Hopefully we can get compile times for stage2 using stage2 to be even lower :D
<fengb>
o_O
<pixelherodev>
Arguably, the stage2 compile is still intolerably slow
<pixelherodev>
It's ~23342 lines plus stdlib, which means just over 1KLoC/s
<pixelherodev>
I've had Rust programs compile at ~50lines per second though, so this is still much better lol
<pixelherodev>
Though, I've had C compiles reach nearly 5KLoC/s
<pixelherodev>
and Zig is supposed to be simpler, so we should be able to exceed that :)
<pixelherodev>
Hmm, should probably reject Windows for now too
<pixelherodev>
It uses a different ABI
<pixelherodev>
(to go back to a different topic :P)
<fengb>
But V can do 1 million lines in <1s
<pixelherodev>
So I'll implement POSIX first, then maybe Windows later
<pixelherodev>
fengb: seriously, please stop :(
<pixelherodev>
trolling is more annoying than anything else
<pixelherodev>
also, LoC/s is more a rough approximation than a useful benchmark
<pixelherodev>
It's not consistent (different programs use different line densities, and some nodes take more time process than others), and it's really easy to cheat on
<pixelherodev>
We could, for instance, write a program using the self-hosted parser (the way ZLS uses it) that extends a program to as many lines as possible :P
<pixelherodev>
s/that/to
<pixelherodev>
s/extends/extend
satchmo_ has joined #zig
CantrellD has joined #zig
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
satchmo_ has quit [Ping timeout: 272 seconds]
satchmo_ has joined #zig
cole-h has quit [Ping timeout: 256 seconds]
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
<pixelherodev>
Okay, wrote a simple test, ZIR parses correctly
<pixelherodev>
Need to function analysis working, then codegen
<pixelherodev>
Ohhh neat
<pixelherodev>
Extra data is stuffed into the Type tag, allowing lower memory to be used for payloads
<pixelherodev>
Clever
satchmo_ has quit [Ping timeout: 260 seconds]
<pixelherodev>
andrewrk: currently, machine code is defined internally as align(1)
satchmo_ has joined #zig
<pixelherodev>
I think this is an example of something that should be backend-specific
<pixelherodev>
e.g. instead of returning 1, it should return `backend.functionAlignment()`
<pixelherodev>
That allows the backend to expose overrides, too
<pixelherodev>
e.g. GCC has `-ffunction-alignment=32`, which Clear Linux uses on Intel hardware for a performance boost, since Intel CPUs prefer machine code to be 32-bit aligned (even though it doesn't require it)
<pixelherodev>
Not going to touch that for now though, since my goal here is just to get parameters working
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
CantrellD has quit [Ping timeout: 264 seconds]
<pixelherodev>
Oh neat, was able to hook up building to a separate script :)
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 244 seconds]
satchmo_ has joined #zig
homa_rano has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 272 seconds]
satchmo_ has joined #zig
Kingsquee has quit [Quit: Konversation terminated!]
drp has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
st4ll1 has quit [Quit: WeeChat 2.8]
satchmo_ has quit [Ping timeout: 260 seconds]
demizer has quit [Quit: WeeChat 2.7.1]
slice has quit [Quit: zzz]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 272 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
<pixelherodev>
andrewrk: I might end up documenting some internal functions further before finishing implementing function call parameters
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
<pixelherodev>
andrewrk: given the presence of fnIsVarArgs, I take it ZIR has a low level varargs feature?
<pixelherodev>
What is it used to implement?
st4ll1 has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 272 seconds]
satchmo_ has joined #zig
<pixelherodev>
For the record, I'm explicitly *not* support the ZIR varargs (assuming it exists)
<pixelherodev>
That can be added later though
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
_Vi has joined #zig
<pixelherodev>
Also assuming only primitives are valid function params in ZIR for now, because I can't find documentation indicating either way
satchmo_ has quit [Ping timeout: 244 seconds]
<pixelherodev>
I don't see e.g. a struct type, so I'm assuming they're broken down within ZIR into primitives
<pixelherodev>
andrewrk: Mostly documenting assumptions here so we can go over them later and when you're online you can correct me :)
satchmo_ has joined #zig
hermier has quit [Remote host closed the connection]
hermier has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
dingenskirchen has joined #zig
satchmo_ has joined #zig
zenxhd has joined #zig
<pixelherodev>
andrewrk: review of #5411 would be appreciated :)
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
alexnask has joined #zig
<pixelherodev>
Half hearted proposal before I go to sleep: there should be a way to make it easier to manage massive structures without exposing everything as public
<pixelherodev>
Maybe something like `@exposeInternals(src, other)` which allows all methods in `other` to access `src`'s private fields
<pixelherodev>
Use case: stage 2 backends
<pixelherodev>
As is, they're all in a single file, codegen.zig
<alexnask>
Lets call it friend :D
<pixelherodev>
(with the exceptions of the Registers, which I added to codegen/ previously, and have refactored into backend/ in my local branch)
<pixelherodev>
alexnask: I don't care what we call it, honestly
<pixelherodev>
The problem is, this isn't scalable
nikoala6 has joined #zig
<pixelherodev>
If we add even just one line for each arch per function, that's still hundreds of lines easily
nikoala6 has quit [Client Quit]
<pixelherodev>
And it's not going to be one line per arch, not by any means
puzzleddev has joined #zig
<pixelherodev>
Which means that codegen would grow to be simply massive
<pixelherodev>
Obviously, that's not a practical option, so some form of refactoring is needed
<pixelherodev>
My current idea is to move everything into backend/$ARCH, with a backend/$ARCH.zig file providing common access to the internals
<pixelherodev>
e.g. @import("backend/$ARCH.zig").Register will give the register enum for any given $ARCH
<gonz_>
Private fields? When did this get added?
<pixelherodev>
This is pretty easy to scale, and future devs can more easily add in new targets
<pixelherodev>
gonz_: since 0.6 IIRC
<pixelherodev>
Not fields
<pixelherodev>
functions
satchmo_ has quit [Ping timeout: 260 seconds]
<pixelherodev>
Sorry, took me a sec to process that
<pixelherodev>
There are no private fields
<pixelherodev>
... heck, why *are* there private functions?
<gonz_>
Aha, I figured you either misspoke or this was some crazy thing someone flash-added.
<pixelherodev>
Did I say fields?
<pixelherodev>
ugh I did
<pixelherodev>
Good catch
<ifreund>
private fields make initialization weird
<alexnask>
pixelherodev, I dont really see the issue with the above, just expose what needs to be exposed with 'pub', am I missing something?
<pixelherodev>
No, actually
satchmo_ has joined #zig
<alexnask>
Or is the point that just a specific file should be able to access them? 🤔
<pixelherodev>
alexnask: I'm looking for the proposal that addded private methods
<pixelherodev>
Because now that I think about it, i don't see why all methods aren't automatically pub
<WilhelmVonWeiner>
yeah private fields really make using libraries annoying when you have to do a minor change in functionality
<pixelherodev>
Right, which is why Zig doesn't allow them
<alexnask>
pixelherodev, THat I can agree withalthough I dont mind the inconsistency between fields and decls wrt pub
<WilhelmVonWeiner>
I hope it doesn't ever allow them
<pixelherodev>
It probably won't
<pixelherodev>
I really think we need something friendly though
<WilhelmVonWeiner>
at work we have a lot of internal builds of typescript libraries because of private crap
<pixelherodev>
Because if a) you should only make functions public if they're to be used outside of the implementation and b) the implementation is massive enough that it's sprawled actoss many files...
<pixelherodev>
s/actoss/across
<alehander92>
overally
<alehander92>
how important is type safety for zig
<pixelherodev>
Sure, you could make every function public
<pixelherodev>
But that defeats the point of private functions entirely
<pixelherodev>
alehander92: I'd say it's extremely important, why?
<alehander92>
i mean it seems to me its more important thatn C
<alehander92>
but e.g. less than rust / haskell
<alehander92>
pixel, just trying to get a feeling
<alehander92>
e.g. the encapsulation and "a motivated programmer can always access etc" from the issue
<pixelherodev>
AFAIK that's true in Rust too
<pixelherodev>
Via unsage
<pixelherodev>
s/unsage/unsafe
<pixelherodev>
I don't know of a single language in which tha's not true
<alehander92>
well .. obviously, but the point is that it's possible to scan for unsafe/completely limit it to 1-2 places in a project
<alehander92>
not really a good comparison imo
<pixelherodev>
Sure, except you can limit it to one place and then call that place everywhere
<gonz_>
alehander92: I don't know that type safety has anything to do with encapsulation, but Zig in general tries to err on the side of compile-time-error vs. run-time-error.
<pixelherodev>
That's true of e.g. java too; you can write a single JNI function that "casts" a value to a different type and then use it everywhere
<alehander92>
well, it doesnt, but the idea of making it impossible for the programmers to do certain things
<pixelherodev>
MyThingy.TerribleIdea(String, int)
<alehander92>
is basically "type safety"
<pixelherodev>
It's not possible to make it impossible
<pixelherodev>
Again, a "motivated programmer" can find a way
<gonz_>
It's no more or less type safe on a base level than f.e. Haskell and in certain contexts more so. You have more static type info in `[5]u8` than you have in `String`, and talking about array lengths in Haskell would be a much more complicated enterprise.
<alehander92>
sorry i didnt want to attack or anything, just trying to compare it
satchmo_ has quit [Ping timeout: 252 seconds]
<alehander92>
pixel, good point, but i'd say unsafe functions can be still limited to what they do
<gonz_>
No, I'm just trying to tease out what we actually mean by type safety here.
<alehander92>
e.g. i can have just 2-3 of them which i know that cant change my e.g. fields
<pixelherodev>
^ definitions are really important
<alehander92>
so even if i use them i still know that a certain field is changeable only from e.g. 2-3 places
<pixelherodev>
If it's changeable in any function it's changeable in all of them
<gonz_>
I work with Haskell and I would say the main difference for me when it comes to the base type system is *what* I can express in the two languages.
<alehander92>
pixel but here it goes the private functions thing
<pixelherodev>
Quick question: can you JIT code from Rust?
<pixelherodev>
I assume the answer is yes
<ikskuh>
probably
<alehander92>
gonz_ cool
<pixelherodev>
since it's just mmap()ing + writing to a buffer + calling
<alehander92>
really i am wondering about another thing sorry guys
<pixelherodev>
Then I guarantee you I can break every single one of Rust's guarantees without the compiler being able to detect it
<alehander92>
its : what is the priority for a feature
<pixelherodev>
Which gets back to, again, motivation
<alehander92>
e.g. first safety 2) speed 3) simplicity or 1) speed 2) safety etc
<pixelherodev>
I can write a module that uses a JIT to violate Rust's safety mechanisms
<alehander92>
purely stuff like this
<pixelherodev>
alehander92: I don't think there's any clear-cut guidelines like that
<alehander92>
because after all you dont have dependent types and z3 model checking builtin etc or even borrow checking: some things are less lax
<pixelherodev>
There's more nuance
<pixelherodev>
`zig zen` might be more useful
<alehander92>
which is perfectly fine
<alehander92>
e.g.
satchmo_ has joined #zig
<pixelherodev>
Right, but again: if you can dynamically generate code, the compiler can't utilize its model checking or type safety
<alehander92>
if i write a sqlite model or postgresql module
<pixelherodev>
No language that can run a JIT can be 100% type safe
<alehander92>
would it be idiomatic to somehow typecheck the schema/queries on compile time and stuff like this
<alehander92>
or would it be "this it too much we dont do it"
<pixelherodev>
If the schema is known at comptime, then yeah sure
<gonz_>
alehander92: I think that'd be something people liked a lot. I know I would.
<pixelherodev>
The one question is whether Rust allows calling an arbitrary address
<alehander92>
ok, awesome
<pixelherodev>
At least, within "safe" code
<alehander92>
pixelherodev well it seems to me
<pixelherodev>
I'm just thinking to myself actually
<gonz_>
In general putting things at compile-time is generally not really frowned upon, especially since there are obvious limitations on what can be done currently, like allocation, etc.
<alehander92>
it would be obvious for me if i use the JIT in my own rust code
<alexnask>
I dont think it would, this would require a cast from a void or u8 ptr to a fn pointer I would assume
<pixelherodev>
Right, but can you do that in safe code?
<alexnask>
But Im not a rustacean or w/e they call themselves
<pixelherodev>
I don't know Rust all that well
<alehander92>
gonz_ i see
<alehander92>
so can one open files / etc?
<pixelherodev>
No
<pixelherodev>
You can *embed* a file
<gonz_>
You can get file content with `@embedFile`, but not that.
<pixelherodev>
But you can't use I/O at comptime
<alehander92>
ok this makes this idea harder
<alehander92>
ah embedFile sounds almost good
<pixelherodev>
You're not allowed to make syscalls
<alexnask>
Inline assembly is not allowed at comptime as wsell as some pointer aithmetic stuff
<alehander92>
except embedFile ?
<alexnask>
Those are pretty much the two restrictions
<alexnask>
alehander92, Well we provide this specifically as a builtin
<alexnask>
For exactly this reason
satchmo_ has quit [Ping timeout: 260 seconds]
<pixelherodev>
alexnask: embedFile doesn't make a syscall
<pixelherodev>
It's a builtin
<alexnask>
(calling non async, non 'unspecidied' calling conventions is probably disallowed too, I should compile some definitive list)
<alexnask>
pixelherodev, Well the compiler does :P
satchmo_ has joined #zig
<alexnask>
Syscalls are not allowed by virtue of using inline assembly
<pixelherodev>
Yes, but that's not your code
<pixelherodev>
The compiler can do whatever
<pixelherodev>
Your code cannot make any *direct* syscalls
<ikskuh>
therer are no syscalls in-language :D
<ikskuh>
syscalls are a user space concept
satchmo_ has quit [Ping timeout: 260 seconds]
<pixelherodev>
Unsurprisingly, intToPtr in Rust requires unsafe, which means I don't have to waste time trying to break it :P
satchmo_ has joined #zig
<ifreund>
as I understand it, dereferencing raw pointers is the only feature unsafe rust "adds" to normal rust
<ifreund>
and with that one feature you can break everything :D
<pixelherodev>
Pretty sure there's more to it...
<pixelherodev>
Not going to waste time thinking about it though
<ifreund>
as in, all the saftey gaurentees fall apart
<gonz_>
`unsafe` is nice, IMO, and I think it's a neat way to say "Here be dragons" and to silo off stuff that is nastier.
satchmo_ has quit [Ping timeout: 260 seconds]
<gonz_>
That doesn't mean Rust is for me, though, but I get what it's trying to do.
satchmo_ has joined #zig
<pixelherodev>
I mostly like stage2's code base, but then I have to do something like this
<ifreund>
sounds like this is your chance to make things prettier
<pixelherodev>
s/vast/cast
<pixelherodev>
ifreund: not really
<pixelherodev>
I mean sure
<pixelherodev>
but that would require tremendous reworks
<pixelherodev>
I'm making things prettier in other ways
<pixelherodev>
Simpler ones
<ifreund>
easy for me to say, i know
<gonz_>
Proposal: Change `cast` to `vast` everywhere.
<pixelherodev>
Plus, this actually makes sense as is
<pixelherodev>
It's only that long because I'm accessing specific fields
<ifreund>
it's verbose, but readable imo
<pixelherodev>
It *might* be possible to improve it
<pixelherodev>
But i sure as hell won't be the one doing that design work
<pixelherodev>
I do think args needs to be renamed there
<pixelherodev>
I'd say payload, but we're using that already too lol
satchmo_ has quit [Ping timeout: 272 seconds]
satchmo_ has joined #zig
<pixelherodev>
andrewrk: should I assume (and assert) that ZIR will be well-formed?
<pixelherodev>
e.g. calls have the right number of args?
<pixelherodev>
Or does the analyzer not necessarily check that before the call is reached?
<pixelherodev>
SOrry to add to the backlog of questions I've asked :P
<pixelherodev>
Yay for EEE
satchmo_ has quit [Ping timeout: 260 seconds]
<gonz_>
alehander92: If you're feeling unsure of whether or not you should invest time in Zig, I can tell you that the time investment needed for Zig is comparatively very low.
<gonz_>
alehander92: It's a language with a fairly small feature footprint and most of what you'd be learning would likely be useful elsewhere (depending on your existing familiarity with lower-level programming).
<gonz_>
I think one of the biggest blockers for a lot of people is actually that Zig very likely won't have that one C++ feature that someone likes so much. It's just not possible to have a language be small and still add everyones' pet features.
<ifreund>
yeah i definitely agree with that. If you've spend any time at all writing C, learning Zig should be a breeze
<pixelherodev>
whelp, I'm actually heading to sleep now
satchmo_ has joined #zig
<ifreund>
pixelherodev: nice, it's afternoon here :P
<pixelherodev>
Should be able to get callconv(.C) calls working tonight though, I have it mostly odne locally
<pixelherodev>
ifreund: it's seven here
<pixelherodev>
AM
<pixelherodev>
s/odne/done
<alexnask>
Gnight :-)
<ifreund>
yeah that's about what I was guessing for the US
<pixelherodev>
Just need to go over the x64 ABI once again, implement arg clas processing (INTEGER,MEMORY,SSE,etc), load to appropriate place, and actual call
<pixelherodev>
But the analysis and such is all in place
<pixelherodev>
Then I need to add more tests
<pixelherodev>
Make sure it fails when given nonsense (e.g. calling with wrong types, incorrect number of args, etc)
satchmo_ has quit [Ping timeout: 246 seconds]
shakesoda has quit [Quit: Connection closed for inactivity]
ur5us has joined #zig
satchmo_ has joined #zig
cren has joined #zig
satchmo_ has quit [Ping timeout: 272 seconds]
<alehander92>
gonz_ hey i am mostly interested as lang design enthusiast: i want to learn more about some languages/concepts and apply that eventually
satchmo_ has joined #zig
<gonz_>
alehander92: All right. From that perspective I think the choice to use `comptime` for a lot of usually disparate features is probably the most interesting aspect of Zig.
<gonz_>
It unifies a lot of concepts under one umbrella.
<alehander92>
i am mostly in the nim community currently, so i have to add the disclaimer that i might try to apply some lessons there but i just like some of zig's ideas and enthusiasm and tooling
ifreund has quit [Quit: WeeChat 2.8]
<alehander92>
yeah i am mostly interested in generics using it, also in error checking and also in the IC/parallel compiler tooling: as i am trying to do something similar(ic/parallel tooling, using error-type-like libs for some things and a lot of macro stuff), so i want to be honest about my motivations :D
<alehander92>
but i just enjoy bikeshedding/random discussions mostly :D ( i'd love to write a lib/or help with stuff i become a bit more familiar though)
satchmo_ has quit [Ping timeout: 260 seconds]
<alehander92>
anyway, time to do some other stuff, see ya these days, thanks for the tips
<gonz_>
You're welcome, have a good one :)
satchmo_ has joined #zig
<cren>
Why does std.fs.Dir have a close method?
<cren>
Do I need to close any instances I instantiate?
<ikskuh>
yes
<ikskuh>
you keep an handle to that dir
<ikskuh>
this also means that you have the guarantee that this directory will exist as long as you have the handle
<cren>
Ok, thanks. Also, I'm sure that this must be documented somewhere, but I can't find it: how do I raise an error?
satchmo_ has quit [Ping timeout: 260 seconds]
<ikskuh>
you don't *raise* errors, you just return them
<ikskuh>
return ErrorUnion.ErrorName;
<ikskuh>
or for implicit errors:
<ikskuh>
return error.ErrorName;
<ikskuh>
your function has to return ErrorSet!ReturnType or just !ReturnType for implicit error set
satchmo_ has joined #zig
<cren>
Is there documentation of all the available errors and error unions?
<alexnask>
You can return arbitrary errors. Most std stuff defines explicit error unions that you can look up in the std docs or in the source code
<alexnask>
These define error set types, you can then use them in error unions, eg. `fn open(path: []const u8) FileOpenError!fd_t { ... }`
nycex- has joined #zig
<alexnask>
They are not collection of values, you can think of them pretty much like enums
<alexnask>
collections*
<cren>
So, by declaring that `open` will return either fd_t or one error from `FileOpenError`, you're telling the compiler that if an error is returned, it will be one of the three from FileOpenError
<ikskuh>
yes
<ikskuh>
but even more: you're telling it the user
<ikskuh>
wonderful example:
<ikskuh>
open("foo") catch |err| switch(err) { }
<ikskuh>
will give you compile errr of which switch entries are missing
<alexnask>
This allows the user to catch the error, switch on it and get a printout of all possible errors from the compiler :D
ur5us has quit [Quit: Leaving]
nycex has quit [Ping timeout: 240 seconds]
satchmo_ has joined #zig
<cren>
Surely you would know that already from the docs
ur5us has joined #zig
<gonz_>
And when someone forgets to change the docs after they add an error?
<alexnask>
Compiler enforced > docs. Also if e.g. an error is added or removed
<cren>
That's interesting. I've always treated the docs as a reliable source of truth.
<gonz_>
To: everyone@coolco.com\nSubject: I added an error, please check your code to see you're handling it.\n\n
<alexnask>
Sure high quality docs are good, the compiler systematically checking for you is the strongest guarantee though
<cren>
I totally get that. It's probably related to the differences in guarantees of behaviour that you need between a systems language like Zig and a dynamic language like Python
<gonz_>
C doesn't guarantee exhaustiveness checks (though I guess some compilers do it nowadays?). It's more an issue of modern expectations, I think. Exhaustiveness checks for enums, tagged unions and error sets are invaluable to me.
<gonz_>
I can't imagine designing without them.
<cren>
gonz_: what sorts of programs do you design?
satchmo_ has quit [Ping timeout: 260 seconds]
<gonz_>
To be clear, I'm talking about modelling domains, etc., not physical/artistic design.
satchmo_ has joined #zig
<gonz_>
As for which programs I'm making with Zig, it's currently a game engine + UI stuff, some interpreters, etc.
<afontain_>
gcc can do it, -Wswitch plus -Wswitch-enum if you want a warning even if you did put a default case
<gonz_>
Mhm
<afontain_>
clang has similar options, maybe the same do work too
<gonz_>
What I'm getting at is that it's not so much a "we need this for systems programming" thing but rather a modern toolset kind of thing.
<gonz_>
If anything, this kind of guarantee is more popular in ML derivatives
ur5us has quit [Ping timeout: 260 seconds]
<alexnask>
Btw, if anyone is writing libraries and putting them on github, you should use the zig-package tag
<ikskuh>
+1
<alexnask>
That way ikskuh's tool zpm can detect them :) Just a PSA
<gonz_>
Thanks for the heads-up.
<gonz_>
Added it to `zig-win32` now
<alexnask>
zig-win32 appeared :D
<gonz_>
I might make my sqlite lib public soonish as well, I guess.
satchmo_ has quit [Ping timeout: 260 seconds]
<gonz_>
Ah, `zig-humantime` still compiles with newer versions as well, may as well have that out there.
<gonz_>
Though it's bordering on `npm`-level package.
<cren>
What do you mean by `npm`-level? Too simple, like `left-pad`?
<afontain_>
zig-humantime is one way only, right?
<gonz_>
Yeah. It has two functions, "seconds" & "milliseconds", which take human readable time strings ("1h3m6s", etc.) and return the corresponding second/millisecond value.
<gonz_>
And it indeed goes only one way, so you can't go from seconds/milliseconds to human readable
<alexnask>
lepto.zig (which will prob become chrono.zig when it has some more features) will provide formatting and parsing as well (and timezones, calendars etc) but it only has timepoitns and durations for now
satchmo_ has joined #zig
<gonz_>
Obviously you could, but I've only ever needed this way
<alexnask>
(strftime-style)
satchmo_ has quit [Ping timeout: 272 seconds]
ifreund has quit [Quit: WeeChat 2.8]
satchmo_ has joined #zig
ifreund has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
<afontain_>
gozn_, thanks for confirming. It's probably simpler the other way around anyway
wozeparrot__ has joined #zig
<gonz_>
Just to be clear, I wasn't disparaging someone else when I said it was `npm`-level.
<fengb>
Best packages are one liners 🙃
<gonz_>
It's my package, so I'm just calling it like it is.
<fengb>
Also nominally does 1 thing but this is the perversion of the npm ecosystem
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
_Vi has quit [Read error: Connection timed out]
nycex- is now known as nycex
nycex has quit [Quit: Quit]
satchmo_ has quit [Ping timeout: 260 seconds]
r4pr0n has joined #zig
nycex has joined #zig
dddddd has joined #zig
satchmo_ has joined #zig
layneson has joined #zig
zfoo has quit [Remote host closed the connection]
satchmo_ has quit [Ping timeout: 260 seconds]
RagingDave has joined #zig
waleee-cl has joined #zig
satchmo_ has joined #zig
decentpenguin has joined #zig
<gonz_>
fengb: :D
<greenfork>
is it expected behavior that program hangs when using evented io_mode with multiple threads? any specific reason why it doesn't hang while in --single-threaded?
cole-h has joined #zig
_Vi has joined #zig
<alexnask>
greenfork, no it should work in multithreaded mode, what os/arch are you running?
<greenfork>
alexnask, I might have said it wrong, it works. But I don't understand why with empty `main()` it doesn't quit when using multiple threads
<greenfork>
I'm on x86_64 linux, everything should be alright
<alexnask>
Hmm I remember this was a bug at some point but I thought it was fixed
<alexnask>
(the loop wasnt doing finishOneEvent in the start code or something like that)
<greenfork>
okay, thanks
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
dimenus has joined #zig
<fraktor>
So when main returns, it doesn't stop the other threads?
<fraktor>
Most of the coroutine stuff I've done is in Go, which does stop the other coroutines.
<oats>
I love this idea of allocator wrappers, such a neat thing
<alexnask>
You should check out #5151 PR then :D (generic composable allocators)
<oats>
though I wonder if there's a way to get valgrind to understand other allocators
slowtyper has joined #zig
<fraktor>
oats: If you wrap the C allocator in another allocator valgrind correctly recognizes it
dimenus has quit [Quit: WeeChat 2.8]
<fraktor>
There's also some valgrind stuff in the standard library, but it might need some more documentation first.
dimenus has joined #zig
dimenus has quit [Quit: WeeChat 2.8]
Akuli has joined #zig
puzzleddev has quit [Quit: Leaving]
r4pr0n has quit [Remote host closed the connection]
<andrewrk>
it drives me nuts when people talk about RAII without explaining exactly what they mean
<andrewrk>
are they talking about c++? c++ resource management is completely broken, constructors are not even allowed to fail
<andrewrk>
so then what? where is this magical RAII paradigm
<companion_cube>
so don't use constructors, use a function
<companion_cube>
Drop in rust works pretty well
<andrewrk>
yeah rust's Drop works well. but I don't hear Rust people saying "RAII". they just say Drop
<andrewrk>
if you use a function in c++ then you're not doing RAII
<companion_cube>
they definitely say it's RAII when talking to C++ people :)
<companion_cube>
a function that does the checks and calls a constructor
<companion_cube>
(like in rust, since after all rust doesn't have constructors at all; RAII is purely about destructors)
<andrewrk>
so you have a c++ function which gets the resource, calls the constructor, and then what, returns it? invoking the copy constructor?
<andrewrk>
this is so clunky
<andrewrk>
why would you copy something just to initialize it
<companion_cube>
ah, well, that's the lack of move semantics by default
<companion_cube>
(I won't argue that C++ doesn't suck! :D)
<gonz_>
andrewrk: Ah, you found the zig "Why Zig..." thread on proggit, I see. :D
<andrewrk>
:)
<gonz_>
"Does it have RAII? No? I'm not interested"
<gonz_>
Oh, well :D
<andrewrk>
"Is it C++? No? I'm not interested."
<nephele>
Only a C++ compiler :)
<companion_cube>
it's more like "does it make doable to use refcounting?" :)
<alexnask>
Dont you know the exact subset of C++ I use is the best language?
<gonz_>
SFINAE, RAII, what other ridiculous acronyms have been invented by <only language to come up with these>?
<alexnask>
Nvm any library I call into may do whatever it wants
<ikskuh>
andrewrk: [c++] constructors are not even allowed to fail
<ikskuh>
they are *meant* to fail (as in "throw an exception")
<ikskuh>
it's not adviced by the core guidelines to make constructors that leave half-valid objects
<andrewrk>
but in C++, constructors throwing exceptions is considered to be bad practice, and many people use -fno-exceptions
<ikskuh>
yeah, there's several fractions on that
<andrewrk>
if you make a library, using exceptions disqualifies the library from being used in any application that uses -fno-exceptions
<companion_cube>
factions* ? :)
<ikskuh>
yeah :D
<ikskuh>
also: community fractions! :D
<ikskuh>
well-made C++ raii with exceptions works *really well*
<ikskuh>
but unchecked exceptions are hell
<companion_cube>
same in rust, I should say
<companion_cube>
Drop works well with generics, imho it's why it's so useful
<companion_cube>
(it composes)
<ikskuh>
imho rusts pattern is RAII as well
<ikskuh>
don't know how well-made it is in practise, though
<companion_cube>
yeah, it is RAII, and seems to work pretty well (it does for me)
<companion_cube>
also makes Arc/Rc a breeze
<ikskuh>
zigs memory management is often also pretty RAIIesque
<ikskuh>
where you have constructors that may fail (Foo.init()) and destructors Foo.deinit()
<ikskuh>
but you can reuse the resources after that
<companion_cube>
but it doesn't compose well in generics (unless you always call `x.deinit()` or something?)
<ikskuh>
so it has storage separated from lifetimes
<companion_cube>
yeah, I guess you can do it in rust with std::mem::swap but it's a bit hackish
<gonz_>
companion_cube: Part of this rests on the idea that allocation can never fail, though.
<companion_cube>
part of what?
<gonz_>
Or at the very least the C++ version of it does
<companion_cube>
(RAII is more assuming that deallocation can never fail)
<ikskuh>
gonz_: c++ does not assume that allocation may never fail
<ikskuh>
people do, though :D
<ikskuh>
new throws a std::bad_alloc when it fails
<ikskuh>
if you use no exceptions, it returns nullptr
r4pr0n has joined #zig
slice has joined #zig
<leeward>
Doesn't the new keyword in C++ throw an exception?
<leeward>
I can read.
tgschultz has quit [Ping timeout: 240 seconds]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
tgschultz has joined #zig
<gpanders>
Hi all, from the Zig docs referring to using an arena allocator for a command line application (item 4 under Choosing an Allocator) it says "When using this kind of allocator, there is no need to free anything manually. Everything gets freed at once with the call to arena.deinit()". Does that mean that when using this allocator I should not include "defer allocator.free()"s or "defer
<gpanders>
array_list.deinit()"s, etc. in my code? Or should I still include those things to keep my code idiomatic? This is more of a "best practices" question than anything really
<ikskuh>
arena allocators are pretty simple:
<ikskuh>
you create a new arena allocator and allocate memory with that
<ikskuh>
if you don't need that memory anymore, you deinit() that arena
<ikskuh>
and all of its memory is released
<ikskuh>
this is pretty nice for temporary data
<ikskuh>
but you should deinit() your arena
<karchnu>
ikskuh: so its a way to deinit all unnecessary memory in a single function call? Yep, sounds kinda nice.
<ikskuh>
yeah
<gpanders>
I'm more curious about what it means to write good Zig code when using an arena allocator. I am writing a command line tool that instantiates an arena allocator in main() and then passes it around to the rest of the application. Throughout the rest of the code I allocate other memory, e.g. in array lists or dynamically allocated strings. My understanding is that it is best practice to always match an
<gpanders>
allocate with a deferred free -- but since that is not necessary with an arena allocator, should I still include those defers, or simply omit them? The arena allocator is always deinit()'d at the end of main()
<ikskuh>
i require some temporary strings there to assemble a path
<ifreund>
freeing memory is important for long-running processes
<ikskuh>
and using the arena makes that code less cluttered
<ikskuh>
but if you get passend an allocation into a function, never assume something about that allocator
<alexnask>
Its also a pretty common pattern for std to return data structures that use an arena to allocate all their memory and call its deinit when deinited
<alexnask>
E.g. the json ValueTree
<alexnask>
(or the zig ast tree)
<gpanders>
thanks for the example ikskuh, it's useful to see real Zig code "in the wild"
<ikskuh>
you're welcome
aerona has joined #zig
<andrewrk>
yeah json ValueTree is a great use case
<andrewrk>
parsing a json payload requires many small allocations that all have the same lifetime
<andrewrk>
it makes it a lot easier to write code that behaves correctly under error conditions
<andrewrk>
the self hosted parser test harness actually tests every possible memory allocation failure case and makes sure no leaks happened ever
<ikskuh>
andrewrk: wow, nice!
<fraktor>
Honestly custom allocators and `defer` are one of the core things I like about Zig. It makes manual memory management actually feasible.
<ikskuh>
i noticed that std.json.Parser.parse actually leaks a single allocation somewhere
<andrewrk>
might be nice to set up a similar test harness
<fraktor>
So this might be a stupid question, but I notice that a lot of issues focus on optimization of the stage1 compiler. I understand fixing bugs in it, but why add new features or improve already-adequate code generation in stage1 when stage2 is being worked on?
<r4pr0n>
well stage1 should always be able to compile stage2
<r4pr0n>
and if you don't add new features you can't use them for the stage2 source code
<fraktor>
Yes, that's true. I should clarify that I'm mostly talking about optimizations (one that I saw is that defer is generating a lot of code in some cases).
satchmo_ has quit [Ping timeout: 246 seconds]
<ikskuh>
fraktor: Even if stage1 isn't meant to be good, it's still a really good thing to know (and document) all the problems with the current code generator approach
<fraktor>
Okay. That makes sense. thanks
alexnask_ has joined #zig
alexnask has quit [Ping timeout: 260 seconds]
aerona has quit [Quit: Leaving]
alexnask_ is now known as alexnask
<andrewrk>
fraktor, many of those issues will never become a problem with self-hosted because they were discovered in stage1, and therefore will be deprioritized or possibly even closed
<andrewrk>
but until we have something shipping that has the problem solved, it's important for it to be an open issue
<fraktor>
Okay. So they're more for documentation purposes than for determining what will be developed in stage1.
satchmo_ has joined #zig
dongcarl has joined #zig
satchmo_ has quit [Ping timeout: 272 seconds]
ikskuh has quit [Quit: Winke winke!]
<dongcarl>
Hi all, any documentation on the zig build system yet? I see it's TODO on the latest docs
slice has quit [Quit: cya]
mq32 has joined #zig
<ifreund>
dongcarl: not really, but I'm sure folks here would be happy to help out
<ifreund>
if you don't know already, zig init-exe or zig init-lib will get you started
<andrewrk>
stabilization of the build system will probably be one of the last things to stabilize
RagingDave has quit [Quit: quit]
satchmo_ has joined #zig
<pixelherodev>
Did I get pinged at any point recently? Because the buffer is highlighted with the "you were pinged!!!" color but I'm looking through the buffer and I don't see one...
<pixelherodev>
meh
<pixelherodev>
andrewrk: did you see my notes in this channel?
joey152 has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
<pixelherodev>
andrewrk: let me know when you're available to discuss stage2 some more :)
<pixelherodev>
I'm going to add more to the draft PR
<andrewrk>
I'm trying to finish up this branch, and then I have some chores to attend to, then I'd be happy to discuss
<andrewrk>
I underestimated how much effort it would take to update translate-c with the new AST API
<pixelherodev>
Sounds good :)
<pixelherodev>
Ah, yeah, I get that
<pixelherodev>
I had a similar but smaller-scale annoyance backporting my stage2 codegen Register stuff over to Lightzing
<alexnask>
I should get around to start porting zls on the new ast branch too
<andrewrk>
alexnask, I think the API changes are done in the branch, and they should be simple enough to update to for ZLS. everything is still arrays with slightly different ways to access them
<andrewrk>
the good news is that parsing speed is doubled
<alexnask>
Nice!
<andrewrk>
and memory usage is cut down quite a bit too
<alexnask>
Cool I will finish fixing a couple of bugs then start adapting :)
<alexnask>
We do tell ppl to use zig master after all
<alexnask>
Wouldnt want to tell ppl to use some commit between 0.6.0 release and master :P
<andrewrk>
ha yeah
bren077s has quit [Read error: Connection reset by peer]
<mq32>
'*const [10:0]u8', found '[]const u8' shouldn't that coerce?
<andrewrk>
the type system cannot be sure that the runtime-known length will be 10
<andrewrk>
also the sentinel does not match
<andrewrk>
the other way coerces
<mq32>
andrewrk: but this was a
<mq32>
foo.bar orelse "text"
<mq32>
shouldn't that coerce to @TypeOf(foo.bar) ?
<andrewrk>
yes probably. hard to say without more context
<mq32>
okay, i worked around it
<mq32>
const lic = pkg.licence orelse "no licence";
<mq32>
works
bren077s_ has joined #zig
<mq32>
.{ pkg.licence orelse "no licence" } does not
<mq32>
seems like the peer type analysis in anonymous structs is different?
<andrewrk>
ahh the good ol' assign-the-thing-to-a-const workaround
<mq32>
:D
<mq32>
also
<mq32>
.{ pkg.licence orelse @as([]const u8, "no licence") } will yield error: cannot store runtime value in compile time variable
<andrewrk>
I'm going to be sure to solve all these edge cases up front in self hosted
<mq32>
yah
<mq32>
focus on stage2 as muc as possible :)
stripedpajamas has joined #zig
<pixelherodev>
stage2 = <3
<pixelherodev>
I'm so glad I can finally contribute to the compiler :)
<pixelherodev>
I was... not all that willing to touch C++ even for this
<pixelherodev>
:P
nephele_ has joined #zig
<gonz_>
This seems like mission accomplished for stage 2, then
nephele has quit [Ping timeout: 244 seconds]
nephele_ is now known as nephele
decentpenguin has quit [Quit: decentpenguin]
Snetry has joined #zig
<andrewrk>
the one last thing that is tripping me up in translate-c, is that some functions append their ast nodes to the containing block node and then return the containing block node (??) instead of the new AST node
<andrewrk>
I wonder if anyone around here knows why that is the case
<andrewrk>
hmm you know what I can do, is just comment out the code and put @panic in there and see what test cases fail
<andrewrk>
then I'll have some context to understand why
layneson has joined #zig
wozeparrot__ has quit [Remote host closed the connection]
wozeparrot__ has joined #zig
aerona has joined #zig
<andrewrk>
it's such a weird feeling when the friggin thing compiles after days of errors
<andrewrk>
there's no light at the end of the tunnel, it's just darkness for days and then all the sudden everything works
<ifreund>
it always takes me a minute to actually believe that it worked too
<mq32>
andrewrk: yeah, unreal feeling
<mq32>
but also a great feeling when the code doesn't crash
<ifreund>
i assume that somethings still broken and i haven't found it yet
<alexnask>
Then comes all the fun of debugging
<andrewrk>
yes I'm about to find out how much havoc I have wreaked on translate-c
<andrewrk>
I do expect it to be faster, however. I'll add a benchmark for it to gotta-go-fast before merging
<andrewrk>
oh. I already did
<andrewrk>
I meant I will add a benchmark for zig fmt before merging
<ifreund>
I kinda want to try my hand at #1499 once stage2 is a little farther along. I'd have to learn a ton to implement that, but it'd be worth doing
<ifreund>
it's because of this issue that i'm still using a glibc based system
<karchnu>
andrewrk: I saw on youtube that you expect to drop C support in v2, do you really think you will get to the point you won't let an optional dependency to LLVM for mixed C-Zig code? I surely don't expect the end of C anytime soon (not even in 20 years).
<andrewrk>
karchnu, I'm not sure what you're referring to, can you be more specific about "drop C support"?
<ifreund>
pretty sure translate C is still going to be part of stage2
<karchnu>
andrewrk: drop the LLVM support. It may only be related to the `zig cc` functionality, but I guess it is also used for being able to import C code.
<andrewrk>
karchnu, the plan is for LLVM/Clang/LLD to be optional dependencies, which enable more features
<karchnu>
ack
<mq32>
btw i really love that plan :)
<gonz_>
Heh, drop C support. That'd be something, given the stated goals of the language.
<andrewrk>
one day, the new generation of students will wonder why the zig language specification has this weird optional extension regarding this "C" thing
<karchnu>
Nice, I'm not the only one with this feeling.
<gonz_>
To clarify, I was being a bit sarcastic. I don't know exactly what gave the impression that C was going anywhere, but I'm fairly confident this is just a misunderstanding.
<alehander92>
haha
<alehander92>
bam 2070 happens and people code in 3d visual programming dialect of python
<pixelherodev>
If that happens I will literally start a revolution
<pixelherodev>
"You will have my Haxe!"
<pixelherodev>
(sorry)
<mq32>
I cannot take Haxe as a name serious
<pixelherodev>
oh wait dammit it's the other way around, "And my axe!"
<pixelherodev>
mq32: neither can I
<pixelherodev>
but
<pixelherodev>
name one other lang that fits in that joke
<alehander92>
no idea what it means
<mq32>
pixelherodev: Schweins-Haxe is [knuckle of ham]
<pixelherodev>
I was making a reference to LotR :P
<pixelherodev>
"You will have my Go!"
<pixelherodev>
There, that's better
<mq32>
^^
<gonz_>
And my VAX
<gonz_>
:|
<mq32>
I'm anti-VAX, no DEC for me!
<pixelherodev>
Ahh, that's a good one gonz_ :D
<gonz_>
I guess most of us are too young for VAXs. I feel old but not that old :D
<pixelherodev>
andrewrk: does ZIR not support iN/uN?
<pixelherodev>
I only see u8 and usize...
<pixelherodev>
Ahh, never mind
<pixelherodev>
int_signed / int_unsigned
<pixelherodev>
{u,i}{8,size} are for reducing memory usage of common types?
<pixelherodev>
No c_char type? I'm guessing we just use u8 for that always?
<pixelherodev>
Hmm, slices need to be split into two parameters, ptr + len, which are both INTEGER class
<pixelherodev>
Should be pretty straightforward though, I hope
<andrewrk>
pixelherodev, not all the type/value representations are added yet
<andrewrk>
it's worth it to take some time to understand how those 2 files work, type.zig and value.zig
<andrewrk>
I think it will make sense once you take a look
<andrewrk>
the idea here is twofold: (1) reduce memory usage (2) avoid the requirement of shared state, to facilitate multi threading
<pixelherodev>
andrewrk: I've been doing that :)
<pixelherodev>
Had to go over them to implement analysis of function argument types, for instance
<pixelherodev>
Took more of a look while I was there
<pixelherodev>
Oh, and I *don't* need to split slices; they get rejected in callconv(.C) functions
<pixelherodev>
I forgot about that :)
satchmo_ has joined #zig
shakesoda has joined #zig
layneson has quit [Ping timeout: 260 seconds]
Akuli has quit [Quit: Leaving]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
bren077s has joined #zig
bren077s_ has quit [Read error: No route to host]
bren077s has quit [Read error: Connection reset by peer]
<pixelherodev>
andrewrk: is there any quick "get target pointer size" utility?
<andrewrk>
feel free to make a local helper function for it where necessary
<andrewrk>
e.g. on Function in codegen.zig
<andrewrk>
whatever makes sense to you
<pixelherodev>
Ahh, didn't know arch had that
<pixelherodev>
Thanks :)
<pixelherodev>
Trying to figure out the best way to get an arbitrarily sized integer Value as a u64 for codegen
<andrewrk>
toUnsignedInt()
<andrewrk>
however it asserts that the value fits in u64
<andrewrk>
so you have to have emitted a compile error or otherwise not be in this control flow if that is not the case
<pixelherodev>
That doesn't seem to support usize though
<andrewrk>
if the type is unsigned and 64 bits or smaller, then you can be sure that check has already happened
<pixelherodev>
Which is why I was looking for pointer size
<pixelherodev>
Thinking of adding .usize => if (fits_in_u64) as_u64 else unreachable
<andrewrk>
I see. Currently it is assumed that u64 is >= pointer size
<pixelherodev>
Okay, I'll just keep with that assumption then
puzzleddev has joined #zig
<andrewrk>
I'm ok with reworking some of the logic if that ends up not being true in the future
<andrewrk>
also remember not to get usize in the compiler code mixed up with usize of the target!
<andrewrk>
a 32 bit compiler should be able to produce 64 bit binaries
<andrewrk>
and vice versa
<pixelherodev>
Right, I know :)
kushalp has joined #zig
<kushalp>
I am trying to write a basic NTP client in Zig. I know how to do this in ~100 lines in C but trying to things as Zig intended. I'm struggling at my first hurdle: using "try". I'm seeing the following error: expected type 'void', found '@TypeOf(std.net.getAddressList).ReturnType.ErrorSet'. Any ideas what I'm doing wrong? The line in question is this: const address_list = try std.net.getAddressList(&arena.allocator, hostname,
<kushalp>
port);
<pixelherodev>
ZLS still eats CPU sometimes :(
<andrewrk>
kushalp, looks like you are perhaps using `try` in a function with a `void` return type
<andrewrk>
`try` means "return the error if any" so the return type has to take that into account
<ifreund>
tldr: make it return `!void`
bren077s has joined #zig
<fengb>
I still read that as not void
<ifreund>
|void would make more logical sense but | is already quite overloaded
<fengb>
Hmm why is exclamation == not?
<ifreund>
no idea, why is ^ xor? why is | or?
<ifreund>
i guess our forefathers just chose whatever symbols they weren't already using for something
<kushalp>
Oh, interesting. I think that's because of how I'm using main: pub fn main() void {
<ifreund>
yeah, my main usually returns !void
<fengb>
Conjunction: the symbol ∧ appeared in Heyting in 1929[2] (compare to Peano's use of the set-theoretic notation of intersection ∩[5]); & appeared at least in Schönfinkel in 1924;
<gonz_>
Algol60 had proper notation for these things AFAIK
<fengb>
I think we inherited a lot of those operators. Except I can’t find the history for !
<gonz_>
Not the ASCII "We have symbols at home" kind
bren077s has quit [Read error: Connection reset by peer]
<fengb>
Mostly annoyed because ! is universal (American?) symbol of error and it’s more natural to be an error
<gonz_>
There's a surprising amount of "right" in ALGOL, actually. You'd be surprised how many things they made worse *after*.
Stephie has quit [Ping timeout: 256 seconds]
<companion_cube>
/\ and \/ wooo
<gonz_>
Or maybe you wouldn't be surprised, I don't know. :D
<fengb>
We shoulda kept the EE gates as symbols :P
bren077s has joined #zig
<andrewrk>
wow, I'm down to 1 remaining translate-c test case failing. so far the debugging has been very straightforward
<pixelherodev>
Nice :_
<pixelherodev>
:)*
<pixelherodev>
I just got the test passing!
<ifreund>
woot!
<andrewrk>
this is incredible. I completely changed the API that a complex, 6,000 line file was using all throughout. it took 3 days just to work through compile errors
<pixelherodev>
Calling a `fn void(usize) callconv(.C)`
<pixelherodev>
:)
<andrewrk>
but I've spent all of 1 hour doing easy debugging and nearly all tests passing
<pixelherodev>
Nicely done :)
<ifreund>
good api i guess :D
<ifreund>
now watch this last test take another hour :P
<pixelherodev>
Gahhh halp
<pixelherodev>
How do I get Git to stop seeing deps/ as changed?!
<pixelherodev>
On a fresh clone even :(
<pixelherodev>
... or... not?
<andrewrk>
idk I think it has something to do with .gitattributes
<pixelherodev>
what the hell?
<pixelherodev>
I use `git stash`, it claims to work but is still there
<andrewrk>
and txt files with weird newlines. I have no idea what's goign on
<pixelherodev>
`gco deps` -> "updated 2 paths"
<hermier>
git diff seems not follow the new lines from .gitattributes
<pixelherodev>
yeah...
<pixelherodev>
it still thinks they're changed
<pixelherodev>
and git rebase refuses to do any work
<hermier>
as soon as the file date don't correspond, the diff enter in action and you are fscked
<pixelherodev>
going to do a fresh local clone, rebase, push back to original fork, push from there to GH :(
<kushalp>
Should I use the standard C library for creating a socket or is there a preferred way to do this in zig? socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
<fengb>
Can you delete the files and check them back out?
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
<pixelherodev>
Ugh, there we go
<andrewrk>
kushalp, check out std.net. it's in the early days, it's missing a lot of API. you could consider contributing or you could just put the code you need in your own project, using the lower level std.os (posix) API
<pixelherodev>
fengb: I've done that before, yes
<hermier>
no, checkout, follow .gitignore, and is instantly different from archive
<pixelherodev>
Still a pain
<andrewrk>
what I want from git is very simple:
<pixelherodev>
Given that it's only the READMEs, can we just wipe those? :P
<andrewrk>
DONT MANGLE THE FILES
<pixelherodev>
Ah wait it's the license too
<pixelherodev>
dammit
<pixelherodev>
do we need to maintain line endings of the license though?
<andrewrk>
no we dont
<pixelherodev>
Can we override that and the README so they don't constantly do this?
<andrewrk>
yes
<fengb>
It kinda sucks that git mangles line endings :/
<pixelherodev>
Sure, but
<pixelherodev>
I literally can't think of a single other issue with it :)
<pixelherodev>
So as much as this bothers me, I still am totally willing to accept it
<pixelherodev>
it's *still* vastly superior to any other VCS I've tried
<hermier>
git does a pretty good job on different host, I don't know why it bombs here, maybe the line encoding don't correspond to what .gitignore says
<kushalp>
andrewrk: Thanks! I'll try to check out more of the repo and docs before asking away in here! :)
<gonz_>
I have a suspicion that Fossil is much better but I've zero reason to try to convert people around me to use it anyway.
Stephie has joined #zig
<fengb>
Because zig turns off line ending mangling and that’s apparently not well tested
<waleee-cl>
some nix/nixos-folks is a bit hyped about pijul 1.0 approaching
<gonz_>
On a surface level Fossil offers a much more human interface as well as more features you pretty much always want anyway, and uses SQLite for history management which all in all is a much better idea than plain files, IMO. The idea of back references also makes it possible to walk history front and back in a different way.
<pixelherodev>
gonz_: Fossil certainly thinks so lol
<fengb>
I learned DVCS with Mercurial and I still wish that won
<fraktor>
I'm working on PR #5412 and someone brought up the point that we might want to change the recursion depth that the `fmt` module uses when displaying self-referential structs at runtime instead of just at comptime. How necessary is that, and would it introduce any footguns?
<pixelherodev>
I think it's useful, yes, and I think that whether it introduces footguns depends on the implementation
<pixelherodev>
fraktor: ^
<fraktor>
It would just be a `pub var` instead of `pub const`.
<fraktor>
I copied the pattern that io uses, where it looks for "fmt_max_depth" declared in the root module and then uses that, or else a default.
<fraktor>
But making it a pub var would make it possible to just do `fmt.default_max_depth = 16` or whatever.
<alexnask>
Nice, switching to the parser branch was easier than expected
<alexnask>
The only change that affects it a bit is the fact that ParamDecl is no longer a Node but I will work around this
<alexnask>
s/it/zls
<pixelherodev>
andrewrk: is there no facility in ZIR testing for "expect an error" yet?
<andrewrk>
pixelherodev, correct. however that is obviously an important kind of test that we need to add
<pixelherodev>
I'll take care of that
<pixelherodev>
I need it for this PR anyways
<pixelherodev>
Might do some more refactoring first though
<andrewrk>
alexnask, the (new) criteria for something to be a Node is whether there is ever a time when a *Node could be more than 1 different thing
<alexnask>
Yes I get it and I agree with the design, it was inconsistent in a couple of places before
<andrewrk>
I'm hoping to get this branch mergable by this evening
<pixelherodev>
alexnask: ... what's your zig-serial ???
* pixelherodev
is mildly afraid
<alexnask>
lol
<alexnask>
I will delete it, xq asked me to make it to test zpm support for multiple packages with the same name
<pixelherodev>
Ahhhhh
<pixelherodev>
phew
<pixelherodev>
was worried for a second
<pixelherodev>
mq32: ... firstly, do you change your name on here constantly just to confuse the rest of us?
<pixelherodev>
Secondly, mind adding a build option to embed the trust CA on Linux too?
<pixelherodev>
Actually, you know what, ignore that
<pixelherodev>
It's fine
<alexnask>
I think the plan is to embed it (or at least the key relevant to github) for every os instead of trying to support all possible distros and/or OSes
layneson has joined #zig
<pixelherodev>
Tackling #1364 before continuing...
r4pr0n has quit [Ping timeout: 240 seconds]
stripedpajamas has quit [Quit: sleeping...]
<pixelherodev>
Ugh
<pixelherodev>
Zig is marked as failing CI
<pixelherodev>
because GitHub was down and CI failed to retrieve wasmtime and such
<andrewrk>
I love that you can use git blame to find the commit that added a test case, and therefore find the relevant code that was changed to make that test case work
puzzleddev has quit [Quit: Leaving]
<andrewrk>
alexnask, sorry, I forgot to mention, I was planning on reverting ast node children iteration to how it works in master
doublex has quit [Ping timeout: 260 seconds]
<alexnask>
Meh this is a small change :P
<mq32>
pixelherodev, nah my server is just rebooting too often
mq32 is now known as ikskuh
<ikskuh>
<pixelherodev> mq32: ... firstly, do you change your name on here constantly just to confuse the rest of us?
<ikskuh>
did that already
satchmo has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
r4pr0n has joined #zig
<pixelherodev>
Anywho, I'm just finishing up more backporting (going to be releasing an unofficial 0.6.3 soon) and then getting back to stage2
chivay_ has joined #zig
chivay has quit [Ping timeout: 264 seconds]
ifreund has quit [Ping timeout: 256 seconds]
<ikskuh>
pixelherodev, could you try to use zpm again? i have now included only the DigiCert certificate
<ikskuh>
that should be sufficient for communicating with github
commander has quit [Ping timeout: 264 seconds]
commander has joined #zig
<pixelherodev>
ikskuh: it'll have to wait
ky0ko_ has joined #zig
<ikskuh>
okay :D
<pixelherodev>
Network is a bit clcogged right now :P
doublex has joined #zig
<pixelherodev>
Pushing the full Zig repo over SSH lol
<pixelherodev>
Not just changes to compile, the way I normally do; the full repo
<pixelherodev>
y
<pixelherodev>
whoops
<ikskuh>
why?
<afontain_>
I just saw zpm and thought it looked nice from the readme. It seems atrociously tied to github though :-(
<afontain_>
If I'm not mistaken, packages are indexed if published on github and the package manager uses github's api to index and retrieve the packages?
<ikskuh>
yeah
<ikskuh>
it's a glorified github search actually
<afontain_>
It seems it depends on this specific centralised service
<ikskuh>
correct
<andrewrk>
afontain_, it's not official
<afontain_>
I saw
* ikskuh
has written a disclaimer for that :D
<ikskuh>
first thing in the readme :D
<fengb>
Since it’s based on GitHub, shouldn’t we name it... zithub?
* ikskuh
slaps fengb around a bit with a large trout
<afontain_>
:D
<ikskuh>
afontain_: i don't know about other hosting services
<ikskuh>
that provide that kind of API
<afontain_>
githuz
<ikskuh>
github provides even finer grained searches like
<ikskuh>
"give me all repos that have a package.zig included"
<ikskuh>
(afaik)
<afontain_>
Well, python, rust, haskell, do have a similar service, but they built it themselves I think
<afontain_>
they are probably at a later stage of development and targeting stable releases,too