<mikdusan>
the weird thing is I have gcc-9.2.0 on archlinux. the `make -n` command shows identical options for me. yes, I have -Werror, and yet never get a maybe-unitialized problem
<mikdusan>
I'd like to know what build options were used for llvmPackages_9.clang-unwrapped
<pixelherodev>
It's amazing how much cleaner a properly designed program can be than a hacked together one
<mikdusan>
geemili36: don't know what to say. just manually edit zig's CMakeLists.txt and nuke `-Werror`
<pixelherodev>
Or fix the maybe-used-uninitialized issue?
<pixelherodev>
Still a bug, no?
<mikdusan>
pixelherodev: i can't even see the issue, nor reproduce the warning/error on my sys
<pixelherodev>
Sure, but I've had similar cases with GCC vs Clang
<mikdusan>
i'm using same gcc-9.2.0, but a diff linux distro
<geemili36>
I'll probably nuke `-Werror` for the short term
<geemili36>
However, this was apparently happened on Fedora as well, so I'll comment on the issue
<pixelherodev>
Might be a slightly different compiler revision?
<mikdusan>
it irks me looking into one of the warning/errors I can see a code path where it may not get initialized, and I suppose the compiler can see it too (inlined template function) but my compiler isn't moaning about it.
<geemili36>
The comment above the line claims that it can't fail, but I can't verify that claim
a_chou has joined #zig
a_chou has quit [Client Quit]
a_chou has joined #zig
a_chou has quit [Client Quit]
<mikdusan>
geemili36: curious, what does `llvm-config --cxxflags` show for you
ur5us has quit [Ping timeout: 240 seconds]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
seoushi has quit [Remote host closed the connection]
<pixelherodev>
I love how a small refactor can make code smaller, easier to read, and open up the door to even further refactoring accomplishing more of the same :)
<pixelherodev>
Changed the signature of a single function in my LLVM lexer, and the resulting changes shrunk the lexer ~20 lines
<pixelherodev>
In the process, around a dozen branches on a large if/else if/else chain became similar enough to merge into one piece :)
<pixelherodev>
Just cut down code size by nearly 30%, became *more* readable and maintainable in the process, *and* made it easier to extend :D
<pixelherodev>
and Zig has only made this *better*. Started with a simple `self.substr_match` function on the lexing iterator that checks if a single substring matches the current position. Altered that to support a variable number of substrings via a tuple (same way std.debug.warn works) and return whether *any* matched. Now, it returns a `?[]const u8` (the matched string *itself*), and the entire code is far far simpler :D :D
<pixelherodev>
Checking whether any instruction matches, for instance, basically looks like `if (self.substr_match(.{ "alloca ", "call " })) |s| token.?.token_type = .Instruction;token.?.source = s[0..s.len-1];` :D
<pixelherodev>
Writing this as proper Zig instead of trying to use C idioms in Zig makes everything much much nicer
<seoushi>
yeah. I started down the path of a direct port of my ecs from c. Then I saw some of things you can do and my code is smaller, more readable and safer. Still learning a lot of things too, it's just gonna get better
<pixelherodev>
tl;dr: Zig is awesome, and it makes everything it touches better :)
<seoushi>
I'm honestly suprised I didn't hear about it sooner. I randomly heard about it from another guy that was making a text editor in it hah
<pixelherodev>
:)
<daurnimator>
wow.... std.Buffer is used in so many places that it makes *no* sense for
* daurnimator
is writing PR to fix them
<pixelherodev>
Got it lexing the first 804 lines of its own IR! (up from ~650 twenty minutes ago :D)
<pixelherodev>
Pretty sure the first version would've failed in the first ten lines
seoushi has quit [Remote host closed the connection]
<pixelherodev>
`%s/\(self.substr_match(\.{.*}\))/\=join([submatch(1), ", null" , ")"],"")` I knew learning this would be useful in the future :)
<pixelherodev>
Automatically appends a `null` argument to every `self.substr_match` call
<geemili36>
Is there a way to run tests on only a part of `std`?
<geemili36>
Actually, I might not need to, it looks like it's the first time through that is slow
<geemili36>
I'm trying to run the zig std library test suite, but one of the tests is being built with the wrong interpreter (I'm on nixos, so the usual `/lib64/ld-linux*` file doesn't exist)?
<andrewrk>
geemili36, -Dskip-libc will skip the tests that are building dynamically linked glibc and trying to run it
<andrewrk>
personally, I followed the guide in CONTRIBUTING.md and I use `-Denable-qemu -Denable-foreign-glibc=/home/andy/Downloads/glibc/multi/install/glibcs`
<andrewrk>
hmm I wonder how one creates a pipe on darwin with O_NONBLOCK
<andrewrk>
I guess fcntl
<geemili36>
Ah, okay
<geemili36>
Oof, a day to build all foreign `libc`s? I think that's going to be a pass for now.
omglasers has joined #zig
<mikdusan>
geemili36: that llvm was not built with `-fno-rtti` . whether that changes some things, I can't say.
<mq32>
<pixelherodev> Writing this as proper Zig instead of trying to use C idioms in Zig makes everything much much nicer
<mq32>
yeah, i've noticed that, too
_whitelogger has joined #zig
zfoo_ has quit [Read error: Connection reset by peer]
_Vi has quit [Ping timeout: 256 seconds]
<betawaffle>
is std expected to be heavily re-organized before a 1.0 release?
<mq32>
betawaffle: yes, it is. std right now is allowed to contain "anything that just works and seems kinda related"
<mq32>
but afaik the plan is to strip it down and put stuff into packages
<betawaffle>
what's your favorite part of std right now?
<mq32>
"std.*"
<mq32>
the point that nearly all of it works also on freestanding targets
<mq32>
"oh, you want json parsing on AVR? Let's do this!"
<shakesoda>
mq32: i just hope that said packages don't make building stuff practically require being online
<mq32>
shakesoda, no. there's an issue about the package manager and what are the plans for it
<betawaffle>
i'm really looking forward to documentation
<mq32>
basically it's a fully decentralized package manager that doesn#t require any "repositories"
<shakesoda>
mq32: i'll have to give it a good read
BaroqueLarouche has joined #zig
<fengb>
@import(“leftpad”)
<betawaffle>
heh
<mq32>
nice thing is that leftpad is a zero-alloc operation in zig :)
<mq32>
ah no.
* shakesoda
just really doesn't want to end up with every little tiny thing being a package like in rust...
<mq32>
lefttrim would be zero-alloc
<mq32>
shakesoda, i think andrew can give you more info about what he wants to keep in std for 1.0
<mq32>
but i also think that something like a json parser isn't the right thing in a standard library
<fengb>
I think it’d be pretty minimal. I hope we’ll have a concept of “blessed” packages
<fengb>
So std can remain small but we still have high quality standard packages
<mq32>
but stuff like containers (ArrayList, PriorityQueue), basic i/o (async or not, network/file/...), should be in a "group" std
<shakesoda>
i'm not sure what i think about json in std but it happens to be convenient that it's there in use cases i actually have
<mq32>
fengb, yeah that sounds reasonable
odc has left #zig [#zig]
<shakesoda>
so... i kinda support it
<mq32>
maybe create something like pacmans "groups" where you can reference "xorg" and get 50 different packages
<shakesoda>
but otherwise, i definitely prefer standard libraries to tend toward being minimal
<fengb>
Right that’s what I’m thinking. Last thing I want to see is the Wild West of npm
<fengb>
And everybody dependent on some random dude’s leftpad
nikoala has joined #zig
<mq32>
it's also a thing about compatibility
<mq32>
that's what i love about (old) .NET
<mq32>
everybody just uses System.Collections.Generic.List or System.Collections.Generic.Dictionary
<mq32>
because "they are there anyways"
<mq32>
whereas C++ is the absolut other way
<mq32>
oh yeah, we're using std::vector, QVector AND boost::vector!
<shakesoda>
to be sure, c++'s standard library is frequently horrible
<mq32>
it's okayish. Qt has a lot of problems as well (mostly typing errors)
<shakesoda>
god help you if you ever get some stl related compile error, or have to use msvc's stl
<shakesoda>
to say nothing of the horrible things it all does to compile times
<mq32>
:D
<mq32>
my C++ compile times aren't that horrible
<shakesoda>
and of course when bringing up compile times the retort from people is "get a faster computer" as if that makes it okay that everything is slow
<betawaffle>
are type names only decided once? if i do `const A = B`, and then get the name of A, will it be the name for B?
<shakesoda>
build times are a lot of what i hate about rust's package situation
<mq32>
betawaffle: yeah, as it's the same time
<shakesoda>
the million packages involved in everything inflate build times *massively*
<shakesoda>
and it's really slow to begin with :(
<mq32>
shakesoda: +2
<mq32>
building my mini-tool on my RPI takes forever
<mq32>
and uses about 2.3 GiB of disk space for build artifacts
<fengb>
There was a discussion about Rust on HN. Best response was “it’s not as slow as C++”
<mq32>
i think Rust relies too much on compiler optimizations
<mq32>
it would be nice if zig had better compile times, but it's not worse either
<mq32>
debug builds are also reasonably fast
<fengb>
Yeah its LLVM IR output is really bloated
<shakesoda>
zig's build times have been okay for me, could certainly be better
<mq32>
go is doing a good job on showing "how fast can we actually be"
<fengb>
Zig will do better once we have our own backend
benjif_ has joined #zig
<betawaffle>
is there a difference between an extern fn and a (non-extern) fn with callconv(.C)?
<fengb>
I don’t think performance has been a priority because it’s stage 1
<shakesoda>
build times in general have informed a lot of technical decisions i've made over the years
<fengb>
I think extern function was replaced with callconv(.C)
<mq32>
<fengb> I think extern function was replaced with callconv(.C)
<mq32>
this
<betawaffle>
oh, so it's just deprecated syntax then?
<mq32>
yep
<mq32>
zig fmt fixes it also on some places already
<fengb>
Yeah zig fmt is replacing it
backwhack has joined #zig
<mq32>
i think build times should never be a concern when doing optimized builds
<betawaffle>
is there a build mode where it will complain about uses of deprecated things?
<fengb>
I honestly wouldn’t have noticed if zig fmt didn’t help me
<mq32>
betawaffle: nope
<mq32>
there'S no way to declare deprecation
<shakesoda>
is there an issue for that?
<mq32>
but for debug stuff, the build should be as fast as possible
<betawaffle>
we need tags...
<shakesoda>
declaring things like deprecation is very useful
benjif has quit [Ping timeout: 272 seconds]
<fengb>
I don’t think deprecation will be a priority before 1.0
<shakesoda>
it's incredibly useful for selfish reasons and not just standard library ones :)
<fengb>
Everything can change!
<mq32>
i'm not sure about "tags" as a language feature
<mq32>
i think we can do tagging completly in user space
* shakesoda
thinks of haxe's properties/attributes you can put on whatever (i think c#, too?)
<shakesoda>
my language bias is showing with that particular ordering
<companion_cube>
attributes/tags are really nice to have in the syntax though
<fengb>
Java has annotations. Python has decorators which can work as tags
omglasers has quit [Read error: Connection reset by peer]
zfoo_ has joined #zig
benjif_ has joined #zig
benjif has quit [Ping timeout: 272 seconds]
<metaleap>
as far as std-libs go, tricky to strike a good balance. .net framework or jdk feel to bloated and blown out of all sensible proportion, but "minimalist, fetch 100s of tiny pkgs and their endless nano-deps via yaml/json" is another ugly extreme as in js/ts. zig is the lovelier language vs go to me, but their stdlib approach has always impressed + satisfied me. yes json/http/sockets at least as a general / not-particularly-specialised/-use-case-optimized
<metaleap>
"reference edition" in a stdlib is *very* appealing. these have to be as omnipresent for current-day throwaways/rapid-iterative-prototyping as stdio/file-io has always been imho
<metaleap>
in the "you must be able to reach for said battery-included even on a desert island" sense.. tho putting it this way, maybe it isnt such a sane desire on 2nd thought :D
<shakesoda>
another concern is being robust against remote resources vanishing (which it sounds like has been considered in the issue about the package manager)
<shakesoda>
even if you aren't on a desert island, if what you originally needed just goes away you might as well be, and this isn't even slightly uncommon
<betawaffle>
sometimes i wish i was on a dessert island, yum
<Snektron>
a bit off-topic but i know there are some OS people here: i'm working on a small kernel with a friend, but the cpu errors when executing a far jump to set the cs register
<mq32>
is there already the change for "remove 'set to uninitialized in allocator interface'"?
<andrewrk>
seoushi_, and that has some zig code running too (e.g. if you ran zig fmt on a file, that would be zig code running on your phone)
<mq32>
andrewrk: how bad would you call my idea to store immutable strings with an allocator and pass a null-allocator (always returns OutOfMemory, free does nothing) to use it with string literals?
<andrewrk>
happy to discuss in a bit; I'm getting ready to stream
<mq32>
ah, oh!
<mq32>
have to watch the recording asap, don't have time to follow the stream atm
<betawaffle>
Snektron: explain?
<seoushi_>
andrewrk: yeah I don't have time at the moment to play with it more. the terminal on the device is a bit painful as well. atleast if you tap on a file from ls it will paste it into your current keyboard input
<seoushi_>
there is no tab so that really messes with me
<seoushi_>
one minor annoyance is that zig is packaged as a .xz would much rather see gz or bz since I had to install something that could extract 7z format
<fengb>
Or zstd? 😇
<andrewrk>
seoushi_, that's good to know, thanks
<seoushi_>
zstd? I was just trying tar -xf which fails. ended up install unar
<andrewrk>
xz is installed by default on many systems, good to know it was missing on this one
<andrewrk>
fengb, I'm ending up fixing a lot of async fn codegen bugs in this branch
<andrewrk>
for #4404
<pixelherodev>
xz > bz/gz :)
<fengb>
Arch has started its migration from xz to zstd. Might finally be the compression that replaces everything
<andrewrk>
for `./zig test ../test/stage1/behavior.zig --test-evented-io`, codegen completes, but then there are several missed spills to fix
<andrewrk>
getting close though!
<andrewrk>
the promise of no function colors is coming true
metaleap has joined #zig
<fengb>
Sweet!
<andrewrk>
this makes file system stuff automatically use a separate thread too
<andrewrk>
(when the os does not provide non-blocking file system I/O)
<fengb>
Oh so we can still simulate async manually?
wilsonk has quit [Ping timeout: 240 seconds]
<andrewrk>
not sure what you're asking
<betawaffle>
what's today's topic?
<fengb>
We can make it async using threads instead of a proper primitive
<andrewrk>
something fun
<mq32>
andrewrk: afaik a modern tar can extract xz by just using tar xf
<pixelherodev>
mq32, yes, but only if `xz` is installed
<betawaffle>
aww, i was hoping for something really dull
<pixelherodev>
Yeah me too
<mq32>
ah, good to know!
<pixelherodev>
mq32, try running that with a modified PATH so `xz` isn't present
<pixelherodev>
It's the same way its gzip decompression works
<mq32>
ah, so they just have convenience unwrap and re-execute :D
<pixelherodev>
Basically, `inline for (compression_methods) |c| { if (file.isCompressedWith(c)) { system(//decompress);}}` before the actual extraction