<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
<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?
<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...
<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, myheaders.at(myheaders.getIndices(name)[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
<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: 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);
<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 https://llvm.org/docs/LangRef.html#calling-conventions
<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>
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
<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
<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
<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>
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>
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. https://i.imgur.com/o9c5ZTn.jpg 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.
<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]