<via>
fmt combined with the slice/buffered streams in io is awesome -- compared to my c version which uses repeated sprintf's and hopeful/careful management of a pointer
fengb has joined #zig
fengb has quit [Ping timeout: 260 seconds]
diltsman has joined #zig
<diltsman>
On head, how do I get my build.zig to build release mode?
<diltsman>
Huh...help seems to indicate --release-fast while -Drelease-fast appears to work.
<Tetralux>
I believe that's right. -Drelease-fast etc.
<Tetralux>
The help should be more clear if that's the case though.
<Tetralux>
That does seem a little inconsistent.
<diltsman>
I know that this isn't Zig, but any idea how to get rid of lld: error: no memory region specified for section '.ARM.exidx'?
<diltsman>
I have this in my .ld file: .ARM :
<diltsman>
{
<diltsman>
. = ALIGN(4);
<diltsman>
*(.ARM.exidx);
<diltsman>
}>flash0
<diltsman>
If I do "zig.exe build", then it works. "zig.exe build -Drelease-fast" fails.
<diltsman>
Do I have to do anything in my build.zig to point release and debug builds to the same linker script?
darithorn has quit [Quit: Leaving]
<andrewrk>
diltsman, do you have reason to believe they're getting different linker scripts?
<andrewrk>
you can pass --verbose to `zig build` to see the args it's passing
<diltsman>
I need to look into exactly what the .o files contain. It is possible that they are doing something slightly different that lld then correctly pukes on.
fengb67 has quit [Ping timeout: 260 seconds]
<daurnimator>
andrewrk: could you have a look into fixing #2850 ?
nifker was kicked from #zig by ChanServ [Banned: disrespect !T 1w]
DutchGhost has joined #zig
bugabinga has joined #zig
DutchGhost has quit [Ping timeout: 248 seconds]
dimenus has quit [Ping timeout: 268 seconds]
dimenus has joined #zig
dimenus has quit [Ping timeout: 246 seconds]
DutchGhost has joined #zig
DutchGhost has quit [Remote host closed the connection]
fubd has joined #zig
<fubd>
comptime question. how would I make a "registry" of types? i.e., I want to define a Foo struct, and call "registerType(Foo)" at compile time, and have at compile time an array of all the types
<mq32>
has anyone started an imaging library for Zig already?
<mq32>
so: loading, manipulating and saving image files?
<scientes>
I think tgschultz has a libpng library
<scientes>
mq32, you can always use C
<mq32>
scientes, this question was more about: "is it worth to start writing a general purpose imaging library for zig?"
<mq32>
i could use some comptime image loading stuff
<scientes>
if it is fun for you, yes
<scientes>
the language has stabilized a lot, but there still will probably be some changes you will have to adapt your work to
<mq32>
yeah, i'm fully aware of that
<mq32>
but i am kinda desperatly searching for a better way to build my embedded projects than having a cluster of small, very different programs that prepare resources for me
<scientes>
well yeah comptime is great
<mq32>
i have like, 10 precompilers for different resources that just prepare binaries
<mq32>
and zig allows to do that *in language* and *in program*
<mq32>
even just
<scientes>
and it works now
<mq32>
const my_blob = @embedFile("is_wow");
<mq32>
and if I do the image processing library right, i can do stuff like this:
<DutchGhost>
see how the `mod_alloc` is replacable, but yet global to the module
<fengb>
Looks okay but thread problems >_>
<DutchGhost>
why thread problems?
<fengb>
Swapping out halfway through
<DutchGhost>
Not if the collections take in the allocator
<fengb>
Usually in cases like this, I'd prefer using a context struct
bugabinga has quit [Quit: Connection closed for inactivity]
<fengb>
Example: two thread try to use different arena allocators. This is global so one of them just swapped allocators underneath the entire program
<DutchGhost>
if any struct that needs an allocator copies the module's global allocator (its just a ptr, so copy is cheap), then it doesnt matter if you change the allocator halfway trough
<DutchGhost>
except top level the allocator must still be in mem ofc :3
<DutchGhost>
which is why still every struct and function using allocation should have its own version of the global alloc ptr
<DutchGhost>
it just copies when created
<DutchGhost>
then you dont have this "ohh but someone swapped underneath me"
<fengb>
Uhhh allocator pointers are the same reference. You currently can't copy allocators
<fengb>
tgschultz has a branch that changes that
<DutchGhost>
notice the mod_alloc is a `*std.mem.Allocator`
<fengb>
Oh I see
<DutchGhost>
I mean it kinda 'solves' the thing of passing allocators to everything, if you wrap it like this?
<fengb>
Honestly, I don't think passing allocators should be solved
<scientes>
ugggh, i really find it annoying that i have to wrap values into pointers to the stack in the compiler
<DutchGhost>
no but it's annoying when you continuously have to pass in the same allocator to everything
<scientes>
oh there are some helpers to that
<fengb>
Either there's a top level entrypoint, in which case you can copy the allocator there. Or there's not an entrypoint, in which case it's better for consuming libraries to pass in allocators
<mq32>
DutchGhost: Last week andrew showed us @import("root") which imports is a reference to your root level file. so you could potentially do `@import("root").allocator`
<fengb>
Like in your code, I can't just put the vector in an arena easily.
<DutchGhost>
but then a module has to assume the top-level attribute is called `allocator`, @mq
<mq32>
yes, that's correct ;)
<DutchGhost>
and so what if it thinks its called `alloc`?
<mq32>
but as fengb said: if you write a library, don't make global stuff and if you write a program, it's a safe assumption
<DutchGhost>
and another module assumes its called `allocator`?
<DutchGhost>
you could @fengb, just set the mod's allocator to an arena allocator, and make a new Vec
<tgschultz>
that's why we pass allocators. the alternative is a default global allocator that everything calls on and then you have all the same problems other languages have because of that
very-mediocre has joined #zig
dimenus has joined #zig
<desperek>
"lld: error: could not open SDL2: is a directory" duh
<desperek>
how do i link it if it doesnt work that way?
bheads has quit [Ping timeout: 248 seconds]
<desperek>
oh ok it works when i add .lib, nvm
<desperek>
why does it work like that though?
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
<mq32>
desperek, i assume because windows usually links with file name whereas unixoids link with "library name"
<desperek>
oh well
<desperek>
mq32, does it link statically with the linkSystemLibrary?
<mq32>
i really have to do some more stuff with zig just for the sake of learning the language... :(
<mq32>
dunno, i'm just into the language theory right now, haven't done much projects with zig yet
<desperek>
i see
<desperek>
thanks
bheads has joined #zig
<fengb>
I remember loving everything I read about Rust... then I used it >_>
<bheads>
I have been thinking lately that signed integer types should be prefixed with s and not i.
<DutchGhost>
why?
<mq32>
fengb, yeah, i made that mistake too ^^
<bheads>
we have uXX for unsigned so sXX for signed makes more sense
<mq32>
i noticed that my small single-file-services take up 600 MB of storage in the build cache
<mq32>
O.o
<bheads>
i32 is a C holder over
<fengb>
It's also in LLVM and Rust
<very-mediocre>
integers are expected to be able to be negative
<bheads>
was teaching someone new to programing
<very-mediocre>
unsigned integers are a specialized integer
<DutchGhost>
whats wrong with Rust fengb?
<mq32>
bheads, i think i32 is more clear as it is more widespread
<bheads>
it just added an extra layer
<very-mediocre>
i32 makes more sense, it's literally just an integer
<mikdusan>
s32 looks like 4-byte utf
<fengb>
DutchGhost: nothing *wrong* with it. It's just a lot of overhead to get stuff done that I can't really grok
<bheads>
it was just a though it terms of teaching
<DutchGhost>
overhead? mmhh
<desperek>
oh yeah i feel very similar i think fengb
<fengb>
There's 3 different string types, macros for error handling, result types, borrow checker, etc.
<desperek>
although i know a person who likes rust
<DutchGhost>
macro's for error handling? whoa
<fengb>
try is a macro
<mq32>
there's a lot of macro stuff going on
<DutchGhost>
we had `try!`
<DutchGhost>
now its `?`
darithorn has joined #zig
<mq32>
the main thing Rust had for me was this (already) huge library
<fengb>
I think Rust is great to replace C++. But I'm not a C++ guy for a reason :P
<desperek>
i feel like i would have to read the whole rust book to get any grasp of it
<DutchGhost>
there's multiple string types, altough you only use `String` and `&str` regularly
<fengb>
Yeah it's just conceptually big
<bheads>
D went crazy with the string types too
<bheads>
string wstring dstring char wchar dchar
<fengb>
Again, I'm not saying Rust isn't good. I just couldn't get into it
<DutchGhost>
and it makes sense, `String` == `Vec<u8>`, while `&str` == `&[u8]`. Its just not that hard when you see it like that
<DutchGhost>
one is owned, the other is a view into an owned thing
<very-mediocre>
imho the biggest annoyance of Rust is lifetime annotations
<mq32>
yeah, but then you don't need two types, just use Vec<u8>
<DutchGhost>
No. Passing a slice is cheaper
<mq32>
DutchGhost, i meant "String" vs. "Vec<u8>"
<fengb>
Anyway... I stuck with zig because I could basically dive right in while fixing a lot of my problems with C
<DutchGhost>
`Vec<u8>` doesnt provide utf-8 safety
<mq32>
yeah, but really? substring doesn't do, either ^^
<DutchGhost>
substring?
<DutchGhost>
whats substring?
<mq32>
why have substring if you do it on code units (string slicing)
<DutchGhost>
what do you mean by substring?
<DutchGhost>
the `&str` thing?
<mq32>
and if you accidentally index a half code point, everything explodes
<DutchGhost>
You cant index half into a code point
<mq32>
you can
<mq32>
but it will panic
<andrewrk>
the space for rust & zig to exist is pretty clear: zig gains simplicity in exchange for moving memory safety to be a runtime concern
<mq32>
as String does code unit indexing, not code point indexing
<andrewrk>
zig's release-safe build mode is slower than rust's release mode
<mq32>
andrewrk, yeah, i think so too. Both languages have their purpose and their predecessors
<companion_cube>
I'd love Zig to be standardized and become part of big compiler distributions when it reaches 1.0, too
<fengb>
Just a random aside: what do game devs think of Zig or Rust?
<companion_cube>
something rust will have more trouble doing
<andrewrk>
zig also have finer grained safety; if you're writing a lot of unsafe code, or code that has a mix of safe and unsafe, I think zig is more safe than rust (in which you would have to use `unsafe` blocks)
<DutchGhost>
And I think that having a dedicated String type is just easier to get stuff done when working with strings. When I use strings, I dont want to go into this 'but its a Vec of bytes' thing and like push raw bytes or whatever
<andrewrk>
DutchGhost, what are you working on that needs a decoded string?
<very-mediocre>
DutchGhost: you can always make one in userland
<mq32>
andrewrk: I like that Zig doesn't use that much of abstractions but is pretty close to LLVM/Hardware without sacrificing this for security
<mq32>
that's the reason i probably won't switch over to Rust in most of my projects because a lot of stuff is considered "unsafe"
<andrewrk>
DutchGhost, if you decode strings unnecessarily, it's needlessly opening a can of bugs
<DutchGhost>
atm nothing andrewrk. yes I know you could very-mediocre. But then you gotta first build it, but that costs time and energy, so then for a little use-case you're not going to
<andrewrk>
I think it's actually an important design decision whether or not you will need to decode strings, that you should figure out somewhat early on
<mq32>
got to go
<DutchGhost>
because well, it just is easier for a little usecase to just go back to a vec of bytes
<andrewrk>
that requires a heavy dependency to get right (the unicode data libraries)
ffddr has joined #zig
<companion_cube>
if you just need a codec you don't need heavy data, do you?
<companion_cube>
utf8 is reasonably easy to decode
<companion_cube>
it's for normalization/modifications/classifications that it becomes complicated
<andrewrk>
right but why decode it if you don't need to understand the codepoints in any meaningful way? might as well have left it encoded
<andrewrk>
if you're just re-encoding it in a different way, for example UTF-16LE to call windows APIs, you don't need a String type
<companion_cube>
decode means you can validate it, at least
<companion_cube>
that's what `str` means in rust: it's valid utf8, is all (and you can iterate on codepoints)
<andrewrk>
yes - I would argue the best way to do that would be to call validate() on an encoded byte buffer though
<andrewrk>
hm I see, so getting the type system to participate in whether it's valid. that has merit
<companion_cube>
that'd be a `[]u8 -> str` function :)
<companion_cube>
rust also has an unsafe version of that where you promise it's actually valid, without runtime check
<DutchGhost>
Im not saying a `String` type should be part of the std. I am saying that I think it's easier to reason about a `String` then a `Vec of bytes`, and most people know what a `String` is, while they dont always know how its represented below, so know they see vectors of bytes all over the place and they dont know what is going on.
<fengb>
I think this is another case where a distinct typealias would be handy
<companion_cube>
but yeah, a `str` is valid utf8 and that's a good invariant to have
<ffddr>
Hi! Is there any way to introduce a struct field based on some comptime condition?
<andrewrk>
ffddr, short answer: no
<andrewrk>
ffddr, if I'm guessing your use case correctly, there's another way to do it which should be OK
<dimenus>
before I open an issue, I wanted to have a quick discussion about Windows. It seems that Zig generates def/lib files even when linking to libc
<ffddr>
andrewrk I see, thank you! actually I did not have any particular use case yet, just validating my understending of comptime expressions in structs.
<dimenus>
and this is causing issues with both the libc hello world example and the windows example
<desperek>
yeah but i kinda still fail to see why would i use it but thats for another field i guess, andrewrk
<very-mediocre>
desperek: it's for dynamic memory, think "new" in C++
<very-mediocre>
in zig you bring your own "new"
<andrewrk>
desperek, if you don't need heap memory, then don't use heap memory. you'll know when you discover you need it
<desperek>
right. thanks.
ffddr has quit [Remote host closed the connection]
<andrewrk>
generally you will run into a problem that needs solving with heap memory when the amount of memory you need to use for something is only known at runtime
<andrewrk>
you can't put that memory on the stack because, how would you know how big a stack you would need?
<companion_cube>
andrewrk: about the `{x; y}` syntax for blocks returning expressions, wouldn't the current warnings on unused values be sufficient to make very clear the distinction between `{x; y;}` (void) and `{x; y}` (same value as y)?
ffddr has joined #zig
AlexMax has quit [Ping timeout: 250 seconds]
darithorn has quit [Quit: Leaving]
<very-mediocre>
I don't think this is the case, but would a compiler be smart enough to optimize an array of bools into an int?
<very-mediocre>
...i guess i will just write this utility function
<samtebbs>
very-mediocre: I know that GCC can do that under certain optimisatio levels
<samtebbs>
Not sure about LLVM
<very-mediocre>
I see
<very-mediocre>
I know very little about esoteric optimizations
<very-mediocre>
oh, i see someone wrote a packed int array in stdlib
<very-mediocre>
that'll work with some u1
<samtebbs>
very-mediocre: Oh nice :)
<samtebbs>
andrewrk: I've been building a z80 computer on and off for a while now, and would love to write some code for it in Zig. Do you know if having z80 as a target in Zig is realistic?
very-mediocre has quit [Read error: Connection reset by peer]
<samtebbs>
There is a fork of llvm with a z80 backend
very-mediocre1 has joined #zig
very-mediocre1 is now known as very-mediocre
<andrewrk>
samtebbs, I do want zig to be able to support a wide range of targets, even wider than what LLVM supports. that's a couple years out though. if you want to make progress on that now, what that looks like is maintaining a fork of zig that uses that fork of llvm with the extra backend
<andrewrk>
I'm happy to help if you decide to do such a project
<andrewrk>
help meaning answer questions if you run into trouble
desperek has quit [Quit: mew wew]
<samtebbs>
andrewrk: That does sound like the best option right now, at least until mainline llvm gets a z80 backend (if ever xD)
<samtebbs>
Thanks
<samtebbs>
I'll add that to the long list of things to investigate :)
<samtebbs>
I think helping with arm and aarch64 support in Zig is my priority
<samtebbs>
I'm going to see if work will allow me to use some of our native hardware to test things on, I can't guarantee it though
<andrewrk>
great :)
samtebbs has quit [Quit: Leaving work, will check back in later]
qazo has joined #zig
fengb has quit [Remote host closed the connection]
<donpdonp>
z80++ i was just watching Ben Eater's youtube vids of building an 8bit cpu from TTL chips
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre1 has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<Tetralux>
If it was because of not handling the error, surely it should say that.
<very-mediocre1>
you have to use try
<very-mediocre1>
without try, it returns SomeErrorset![]u8
<very-mediocre1>
also you're using `if` in a way that tries to unwrap the expression in the parentheses (optional type -> unwraps to something if it isn't null)
<Tetralux>
If works with errors, because it you use `else |err|` it works fine.
<very-mediocre1>
- std.fmt.bufPrint has a return type of ![]u8 so you have to handle the error as you correctly identified, after doing so you're left with a []u8 instead of ![]u8
<very-mediocre1>
- you can't do if([]u8)
<very-mediocre1>
hm oh yeah
<very-mediocre1>
ok i see your point
<mikdusan>
Tetralux: yeah nice errors like "did you mean to do `else |err|` is probably stuff that will come in with stage2 compiler
<very-mediocre1>
Tetralux: i totally misunderstood your example, you're right
<very-mediocre1>
indeed the docs say "// The else and |err| capture is strictly required."
<Tetralux>
It should say "error not handled"
<Tetralux>
There isn't an optional here...
ffddr has quit [Remote host closed the connection]
tankf33der has joined #zig
<tankf33der>
o/
<tankf33der>
i want to read a two numbers from stdin and print to stdout every number increased by 1.
<tankf33der>
can somebody write me this program on zig? i know, really strange request.
darithorn has joined #zig
HesamR has joined #zig
HesamR has quit [Remote host closed the connection]
<andrewrk>
technically the ABI would be gnu not msvc but they *are* ABI-compatible. I'm still thinking about how to deal with that
<dimenus>
wait, full blown cygwin or mingw64?
<andrewrk>
anything that builds with mingw-w64 builds with this
<dimenus>
nice
<andrewrk>
it adds about 59 MiB in installation size to zig (7 MiB to the tarball size)
<dimenus>
I think my next goal is going to be to clean up / finalize MSVC detection on windows
<dimenus>
it's picking up 2017 instead of 2019 on my machine
<andrewrk>
well here's the thing
<dimenus>
2015 is not worth the effort
<andrewrk>
maybe we can simply delete MSVC detection and stop caring about MSVC's existence
<dimenus>
mingw's libc is hacky IIRC
<dimenus>
we still need msvc detection for kernel32 et al
<dimenus>
that doens't go away
<andrewrk>
what we need is a really good counter example, of why we need msvc integration
<andrewrk>
nope, zig provides kernel32 et all in this branch
<dimenus>
not when you link a c library on windows
<dimenus>
i ran into fat bugs when doing that
<dimenus>
(which is what my PR is about)
<andrewrk>
that's just a problem with polluting the current working directory
<dimenus>
we generate def/libs for what is called in Zig, not what hte library calls
<andrewrk>
and not specifying full paths to lib files
<dimenus>
but we do still need the detection?
<andrewrk>
this branch has full blown kernel32 & friends
<dimenus>
that's how we get the full path to kernel32
<shachaf>
Man, Windows sounds like a complicated platform to compile for.
<dimenus>
you don't know the half of it :P
<shachaf>
Why do you need kernel32 to compile?
<andrewrk>
kernel32 is essentially the stable syscall API on Windows
<shachaf>
Do you mean the .dll or the .lib?
kristoff_it has joined #zig
<shachaf>
I'm trying to figure out how things work. It looks like mingw can link directly to a .dll but I'm probably confused about things.
<dimenus>
on windows, you don't directly link with a dll
<dimenus>
you link with an import library
<dimenus>
or a static library
<shachaf>
"The cygwin/mingw ports of ld support the direct linking, including data symbols, to a dll without the usage of any import libraries."
<andrewrk>
kernel32.lib is an "import library" which is just setting up to dynamically load kernel32.dll
<shachaf>
Maybe this is just some random thing that doesn't actually work well, though.
<andrewrk>
mingw is not to be confused with mingw-w64, which is a fork
<andrewrk>
mingw-w64 supports i386, x86_64, 32-bit arm, and 64-bit arm
<andrewrk>
I don't know why anyone uses mingw anymore
kristoff_it has quit [Ping timeout: 245 seconds]
<shachaf>
It sounds like mingw64 can do it too?
fengb has quit [Ping timeout: 260 seconds]
FireFox317 has joined #zig
<FireFox317>
Nice work andrewrk! I do want to note that there is a security vulnerability with ASLR or something, probably good to keep in mind or to write down for sure