<kameliya[m]>
haha! yeah, nice :) i had a similar feeling when i started using zig in earnest ~9 months ago. i've just been having a super good time since then; really feels like what i was missing when i wanted to do low-level stuff but without the clunky feeling rust picked up.
<vent>
I was very happy to see there's an svd2zig, I tried it out on an SVD file for my stm32h7. Once I've picked up some speed, I think Zig would be great for some bare-metal coding.
<vent>
Only thing I haven't quite worked out is how Zig's runtime safety checks would work on a target like that.
<ifreund>
you'd define your own panic handler to do whatever you want
<kameliya[m]>
yeah! i've been using zig on baremetal aarch64 and riscv64 and handling the panics oneself is quite clean.
<vent>
Ah nice. I suppose I'd probably just send it's output over a serialport, or the ITM that's on the target's ST-LINK. Very nice.
<kameliya[m]>
yep! and then maybe trigger a reset or whatever
<kameliya[m]>
you can see here how the stdlib lets you override panic by defining one in your root compilation unit
<kameliya[m]>
it just checks if your root module has a public `panic` decl, and if it does, that becomes the panic handler for the whole, otherwise the builtin one is used
<vent>
Ah thanks!
ennui has joined #zig
<vent>
And one thing I'm very excited is the convention of passing in an allocator to anything that needs dynamic memory. That lets you use pretty much anything on a heapless target, since you could just pass in a `std.heap.FixedBufferAllocator`.
<vent>
Which is an idea so good I'm surprised I haven't heard of it before.
<kameliya[m]>
right! it's also super nice because it means you can decide to restrict memory use by a component whenever you want, by passing it a more restrictive allocator.
<kameliya[m]>
the design encourages people to handle out of memory properly.
ur5us has joined #zig
<vent>
We do a fair amount of bare-metal stuff at my work, I may try to get the company using it instead of C once it's got a 1.0 release. Although that'll be hard for a safety-critical product without a MISRA cert and all that other bureaucratic nonsense.
<kameliya[m]>
ah, yes. even by 1.0 (might be some years), I would still be reading the assembly output pretty carefully if it was safety-critical!
<vent>
Yeah, and safety-critical stuff is always a decade or two behind the bleeding edge, so it'll be some time. Eventually they'll come to their senses of moving away from C in favour of something with builtin safety checks though.
<vent>
Hopefully in my lifetime at least.
<kameliya[m]>
hah, yes
<kameliya[m]>
fingers crossed
<ennui>
just started with zig, feel a bit disappointed. the following snippet takes ~0.6 s to run on a modern NixOs desktop:
<ennui>
{ echo "// $(date)"; echo 'pub fn main() void {}';} > basic.zig && time zig run ./basic.zig
<ennui>
a C equivalent might take a tenth of that time. is this normal?
<kameliya[m]>
my work is currently rails and typescript, so no zig here, yet ..!
<ennui>
<kameliya[m]>
ennui: that's including compiling with llvm .. do you mean to include that time?
<ennui>
yes, i mean the compile times
<ennui>
time
<kameliya[m]>
yes, it's not a super optimised compiler yet
<g-w1>
thats going to be fixed soon with the new stage2 compiler. the one written in c++ is pretty slow but thats going to change soon!
<ennui>
kameliya, g-w1: great to hear that, thank you!
<g-w1>
stage2 is written in zig and is being hevealy developed
<ennui>
perfect, i'm really exited about how where this is going.
<vent>
I noticed that Zig's language is designed so that each line can be symboled without context, hence the lack of multiline comments like C and the somewhat weird syntax for multiline strings. I think that's pretty clever.
<kameliya[m]>
sometimes I get annoyed when I have to do a lot of casts with ints, but then i remember what it took to find this bug.
<kameliya[m]>
vent: right! as far as i'm aware there's a lot of focus on why the lexing and parsing are the way they are. i'm not too across the details.
<vent>
Ah yeah! We've all experienced bugs like that. Yeah, this is why I like my type systems really, _really_ strict.
<kameliya[m]>
yeah :)
<vent>
Oh! One thing that blew my mind is arbitrary-width integers. How the hell does Zig get away with that? The fact you can do stuff like this make me very happy: http://ix.io/2SoZ
ceberly has joined #zig
<kameliya[m]>
i suspect LLVM gives us a big hand there, but fair warning: packed structs are currently weirdly broken on some edges.
<kameliya[m]>
the going advice is to assert the `@sizeOf` and/or `@bitSizeOf` the struct is what you expect
<kameliya[m]>
because sometimes you'll put 64 bits in a packed struct but then you check and zig proudly tells you there's 65 bits and it's 9 bytes wide
<g-w1>
at comptime!
<kameliya[m]>
yes! not at runtime
<vent>
Ah, thanks for the advice. Would that be using `std.debug.assert`? It would execute at compile time if you're passing @sizeOf and a comptime_int right?
<vent>
Something like this?: comptime std.debug.assert(@sizeOf(Float) == 4);
<kameliya[m]>
yep, that'll do. or `comptime { std.debug.assert(...); }` at the top level
<vent>
Yep, just tried asserting it's 3 bytes, and the build failed. Fantastic.
<kameliya[m]>
hah >.< oof
<kameliya[m]>
yeah. for the moment, i'm hacking around it with bit shifts and masks. it sucks, but we'll get there soon enough.
<vent>
I think I may keep going with the packed struct approach because I love it so much, and just make sure to assert the size. They'll only get more stable over time.
<kameliya[m]>
yes. you can also do comptime magic to select what works depending on the compiler!
<kameliya[m]>
here i'm checking whether the elf_header has the "machine" field and using it if so. once that PR gets merged, it'll start working generally, until then it falls back to an empty string.
ceberly has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ceberly has joined #zig
<vent>
See I love the way reflection is so easy like that. And it's all checked at comptime, so it's all good! I've not seen generic code this readable before.
<kameliya[m]>
right? it lets you do some really interesting stuff, in a way that feels very flexible and not.. hacky? it makes sense, you can think about it cleanly.
<vent>
Well you can understand what's going on by just walking through the code. The idea feels like it _should_ be hacky, but the results really aren't.
<kameliya[m]>
sometimes i can't even dereference a pointer because the MMU is broken
<kameliya[m]>
but i still want some debug output
<kameliya[m]>
this unrolls the entire `[]const u8` message into the code, so it doesn't try to read from anywhere
<vent>
Ohh, that's cool. I was wondering why the `msg` was comptime.
ceberly has quit [Client Quit]
<kameliya[m]>
vent: right, yeah! at some stage it starts to feel less hacky and you feel like the compiler is very flexible.
<kameliya[m]>
yeah, it's just for that exact purpose
<kameliya[m]>
`carefullyAt` above it lets you freely intermix comptime-known strings and integers
<kameliya[m]>
and unrolls all of it
<g-w1>
it will feel less magic once there are 0 compiler bugs too. it will fee like this is how it meant to be
<vent>
To me it makes me feel like working with the type system at a much more granular level.
<kameliya[m]>
yes, definitely
ceberly has joined #zig
<vent>
Couldn't that `inline while` be something like `inline for (parts_info) |field|`?
<kameliya[m]>
👀 yes, absolutely!
<kameliya[m]>
i had it written one way before
<kameliya[m]>
it'll be `... |info, i|` since i need to use the index, but yeah, nice!
ceberly has quit [Client Quit]
<kameliya[m]>
i should clarify, i'm no expert on this stuff, but i like using it to make nice stuff happen. a lot of what i do can probably be cleaned up
mshockwave has joined #zig
<kameliya[m]>
better now.
<vent>
I'm not sure you even need the index, since you're only using `i` to indext to `parts`.
<kameliya[m]>
i do! i'm iterating parts_info, not parts.
<kameliya[m]>
parts_info is derived from `@TypeOf(parts)`, not `parts` itself.
<vent>
What Zig needs is a really pedantic linter. I think it fit's it's Zen idea of "Only one obvious way to do things"
<kameliya[m]>
so it doesn't have values.
<kameliya[m]>
hmm, maybe!
<vent>
Oh, yeah you're right, my mistake. I forgot `parts_info` and `parts` were different.
<kameliya[m]>
ya. i can only iterate the types at comptime, not the values.
<vent>
Oh wow, I just read the README for that repo. That's really impressive!
<kameliya[m]>
oh, thanks! it's been lots of fun :)
<kameliya[m]>
honestly the best part of it has been the motivation for making fixes to qemu and u-boot.
<kameliya[m]>
it's been good experience
<kameliya[m]>
bbiab, lunch
<vent>
Yeah it looks like a great project. I think I had some issues with u-boot before on an IMX6, where it wasn't booting from emmc when the micro was verifying the key signature of the u-boot image. But it would work fine booting from an SD card. I forget what our solution was.
<vent>
Well I'm off to hit the hay. Great chat :)
Amun_Ra has quit [Ping timeout: 240 seconds]
gpanders_ has joined #zig
gpanders has quit [Ping timeout: 268 seconds]
Amun_Ra has joined #zig
nvmd has quit [Quit: Later nerds.]
wilsonk__ has joined #zig
wilsonk has joined #zig
wilsonk_ has quit [Ping timeout: 260 seconds]
<g-w1>
vent: if you see this, I think the idea is for the linter to be in the compiler. from what ive heard, there will be no warnings, only compile errors.
wilsonk__ has quit [Ping timeout: 245 seconds]
cole-h has quit [Ping timeout: 260 seconds]
brzg has joined #zig
brzg has quit [Quit: leaving]
ennui has quit [Ping timeout: 260 seconds]
leon-p has quit [Quit: leaving]
squeek502 has quit [Remote host closed the connection]
<dyeplexer>
In https://ziglearn.org/chapter-1/ , `var inferred_variable = 5000;` is no longer a legal statement right? I am using 0.8.0-dev and it fails saying that I have to explicitly specify the type.
tomku has quit [Quit: Lost terminal]
tomku has joined #zig
layneson has quit [Ping timeout: 245 seconds]
tomku has quit [Quit: Lost terminal]
<g-w1>
it does not work in a non-comptime scope
<g-w1>
if you do comptime { var inferred_variable = 5000; } it works because this is at comptime so a variable of type comptime_int works!
<dyeplexer>
yes. Was the statement valid before though?
<g-w1>
i dont think
<g-w1>
that should probably be cleared up
<g-w1>
raising an issue on the discord rn
<dyeplexer>
i see
tomku has joined #zig
tomku has quit [Client Quit]
texno has joined #zig
recursive_fault has joined #zig
tomku has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
remby has joined #zig
recursive_fault has quit [Ping timeout: 240 seconds]
tav has joined #zig
wilsonk_ has joined #zig
wilsonk__ has joined #zig
wilsonk has quit [Ping timeout: 256 seconds]
<andrewrk>
g-w1, what's the question?
<andrewrk>
hello dyeplexer
<andrewrk>
zig requires integers to have a known size if you want to put a runtime value in them, so it knows how much memory to use for the variable
wilsonk_ has quit [Ping timeout: 245 seconds]
<dyeplexer>
yes. The example mentioned in https://ziglearn.org/chapter-1/ however does not enclose the inferred runtime variable in a comptime directive, and it doesn't mention anything about it either so I thought it was based on an old version of zig.
<andrewrk>
it looks like it is only intended to demonstrate syntax
<dyeplexer>
even, so, I think it would be better to include a note about this behaviour and link to the later section regarding comptime. a person who tries compiling and trying things as the tutorial progresses would be confused about the behaviour with no asterisks given.
<dyeplexer>
*even so,
<andrewrk>
Sobeston is a friendly chap, you could try bringing it up with him
<andrewrk>
he's the one who runs ziglearn.org
earnestly has quit [Ping timeout: 265 seconds]
knebulae has quit [Read error: Connection reset by peer]
waleee-cl has quit [Quit: Connection closed for inactivity]
<dyeplexer>
hm. The latest revision on git for the chapter now assigns a coerced value to the inferred var, so the snippet is correct now.
<dyeplexer>
I'll still put on an issue for better elaboration I guess
johannes has joined #zig
johannes has quit [Client Quit]
sord937 has joined #zig
osa1 has joined #zig
cole-h has joined #zig
tnorth has joined #zig
decentpenguin has quit [Quit: ZNC crashed or something]
bitmapper has quit [Quit: Connection closed for inactivity]
decentpenguin has joined #zig
remby has quit [Quit: remby]
<protheory8-new-m>
Is there a way to convert `[]const u8` to `[*]const u8`?
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
<daurnimator>
protheory8-new-m: `.ptr`
<protheory8-new-m>
Thanks, this wasn't showing up in auto completion for some reason.
zupss has joined #zig
zupss has quit [Ping timeout: 245 seconds]
zupss has joined #zig
ubert has joined #zig
cole-h has quit [Ping timeout: 246 seconds]
notzmv has quit [Ping timeout: 256 seconds]
SamL has joined #zig
earnestly has joined #zig
txdv has joined #zig
<txdv>
const Self = @This(); why is this needed? Seems like some boilerplate to which everyone does
notzmv has joined #zig
<ifreund>
txdv: it is only needed in generics or other situations where you don't have access to the specific type
<ifreund>
we're moving away from using it where not necessary in the self-hosted compilers codebase
shadeops has quit [Ping timeout: 256 seconds]
sundbp has joined #zig
sundbp has quit [Client Quit]
sundbp has joined #zig
snamber has joined #zig
snamber has quit []
zags has joined #zig
constatinus has joined #zig
<constatinus>
guys how can i create a multidimensional array of strings []const []const u8?
sundbp has quit [Quit: Leaving]
sundbp has joined #zig
<ifreund>
are the contents fixed at comptime or do they change at runtime?
<dutchie>
similarly you can avoid anytype in is_anagram: `fn is_anagram(wa: []const u8, wb: []const u8) bool`
<FrancescoAlem>
modifying the type signature leads to :./anagram.zig:44:43: error: expected type '[]const []const u8', found '[10][]const u8'
<FrancescoAlem>
Thank you dutchie
<constatinus>
can zig read the output of a ChildProcess? the stdin field is a ?File for some reason
<dutchie>
FrancescoAlem: should work if you call it like `find_anagrams(a, "ciao", &words)`
<ikskuh>
FrancescoAlem: as dutchie showed: pointers to arrays coerce to slices, thus "*[10][]const u8" will fit your type and you just have to use "&words"
<ifreund>
constatinus: set stdin_behavior/stdout_behavior
<ifreund>
note that stdin is the input not the output though
<FrancescoAlem>
okay it worked, I get the `defer`/`errdefer` tips, but why is explicit types good style?
<constatinus>
yeah i meant the stdout field, but theyre both the same. i set it to stdout-behaviour to Pipe and when i spawn the process stdout is still null
<dutchie>
FrancescoAlem: it'll give you better error messages and helps document what your functions are doing
<ifreund>
constatinus: you are checking stdin not stdout
<constatinus>
oh god kill me
<constatinus>
thanks idk how that go there
<constatinus>
got*
<ifreund>
no problem, glad it was easy to fix :)
<FrancescoAlem>
dutchie good point! Thanks everyone
snamber has joined #zig
<snamber>
Hey everyone, I am attempting to create a library to connect two different geospatial tools together. Both are C libraries. I think zig would be the perfect fit to achieve this in a more modern / elegant / safe manner.
<snamber>
Now I need to wrap / use these two C libraries, and at least one of them is quite complex.
<snamber>
Is there a way to achieve autocompletions ala zigtools/zls for imported C libraries? Or how do you go about wrapping a more complex C library in zig? Maybe there's a video or resources for that?
<ifreund>
zls doesn't support that yet sadly
<ifreund>
if you want to take the time to write good manual bindings you can get something quite a bit nicer to use than the autogenerated output of @cImport()
<ifreund>
it was a good bit of work, but very worth it for my project in the long term
<snamber>
I can imagine; I'll try it on the smaller of the two libraries first, to learn the approach
<snamber>
Thanks a lot for the link!
<ifreund>
no problem!
<snamber>
changing naked pointers to slices, getting a nice build system, and the benefits of a readable, safe, fast language might be worth it to put in the work
<snamber>
the bet is that in the longer run it would be faster than working in C directly
<ifreund>
I'm definitely more productive in Zig than C at this point
<ifreund>
Even though I've been writing zig for a much shorter time
<snamber>
That's very good to hear; ok I'll watch your talk now, and get to wrapping the small library! Thanks!
knebulae has joined #zig
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
leon-p has joined #zig
<constatinus>
another question, in ChildProcess.stdin, before i spawn a process, stdin is null, how can i create a File in it so that i can input stdin in my ChildProcess and then run (spawn) it?
<ifreund>
constatinus: if you set stdin_behavior to pipe, stdin will be set to the write end of a pipe on spawning the process
SamL has quit [Quit: Ping timeout (120 seconds)]
<constatinus>
its set to pipe, but i didnt spawn it beforehand. Now, in this segment of code https://pastebin.com/jZtBCF9T after the debug print "here" the program just kind of hangs and because im supposed to be inputting into a python script when i control c out of the program i get a KeyboardInterupt, the script still hanging and waiting for input. Have i written to the pipe correctly or do i need to end it
<constatinus>
somehow?
<ifreund>
that dependes on what the process you are spawning expects. You could try closing the pipe after you are done writing
<constatinus>
ah, i got it
<constatinus>
just now
<constatinus>
i did fil.close() after the _ = try ... line
<ifreund>
also you probably want to use file.writer().writeAll()
<ifreund>
a raw write might not write the full beffer
<constatinus>
alright im using writer now
FrancescoAlem has quit [Quit: Connection closed]
SebastianM has joined #zig
constatinus has quit [Quit: WeeChat 3.0.1]
SebastianM has quit [Quit: -a- Bye Bye]
crimson_pingvin has joined #zig
decentpe- has joined #zig
neptunepunk has joined #zig
ceberly has joined #zig
Nilium_ has joined #zig
Ankhers_ has joined #zig
oats_ has joined #zig
neptunepink has quit [Ping timeout: 256 seconds]
crimson_penguin has quit [Ping timeout: 256 seconds]
Nilium has quit [Ping timeout: 256 seconds]
decentpenguin has quit [Ping timeout: 256 seconds]
sjums has quit [Ping timeout: 256 seconds]
Ankhers has quit [Ping timeout: 256 seconds]
Ekho has quit [Ping timeout: 256 seconds]
oats has quit [Ping timeout: 256 seconds]
cow-orker has quit [Ping timeout: 256 seconds]
vent has quit [Ping timeout: 256 seconds]
Nilium_ is now known as Nilium
crimson_pingvin is now known as crimson_penguin
decentpe- is now known as decentpenguin
Ankhers_ is now known as Ankhers
vent has joined #zig
<vent>
g-w1: On your point about linting in Zig, and how there would be no warnings only compiler errors. I think that's a good idea to be honest. I think the opportunity for people to ignore lints is too big, and so making them compiler errors that you either have to fix or toggle the linter off for that section of code is a good idea. Just gotta make sure there are no false-positives.
notzmv has quit [Ping timeout: 246 seconds]
<g-w1>
from what ive heard, zig is focused on maintanable code, that means that nothing will compile if it is not good code
oats_ is now known as oats
Ekho has joined #zig
<vent>
That's a very sensible philosophy
<vent>
"Quick and dirty" hacks are why my old company is now going out of business lol
<vent>
Well, not _my_ company, but the company I used to work for
<ikskuh>
"Quick and clean" is my experience with zig :D
ceberly has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<vent>
I think a good solution would be for errors like "unused variable" and "change this while to a for" to only be errors in release builds. In debug builds they're warnings.
<g-w1>
there is a proposal like this for "sloppy mode" already
<vent>
I think that still follows the idea of "no warnings, only errors", but more practically. You only care about reducing warnings when you're cleaning up and finalizing your code for release anyway.
<vent>
I do think that casing should be an error though. If you _need_ to use different casing, there can be a builtin to toggle it off for your project. Perhaps that could go in the build.zig.
<g-w1>
if you have ideas like this, the best way to make them heard is to make a proposal on github
<vent>
I think I'll do just that. Although that chat log would disagree, I'm a big fan of Rust's warnings for incorrect casing. I think it's the only way you'll be able to keep casing standardized as the language grows.
<g-w1>
ill say one thing, some people start making proposals without having written zig, so just make sure that you are comfortable with the language before making a proposal so that it has a greatest chance of getting accepted
<vent>
Yeah, that's a good idea. I'll spend more time with the language and maybe make the proposal in a week or so.
texno has quit [Changing host]
texno has joined #zig
<g-w1>
is this a bug or not? ./src/main.zig:252:9: error: incompatible types: 'std.io.writer.Writer(void,std.io.NullWriter,std.io.dummyWrite)' and 'std.io.writer.Writer(*std.io.buffered_writer.BufferedWriter(4096,std.io.writer.Writer(std.fs.file.File,std.os.WriteError,std.fs.file.File.write)),std.os.WriteError,std.io.buffered_writer.BufferedWriter(4096,std.io.writer.Writer(std.fs.file.File,std.os.WriteError,std.fs.file.File.write)).write)' if
<g-w1>
I think it is not a bug in stage1, but some people on the discord server think it isolier
<g-w1>
s/isolier/is
caolanm has left #zig ["Leaving"]
yyp has joined #zig
zupss has joined #zig
<superdump>
i am trying to get zls to work on macos. i followed the instructions but when running zls from the command line i get: dyld: Symbol not found: __tlv_bootstrap
<superdump>
i'm wondering if this is perhaps something to do with the llvm setup
<snamber>
superdump at hash d9e46dceeca3f66b87e6b2e36415417495d2d2a0 the zig build works, and that version of zig can then compile zls as well
<superdump>
zig: 0.7.1
<Nypsie>
I think this happens with the release binary of zls. The macos version was crosscompiled which had that error back then
<superdump>
ok
<snamber>
That hash sounds random, but it's a kind of recent hash (after 0.7.1) but before the AST rewrite
<superdump>
so i could try just building zls with my installed zig?
<snamber>
the way it worked for me is this: first build zig at that hash, and then build zls with that newly built zig
<Nypsie>
There were some changes that require you to have more recent version of Zig than 0.7.1, but older than current master :P
<Nypsie>
I'd suggest what Snamber said
<snamber>
honestly I was intimidated at first, but building zig is actually pretty painless
<Nypsie>
Alex is back now so I'll cooperate with him to get my PR merged so it works with master again.
<g-w1>
there are still some regressions, but those can be fixed after the merge ig
<g-w1>
its very hard to make repros for it :(
<Nypsie>
Ah you found more regressions? :(
<g-w1>
yeah
ubert has quit [Remote host closed the connection]
txdv has quit [Ping timeout: 240 seconds]
ubert has joined #zig
<superdump>
using zig 0.7.1 to build the 0.1.0 version of zls seems to at least allow the zls binary to run
<g-w1>
that will work too i think :)
<snamber>
that's another way, good idea
<snamber>
then you miss out on the zig developments since 0.7.1, but that's all, and you don't need to compile zig
<superdump>
my intention was to try to stick to releases for now as i'm completely new to the language
<g-w1>
thats fine, 0.1.0 will work totally fine for you as it was released around the time that 0.7.1 was released
cow-orker has joined #zig
ceberly has joined #zig
xackus has joined #zig
jokoon has joined #zig
ceberly has quit [Client Quit]
<superdump>
hmmmmm. i'm thinking i'll have a go at ray tracing in one weekend. first thing i'm thinking of is to initialise a library project, and then write example programs that use different parts of the library. so i guess for each example program i will need to add an executable target to the build that depends on the library target that was generated by zig init-lib. and then it's not clear to me if i can just make separate files in
<superdump>
src/ and import them into src/main.zig and everything will magically work... need to do some reading i guess
<snamber>
I encountered that issue as well. That was one reason why (like mentioned above) I built zig at d9e46dceeca3f66b87e6b2e36415417495d2d2a0.. this works on Big Sur and it works with zls
<snamber>
"Why not master head?" - Because zls doesn't work with master head
<snamber>
(yet)
<snamber>
kevinsjoberg: ^ hope that helps (plus some encouragement: building zig works actually exactly as advertised, fairly painless)
<g-w1>
you can also just download a zls binary from github i think
<g-w1>
then you can use master zig
<superdump>
g-w1: do i need to list all source files or does importing a file into a file that is in a static library target make things 'just work'? also, don't i need to specify the dependency of the example executable on the library i'm making?
<g-w1>
it should Just Work
dimenus has joined #zig
<g-w1>
as long as you have an executable that imports other .zig files, it will work, no header/linking/other stuff required
<superdump>
i think ideally i'd like the examples to link as if the project's library were an external dependency, to show how to use it if you see what i mean
<superdump>
can i import the project as a namespace? so if it's in a directory called 'project' then i could import 'project'?
<ifreund>
you can only import files not directories
<superdump>
or else if i were to make a separate project that is supposed to use this library project (let's call the exe and lib) how would i make use of lib from exe?
<superdump>
ah
<superdump>
so it's all just path based
<superdump>
that's nice and simple. i dig it :)
<ifreund>
yep, and files are just structs, there's no special semantics
<ifreund>
you can also create packages using the build system though, which allow you to import things by name instead of by path like @import("std");
<g-w1>
note: there is no binary form of a zig library. it is only source-based.
<kevinsjoberg>
g-w1 snamber thanks for the help. I built master and it worked perfectly. Appreciate the help!
<snamber>
kevinsjoberg: awesome!
<superdump>
hmm. i'm thinking of having something like src/lib.zig which is kind of a 'top-level' library import, and then within that file i would like to have import of something like other.zig which is also in src/, and sort of re-export everything from that namespace. the idea being that in my example i do something like const mylib = @import("../src/lib.zig"); and then mylib.other.something(); if you see what i mean.
<superdump>
does that make sense as a way of structuring things within zig?
<ifreund>
sounds reasonable to me
<ifreund>
the jury's still out on what exactly idiomatic Zig is, so experimentation is good
<superdump>
how do i 're-export' other.zig through lib.zig?
<ifreund>
in lib.zig: `pub const other = @import("other.zig");`
<ikskuh>
pub const other = @import("other.zig");
<ikskuh>
...
<superdump>
ah, i was close
<superdump>
i did export const other = ...
<ikskuh>
welcome to zig. where two people write literally the same code :D
<ikskuh>
"export" will export a *symbol* from your library
<ifreund>
(which you could then call from C code)
<ikskuh>
so another C library can import then
<superdump>
aha, i see
<superdump>
so, next problem: what path should i use for the import in examples/exe.zig to make use of src/lib.zig ?
<g-w1>
you want to addPackage in build.zig to src/lib.zig as whatever your package name is and then @import("thatname")
<superdump>
../src/lib.zig didn't work, nor did src/lib.zig (it said ./examples/ppm.zig:1:12: error: import of file outside package path: '../src/lib.zig' so i thought maybe trying a path relative to the base)
<g-w1>
so in your case in build.zig example_exe.addPackage(.{.name = "mylib", .path = "src/lib.zig"}); then in examples/ppm.zig you can @import("mylib") to get src/lib.zig
<superdump>
bingo, thanks. it feels a little odd not to define the product of building the library that is the main focus of the project as a package, and then just be able to import that or add it as a dependency to the executable
<dutchie>
the point is that the library is the source code, and therefore doesn't need to be built
<superdump>
it feels like i'm defining a target that is a static library build of the project, and then redefining that static library as a package but only for that one executable
<g-w1>
the compiler *doesn't* build the library. it is the exact same compilation unit
<g-w1>
what build.zig does is actually just invoke the compiler: zig build-exe examples/ppm.zig --pkg-begin mylib src/lib.zig --pkg-end
<superdump>
ah right, yes i remember hearing something about that in andrew's 2018 video
<superdump>
so you are not supposed to build the static library and then link it into the executable
<g-w1>
then you can @import("mylib") from ppm.zig the exact same way
<g-w1>
superdump: exactly
<superdump>
you are supposed to specify all the source code to build for that particular target, and then zig builds it as one unit into the result
ceberly has joined #zig
<g-w1>
you can if you wan't, but the code will be less optimised and you won't be able to use cool zig things like errors and union(enum)s
<g-w1>
superdump: yes
ceberly has quit [Client Quit]
<superdump>
right. unlearning and relearning. thank you for answering my initial hump questions :)
<g-w1>
np :)
<dutchie>
i find it amusing how much harder all this makes releasing a closed-source library in zig
<superdump>
ziglearn.org looks like the piece i was perhaps missing. i was looking for something like the rust book. i'll have a read through that
<dutchie>
i guess you'd have to put out some binary blob and a wrapper library
<g-w1>
maybe, or just use the c abi
<dutchie>
yeah, that's what i was thinking at first. but as you said you lose a lot of nice features
tnorth has quit [Ping timeout: 260 seconds]
<superdump>
could there be a way to shove the zig-specific stuff alongside the static library so that if you're using it from zig, you can retain the magical errors and such, and if using from C then you have to live with not? although you still need to be able to handle errors from C so i'm not sure how that would work
<ifreund>
you probably want to map zig error sets to C enums if exporting a C API for a zig libraray
zups has joined #zig
waleee-cl has joined #zig
<yyp>
How does linking system C libraries in Zig work internally? How could #8144 even become a thing?
xackus has quit [Ping timeout: 245 seconds]
<ifreund>
yyp: to be able to cross compile to arbitrary glibc versions zig generates a stub libc.so file for the desired glibc version and links against that
<ifreund>
this works fine if you aren't also linking against system libraries built against a different glibc version
<ifreund>
the fix is to make zig default to linking against the system libc if this is the case
jokoon has quit [Quit: Leaving]
<ifreund>
(you can already tell zig to do this with zig build-exe --libc)
<yyp>
Is it possible to apply --libc to zig build (not build-exe)?
<ifreund>
yyp: yes, see the comments at the end of the river issue
voldial has joined #zig
<yyp>
That works, thank you!
yyp has quit [Quit: disconnected]
<superdump>
ifreund: in that case it might be nice to have some way of automatically mapping from/to zig error sets and C enums. but perhaps that's too complex to add as a feature. i definitely respect the keeping it small and simple ethos
<ifreund>
superdump: you can probably implement a function that does that for you at comptime with @typeInfo() and @Type()
<superdump>
hehehe, shiny
<ifreund>
zig's metaprogramming is quite powerful despite being simple :)
<superdump>
i definitely like the idea of comptime
<g-w1>
i tried that, but stage1 didn't allow it, but thats an implementation bug
<superdump>
is it intended that a 'standard' C-style for (int i = 0; i < N; i++) {} loop be implemented using while instead, or is there some range syntax or something to use with a for loop?
<dutchie>
`var i: usize = 0; while (i < n) : (i += 1) { ... }`
<dutchie>
optionally wrap the whole thing in a block if you don't want i to leak scope
<dutchie>
for loops only work on arrays and slices
<superdump>
right, i was wondering if there was a way of generating the array of values with a range or something
<superdump>
but that would then use the memory for the full array perhaps, unless the generator were an iterator or something
<dutchie>
yeah, there is an alternative pattern for "iterators"
zups has quit []
<superdump>
ah, you said for loops only work on arrays and slices. so not iterators. i only briefly saw something about iterators
<dutchie>
`var iter = Something.iter(); while (iter.next()) |item| { ... }`
<superdump>
mmm
<dutchie>
i wonder whether there is a place in std for a counting iterator
<superdump>
ok, while loop it is i guess
<dutchie>
probably not, since you can just do it with the first while loop i showed
<superdump>
yeah, i was wondering if there was one, but i don't know if it gains anything
<superdump>
exactly
<superdump>
if anything it's just slightly more verbose perhaps
kevinsjoberg has quit [Ping timeout: 240 seconds]
<superdump>
what should i use from the standard library if i want to print to stdout some text data that is actually meant to go to stdout as it is the output of the program and not a log message?
<dutchie>
won't you have to .writer() it before calling print?
<superdump>
you do
<superdump>
with .writer() it works
<superdump>
nice
<superdump>
it's alive!
snamber has quit [Remote host closed the connection]
<superdump>
"Zig gives no guarantees about the in-memory order of fields in a struct, or its size." that's... a thing
<fengb>
It's allowed to reorder to optimize the struct for either performance or size, yes
<g-w1>
its so that you can have optimisations. if you want garuentees, use `extern struct {}` which uses c abi
<superdump>
i was thinking for example about making a struct to hold a colour, and perhaps writing that colour data directly to disk from memory
<superdump>
extern struct {} sounds useful then
<fengb>
`extern struct` has size guarantees yeah
<fengb>
consistency guarantees*
<g-w1>
yes superdump thats what std.elf uses for serializing and deseralizing elf headers
Akuli has joined #zig
<ifreund>
packed structs will be the better choice for stuff like this than extern structs when they are less buggy in stage2
<ifreund>
they already work great if you're careful to keep everything byte aligned
<g-w1>
yeah, although sometimes extern structs can act packed, they do in this case (elf)
<superdump>
maybe as i am learning i will try using plain structs and see what problems i hit
<ifreund>
indeed, though they also require a fair amount of care and familiarity with the C ABI to make sure you don't introduce padding
jokoon has joined #zig
<marler8997>
zig_version..??.??
<marler8997>
wth, how do these new features get in and I have no idea about them ?
cole-h has joined #zig
dyeplexer has quit [Remote host closed the connection]
jokoon has quit [Quit: Leaving]
wilsonk__ has quit [Quit: Leaving]
wilsonk has joined #zig
<superdump>
if i want a variable for an uncompressed image in memory, in C i might just malloc enough memory for a 1D array and used width * y + x to index into it. how would you do it in zig? maybe a 2D array would be preferred but perhaps the dimensions are not known at compile time?
<ifreund>
superdump: if the dimensions aren't comptime known I'd probably just do that the same way as in C
* superdump
nods
remby has joined #zig
SimonN has quit [Remote host closed the connection]
texno has quit [Quit: leaving]
SimonNa has joined #zig
<superdump>
./examples/ray_tracer.zig:31:57: error: expected type '[]u8', found '*[90000].zigzag.vec.Vec3'
<superdump>
var allocator = std.heap.FixedBufferAllocator.init(&image).allocator;
<superdump>
what's happening here?
<superdump>
can i not pass something other than []u8 to .init() ?
<superdump>
perhaps FixedBufferAllocator is only for allocating []u8
<Gliptic>
it's not for allocating only []u8, but it will allocate _from_ a []u8 you pass
TheLemonMan has joined #zig
<Gliptic>
also, I don't think you can just do .allocator, you need to store this as a FixedBufferAllocator somewhere
<g-w1>
it uses fieldParentPtr to do an interface
<superdump>
in the fixed buffer allocator example here: https://ziglearn.org/chapter-2/#allocators what is happening? is it actually allocating a [1000]u8 on the stack and then the fixed buffer allocator is being asked to allocate [100]u8 from that?
<superdump>
if so, i think i misunderstood
<superdump>
earlier
<Gliptic>
superdump: yes, that's what's happening
<superdump>
ok
<TheLemonMan>
marler8997, ping
<marler8997>
hey
<superdump>
then i guess i want a heap allocation and to use that allocated memory as backing for a []T
<Gliptic>
or just use a heap allocator directly?
<TheLemonMan>
are you still running Windows?
<g-w1>
superdump: why don't you use the std.heap.GeneralPurposeAllocator(.{}){} ?
<marler8997>
of course, always have been
<superdump>
g-w1: i have just realised that i should :)
<g-w1>
nice
<TheLemonMan>
bad habits are hard to die, amirite ;) anyways can you give #8174 a spin? the console stuff doesn't work on Wine and I didn't find enough time to fix that bug
<superdump>
i hadn't read the entire section and i just misunderstood what the fixed buffer allocator was doing so i thought i could use it. i was wrong
<TheLemonMan>
it should™ work, drop a line in the PR if it does(n't)
<andrewrk>
ooh I'm excited about this one
<g-w1>
does it fix the bug that you asked loris to fix?
<marler8997>
yeah I give it a spin in a big, if I don't forget :)
<marler8997>
*bit
<andrewrk>
g-w1, looks like it
<g-w1>
nice
<TheLemonMan>
marler8997, I've just learned that sticking post-it notes all around your screen is the best way to avoid forgetting stuff
<marler8997>
that's a freakin awesome idea
<marler8997>
do you actually do that?
cbix has quit [Excess Flood]
<TheLemonMan>
yep, the laptop looks quite funny when closed heh
<marler8997>
I'm literally going to do that now
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<andrewrk>
lol
<andrewrk>
marler8997, if you tell me it works fine on windows I'm going to spank that merge button straight away
<marler8997>
lol
<marler8997>
I'll see if I can get to it soon then
<TheLemonMan>
take your time, I'll periodically ping you heh
kevinsjoberg has joined #zig
<tav>
hey guys — long time, hope all is well
<tav>
I'm coming back to Zig and have a few questions:
<tav>
1. Is it possible to annotate struct fields with additional metadata yet? e.g. to support database models, serialisation info, etc.?
<TheLemonMan>
no
<tav>
2. Is it possible to generate a struct using a code generator, e.g. for protobuf messages, and then hand-write custom methods for those structs while keeping struct definition and additional methods within the same package somehow?
<TheLemonMan>
maybe with some creative use of usingnamespace
<tav>
the doc on usingnamespace wasn't super helpful. any chance you could elaborate?
<tav>
thanks for all the answers, g-w1, TheLemonMan and ifreund!
neptunepink has joined #zig
ur5us has joined #zig
dfacto has quit [Ping timeout: 245 seconds]
<andrewrk>
TheLemonMan, what do you think about this idea I just had: new policy for llvm updates: as soon as they release rc1 we merge the llvmxx branch into master
<andrewrk>
hmm seems a bit chaotic
<andrewrk>
another question, how to translate {Bi2} to the new fmt stuff? specifically the '2'
<andrewrk>
that tells how many significant digits to display
<TheLemonMan>
{:2}
<TheLemonMan>
hmm, merging early is a bit dangerous for people just wanting to use master
<TheLemonMan>
but such is life on master, I like that idea
<ifreund>
andrewrk: from the prespective of a zig contributor who has thus far managed to avoid needing to build llvm from source, that sounds kinda painful
zags has quit [Ping timeout: 256 seconds]
<marler8997>
TheLemonMan, what's an easy way to test your change?
<andrewrk>
ifreund, how are you providing the llvm dependency currently?
<andrewrk>
marler8997, run the std lib tests while resizing the terminal chaotically
<ifreund>
andrewrk: right now I just use my distro (void)'s llvm package
<marler8997>
ok
<andrewrk>
ifreund, I see - that's going to stop working regardless once 12 gets released in a few days
<ifreund>
to deal with the lag between the last llvm release and the void package being updated I used a binary from nixpkgs for awhile
<ifreund>
but I don't think nixpkgs provides binaries for the rc builds
<andrewrk>
I see
<ifreund>
just to give some perspective, I'm sure I could manage to build from source given enough motivation
<g-w1>
what is the motivation for this change? im not sure im seeing it
<ifreund>
more testing for the new llvm to catch regressions
<g-w1>
ah
<andrewrk>
the CI gets involved more quickly. we get forced to explicitly report bugs and disable the failing tests
<andrewrk>
right now llvm12 branch is festering a bit with some unreported bugs
<g-w1>
how will the ci get llvm12?
<andrewrk>
I spend all day compiling llvm12 for every target
<andrewrk>
creating tarballs for the ci to download
<andrewrk>
oh yeah I remember one reason we don't do this. because I don't want to do that multiple times
<andrewrk>
it's enough to do it for the actual release and bug fix releases
<g-w1>
wont every rc you have to do it again?
<andrewrk>
yeah we're saying the same thing right now
<g-w1>
does llvm not provide binaries for rcs? i assume they have enough power
<andrewrk>
they don't provide what we need
<g-w1>
ok
dfacto has joined #zig
sord937 has quit [Quit: sord937]
<andrewrk>
TheLemonMan, btw did you have any interest in attending stage2 compiler dev meetings? so far we've been doing them on discord. right now joachimschmidt is going over the arm feature detection stuff
<andrewrk>
we can change venue if it helps
zags has joined #zig
snamber has joined #zig
signop_ is now known as signop
craftinglinks has joined #zig
zags has quit [Ping timeout: 246 seconds]
* ifreund
wonders if the zir-memory-layout branch will grow as large as the ast-memory-layout one
<ifreund>
I guess not having to deal with zig fmt might keep things a little more contained
<Nypsie>
I guess we're 'lucky' that the sema part is still incomplete and we don't have to refactor as much as if we did it at the very end
<g-w1>
is it also going to be ir.zig? I just had that question. or will that be another day?
<ifreund>
g-w1: as I understand it, tzir-memory-layout will be the 3rd and final branch
dfacto has joined #zig
<ifreund>
probably also the time to s/ir/tzir/
fputs has quit [Quit: WeeChat 3.0.1]
<andrewrk>
yes and zir_sema.zig is getting renamed to Sema.zig
<g-w1>
its going to be a struct?
<andrewrk>
ifreund, it touches about 11029 lines of code. the other branch touched 20,800
<andrewrk>
hmm I should meansure by deleted lines. s/20,800/16,573/
sundbp has joined #zig
<Nypsie>
You'll mostly be operating on an index. You use that index to get the tag from a tag list, and data from the data list which could contain the lhs and rhs for a binaryOp for example.
<ifreund>
andrewrk: cool, I hope to find time to contribute a few commits to the branch. Helping on the last one got me very comfortable with that part of the codebase
<Nypsie>
(to g-w1, I need to learn how to IRC properly)
<ifreund>
I figure if I learn my way around the rest of the compiler as well I'll have the power to fix any bugs I want :D
<andrewrk>
sweet!
<Nypsie>
ifreund, I'm with you there. Even though I didn't manage to contribute to the ast branch, fixing bugs in zls which uses zig's parser made me pretty comfortable with its structure, the 'pitfalls', etc
<TheLemonMan>
andrewrk, interest yes, time not so much as of lately... do you keep a log of the meetings content? (or is that a video meeting ?)
<TheLemonMan>
marler8997, shit, can you dump the contents of info ?
<marler8997>
maybe if you fix that crash you can get something working on wine?
<TheLemonMan>
Wine's implementation of FillConsoleOutputCharacter is somehow always returning an error
<marler8997>
ah, nevermind then
<TheLemonMan>
hmm, you want the number of lines below the cursor so it should be ((info.srWindow.Top - info.srWindow.Bottom + 1 - (info.dwCursorPosition.Y - info.srWindow.Top))
xackus has joined #zig
<marler8997>
thread 7960 panic: attempt to cast negative value to unsigned integer
<TheLemonMan>
of course it's top - bottom
<TheLemonMan>
the hell, I should go to sleep
<marler8997>
top=2286 bottom=2333 y=2333
<TheLemonMan>
makes sense, it's going to clear only one line
<marler8997>
I don't get it, what's the right expression?
<ifreund>
(or give me permssions to do so myself if you feel like it :P)
ur5us has quit [Remote host closed the connection]
LewisGaul has joined #zig
LewisGaul has quit [Client Quit]
LewisGaul has joined #zig
<andrewrk>
ifreund, patch looks good, also you have write perms now
<ifreund>
sweet, thanks :)
dimenus has joined #zig
<LewisGaul>
Hey all, just watched Loris's community update on youtube and had a couple of questions on community spaces:
<LewisGaul>
- Is there a list of Zig-related blog posts anywhere? If not I'd be happy to create one - I have a couple of blog posts that I don't think have much reach right now!
<LewisGaul>
- Is there a Q&A style community, like discourse? I'm used to the discourse spaces of Python/Rust/Elm, and quite like the format personally, both for asking and answering (the ability to ask a question and come back to it later, without it getting lost in chat)
dimenus has quit [Client Quit]
dimenus has joined #zig
<ifreund>
LewisGaul: I guess the subreddit is the closed thing we have to the latter
<ifreund>
as for a collection of zig blog post I haven't seen anything like that yet, would certainly be cool!
<ifreund>
filtering by the zig tag on lobste.rs might be a good starting point
<LewisGaul>
ah right yeah, I haven't ever really used reddit actually. I guess I could stick a list in a gist, is that a good choice of format?
<LewisGaul>
Also, unrelatedly, I have been meaning to finish off that zig fmt PR, will get to it soon hopefully
<g-w1>
maybe a wiki page is better? (although that could get a little self-promotionaly)
<LewisGaul>
I wasn't sure whether the Zig GH org would be the right place to maintain a list of blog posts as in theory they could be changed under their feet, so perhaps better to have more of an unofficial list with a lower bar to getting posts added there? Not sure :)
<LewisGaul>
on the other hand it doesn't make a lot of sense for someone 'random' (e.g. me!) to have gatekeeper powers
<ifreund>
makes total sense, the zig community is all about decentralization
<ifreund>
if you're list should happen to become too closed someone else can always make another :P
ur5us_ has quit [Ping timeout: 260 seconds]
<LewisGaul>
haha, ok sure :)
<ifreund>
LewisGaul: and RE that zig fmt PR, no stress I was actually meaning to finish off myself tomorrow if I find the time
<LewisGaul>
ifreund I did start taking a look at the suggestion you had, but was looking into removing the separate treatment of the two block cases, and ended up getting into a bit of a mess. The problem is I don't have the context of why the two cases were made separate in the first place :)
<LewisGaul>
If you want to just finish it off on my PR branch then feel free, I'll be interested to see your solution