ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
return0e has joined #zig
return0e_ has quit [Ping timeout: 245 seconds]
_whitelogger has joined #zig
<tyler569> I seem to have found an issue that's a dup of #1689 / bad inline asm, generates invalid IR, crashes LLVM. I see Andrew had some next steps for that but then the ticket closed a few days later, is the expectation that those asm issues should be fixed?
<tyler569> Happy to report it, just trying to gauge if it would be useful for me to open a new issue saying basically "I see this thing too"
<andrewrk> tyler569, yes, according to the issue we thought it was fixed by Sahnvour's patch
<andrewrk> feel free to comment and I'll reopen it, or file a new issue
<hryx> I pushed changes to my parser branch which exposes the MemoryLeakDetected issue again. Test case from last night should show the leak instead of error.NotImplmented now:
<mikdusan> is there a control for PR to disable checks until some known issues are worked out?
<mikdusan> (on github)
_whitelogger has joined #zig
hio has quit [Quit: Connection closed for inactivity]
ltriant has joined #zig
Ichorio has joined #zig
ltriant has quit [Ping timeout: 255 seconds]
<emekankurumeh[m]> i think opening a draft instead of pull request does what you are asking for
hoppetosse has quit [Ping timeout: 268 seconds]
<emekankurumeh[m]> is there a reason that "-static-libgcc -static-libstdc++" is passed to the compiler only on macos?
<emekankurumeh[m]> nvm i figured it out.
ltriant has joined #zig
ltriant has quit [Ping timeout: 244 seconds]
<daurnimator> Idea: a CI job that runs `zig fmt` on `std/` and complains if anything isn't already correct
<daurnimator> Further idea: new flag for `zig fmt` that doesn't format anything, but just exits with a code depending on if something changed or not
* daurnimator creates issues
<andrewrk> --check does that
<mikdusan> like `zig fmt --check` ?
<andrewrk> it's not time for a ci job yet, the syntax isn't stable enough
<daurnimator> andrewrk: but shouldn't zig fmt still pass? and if you change zig fmt, then you should add a commit to reformat std/ on the way?
<daurnimator> same as if you sent a PR, e.g. changing the sigil for optional pointers: you'd have a commit changing the compiler; then a huge commit changing all the stdlib.
<redj> andrewrk: belated congrats on the recent releases (0.3.0, 0.4.0)... these release notes are impressive!
<emekankurumeh[m]> a github app that runs `zig fmt` might do what you're looking for
<redj> andrewrk: what's that talk you're preparing for?
* redj is excited for 0.5.0
<redj> I hope the roadmap for it holds :P
<emekankurumeh[m]> when's the talk?
<andrewrk> tuesday
<emekankurumeh[m]> that's soon
<andrewrk> daurnimator, I think that will be reasonable soon
<redj> andrewrk: nice, I wish you a great talk with excellent outcome for zig! :)
<andrewrk> daurnimator, after hryx's project + putting zig fmt into libuserland.a
<andrewrk> thank you redj
<daurnimator> andrewrk: would you accept a PEG module into std/?
<andrewrk> a zig implementation of a parser expression generator?
<daurnimator> yes
<andrewrk> which outputs .zig code?
<daurnimator> no. which has a function: pub fn match(self: PEGParser, input: []const u8) PEGResult { }
<daurnimator> (and a large number of functions to create PEGParser objects at either comptime or runtime)
<andrewrk> that sounds like a nice self contained API. go for it. it'll be good for language test coverage, and then probably a candidate to move to a third party package in the 1.0 std lib audit
<daurnimator> andrewrk: reason against 3rd party is dependency path: zig package manager => http client => PEG parser for header fields
<andrewrk> certainly if there is an http client in std and it depends on a PEG then the PEG belongs too
<andrewrk> why use a PEG for http parsing?
<andrewrk> is it really that complicated?
<daurnimator> andrewrk: many header fields are stupidly complex...
<daurnimator> core.lua might be a good start
<emekankurumeh[m]> would it be better to parse them lazily?
<daurnimator> emekankurumeh[m]: what do you mean?
<andrewrk> mikdusan, is your PR ready for review?
<daurnimator> emekankurumeh[m]: my intention was that headers would be parsed as needed e.g. const content_length:usize = std.peg.match(std.http.parsers.content_length,[0]));
<emekankurumeh[m]> not lazily per se, but like picohttpparser
<emekankurumeh[m]> also wouldn't your example need to wrap the return type similar to the json module?
<daurnimator> emekankurumeh[m]: not sure. ideally note: the result could be a function of the pattern definition
<daurnimator> pub fn match(self: PEGParser, input: []const u8) PEGResultType(self) { }
_whitelogger has joined #zig
<emekankurumeh[m]> not to nitpick, but if you open a pull request to fix an issue on github, adding "closes #issue-number" closes that issue automatically
<daurnimator> emekankurumeh[m]: also "Fixes" and "Resolves" IIRC.
ltriant has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
Ichorio has quit [Ping timeout: 244 seconds]
very-mediocre has joined #zig
slugm has joined #zig
jjido has joined #zig
<daurnimator> do we want syscalls to have workarounds like in musl?
<shachaf> Workarounds?
<daurnimator> shachaf: some syscalls have known broken corner cases. e.g. right now I'm looking at sendmmsg
ltriant has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
ManDeJan has quit [Ping timeout: 255 seconds]
hio has joined #zig
slugm_ has joined #zig
slugm has quit [Ping timeout: 255 seconds]
<daurnimator> hrm. awkwardness: `const last:u32 = 0; const mylen:u32 = 500; for (myarray[0..mylen]) |x, i| { last = i; }` // expected type 'u32', found 'usize'
<daurnimator> should I fix it by A. changing `last` to a usize? even though it will never use the whole range? or B. add an @intCast in there.
slugm__ has joined #zig
slugm__ has quit [Remote host closed the connection]
slugm_ has quit [Ping timeout: 246 seconds]
slugm has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 244 seconds]
glassofethanol has joined #zig
<daurnimator> Do we have an existing htons-like function?
<daurnimator> I want to use it as part of an initializer; so writeIntBig taking a destination address doesn't really work
slugm has quit [Ping timeout: 250 seconds]
slugm has joined #zig
glassofethanol has quit [Quit: leaving]
_whitelogger has joined #zig
hio has quit [Quit: Connection closed for inactivity]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ltriant has joined #zig
shritesh has joined #zig
ltriant has quit [Ping timeout: 268 seconds]
slugm has quit [Ping timeout: 246 seconds]
jjido has joined #zig
Ichorio has joined #zig
slugm has joined #zig
utzig has left #zig [#zig]
shawn_ has joined #zig
shawn_ is now known as scientes
hio has joined #zig
slugm_ has joined #zig
slugm has quit [Ping timeout: 268 seconds]
slugm__ has joined #zig
slugm_ has quit [Ping timeout: 245 seconds]
ltriant has joined #zig
hio has quit []
ltriant has quit [Ping timeout: 268 seconds]
<shritesh> Anyone with lua experience around?
<shritesh> More specifically: embedding lua
<daurnimator> shritesh: yeah. a lot...
<shritesh> daurnimator: Can a Lua ffi call possibly be generalized? Like say a `fn some_call(ctx: lua_context, arg1: type_1, args...) return_type` do the right thing if this was a feature in the host language?
<daurnimator> shritesh: sure. are you trying to make
<shritesh> OMG YES!
<daurnimator> shritesh: missing primitive is that zig doesn't have a @callfunctionwithargs(myfunc, myargs);
<daurnimator> `myargs` there needs to be some sort of tuple-y thing.
<shritesh> @inlineCall?
<daurnimator> shritesh: nope. you can't build args yourself.
<shritesh> So here is what I'm doing: I'm trying to add more calling conventions to extern and export functions that know about different FFIs and are able to "do the right thing" for that case. I have some small example working for JS/Wasm with a new `javascript` keyword but it can be generalized when #661 is solved. I realized that we can do the same thing with other languages like Lua, Java JNI?, Objective-C, and have even better cross-language story.
<shritesh> I wanted to see if it's possible and looks like it is with JS at least.
<scientes> that's cool
<scientes> I was thinking about this regarding cockpit--i was trying to tell them that the C ABI is a API
<scientes> and they could just use it via FFI
<shritesh> cockpit?
<daurnimator> shritesh: the lua shared object interface is that your library exports a function: static int luaopen_yourlibname(lua_State *L);
<daurnimator> uh, not static.
<scientes> shritesh, its a way of binding to javascript through AJAX
<scientes> its a web UI to Linux done right
<scientes> they just didn't get that C is a API
<shritesh> scientes: So did they create an Enterprise Architecture(tm) instead?
<scientes> shritesh, no, whats correct about it is that you can directly call stuff on the server, so its not over-engineered
<shritesh> ah. cool
<scientes> just not C libraries
<scientes> oh that page is pretty bad
<shritesh> daurnimator: would something like `export fn[CC.lua] func_u32(L: lua_state) u32 { return 42;}` make sense?
<scientes> why "func_u32"?
<shritesh> name of the function, I guess
<scientes> ok, nothing special there
<shritesh> I'm going with daurnimator's gist
<shritesh> welp he doesn't have a u32 but let's assume there was one :D
<scientes> and, "CC.lua", is CC a zig variable? otherwise probably just [lua]--and if we are going to do that, you should probably be able to put llvm calling convetions in there
<scientes> with "ccc" being the default
<daurnimator> shritesh: so that would automatically wrap the function for you or something?
<shritesh> I'm just going with what's suggested in #661
<scientes> oh, we already have calling convention in @typeInfo
<shritesh> daurnimator: Yes.
<scientes> just extend that
<shritesh> Yes. Only for extern and export
<scientes> except...that requires adding a keyword
<scientes> maybe those should be removed, for this [lua] syntax
<scientes> @setCold(is_cold: bool)
<scientes> clean that up
<shritesh> That's what I've done locally right now. But we can just add another item to the enum
<daurnimator> shritesh: why only for extern/export?
<shritesh> daurnimator: Does it make sense elsewhere?
<daurnimator> shritesh: with lua you're meant to pass functions to `lua_pushcfunction(L, yourwrapperhere)`
<scientes> "extern" basically means "ccc", so yeah that shouldn't be required
<scientes> and export as well
<daurnimator> shritesh: in your luaopen_XXX entrypoint, you usually tell lua about your libraries types and push all your wrapped functions into lua.
<scientes> but there shouldn't be too many ways to do the same thing, so i guess [ccc] would be forbidden
<scientes> daurnimator, that is not that differnt to creating a header file for export
<shritesh> gotcha. Right now I have a `extern javascript fn add(..) u32`. And during IR phase it does something else when the function had javascript.
<scientes> this is slick though, it could work with cpython, cruby, et cetera
<shritesh> ...and it uses the information to generate a .js at the end
<daurnimator> scientes: the way I was playing with was you do: myluawrappedfunc = ziglua.wrap(myfunc); lua.lua_pushcfunction(L, myluawrappedfunc);
<shritesh> That too. And I think with stage1 being hybrid, we should be able to have something like std.ffi.{cython, cruby, js, lua, ...}
<daurnimator> ehhh, I'm not so sure.
<shritesh> okay :D
<daurnimator> in the mean time though; a proposal to make calling arbitrary functions possible would be great
<scientes> shritesh, i think that is really sexy, because it makes zig a go-to language for writing performant parts of scripting languages, instead of C
<shritesh> Again, let's err on the side of me not knowing what I'm doing / talking about here.
<scientes> with a much better cross-platform story
<shritesh> scientes: That's where I want this to go.
<shritesh> And I think it also makes sense for writing shaders, GPU kernels with those architecture/platform specific boundaries well defined
<shritesh> `export fn[CC.CudaDevice] myKernel(...) type;`
<shritesh> totally
<scientes> daurnimator, and that could also be used to call the LLVM bindings at comptime
<shritesh> I'm also not happy with how I overloaded wasm modulenames with `extern "modulename" fn ..`. That could be `extern fn[CC.Wasm("modulename")]] ...` with a tagged union
<scientes> which will allow full power comptime (without insane operator overloading)
<shritesh> yep. I think it creates a boundary for platform specific things.
<shritesh> WasmAllocator currently uses @"llvm.wasm.memory.size.i32". We should be able to gate that inside functions that are marked fn[CC.Wasm]
<daurnimator> shritesh: how could you export the same function for multiple targets?
<shritesh> You don't. You just become really explicit about platform specific things.
<scientes> daurnimator, you also might want to export the same function for multiple compile targets of the same architecture, like avx2 and sse2
<daurnimator> e.g. imagine I'm writing a web app and I want to do server-side and client-side rendering with the same code. I have `fn add(x: u32, y: u32) u32` => how do I A. use it in my server. B. have it exported into a wasm object that I can then serve?
<scientes> and have the most performant one selected at program startup
<daurnimator> scientes: ifuncs are a special thing of their own
<scientes> daurnimator, yes, but we should be able to do it without IFUNC, because that is ELF-specific and totally not needed for that feature
<daurnimator> scientes: for ELF targets; you *should* use IFUNCs.
<scientes> yes
<scientes> although we are not for vdso right now, we just use a function pointer
ltriant has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
shritesh has quit [Ping timeout: 245 seconds]
shritesh has joined #zig
slugm__ has quit [Ping timeout: 245 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
hoppetosse has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
slugm__ has joined #zig
slugm__ has quit [Remote host closed the connection]
ltriant has joined #zig
ltriant has quit [Ping timeout: 250 seconds]
<andrewrk> here are some relevant issues to the above discussion
<andrewrk> calling conventions
<andrewrk> function multi versioning
<emekankurumeh[m]> what would wwe need ifuncs for?
<andrewrk> ifuncs is one way to implement function multiversioning
<andrewrk> which is this: <scientes> daurnimator, you also might want to export the same function for multiple compile targets of the same architecture, like avx2 and sse2
<emekankurumeh[m]> couldn't we do this instead?
<andrewrk> emekankurumeh[m], do what?
<emekankurumeh[m]> function multiversioning
<andrewrk> the problem that function multiversioning solves is that you have a single binary that works on multiple different CPUs with different capabilities
<emekankurumeh[m]> so basically whats happening in compiler_rt but at runtime?
<andrewrk> pay some small upfront cost before main() to detect CPU features and swap out some of your functions for the versions that take advantage of cpu-specific features
<andrewrk> I'm not sure what you mean, what is happening in compiler_rt?
<andrewrk> not saying this is a good idea, but to think about it academically, if you extended the function multi-versioning concept further, you would even ship a single binary that worked on all operating systems too
<emekankurumeh[m]> the file i linked earlier, it decides at comptime which functions to export and under what name to export, which sounds like what ifuncs do if i understand them correctly.
<emekankurumeh[m]> nevermind, i just realized that ifuncs work at runtime
<andrewrk> note this is only 1 possible way to solve the problem
fengb_ has joined #zig
<fengb_> How do I keep debug symbols while building the zig compiler? I tried "-DCMAKE_BUILD_TYPE=Debug"
<andrewrk> fengb_, are you on windows?
<fengb_> Mac, but I'm using Docker
<andrewrk> debug is the default, which has debug symbols on
<fengb_> Hmm, gdb can't load the symbols for my built version
<andrewrk> this is the first I've heard of this problem
<andrewrk> fengb_, it's possible that the crash was in LLVM, which is built in release mode, and the debug info wasn't able to figure out how to get up the stack
<andrewrk> you could try a debug build of LLVM for this case
<fengb_> Ah okay. That's probably it
donpdonp has joined #zig
<fengb_> So... LLVM has no idea what the WASI environment/libc is. Should I just hack around it?
<fengb_> Or overload one of the existing ones, like musl
<donpdonp> how do i tell build.zig to include --library c
<andrewrk> artifact.linkSystemLibrary("c")
<andrewrk> fengb_, LLVM does know about WASI
<fengb_> Only the OS. The env target is missing, probably because it's not even officially defined yet
<donpdonp> andrewrk: thx
<andrewrk> fengb_, yes, zig will need the ability to have the set of target C ABIs be different than the set that LLVM recognizes. currently it's 1:1. you can see the pattern set by Os
<fengb_> afaict, it's not attempting to be ABI compatible with anything existing, but it defines a new ABI
<fengb_> Ah okay, I'll keeping hacking for now. Thanks
<donpdonp> am I doing this wrong? b.addNativeSystemIncludeDir("../libui"); ls ../libui/ui.h -> is there; zig build -> note: 'ui.h' file not found #include <ui.h>
<andrewrk> donpdonp, sounds like artifact.addIncludeDir is closer to what you want
<andrewrk> if it's a relative path that sounds like something in your project directory right? as opposed to something installed on your system
<donpdonp> andrewrk: ah yeah addIncludeDir is it. i think maybe it used to be on Builder but now its on artifact?
<andrewrk> that might be true
japanoise has quit [Ping timeout: 252 seconds]
<donpdonp> another point of confusion is ive got const exe = b.addExecutable("main", "src/main.zig");b.default_step.dependOn(&exe.step);
<andrewrk> zig build system has been sort of evolving slowly, I haven't sat down to really streamline it yet
<donpdonp> zig build completes without error, but no 'main' file in current dir
<donpdonp> (0.4.0+98fa065d fyi)
<andrewrk> that text explains your options
<donpdonp> ah ok thx
<donpdonp> im trying to push this zig 0.3 (or even 0.2) hello-world level code into 0.4 world.
<shritesh> Here's a proof of concept of how zig might make JS-interop feel better. It doesn't handle non-primitive types yet but that's next.
<emekankurumeh[m]> where does zig store information for stack pointer names?
<emekankurumeh[m]> found it
<andrewrk> shritesh, what's the benefit of numerics.js rather than using the wasm directly?
<andrewrk> maybe for non primitives it will be more celar
<andrewrk> *clear
<shritesh> For non-primitive types, nothing. But passing strings / structs around requires a lot of coordination with the wasm_allocator.
<shritesh> *for primitive type
<shritesh> Just being able to pass u8 slice across would be such an improvement. See and
<emekankurumeh[m]> does anyone know what would cause the error "<unknown>:0: error: invalid symbol redefinition"?
<andrewrk> shritesh, I think it's a good idea to stick to the C ABI types for this
<andrewrk> if this proposal is accepted, then slices would be allowed in C ABI functions and types:
<andrewrk> there will always be some API inconvenience at this place where the ABI is required to be stable
<andrewrk> a lot of zig semantics rely on not having to be a stable ABI
<shritesh> That'd be nice. Will the first usize? be the length?
ltriant has joined #zig
ltriant has quit [Ping timeout: 246 seconds]
<shritesh> And here's the thing too: non-javascript embeddings (WASI/Odin/terrarium) do not have this problem at all. All of them follow the C-ABI and work really well out of the box.
<shritesh> Maybe we put the burden on some foundational libraries with well maintained JS shims instead
<shritesh> a blessed zig.js of some sorts
<hryx> Question: the grammar allows for declaring an enum type with or without a parenthetical tag type: `enum {...` or `enum(u8) {...`
<hryx> So far so good, but it also allows for a parenthetical on struct types
<hryx> e.g. `struct {...` and `struct(something) {...`
<hryx> I can't find any examples of that usage anywhere in the compiler code base. What is it for?
<hryx> For reference, the grammar rule this corresponds to is ContainerDeclType
<andrewrk> hryx, probably a mistake
fengb_ has quit [Ping timeout: 256 seconds]
<andrewrk> or a yagni violation
<hryx> andrewrk: ok, I'll open an issue and maybe Jimmi can weigh in
<hryx> ah, hehe
very-mediocre has quit [Ping timeout: 256 seconds]
shritesh has quit [Quit: Segmentation Fault]
<Xe> working more on olin stuff today, packing is a thing
<Xe> so the webassembly allocator is at @import("std").heap.wasm_allocator right?
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 246 seconds]
Ichorio has joined #zig
Ichorio_ has quit [Ping timeout: 250 seconds]
shritesh has joined #zig
<shritesh> Xe: yes
Ichorio_ has joined #zig
<Xe> shritesh: what is the type of the allocator?
<shritesh> It's std.heap.WasmAllocator but it conforms to std.mem.Allocator
<Xe> :+1:
ltriant has joined #zig
Ichorio has quit [Ping timeout: 255 seconds]
wink_ has joined #zig
Ichorio_ has quit [Read error: Connection reset by peer]
ltriant has quit [Ping timeout: 255 seconds]
gamester has quit [Remote host closed the connection]