<mikdusan>
as I glean more things from this channel and making the odd contribution, I'll update it. goal is to help anyone wanting to debug/contribute stage1
shritesh has quit [Remote host closed the connection]
shritesh has joined #zig
<fengb>
mikdusan: this is amazing
<mikdusan>
thank u
shritesh has quit [Remote host closed the connection]
shritesh has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
<curtisf>
Is there any way to turn a []u8 into a []u4 (each byte indexed as two nibbles)?
<fengb>
We don’t have packed slices/arrays builtin
<fengb>
The std data structure might work but it sounds pretty gnarly
<marler8997>
just to double check...passing an array (i.e. [100]u8) to a function would have the same runtime ABI as passing a struct with 100 u8 fields?
<fengb>
Struct layout isn’t guaranteed unless you use packed or extern
<marler8997>
ok, assume a packed struct
<marler8997>
the point of the question was, is the 100-length array passed by value like passing a struct by value?
<fengb>
I believe so yes. But I’m pretty sure it’s not copied like it would be for C structs
<marler8997>
not copied? so then then answer is no?
<fengb>
Zig shouldn’t copy the data. It’d be a const reference
<marler8997>
hmmmm, does that mean I could take the address of it, and that address will still be valid when the function returns?
<fengb>
I don’t think this is defined yet, but it’s not like C where a struct is defined to make a memory copy for a struct
dbandstra has joined #zig
<fengb>
Zig compiler chooses the best strategy
<Tetralux>
Basically, it passes a ptr to a large struct (like [100]u8) as an optimization
<Tetralux>
You therefore cannot take a ptr to it and have it worked like you said.
<fengb>
Yeah, and for data that’s smaller it’d do a real copy
<fengb>
But you shouldn’t rely on it
<marler8997>
Tretralux: why not?
chemist69 has quit [Ping timeout: 264 seconds]
<Tetralux>
Because the data is copied into the function as far as the compiler is concerned.
<marler8997>
interesting
<marler8997>
so in practive, the address would probably be valid because of the optimization
<marler8997>
but in theory, you shouldn't rely on it
<curtisf>
using it after return would be undefined behavior
<fengb>
It’s undefined behavior
<marler8997>
is that in the spec somewhere?
<curtisf>
Andrew has mentioned that he hopes to make this _checked_ undefined behavior, but it's currently not
<Tetralux>
I suggest you actually write a program to test what happens.
<marler8997>
I have written a program
<Tetralux>
Print out the ptr address both in and out of the fn.
<marler8997>
It does the optimization
<fengb>
Zig doesn’t have a real spec :P
<marler8997>
but I'm asking if I can rely on it
<Tetralux>
Okay yeah
<fengb>
No you can’t
<Tetralux>
Don't.
<Tetralux>
:p
chemist69 has joined #zig
<curtisf>
I'm not sure how different Zig's memory model is from C, but two pointers having the same integer value doesn't mean they are the same pointer
<curtisf>
(in C)
<marler8997>
this sounds like an area where we need to work on the spec
<Tetralux>
curtisf: Two pointers that point to the same address, necessarily do point to the same data in memory.
<fengb>
Zig’s function call behavior is intentionally not a stable ABI
<fengb>
Except with extern
<marler8997>
ok
<Tetralux>
marler8897: Think of it like how clang can opimize a C++ function that scans an integer for how many bits are set to one---it optimizes it to a single popcnt instruction.
<Tetralux>
You don't want to _rely_ on it doing that
<companion_cube>
Tetralux: the C spec makes pointers typed, I think
<Tetralux>
But the fact that it does is obviously what you want.
<marler8997>
I understand what undefined behavior is
<curtisf>
@Tetralux That's not quite true, because a pointer may not point to valid data but happen to point to an address which is valid by another object
<marler8997>
I am surprised that taking the address of a statically sized array parameter is undefined
<Tetralux>
marler8897: That's not what's undefined.
<marler8997>
the lifetime is undefined
<marler8997>
if I take the address, it could be taking the address of a value on the functions frame or the address of a variable passed in by the caller
<Tetralux>
It's just that you don't want to rely on optimizations.
laaron has joined #zig
<marler8997>
if it's defined, then whats the definition of taking the address of a statically sized array parameter?
<marler8997>
what's the definition?
<fengb>
Parameter location isn’t consistent
<Tetralux>
The definition is that it'll either point to a local copy in that functions frame, OR, the original array in the caller frame, in this case.
<fengb>
You can use it but who knows where it is after a return
<Tetralux>
It points to a local copy if it's small.
<fengb>
Also it’s a const ref so you can’t change the data
<marler8997>
you gave me a definition but I have a feeling that's not the language definition, just the current LLVM implementation
<fengb>
Andrew mentioned he’s letting the compiler choose passing strategy
<marler8997>
as I understand it, C functionally solves this by only allowing the optimization if the address isn't taken
<Tetralux>
And that's the other important point - the optimization is to pass by const&, therefore if you modify the array, it may not do the optimization.
<marler8997>
well...that actually doesn't sound right
<marler8997>
The compiler makes the array const so I don't think you can modify it
<Tetralux>
That sounds about right.
<Tetralux>
I've never passed a large fixed array to a fn xD
<marler8997>
I'm trying to figure out how to properly handle fixed-size arrays in a generic function I'm writing
<fengb>
What’s wrong with a slice?
<marler8997>
The function returns the pointer to the array, but it sounds like that won't work for statically sized arrays, even though it may work with the optimization
<marler8997>
the generic function supports whatever makes sense
<fengb>
You can return the array
<curtisf>
function parameters are `const` anyway, so you shouldn't be able to get a non-const pointer to them anyway, right?
<marler8997>
It only returns a pointer
<marler8997>
not a value
<marler8997>
it can be a const pointer
<Tetralux>
Where does the memory live if you're returning it?
<marler8997>
what makes you think it needs to be non-const?
<marler8997>
it lives in the memory passed in by the caller
<curtisf>
I thought I mentioned you modifying it
<marler8997>
so depending on what type they pass in will determine where it lives
<Tetralux>
So essentially, they have a *T, they pass it to you, and you give back a *T?
<marler8997>
yes
<marler8997>
[*]T, pass back the pointer
<marler8997>
*T pass back the pointer
<curtisf>
I don't think you can say it depends on the type, in principal the compiler would be free to decide on a call-by-call basis
<marler8997>
[N]T, sounds like it should be an error
<marler8997>
I'm saying that the function will treat the value differently depending on the type
<marler8997>
and it will be up to the caller to understand how to call it correctly for their particular type
<Tetralux>
I mean, [N]T is a value, not a pointer.
<Tetralux>
So if they're giving you that, they aren't giving you a ptr.
<marler8997>
right, so it sounds like it doesn't make sense inj this case
<Tetralux>
It prob depends on what exactly this proc of yours does
<Tetralux>
But also
<Tetralux>
They could just pass you *[N]T instead
<marler8997>
it's just returning an iterator/rang type struct of the argument
<Tetralux>
Yeah, so they should pass you a *[N]T instead, by the sounds of it.
<marler8997>
correct, but I was just clarifying that [N]T should be an error
laaron has quit [Remote host closed the connection]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
mahmudov has quit [Ping timeout: 258 seconds]
curtisf has quit [Remote host closed the connection]
laaron has quit [Remote host closed the connection]
lunamn has quit [Ping timeout: 246 seconds]
dbandstra has quit [Quit: Leaving]
<bgiannan>
would be nice if `assert` could have a message associated to it
dbandstra has joined #zig
laaron has joined #zig
Hirezias has joined #zig
Hirezias has quit [Ping timeout: 252 seconds]
Hirezias has joined #zig
lunamn has joined #zig
dbandstra has quit [Quit: leaving]
ltriant has quit [Quit: leaving]
<Yardanico>
hello, how can I check if a value is in an array? something like "if (op in op_list". I tried searching in docs and github repo but didn't find any useful info
<Yardanico>
well, I can use for loop for that I guess, but I thought it was available with some operator or function
<Hirezias>
I don't know if it is the best solution, but you can do somthing like ``` for (op_list) |value| { if (std.meta.eql(value, op)) break true; } else false; ```
<Yardanico>
yeah, thanks, I thought roughly about the same solution
<Yardanico>
I'm just starting with Zig :)
<Hirezias>
I'm just starting too, so I took your question as an exercice, and I'm curious to see if someone else will give us a better solution :)
<Yardanico>
and another question - to make struct fields modifiable I need to use pointers, right?
<Hirezias>
I'm not sure to understand. Pointers assume that the memory is located in an other place in the memory, so you can take it adress. You just want to change the value stored in your struct, right ?
<Yardanico>
yes
<Yardanico>
but I get " error: cannot assign to constant
<Yardanico>
self.pos = new_pos;"
<Hirezias>
Aren't you declaring the struct instance as a constant ?
<Yardanico>
ah lol
<Yardanico>
I should use "var" instead?
<Hirezias>
Yes :)
<Yardanico>
thanks with "var" it's fixed now, sadly I'm leaving soon, gonna come back in about 5-6 hours to ask more questions probably :D
<Hirezias>
See you later :)
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<bgiannan>
`const MyStruct { i: i32 = 0 }; var a_struct: MyStruct = undefined;` <- I suppose `a_struct` won't get the default value of `i`?
<mikdusan>
bgiannan: correct; if you want just defaults init then `var a_struct = MyStruct{};`
<Hirezias>
I ran warn("{}", a_struct.i); just after the undefined declaration of a_struct, and I'm surprised to see that's not an error contrary to direct usage of a_struct. Does this makes sense ? (btw, as mikdusan says, a_struct.i is not initialized)
<mikdusan>
yes undefined is undefined. I'd hazard a guess that compiler reachability analysis will improve greatly in the future and if it can, emit diagnostics about undefined cases that can be determined at comptime
<Hirezias>
Ok, thank you. Must be considered as WIP so :)
<mikdusan>
on thing to note is `= undefined` can do some pretty cool things already in debug/safe compile modes
<mikdusan>
iirc, it initializes `0xaaaaaaaaaa` patterned memory in some cases
<mikdusan>
so if you get a crash that really sticks out in a backtrace and so forth
<Snektron>
gonz_: yeah i haven't been able to do many side projects in the last few months due to my bachelor's thesis eating up all my time, so i didn't keep up with development
<Snektron>
Now that's mostly finished so i can get back to making stuff in class
<gonz_>
I'll likely be the same in not too long because of work :/
<Yardanico>
Can I write a function with an array argument which will be able to accept arrays of different sizes of the same type?
<bgiannan>
you need a slice not an array then
<Yardanico>
Ah thanks I thought something like that should exist, didn't see them when skimming over the manual
laaron has quit [Remote host closed the connection]
laaron has joined #zig
utzig has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
rivten has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<rivten>
hey everybody ! i've got an issue where, when trying to compile C file with zig, zig can't seem to find windows.h... should I do something specific besides linking with C in build.zig file ?
<rivten>
"zig targets" does say that my native arch is x86_64-windows-msvc
<rivten>
(but it is not listed in the Available libcs though... maybe that's the issue ^^)
<bgiannan>
maybe provide it with `--library-path /path/to/windows.h`
<bgiannan>
or the equivalent in build.zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<gonz_>
rivten: What bgiannan said. You can actually extract the `cimport.zig` file later and remove whatever references you had to your specific directories after.
<gonz_>
I've done this with all of win32 and it works.
<rivten>
ok thanks a lot :)
<gonz_>
The import file will be in one of your object folders in the cache by default, but you can just reach in and pull it out to your source directory and give it a proper name.
<gonz_>
Depending on what you're doing you might want to use `@cDefine` to define `WIN32_LEAN_AND_MEAN`.
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<Yardanico>
So you can actually gradually translate a C program to Zig if Zig can compile C?
laaron has quit [Remote host closed the connection]
<mq32>
yes :)
laaron has joined #zig
<gonz_>
Yardanico: Indeed. I was trying to be principled and adding external calls as I went for my win32 project, but it's not a good starting point. It's better to just get the C stuff from `windows.h` and add nice zig interface functions after when you know what your program is doing.
<gonz_>
At least that's my impression so far.
mahmudov has joined #zig
rivten has quit [Remote host closed the connection]
<Yardanico>
Is there a way to explicitly discard a return value of a function other than creating variables like "const temp = myfunc();"?
<fengb>
_ = myfunc()
<Yardanico>
thanks!
FireFox317 has joined #zig
<FireFox317>
andrewrk: Thanks for merging the PR, are you streaming tonight?
<Yardanico>
I should report all compiler crashes, right?
DutchGh0st has joined #zig
<DutchGh0st>
Hi
<DutchGh0st>
Im trying to @cImport a library
<DutchGh0st>
but it fails
<DutchGh0st>
its not a system lib
lunamn_ has joined #zig
<samtebbs>
Yardanico: You should indeed, but check if they've been reported first. What crash are you experiencing?
<Yardanico>
samtebbs: well I didn't yet make a small repro, I'm currently porting a small math expression evaluator library I wrote for Nim in the past, and after changing locations of return statements I got a "unreachable: /deps/zig/src/codegen.cpp:ir_render_un_op:3305" crash
<samtebbs>
DutchGh0st: Hi, what's the failure and how are you compiling?
<DutchGh0st>
`/mnt/c/Users/Kasper/Documents/Zig/isen/test/zig-cache/o/msNPjw8kyeDmJKpSWFzjRr4V6Nan8r4TcshRmNz2FPu8JFQ1768mMrTfKYyXg9wd/cimport.h:1:10: note: 'propeller.h' file not found#include <propeller.h>`
<DutchGh0st>
Just `zig build-exe /mnt/c/Users/Kasper/Zig/test/src/main.zig`
lunamn has quit [Ping timeout: 245 seconds]
<fengb>
`-isystem [dir] add additional search path for other .h files`
<fengb>
You'll probably need this too: `-L[dir] alias for --library-path`
<DutchGh0st>
actually also with the `--library c` option
<samtebbs>
Yardanico: I searched the issues for `ir_render_un_op` but couldn't find anything, so see if you can make a minimal example that causes the crash and then we can see if it's been reported
<Yardanico>
samtebbs: yeah I'm currently trying to make it smaller
<DutchGh0st>
`-isystem .` beheind the `--library c` flag gives a segfault at address 0x0
<fengb>
o_O
<DutchGh0st>
`propeller.h` lives in the zig project
<DutchGh0st>
let me throw this against gdb
<fengb>
Hmm, can you try -isystem "$PWD"
<DutchGh0st>
segfault at 0x0
<samtebbs>
DutchGh0st: That would be worth reporting. Try `-L .` as a workaround
<fengb>
-L is for linking. It shouldn't solve missing headers
<DutchGh0st>
still not found
<fengb>
I must be tripping some LLVM optimizer. Changing `ref_node.next orelse return null` to `ref_node.next.?` is adding 901 bytes that I can't explain
<fengb>
The core logic doesn't have nulls, but handling them differently has wildly different impacts
<DutchGh0st>
AHHA
<DutchGh0st>
I know what went wrong
<DutchGh0st>
I just a definition that wasnt defined in the cImport thing
<DutchGh0st>
somehow that segf's the compiler
<fengb>
Compiler segfault is never solely user error :P
<samtebbs>
It shouldn't ever be user error tbh :p
<samtebbs>
fengb: Doesn't `orelse` unwrap an optional? In that case just using `ref_node.next` will have the same effect as `ref_node.next orelse null`
<FireFox317>
Yardanico: It probably has something to do with the fact that you use the `if(true)`
<Yardanico>
FireFox317: not really, I can post the original 150 line file and it still crashes
<Yardanico>
although I don't have any "if(true)" there
<FireFox317>
Ah okay, let me try to make this reduction smaller
<FireFox317>
You are on master right?
<Yardanico>
if you make it "if(false)" the code will compile because Zig will not even look into that if branch because it knows that it won't be ever executed
<Yardanico>
FireFox317: yes, I downloaded binary for the latest commit
laaron has quit [Remote host closed the connection]
<Yardanico>
samtebbs: so should I report an issue to github or you will do it?
<samtebbs>
Yardanico: go ahead and report with the even more reduced case :) We could reduce it even more fengb spotted the issue but this is a good starting point
<samtebbs>
Remember to include the fact that the error union is negated in the title
laaron has joined #zig
<samtebbs>
Yardanico: Actually we should check if it's been reported first
<FireFox317>
Yardanico: I found it
<fengb>
Might have to do with the lazy refactor
<samtebbs>
Yardanico: doesn't look like it has been reported
<FireFox317>
there is a minus sign before self.parse_factor() on line 25
<fengb>
5 mins late ;)
<Yardanico>
ah well, it seems that I can't call the function which has a error union as a return type recursively
halosghost has joined #zig
<Yardanico>
that's a bit sad :P
<Yardanico>
"/home/dian/projects/zigtest/hello.zig:76:20: error: cannot resolve inferred error set '@typeOf(Parser.parse_factor).ReturnType.ErrorSet': function 'Parser.parse_factor' not fully analyzed yet"
<Yardanico>
but not too bad, I can change a bit of code to workaround this
<fengb>
You need to explicitly define the error set
<FireFox317>
Yardanico: Is there a reason you put a minus sign there or was it a typo?
<FireFox317>
Oh to negate that lol
<Yardanico>
FireFox317: well, kind of. In my original math expression evaluating lib it was used for handling unary + and -, but now that I think about it, I can probably parse them without recursion
<gonz_>
But the purpose was always `return -(try self.parse_factor());`, then?
<Yardanico>
yeah, I'm just new to Zig so I forgot to add that here :D
<gonz_>
Did I understand correctly that this segfaults the compiler?
<Yardanico>
basically the compiler reaches the part it shouldn't ever reach
<FireFox317>
Yardanico: I got it down to 4 lines xd
<Yardanico>
FireFox317: lol
<FireFox317>
Nvm, i got the same
<FireFox317>
But without main xd
<FireFox317>
Or i mean, one function less, but this is a good report anyway, thanks for reporting
<fengb>
I found it! By making the function longer, it convinced LLVM not to inline
DutchGh0st has quit [Ping timeout: 268 seconds]
<FireFox317>
Is it only possible to negate integers?
<samtebbs>
Yardanico: Thanks. This should actually be a contributor friendly issue
<samtebbs>
From first glance at least
<samtebbs>
fengb: Ah that makes sense :D
<samtebbs>
fengb: Are you working on something size-sensitive?
<fengb>
Yeah, zee_alloc aims to be as small as possible
<samtebbs>
fengb: Weird that release-small was causing a size increase like that
<samtebbs>
How small have you gotten it to be so far?
<fengb>
Rust's tiny allocator (wee_alloc) is under 1kb. I'm barely squeeking 1.6
<fengb>
The compiler is setting -Os. I wonder if doing -Oz would be better
mahmudov has quit [Remote host closed the connection]
kristoff_it has joined #zig
<samtebbs>
fengb: What does Oz do?
<fengb>
Smaller than -Os, but it didn't do anything in this case
<andrewrk>
fengb, I'm happy to see at least 1 project using "small" as the release mode
<samtebbs>
fengb: You should write a microcontroller demo at some point
<fengb>
Eh?
<fengb>
I don't know anything about microcontrollers >_>
<samtebbs>
Well microcontrollers tend to want compact code, so it would be a good demo use case for the allocator
<andrewrk>
I believe the use case in question is web assembly
<fengb>
I suppose microcontrollers isn't out of the picture, but it hasn't been my focus. And I don't know anything about them
<fengb>
And also... this allocator doesn't try to use compact blocks so it might not be the best for limited heap
<samtebbs>
Oh I see
<samtebbs>
wasm is a cool use case
<fengb>
Memory is cheap. Codesize is expensive. Such is the web :P
<Tetralux>
What's the max amount of memory you can alloc on wasm?
<andrewrk>
however much the user allows you
<fengb>
Browser dependent
<fengb>
Technically limited by 4GB due to 32bit addressing
<mq32>
samtebbs, i did want to make a demo with zig, but i was too lazy to fixup the compiler to be able to :D
halosghost has quit [Ping timeout: 245 seconds]
<mq32>
maybe Snektron did fix the arm cortex m3 stack pointer thingy in his arm cleanup
<andrewrk>
mq32, what's your blocking issue?
TheLemonMan has joined #zig
halosghost has joined #zig
<Tetralux>
How does the user specify how much to allow it?
<Tetralux>
Like, a browser setting that you have to dig for to adjust?
<andrewrk>
Yardanico, thanks for the bug report
<samtebbs>
mq32: Nice :) Let me know when you have one, I love a nice microcontroller demo
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
<Yardanico>
about microcontrollers: it seems there was some work by Espressif to make a LLVM backend for their chips (ESP32 and ESP8266), however it seems it's not yet done
<samtebbs>
Hey andrewrk, I've been thinking about what it must be like to work on your own project full-time, would you be interested in doing "a day in the life" or similar during one of your streams/in a blog post?
<andrewrk>
possibly. what does that entail?
kristoff_it has quit [Ping timeout: 244 seconds]
<samtebbs>
perhaps your routine, how you allocate your attention, what you think can be improved
<lucus16>
I tried passing --library c which eliminates the note about libc but it still won't find termios
<andrewrk>
lucus16, you don't need nix-shell -p glibc
<lucus16>
sure, but what do I need?
<andrewrk>
you're trying to link against termios, which depends on libc. so you do need --library c. you also need --library termios or whatever c library that is
<andrewrk>
you probably also need to include termios in your nix shell invocation to make the c library available
<lucus16>
hmm, I thought termios was part of libc
<andrewrk>
oh, look at that, it is. I hadn't seen that before
<Yardanico>
By the way, how do I use exported symbols from .so and .dll in Zig?
<Yardanico>
if I know declarations of functions in these libs, that is
<Tetralux>
andrewrk: You know how we have `zig init-exe`? - well - what do you reckon to being able to do `zig init-exe --library c` generating a build.zig that has `b.linkSystemLibrary("c")`, for example
<lucus16>
Or the generated build.zig could include a bunch of comments that show how to do various basic things, similar to how haskell cabal files are generated with a bunch of comments
<FireFox317>
Yardanico: I added a PR for #3179
<lucus16>
Anyway, thanks a lot!
<Tetralux>
lucus16: That's also not an unreasonable idea.
<Tetralux>
Does it literally just copy the files in std/special/init-exe into the cwd?
<andrewrk>
yes
<andrewrk>
I don't think making them configurable with command line switches is worth the developer time, user's time to learn the interface, or the bytes in the binary of the compiler
<FireFox317>
I just saw i made a tiny formatting error, will amend that quickly
<andrewrk>
FireFox317, would you mind changing the message to: "negation of type '%s'" ?
<Tetralux>
RE: user time to learn the interface; already do that with build-exe; I could argue that it just makes intuitive sense for the flags to be transferrable.
<FireFox317>
andrewrk: Will do that!
<Tetralux>
Like, maybe your program started out by being a single file because it had limited scope, or you're just learning and didn't think you'd use build.zig to start, or whatever the case - maybe you just make new projects often--
<Tetralux>
So being able to just change "build-exe" to "init-exe" and generate a build.zig - that seems cool to me.
<FireFox317>
andrewrk: Updated!
<andrewrk>
FireFox317, thanks! approved, will merge in a couple hours when the tests pass
<TheLemonMan>
andrewrk, want me to add some checks to @inlineCall or are you going to do that yourself?
<andrewrk>
TheLemonMan, go for it, I wasn't planning on working on that anytime soon
<Yardanico>
I asked that before but it seems the message went unnoticed, so can I use symbols from .dll or .so files directly from Zig without having to write .c files? So I'll write function headers in Zig as well
<andrewrk>
Yardanico, same as C, you can use the .h files or you can write extern function prototypes
<andrewrk>
TheLemonMan, these bug fix PRs are coming at a most welcome time, it's release month
<TheLemonMan>
0.5.0 is gonna be packed with new features heh
<Yardanico>
currently it doesn't have anything other than lexer/parser diagnostics, but even with that it's useful
<andrewrk>
neat
<TheLemonMan>
r7
<TheLemonMan>
that's the stack pointer for Thumb
Akuli has joined #zig
<TheLemonMan>
eh scrap that, I've misread stack as frame
<TheLemonMan>
I guess the llvm assembler will merrily accept "sp"
<andrewrk>
TheLemonMan, target.cpp, function arch_stack_pointer_register_name
<andrewrk>
should be able to test it by cross compiling for the target and using @newStackCall
<Yardanico>
hmm, pretty strange, std.DynLib module doesn't seem to work on a .so I'm trying to use (well, to be precise, this .so library is writte in Pascal and AFAIK it's compiled by fpc)
<Yardanico>
however I can see the exported symbol with other tools like `nm -gl liblibrouter.so`
<mq32>
andrewrk, yeah that was the problem where i got stuck
<andrewrk>
Yardanico, std.DynLib is not ready for general use yet. Are you sure you're trying to runtime-load a dynamic library rather than simply dynamic link against it?
<mq32>
probably i don't need @newStackCall at all in the final version, but for now it is required
<Yardanico>
andrewrk: oh, I thought I need DynLib for runtime-loading a dynamic library, sorry, I just really didn't find any examples without DynLib
<andrewrk>
mq32, oh, that should be a real quick fix. I'm pretty sure TheLemonMan is right, it's sp
<mq32>
cool!
<Yardanico>
this library is closed-source so I only have a .so file for it :)
<mq32>
i don't have a self-built zig version (don't want to have another project i'm working on ^^)
<mq32>
but eagerly waiting for that to be fixed
<andrewrk>
Yardanico, you can still dynamic link against it. are you using build.zig or CLI?
<Yardanico>
andrewrk: CLI, I didn't try build.zig yet
<andrewrk>
mq32, pushed to master. a download should be available in a couple hours
<mq32>
♥
<andrewrk>
I wish I knew you were blocking on that earlier :)
<mq32>
no thing, i have a lot of open projects i can work on
<mq32>
but yeah, a microcontroller demo sounds like a cool thing to demo :)
<mq32>
i'd go for plasma effect on LCD + some serial stuff
<mq32>
i only have to cross-port that from C++
<andrewrk>
you can also implement @newStackCall with inline assembly
<marler8997_1>
anybody every seen this error? Unable to hash /home/marler8997/git/zig/build/lib/zig/libc/musl/src/signal/sigaddset.c: file system error
<TheLemonMan>
yeah, you need to raise the number of available fds
<marler8997_1>
trying to cross-compile hello.c to aarch64-linux-musl
<TheLemonMan>
ulimit -n 4000 worksforme™
<marler8997_1>
ok will try
<marler8997_1>
if this fixes it, would this warrant an issue? not sure how or if zig could handle this though
<TheLemonMan>
ehh, that's a known issue that stems from how the caching system works, there's a ticket with more details on gh
<marler8997_1>
it did fix it
kristoff_it has quit [Ping timeout: 245 seconds]
<marler8997_1>
crazy that I can download a 40 MB archive, extract it and cross-compile C code to so many different platforms
<Tetralux>
> ehh, that's a known issue: Is it because the caching system keeps all files open or something?
<Tetralux>
marler8997_1: Also yeah - that is a pretty neat thing about Zig
<mq32>
marler8997_1: i think it's saddening
<mq32>
not that zig is doing it
<mq32>
but that nobody else seems to care about size anymore
<marler8997_1>
size and dependencies
<Tetralux>
I have long-since wanted to find a compression algorithm that is faster than gzip.
<Tetralux>
The cache artifacts gets garbage collected? xD
<marler8997_1>
It sounds like he keeps the file descriptors open in order to lock them, probably to keep another external program from deleting them?
<Snektron>
mq32: if you want a build from master, just say so
<Snektron>
it takes about 30 seconds for me to build that from scratch
<andrewrk>
TheLemonMan, marler8997, ah yeah, bnoordhuis suggested something that can fix that, and I didn't understand it at first but now I do
<andrewrk>
let me see if I can find it
<mq32>
Snektron: i don't have the hardware with me right now, would have to wait until tomorrow anyways
<andrewrk>
the caching system does keep all the files open, but that's intentional. because those open files are locks, which prevent the reaper from deleting them while an ongoing compilation is in progress
<Yardanico>
with --library and --library-path I get "Segmentation fault at address 0x0" at runtime (if I don't specify the lib it fails to find the symbol, so at least it find the symbol, but executing a function fails for some reason), IDK if that's Zig's or lib's fault
<Tetralux>
I guess I'm not clear on what the reaper is here.
<andrewrk>
Tetralux, it doesn't exist yet :) but it's planned that zig will keep cache directories to a maximum (configurable) number of bytes
<andrewrk>
Yardanico, you also need to link libc
<Yardanico>
andrewrk: oh
<andrewrk>
probably
<Tetralux>
Stupid question, but why not just run the reaper once the linker returns, and then you don't have to even care what gets evicted, because nothing will be using it.
<andrewrk>
Tetralux, because there can be another process on the system running
<Yardanico>
andrewrk: yeah you're absolutely right, Zig now correctly calls a function from the lib, thanks for answering my questions :)
<andrewrk>
Yardanico, libc isn't automatically pulled in, because it's not *technically* required. but usually is by a third party library
<Tetralux>
andrewrk: Ahhh.
<Tetralux>
Hmmm.
<Tetralux>
I mena
<andrewrk>
you can race 2 zigs against each other and they will not clobber
<Tetralux>
Surely you just could just have one lock file?
<Tetralux>
zig-cache/cache.lock
<andrewrk>
sounds like you're working on a comprehensive proposal to fix 2280. I look forward to reading it :)
<Tetralux>
I mean, rather than everyone suffering from this problem, it could be remeded by implementing what I just said as a stop-gap - since it would prevent more than one compilation from occurring at a time.
<andrewrk>
if your suggestion contains the word "just" in it, then just go implement it real quick with tests, it should be easy
shritesh has joined #zig
* Tetralux
grins
<andrewrk>
well, that's not optimal, is it?
<Tetralux>
I long learned that writing the most optimal thing the first time is a bad strategy for getting stuff done.
<Tetralux>
To this day, I still overthink my first iteration of anything.
<companion_cube>
oh, a zig lsp server :o
<Tetralux>
You wanna write the most stupid, make-this-thing-work thing, and know you'll improve it over time, as you get a better idea of what you even need it to exactly do.
<Tetralux>
#PreachingToTheChoir.
<TheLemonMan>
perfect is the enemy of good
<Tetralux>
TheLemonMan: Indeed.
<andrewrk>
zen of zig says, that's fine as long as the peak of your good mountain is perfection. otherwise you're climbing the wrong mountain
<Tetralux>
.. which assumes you even know what the best mountain is.
<fengb>
Belated: I was really disappointed when Rust didn’t include any cross compilation out of the box. Zig has spoiled me
<andrewrk>
Tetralux, no, it only suggests abandoning mountains that have been identified as not having a peak of perfection
<Tetralux>
Indeed - but for that, you must have attempted to climb the bad mountain. :3
<gonz_>
fengb: Doesn't it? I've never tried it, but I assumed at least x64 on the 3 main platforms was provided out of the box.
<Tetralux>
Or, more importantly, maybe the best mountain takes years to climb.
<Snektron>
Theres cross compiling with rust
<Tetralux>
The bad one, which also occomplishes the task, takes 30 seconds by comparison.
<Tetralux>
Stop-gap means stop-gap, right.
<Snektron>
hang on, i've used that before for arm stuff
<Tetralux>
Maybe we're kinda talking at cross-purposes a little - I imagine you know this already. xD
<andrewrk>
mq32, assuming you're using --single-threaded, zig's async/await on microcontrollers has no more overhead than functions, when compiled in release modes
<mq32>
but it will provide functional suspends, right?
<mq32>
also i forgot how to add libc with build-exe :D
<andrewrk>
marler8997_1, I tested & pushed b564e7ca59818e4 which resolves the file descriptor limit problem (in most environments) when building musl
<andrewrk>
mq32, --library c
<marler8997_1>
oh...
<mq32>
thx
<marler8997_1>
I will try
FireFox317 has quit [Ping timeout: 258 seconds]
<andrewrk>
mq32, also... been meaning to do this for a long time - I just added -l as an alias for --library
<andrewrk>
-lc
<mq32>
i think it would also be helpful if the "requires libc" error message just tells you how to link libc
<fengb>
How about an alias `-lib` so you can type `-libc` :P
<waleee-cl>
a bit weird mixing of gnu-long-style options and bsd-style single-letters
<mq32>
just support microsoft style as well!
<mq32>
/lib:c
Ichorio has joined #zig
<mq32>
*grin*
<andrewrk>
it's for compatibility with c compilers. Often environments have $CFLAGS or something, and you can generally put that on the same line as `zig build-exe` and it will give the paths to libraries and such
<mq32>
andrewrk, i finally published a small zig project of mine :)
FireFox317 has quit [Remote host closed the connection]
<Sahnvour>
andrewrk: yeah I'm debugging it for #2861 and suspect it does not work
<Sahnvour>
was wondering if someone actually used it at comptime for stuff
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<mq32>
mahmudov: :)
ky0ko has joined #zig
<andrewrk>
Sahnvour, I haven't tested it in a while, but in theory if you configure with -DZIG_TEST_COVERAGE and then build and then run the behavior tests, you can then use gcov to look at an html output of all the lines of stage1 code and see what is covered
<andrewrk>
Sahnvour, uh, that's probably easier in a posix environment
<Sahnvour>
guess so :p I will just post a comment with my findings for now
<halosghost>
andrewrk: oh, that's awesome, I didn't realize you could use literal unicode in identifiers with @""
<halosghost>
andrewrk: very cool
<andrewrk>
you can also put invalid unicode in identifiers. it's just bytes
<halosghost>
heh
<halosghost>
interesting, so that means you could have identifiers with spaces in them
<halosghost>
I sense an opportunity for quasiquotes and arbitrary mixfix :P
<mahmudov>
i am using 64 bit linux distro in qemu vm
utzig has quit [Ping timeout: 258 seconds]
Ichorio has quit [Ping timeout: 264 seconds]
utzig has joined #zig
<Yardanico>
mahmudov: change CPU model in qemu settings so it would report a different CPU model
<Yardanico>
By the way, is there a way to use the same string type for both handling literals and input? For now my parser uses []u8 which works fine for user input (e.g. from io.readLine), but doesn't work for string literals
<fengb>
Literals are probably []const u8
<fengb>
[]u8 autocasts to []const u8, but not vice versa
<fengb>
So if you don't need to mutate, you should just use []const u8 everywhere by default
<Yardanico>
ah nvm, you're right, I guess I should use []const u8 everywhere
<Yardanico>
yeah it works, thanks a lot
<Yardanico>
yeah I don't mutate my string, only read characters from it
<andrewrk>
mikdusan, no, there was one - it might have been on one of his own projects - where he experimented with string hashing for like a week and then had a sort of "conclusions" post
<mikdusan>
oh ok i think i remember that one
so has joined #zig
<Yardanico>
Basically I'm trying to rewrite a simple recursive math expression evaluator to Zig (the original one is in Nim and I also wrote a V version a few days ago) - https://i.imgur.com/0BhXwds.png
<Yardanico>
Well, it's understandable that Zig is a bit more restrictive since it counts on readability and has manual memory management
<mikdusan>
Yardanico: after you rewrite for zig, i'd be interested in your impressions/cojmparison about friction from each of the languages
<Yardanico>
mikdusan: honestly I'm not that good of a programmer, I mostly write some small projects for myself
<andrewrk>
Yardanico, you don't need {} in switch prongs
<andrewrk>
"pi" => math.pi,
<Yardanico>
mikdusan: well, Zig of course feels very different from Nim, because one of the main points of Nim is powerful macros (operating on AST like in lisp), proper templates and a lot of other stuff to allow to create DSLs, and Zig tries to be straightforward (so you can read the code faster if you're unfamilar with it)
<andrewrk>
you can also do result = switch
<Yardanico>
and V language is very new and a little bit too "hyped", it doesn't have a half of promised features yet, their compiler doesn't even use AST yet, but somehow they say they will get 1.0 by December 2019
<andrewrk>
I'm honestly surprised that switching on strings works in v
<companion_cube>
:DDDDD
<fengb>
I'm surprised anything works in v >_>
<Yardanico>
V has a half-working small compiler and has 11k stars on GitHub (anothere example why stars on github don't represent anything other than "hype" or maybe, maaybe "popularity")
<andrewrk>
switching on []const u8 is the same problem as what we just dealt with in regards to std.AutoHashMap
<mikdusan>
Yardanico: how would you compare development time in Nim vs. Zig ?
<andrewrk>
you can be honest, we won't get mad
<fengb>
I dream of a day when npm modules bundle wasm instead of depending on gyp
<andrewrk>
fengb, yes!
<andrewrk>
fengb, and zig can even participate in this, with status quo
<companion_cube>
I dream of a day where electron apps, even if they still exist, use mostly wasm
<Yardanico>
mikdusan: well, probably you can write code faster in Nim, since it's older, has a bigger community (around 2k gtihub repos, not a lot comparing to JS or C, but bigger than some other languages), and has a pretty big stdlib which covers quite a lot of stuff. But it's also slower than Zig (well, I don't know how much slower), and has a GC, so writing low-level stuff is harder in Nim since most of stdlib doesn't work without a GC
<fengb>
wasm doesn't interopt with UI very well. People use Electron to avoid yet another gui
<companion_cube>
well wasm as it exists right now is only the MVP
<companion_cube>
I'd be curious to hear about D vs zig, actually
<companion_cube>
since D has @nogc these days
<Yardanico>
but honestly I think myself that I should learn a more "proper" language with manual memory management and pointers (well they exist in Nim as well, but auto-dereferencing works almost always) to better understand computers and be able to write very fast software :D so I decided to find a new language
<andrewrk>
rust would be another good choice
<mikdusan>
Yardanico: is the math expression evaluator something that will be a tool to standalone or integrate with something else? or just a general programming project?
<Yardanico>
yeah, I thought about it, but it's syntax scares me a bit (it's really verbose). Didn't really try it though
shritesh has joined #zig
<Yardanico>
mikdusan: just a small programming project of mine, I didn't really do programming much in the past year , but I want to start writing more libs/stuff again, you can see my projects at https://github.com/Yardanico/ (spoiler: almost all of them are in Nim)
shritesh has quit [Quit: Leaving...]
<mq32>
oh wow
<mq32>
i just read through the language page of V and that sounds ambitious for a single guy
<companion_cube>
ahahaha
<companion_cube>
also read twitter shitstorms, and issues on v's repo
<Yardanico>
however I talked with another guy which also did some work on V and he said that they will probably only add proper AST parsing to the compiler after 1.0
<Yardanico>
I think that V right now is almost just a syntax skin for C :D
<marler8997_1>
will hasField be deprecated since you can get the same info from TypeInfo?
<andrewrk>
TypeInfo isn't lazy enough for that to work yet
<andrewrk>
it's also O(1) vs O(N), and even though that's at compile-time, compilation time matters
* scientes
thinks compilation time should be O(N^3) :)
<mq32>
Yardanico, yeah the front page just feels like "look how awesome V is! (oh and we can only compile natively for MAC, though)"
<mikdusan>
scientes: so like usually less than N ? impressive. ;)
<scientes>
mikdusan, compilation time can't get better than N
<scientes>
because you have to parse the code
<mikdusan>
bitwise xor
<Yardanico>
mq32: well V works on Linux/win/macOS, it's just that you can't cross-compile to macos
<mq32>
just xor the code with 0x23 and write that into the binary!
<mq32>
Yardanico, yeah maybe :D i have just read the vlang.io page
<scientes>
mikdusan, bitwise xor is O(N)
<mikdusan>
scientes: it was a joke. (N ^ 3)
<scientes>
mikdusan, ahhhhhhhhhhhhhhhh
ltriant has joined #zig
<mq32>
andrewrk, have you planned to remove the llvm dependency from zig in the future?
<scientes>
mq32, do you know what that would entail?
<mq32>
yes.
<mq32>
that's why i'm asking
<scientes>
I think the plan is to add other backends
<mikdusan>
that'll be interesting. if using a different backend, will zig still get target ABI information from LLVM API, or will that also be tabled'd out?
<shachaf>
Is stack layout done by LLVM in the normal case and by the Zig compiler in the async case?
<shachaf>
I mean frame layout.
<shachaf>
I guess that's not really ABI in the former case anyway (and maybe not the latter case either).
komu has quit [Remote host closed the connection]
<andrewrk>
shachaf, yes, that's how it works
<andrewrk>
and tbh it would be nice if we could do the stack layout too, because we want to know the stack size of functions, and don't have access to it currently
<shachaf>
Right, I was wondering what the plan was for that.
<shachaf>
If there are no cycles you can maybe have LLVM compile one function at a time? I don't know what the interface is.
<shachaf>
But doing stack layout presumably means doing register allocation and a bunch of other things yourself.
<andrewrk>
I have some ideas of things to try
<andrewrk>
even if we don't have access to the information until after an object file is generated, references to the size as an extern variable and then another .o file can be created which contains the needed stack sizes
<shachaf>
Hmm, would that allow comptime if on the stack size?
<andrewrk>
certain things would work but if you tried to inspect the actual integer value, it would be a compile error, the value isn't available yet
<shachaf>
Maybe that's not such an important use, but I always thought of it as a comptime value.
<andrewrk>
comptime if on that value is inherently problematic because it's highly likely to introduce a dependency loop
<shachaf>
Only if there are cycles, right?
<andrewrk>
something as simple as an expression inside the if would introduce a cycle
<shachaf>
I guess without comptime if, there's guaranteed to be a fixed point, because stack usage is monotonic or something.
<andrewrk>
the main use case is for creating a thread
<andrewrk>
and for giving the stack size value to the linker
<shachaf>
OK, for things like that it doesn't matter so much.
<andrewrk>
here we would like to use @stackSize(startFn) instead of hard coding 8 MiB
<andrewrk>
here there are no cycles because the stack of std.Thread.spawn() is independent from the new thread's startFn
<andrewrk>
but still, trying to access the numerical value is problematic because it will change after running llvm optimizations
<andrewrk>
and ideally, if we get this working, it will take into account optimizations
<shachaf>
Right. If there are no cycles and you compile functions in topological order, it could be OK, but maybe you want comptime execution to happen before optimizations.
<shachaf>
I suspect this isn't actually that important.
<andrewrk>
I have the same suspicion. I think the important part is threads & main stack size in ELF/PE file
<andrewrk>
consider, one of the main arguments people give for goroutines is that they have segmented stacks, e.g. you can spawn more of them in parallel without running out of memory
<andrewrk>
but if we correctly solve stack size for threads, you could just spawn as many *actual kernel threads* with the same memory cost, and without the downsides of segmented stacks
<shachaf>
I thought the big argument was really cheap context switches.
<shachaf>
(And doing your own scheduling and so on, which can be more efficient.)
<andrewrk>
is that so? I don't have a clear enough memory about it
<andrewrk>
anyway for that use case we have std.event.Loop anyway
<shachaf>
This is an argument for coroutines/userspace threads in C, not Go, admittedly.
<shachaf>
Also I think Go doesn't use segmented stacks anymore? They grow the stacks instead. I guess the same arguments apply, though.
<andrewrk>
I believe that's the same thing. You start with 1 stack segment, and if it needs to grow, you add another segment
<shachaf>
Well, they realloc the stacks and rewrite the pointers to point to the new memory, I think.
<andrewrk>
ah interesting. yeah I think the same arguments apply
<shachaf>
I think async functions are probably ultimately better than userspace threading in most respects.
<andrewrk>
I'm excited about this proof-of-concept I'm working towards. We really are going to have the ability to express concurrency without having to put "async" in front of every function
<shachaf>
I still have that video open in a tab. I should watch it.
<andrewrk>
I'm planning on doing a late live stream tonight. I want to get one more thing working first
<andrewrk>
I also need to cook dinner for my gf
<shachaf>
But it seems like this is pretty clearly better than using a "regular" stack which is sized to the right size, and doing stack switching.
<andrewrk>
if you watch that video, there's a great question someone asked and I tried to answer it with a fibonacii example, and it crashed the compiler. I have that example working now
<shachaf>
Is the way @Frame layout works documented anywhere?
<shachaf>
Or just are there examples, I guess.
<shachaf>
Does it generate an explicit struct or just an opaque memory buffer of a certain size?
<andrewrk>
it has stuff at the beginning that is common to all async functions, then it has return type, args, error return trace info, local variables
<shachaf>
So it just has a struct with a field for every local variable right now.
<shachaf>
Presumably local variables that are never live at the same time could share memory, like with stack layout.
<andrewrk>
yes however that requires escape analysis. one is guaranteed that pointers to local variables of async functions live until the async function returns
<andrewrk>
oh I think you're talking about a different issue, which I have one open for
<shachaf>
It seems to me like it's more or less the same problem as stack layout, which is why sharing code would be nice.
<shachaf>
Right, that's what I mean.
<shachaf>
I should probably watch the video before asking all these questions. :-)
<andrewrk>
eh, video is not the best way to learn information, I don't blame you
<shachaf>
At one point I'd be curious to see a comparison of async functions and C-style stack switching coroutines. I don't have a good feel for how much more efficient the former is.
<shachaf>
I guess I should write some kind of asynchronous server in Zig and see how it goes.
<shachaf>
Maybe something to try out io_uring too.
<andrewrk>
if you tried that today you'd probably run into the very same issues that I'm in the middle of solving
<andrewrk>
but I think I'm close to a proof of concept