ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Client Quit]
<andrewrk> grinz, is your gist referring to #588 which is to be solved by #770?
<andrewrk> yes, interop with C and with common operating system API such as windows and linux
<andrewrk> I don't think winapi uses utf-8. see https://github.com/zig-lang/zig/issues/534
<grinz> this is exactly why []null type is useless in that case
<grinz> andrewrk, yeah
<grinz> is there api to enumerate (and call by name) functions in scope/struct?
<andrewrk> grinz, []null for UTF-16 means it is terminated with u16(0)
<andrewrk> so it still works
<andrewrk> the full type would be: []null u16
<andrewrk> I don't think we have a function for that yet, but feel free to file an issue - it's planned to support that kind of reflection
<grinz> what about computed goto support?
<andrewrk> see this comment for computed goto: https://github.com/zig-lang/zig/issues/630#issuecomment-349096978
<andrewrk> short summary is: let's come up with a use case where performance could be measurably improved by computed goto. and then let's try to write an LLVM optimization pass that detects the pattern and changes it to computed goto.
<andrewrk> if that doesn't work we can talk about adding computed goto to the language
<grinz> optimization pass is not good enough
<grinz> is has to be assert-like statement
<andrewrk> good enough in what sense?
<grinz> optimizations are too fragile
<grinz> you violate it rules and get bad performance without any warnings
<andrewrk> I agree with both of those statements, but I am not convinced that computed goto at the language level solves them
<andrewrk> if performance of a particular section of your code is a feature, then you need a test that makes sure that performance is maintained
<grinz> I am fine with while (true) switch construct as long as we have a way to get an error if compiler failed to transform to computed goto
hoppetosse has quit [Ping timeout: 260 seconds]
<andrewrk> I think this issue is worth discussing in the bug tracker if you would be willing to start that conversation
<GitHub60> [zig] andrewrk pushed 1 new commit to master: https://git.io/vAV8V
<GitHub60> zig/master 8db7a14 Andrew Kelley: update errors section of docs...
<GitHub66> [zig] andrewrk closed pull request #768: document when to use error!type in function decl (master...func-decl-error) https://git.io/vALWd
<grinz> Well, I am still not sure I want to use clang for writing lexer. My latest experiment shown that compilers generally are not able to generate sane code for lexers
<grinz> You add one line and get new assembly for the whole function hurting performance by 20-30%
<andrewrk> grinz, are you considering having the lexer be in assembly?
<grinz> And you can always use C for the lexer as a workaround so its not much of a problem
<grinz> yup
<andrewrk> interesting. zig does have inline assembly, if that helps. it's mostly the same syntax as gcc and clang
<andrewrk> I'll be on later. bye
hoppetosse has joined #zig
hoppetosse has quit [Ping timeout: 248 seconds]
hoppetosse has joined #zig
hoppetosse has quit [Ping timeout: 240 seconds]
davr0s has joined #zig
<grinz> Is it possible to define function that takes value of arbitrary type T without passing T explicitly?
<MajorLag_> fn myFunc(thing: var)
<grinz> oh
<grinz> I was confused by error message "error: parameter of type '(integer literal)' requires comptime"
<grinz> When I tried myFunc(123)
<MajorLag_> been there.
<grinz> But i want that function to work with integer literals.
<grinz> Adding comptime breaks runtime values (obviously)
<grinz> Also it would be nice to take types as well
<grinz> And no function overloading, right?
<grinz> so many issues(
<MajorLag_> Yeah, unfortunately comptime is broken in many ways.
<grinz> No operator overloading?
<MajorLag_> Nope
<grinz> Why? Is it planned?
<MajorLag_> I don't know andrewrk or the rest of the community's reasoning. Personally I think it just obfuscates things. As far as I am aware there are no plans to implement it, but I'm relatively new to Zig myself so don't have a good knowledge of previous discussions.
<grinz> Then 1 + 2 should also be replaced with 1.add(2)
<grinz> Lack of operator overloading is major PITA when working with custom big integer / money / simd types
<MajorLag_> 1 + 2 is obvious though. There's no hidden allocation or computation involved.
<MajorLag_> You can't say that about overloaded operators.
<grinz> a | b is more obvious than _mm_or_si128(a, b)
<grinz> result &= (mouse_x < test.left) | (mouse_x > test.right) | (mouse_y < test.top) | (mouse_y > test.bottom);
<grinz> Now imagine that without operator overloadin
<grinz> I was able to apply De Morgan's rule after I made SIMD wrapper with operator overloading.
<grinz> Function call version was too messy to figure out possibility of such transformation
<grinz> comptime var output2: []const u8 = "test"; @compileLog(output2);
<grinz> this outputs "| (struct []const u8 constant)". Why not "test"?
<MajorLag_> Good question. Bug?
<grinz> But I can use @compileError instead!
tiehuis has joined #zig
<tiehuis> compileError is only working for the string case since it accepts only a string unlike compileLog which will try and print the repesentation of any type
<tiehuis> not sure why the array is treated as a struct though, that definitely seems a bug
<tiehuis> actually maybe string slices are stored in a similar way as a struct internally, with the pointer and len fields
<tiehuis> i think that would make sense here and explain what is going on
<grinz> But it's broken anyway
<tiehuis> also if you just defined the value as `const output2 = "test";` you would get the output you want
<tiehuis> but thats only because it defines it as a [4]u8 and not a []const u8 which you may not want
<grinz> I need compile time string builder.
<tiehuis> you can do compile-time concatenation with '++'
<grinz> And it's not going to work with array type as I cannot redefine such var due to type mismatch
<tiehuis> can you show what an expected use of it and how you would use it
<tiehuis> nevermind that, let me have a look
<grinz> i know about ++. It works fine with slice but @compileLog do not show it contents
<grinz> Only @compileError
<tiehuis> i don't think it would be unreasonable to special case comptime slices
<grinz> comptime var output: []const u8 = "";
<grinz> I use it like this. And then output = output ++ "...";
<grinz> BTW this crashes compiler: comptime var output = ""[0..];
<grinz> zig/src/analyze.cpp:394: TypeTableEntry* get_pointer_to_type_extra(CodeGen*, TypeTableEntry*, bool, bool, uint32_t, uint32_t, uint32_t): Assertion `byte_alignment > 0' failed.
<tiehuis> what version compiler? i can't seem to replicate that
<grinz> 0.1.1.b66547e9
<grinz> nightly
<tiehuis> anymore to that example, just updated to latest and still not getting it: https://clbin.com/us56P
<grinz> LLVM 5.0.1
<tiehuis> same version myself
<grinz> It also crashes without comptime
<grinz> pub fn main() void { ""[0..]; }
<grinz> Minimized example
<grinz> But this one works fine: var a = ""[0..]; pub fn main() void { }
<tiehuis> what is your build command for these?
<grinz> zig build-exe a.zig
<grinz> 1+ char strings works fine
<grinz> Same problem: pub fn main() void { ([]u32{})[0..]; }
<tiehuis> yeah still can't replicate this. there must be a different somewhere between our environments.
<tiehuis> my version for reference is: 0.1.1.8db7a142
<tiehuis> is this a release or debug compiler?
<grinz> cmake defaults to debug I guess
<grinz> yes, debug
<tiehuis> hmm, `get_pointer_to_type_extra` doesn't even appear on line 394 for the latest source
<grinz> Because I had b66547e9
<grinz> 0.1.1.8db7a142 - still crashes
<tiehuis> thats pretty much the latest commit, though
<tiehuis> last is just a doc update
<tiehuis> i'll rebuild in debug and see
<tiehuis> ah there we go
<tiehuis> should have tried that sooner sorry
<tiehuis> i can make an issue for this if you want
<grinz> I'll file it
tiehuis has quit [Quit: WeeChat 2.0.1]
_whitelogger has joined #zig
<grinz> So weird
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
grinz has quit [Quit: Page closed]
klltkr has joined #zig
klltkr has quit [Ping timeout: 268 seconds]
hoppetosse has joined #zig
<hoppetosse> andrewrk: I'm trying to get zig to compile to wasm, using zig build-obj main.zig --target-arch wasm32 --target-environ unknown --target-os fr
<hoppetosse> eestanding
<hoppetosse> fails with "unable to create target based on: wasm32-unknown-unknown-unknown"
<hoppetosse> I'm about to try going from llvm IR to wasm with binaryen, but
<hoppetosse> I'm not really sure what I'm doing, haha
hoppetosse has quit [Ping timeout: 256 seconds]
mal``` has joined #zig
mal`` has quit [Ping timeout: 264 seconds]
tridactyla has quit [Ping timeout: 264 seconds]
davr0s has quit [Ping timeout: 240 seconds]
davr0s has joined #zig
hoppetosse has joined #zig
jfo has joined #zig
<jfo> hey y'all what is the state of the art in writing formatted strings to stdout
jfo has quit [Remote host closed the connection]
jfo has joined #zig
jfo has quit [Remote host closed the connection]
jfo has joined #zig
<jfo> hoppetosse: are you still here? I'm working on getting zig -> wasm working smoothly
<hoppetosse> jfo: yep, still here
<hoppetosse> Have you had any success=
<hoppetosse> ?
<jfo> the bad news is that there are multiple hoops to jump through, including circumventing a bug that prevents passing `wasm` all the way to llvm as a target
<jfo> the good news is that after llvm6 comes out any minute now, and that gets fixed, this will be very easy to do
<hoppetosse> Oh wow, awesome
<jfo> (those are two separate things, the bug is not because of llvm)
<hoppetosse> you've gotten a lot further than I have
<jfo> we're hoping to see wasm land as a native target in llvm7 in ~6 months, the bulk of the work until then will be stubbing out or implementing std lib operations to make the language usable
<hoppetosse> I was still trying to figure out how to get the --target through
<jfo> yeah I've been really excited about wasm... llvm being able to output it directly and not go through a binaryen backend is awesome
<hoppetosse> Lookin forward to it XD
<jfo> I kept trying c -> wasm every few months but would be really frustrated by the brittle toolchains and how huge and inscrutable emscripten output is... I understand now it's basically polyfilling libc lol
<jfo> yeah I'm optimistic! zig is a good candidate for wasm development what with the manual mem management etc :)
<jfo> but the whole pipeline is not quite ready for prime time yet
<hoppetosse> Still, you've managed to
<hoppetosse> get something working
<jfo> :) yeah it was a lot, actually I forgot to mention the step where you have to compile llvm from source with the experimental target flag then compile zig off of that... like I said lots of hoops haha
<jfo> did you have a usecase in mind or are you just experimenting?
<hoppetosse> Oh, so you mean I can't just make a zig build with your changes?
* hoppetosse ctrl-c's
<hoppetosse> My usecase is games
<hoppetosse> I'm doing a game development course and we'll be doing web development for the next semester. Since I've already done web dev professionally, I kinda wanted to explore wasm and game related tech
<jfo> yeah sorry, that gist is a bit light on some of the important details.
<jfo> games, cool!
<hoppetosse> I've got a small zig project for a game engine
<jfo> I would be very interested to see if it's possible to get that working in wasm land
<hoppetosse> and one of my classmates wants to help me, so this will be an exciting 6 months
<jfo> does it interact with the gpu?
<hoppetosse> opengl
<jfo> hmm, yeah getting wasm talking to webgl is something I am really interested in doing
<hoppetosse> I haven't touched it much over the past few months
<hoppetosse> I'd been developing on linux, started trying to get it working on windows and failed so far
<hoppetosse> but there's a few breaking changes coming
<jfo> it likely be a while before the wasm support is mature enough to be able to handle those dependencies
<jfo> yeah quite a few
<hoppetosse> I also want to cut dependencies
<hoppetosse> libpng has been an issue
<hoppetosse> I've ported a simple c++ png decoder to zig
<hoppetosse> It's compiling, but I think I screwed up the huffman encoding part
<hoppetosse> I don't really want to depend on zlib either
<jfo> the issue with dependencies in wasm is that they have to have some kind of mapping to the browser api. currently most of the standard lib is unsupported, I've just been able to compile basic functions, which is a good start...
<jfo> this is why emscripten is so heavy, it does a lot of that hooking things up
<jfo> it's not impossible to imagine compiling zig to llvm or wasm and being able to link everything together via emscripten or something, ultimately I'd like out of the box support from zig via llvm directly for a lot of this, but it's definitely in the early stages and certainly non-trivial
<hoppetosse> Yeah, I'm going trying that now
<hoppetosse> at least work out what I'll need
jfo has quit [Remote host closed the connection]
jfo has joined #zig
jfo has quit [Remote host closed the connection]
jfo has joined #zig
<jfo> hoppetosse: I reread the gist, the only big thing I've left out is what I thought it was... you have to 1) build llvm from http://prereleases.llvm.org/6.0.0/ adding the DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly to CMake
<jfo> then build zig where -DCMAKE_PREFIX_PATH is set to the install directory of that llvm
<jfo> off of the llvm6 branch
<jfo> and from there I think the gist is accurate
<hoppetosse> I'll give it a shot, thanks for the bearings =)
<jfo> but it _is_ pretty rocky going atm, good luck lmk how it goes if you try anything out with emscripten
<hoppetosse> Thanks, will do!
jfo has quit [Remote host closed the connection]
jfo has joined #zig
jfo has quit [Ping timeout: 252 seconds]
jfo has joined #zig
jfo has quit [Remote host closed the connection]
jfo has joined #zig
jfo has quit [Ping timeout: 240 seconds]
jfo has joined #zig
jfo has quit [Remote host closed the connection]
jfo_ has joined #zig
jfo_ has quit [Remote host closed the connection]
jfo has joined #zig
jfo has quit [Client Quit]
hoppetosse has quit [Ping timeout: 240 seconds]
<GitHub29> [zig] thejoshwolfe closed pull request #784: Add utf8 string view (master...utf8-string-view) https://git.io/vA2il
<GitHub83> [zig] thejoshwolfe pushed 1 new commit to master: https://git.io/vAwIs
<GitHub83> zig/master 08d595b Marc Tiehuis: Add utf8 string view
hoppetosse has joined #zig
<GitHub84> [zig] bscheinman opened pull request #790: General-purpose memory allocator (master...gpalloc) https://git.io/vAwna
<GitHub120> [zig] bscheinman opened pull request #791: Add support for event loop and basic network listeners, and a general-purpose memory allocator (master...gpalloc_squash) https://git.io/vAwcq
hoppetosse has quit [Remote host closed the connection]
hoppetosse has joined #zig
<GitHub4> [zig] bscheinman closed pull request #790: General-purpose memory allocator (master...gpalloc) https://git.io/vAwna
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
cenomla has joined #zig
hoppetosse has quit [Ping timeout: 252 seconds]
hoppetosse has joined #zig