ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
moo has quit [Ping timeout: 245 seconds]
<shritesh> Async await is part of the language already and is being improved upon.
<Sahnvour> macros are useful for repetitive stuff merging identifiers and string litterals, or control flow, but granted, this was semi-ironic
<Sahnvour> thinking about C macros, Nim ones look way better but I never got around using them
Sahnvour has quit [Read error: Connection reset by peer]
<scientes> you can do all that with comptime
<scientes> like if you want a function that gives you the names of enums, you can do that
<scientes> while go has to have a "generator" program that makes ugly code to do that
<scientes> what I don't think I can do with comptime is generate a perfect hash function
<scientes> I've got a new algorithm for that that I wanted to code up, but haven't gotten around to---because having a program generate code is kinda ugly
<scientes> yes
<andrewrk> emekankurumeh[m], that migth give you some ideas of how to use comptime in interesting ways ^
<shritesh> Are there any kinds of applications / use cases that zig would be a bad fit for once it is 1.0?
<scientes> I have an algorithm that never fails, and can be created in O(nlogn) time, while gperf is O(n^3)
<scientes> its not really a hash function, but to the computer it doesn't really matter
<scientes> just a highly optimized multi-way bisection
<scientes> shritesh, it isn't a scripting language
<scientes> I really struggle with assembly in zig
<scientes> something as simple as porting clang's cpuid.h prooved difficult
<scientes> i just can't get the syntax right, and the syntax that works in clang is not llvm's syntax
<scientes> and you can't use cImport unless you are using libc, despite C not requiring a run-time
<andrewrk> you can use @cImport without libc
<scientes> oh ok
<andrewrk> but you can't use, e.g. stdlib.h
<andrewrk> because that's provided by libc
<scientes> yeah but the zig tree has <cpuid.h>
<andrewrk> that's always available
<andrewrk> but if you need it for otherwise normal zig code, something is wrong
<scientes> I just struggle to write assembly in zig
<andrewrk> shritesh, funny, I find that question difficult to answer
<scientes> cause i can't get the syntax right---its fine if its pure assembly, but i can't get the restraint syntax right
<andrewrk> I spend a lot of effort trying to make there be fewer ways to say "yes" to that question
<scientes> i don't think i've gotten it to work even once
<andrewrk> it should be identical to clang
<shritesh> andrewrk, I am feeling the same. Unlike, scientes, I think zig can replace a lot of my scripting needs (usually python)
wootehfoot has joined #zig
<scientes> it can, i'm just saying it is differn't
<scientes> there are many things that a scripting language will require a lot less code for
<andrewrk> using zig as an embedded scripting language for a game, would be a bad fit
<andrewrk> game engine itself, sure :)
<scientes> for scripting I want a language where regexps are extremely accessable
<andrewrk> well, then again, you could target WASM. maybe that's not even a bad idea
<scientes> lua would probably run well in WASM
<shritesh> With comptime, I think we should be able to provide a powerful typed-regex experience.
<andrewrk> it's one of my goals to have standard library regex that can be compile-time checked if the regex string is comptime known
<scientes> but then again, you already have javascipr there, so thats what people would use
<scientes> andrewrk, yes, i've been thinking about that for years
<scientes> andrewrk, there are two levels of FCP--compiling the regexp, and executing it
<andrewrk> we'll need faster comptime eval / better memory handling for that. that's probably a bit in the future from now
<andrewrk> my goal is for stage2 comptime eval to be roughly the same speed as CPython
<andrewrk> I think that's a reasonable goal
redj has joined #zig
<andrewrk> it has to do more work than CPython, because sometimes the instructions have to emit at runtime
<scientes> well regexp is its own special world, so its performance is separate
<andrewrk> sure, but we also want zig's comptime eval to be reasonable in general
<scientes> if you mark a function as pure, it can just be compiled and run
return0e_ has joined #zig
<scientes> pure functions depends on multiple returns
return0e has quit [Ping timeout: 252 seconds]
<scientes> and also better array handling
<hryx> Something I should have asked a long time ago: what does "Avoid local maximums" mean? I'm not familiar with that term
wootehfoot has quit [Read error: Connection reset by peer]
<scientes> hryx, limits that come from the code rather than the runtime
<hryx> Ohhhh
<scientes> oh woah
<andrewrk> idea being, if you are halfway between "local minimum" and "local maximum" you should actually go to the right, even though it may be tempting to go to the left
<hryx> I see now! thankye
<andrewrk> zen of zig shouldn't be taken *too* seriously. it's all pretty subjective. often one can use them to justify any decision
<hryx> so you're saying I _shouldn't_ have tattooed them on my back?
<andrewrk> haha
<hryx> oh andrewrk is 0.4.0 scheduled for Monday?
<andrewrk> yes
<hryx> cool
<andrewrk> I am working on the release notes now
<andrewrk> and then I still need to get down to 30 issues today @_@
<andrewrk> thanks shritesh for helping with that :)
<andrewrk> also have to run 15 miles tomorrow
<hryx> nice shritesh, you've been a busy bee
<hryx> I didn't quite get to the stage2 parse recursion refactor you recommended andrewrk, but that's the next thing I want to tackle
<andrewrk> you're into that eh? cool
<shritesh> It's my way of productive procrastination lol
<hryx> refactoring feelz good
<andrewrk> almost feels sad to destroy Jimmi's work of art
<andrewrk> a recursion-free recursive descent parser
<hryx> I could never live with myself if I destroy anything of Jimmi's
<andrewrk> hryx, the arena pattern is probably good to stay though - you can see how it means the parser never has to free() anything
<andrewrk> I was pretty pleased when I realized that
<hryx> awesome
scientes has quit [Read error: Connection reset by peer]
scientes has joined #zig
<scientes> Its faster to not free
<scientes> not to mention it makes the code simpler
<andrewrk> yeah, arenas are pretty great. If you think about it, every stack frame is a mini-arena
<andrewrk> coroutine frames too
<scientes> the arena can be optimized to use a dedicated "aux" stack pointer register
<scientes> hehe
<scientes> but thats pretty involved
<scientes> the stack is insanely fast because of that dedicated register
_whitelogger has joined #zig
<scientes> why is it so hard to find detailed spec of what some avx instructions do
<scientes> the abstract really doesn't make it clear
_whitelogger has joined #zig
shritesh has quit []
_whitelogger has joined #zig
<hryx> I'm unable to build stage1 for commits after 8e6ff8d615820f7f732724a5db1639ae5f12fb4e (fix NaN comparing equal to itself), not sure why. The issue seems to be that isnan is undefined, even though <math.h> is included
<hryx> correction: "fix NaN" is the first commit after 8e6ff8d6
_whitelogger has joined #zig
<andrewrk> hryx, what os?
<hryx> Linux Mint based on ubuntu 16.04, kernel 4.15.0, x86_64
<andrewrk> can you try this? https://clbin.com/f0IFA
<hryx> on it
<andrewrk> hryx, this diff passes all tests for me, so if it solves the problem for you I will push it to master
<hryx> andrewrk: looks good!
<hryx> able to build stage1 with that change
<hryx> thanks for the quick fix
<andrewrk> no problem
tridactyla has joined #zig
hio has joined #zig
return0e has joined #zig
return0e_ has quit [Ping timeout: 264 seconds]
<daurnimator> andrewrk: I just read through #164. It reminded me of a different question I had: as zig has no operator overloading or way to create custom primitive types, how should something like unums ( https://en.wikipedia.org/wiki/Unum_(number_format) ) be introduced to zig?
<hryx> daurnimator: unum looks interesting. I feel like someone shared that months ago -- maybe it was you?
<daurnimator> hryx: maybe.... not sure
<hryx> hmm
<daurnimator> I guess the approach wouldn't be too different to e.g. fixed point types. which seem to have an issue #1974
<hryx> Wouldn't this type be possible to implement as a struct with methods? Besides convenience and brevity issues, is there a big downside of that approach?
<hryx> oh unless this is actually supported in hardware somewhere
<hryx> I guess it could in the future. Maybe dats your point
<daurnimator> hryx: experimental hardware support exists. the proposal on the unum side is that existing architectures would all get a 'softunum' library like we have softfloat libraries for some processors today
Ichorio has joined #zig
Zaab1t has joined #zig
tyler569 has joined #zig
kristate has joined #zig
<kristate> Hi everyone
<hryx> hello kristate
<kristate> Jimmi (Hejsil) and I are hacking away here in Kyoto, Japan
<kristate> might do a live-stream here in a bit to hack on the last bugs before 0.4.0
<hryx> yay!
<hryx> kristate I meant to contact you last time I was in Kyoto. Sorry I didn't stop by
<hryx> I live in san francisco USA
<kristate> hryx: cool, let me know if you're interested in a job :)
<hryx> is the stream on twitch?
<kristate> yeah, hang on -- setting it up
<kristate> okay, it's comptime: https://www.twitch.tv/findyourownpath
Sahnvour has joined #zig
fsateler_ has joined #zig
fsateler has quit [Ping timeout: 268 seconds]
jjido has joined #zig
<telemach> hey folks, does this error look familiar to anyone?
<telemach> zig-cache/o/bEb_ELwjbsYjnHh0o5x1-eS8XslMmmgwXSxRE_P14wUmxEkhlKZ8DNQd4pumngX8/cimport.zig:440:5: error: expected optional type, found '[*c].cimport:5:13.LV2_Atom_Forge'
<telemach> forge.?.Blank = map.?.map.?(map.?.handle, c"http://lv2plug.in/ns/ext/atom#Blank");
<telemach> i get a lot of them trying to use LV2's atom/forge.h
<telemach> seems zig fails to properly process header file
<telemach> this one
<telemach> generated fn signature is pub fn lv2_atom_forge_init(forge: [*c]LV2_Atom_Forge, map: [*c]LV2_URID_Map) void
<telemach> so i guess it either should be ?[*c]LV2_Atom_Forge or no `.?` check for optional?
<scientes> kristate, hi, I sent you an e-mail
shritesh has joined #zig
Ichorio has quit [Ping timeout: 268 seconds]
neceve has joined #zig
a_chou has joined #zig
a_chou has quit [Ping timeout: 264 seconds]
jjido has quit [Quit: Connection closed for inactivity]
a_chou has joined #zig
a_chou has quit [Client Quit]
shritesh has left #zig [#zig]
shritesh has joined #zig
wootehfoot has joined #zig
<andrewrk> telemach, ever since the C pointers update, you don't need the .?
<Sahnvour> just discovered slices are not `packed`, is there a reason for this ?
<andrewrk> Sahnvour, what do you mean?
<scientes> Sahnvour, slices are adorned arrays
<andrewrk> shritesh, btw you can use zig to compile C code for wasm too
<scientes> Sahnvour, but i have a bug to investigate that
Ichorio has joined #zig
<Sahnvour> andrewrk I mean the actual pointer+size struct
<Sahnvour> this doesn't work: https://pastebin.com/raw/L2pmRNuT
<Sahnvour> error: non-packed, non-extern struct '[]u32' not allowed in packed struct; no guaranteed in-memory representation
<andrewrk> ahh now I understand
<andrewrk> ok so there are 2 design questions on the table here
<andrewrk> 1. should packed structs be allowed to have a non-guaranteed in-memory representation? (and therefore allow any types in them)
<andrewrk> 2. should slices have a guaranteed in-memory representation?
<andrewrk> I think the answer to (1) is "yes"; otherwise there would be no way to manually lay out a struct that had zig types in it
<Sahnvour> given the quite direct mapping of slices to a pair of 64bit values, I did expect 2. to be yes, at least optionally
<Sahnvour> well, to a pair of machine-sized values but your get the point
<andrewrk> so whether or not a packed struct has guaranteed in-memory layout would be a property determined by what fields it contained
<andrewrk> regarding (2) I think that sounds reasonable and would be worth opening a proposal for
<andrewrk> the only reason not to would be if it enabled some kind of debug safety feature
<andrewrk> for example bare unions have a secret safety field thanks to not having a guaranteed in-memory layout
<Sahnvour> what benefits do we get from guaranteed in-memory layout for (userland) packed structs ?
<andrewrk> types that have guaranteed in-memory layout have well-defined behavior with @ptrCast and @bitCast, even at compile time
<Sahnvour> if I get this right, the goal is to not surprise the user with hidden or reorganized fields, since the compiler knows everything about the structs in the end
<Sahnvour> and not a technical difficulty, correct ?
<andrewrk> correct - for some use cases the programmer wants guaranteed in-memory layout
develonepi3 has left #zig ["Leaving"]
kristate has quit [Remote host closed the connection]
reductum has joined #zig
<scientes> how do i get the code an IrInstruction comes from?
<scientes> nvm
wootehfoot has quit [Read error: Connection reset by peer]
_whitelogger has joined #zig
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 246 seconds]
reductum has quit [Quit: WeeChat 2.4]
wootehfoot has joined #zig
Ichorio_ has quit [Ping timeout: 245 seconds]
squeek502 has joined #zig
tiehuis has joined #zig
Sahnvour has quit [Ping timeout: 268 seconds]
fsateler_ has quit [Read error: Connection reset by peer]
fsateler has joined #zig
Zaab1t has quit [Ping timeout: 264 seconds]
jjido has joined #zig
<telemach> andrewrk: yes, but this file is generated by Zig from C header
<telemach> i'm on relatively recent master 0.3.0+90b6eab0
return0e_ has joined #zig
return0e has quit [Ping timeout: 264 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined #zig
dembones has joined #zig
<dembones> I'm struggling with pointers to generic functions. I think it's because I'm not getting comptime everywhere I think I am.
<dembones> The non-generic version is here: https://github.com/brhamon/zigdate/blob/master/src/divInteger.zig
<dembones> I've rewritten truncatedDivision, flooredDivision, and euclideanDivision so that they operate on all signed integer types
hio has quit [Quit: Connection closed for inactivity]
<dembones> And they pass tests on i32
<dembones> but I'm trying to write tests for other integer widths, and I'm going in circles a bit.
<dembones> here's the version which has generics passing on i32: https://github.com/brhamon/zigdate/blob/generics/src/divInteger.zig
wootehfoot has quit [Read error: Connection reset by peer]
<dembones> If you clone that code, you can just do `zig test src/divInteger.zig`
<dembones> From the code on branch `generics`, I have three consecutive calls to `run`. The first challenge is to rewrite those three calls as a `for` loop.
<hryx> Why does the grammar rule for ContainerMembers contain a trailing slash (choice operator)? I can't find any information on what this would mean in a PEG