<pixelherodev>
andrewrk: guess what I did today? :D
<pixelherodev>
#5422 is just about ready to merge :)
marijnfs has joined #zig
<pixelherodev>
Tests pass locally, and I was able to enable one of the ones that was previously failing :)
<pixelherodev>
Fully rebased against master, I removed some of the changes you added and replaced with a wrapping API over ZIRCases
<pixelherodev>
Altered the error testing implementation to more closely match the one you added
marijnfs_ has quit [Ping timeout: 264 seconds]
gazler__ has joined #zig
gazler_ has quit [Ping timeout: 258 seconds]
reductum has joined #zig
redj has quit [Ping timeout: 260 seconds]
redj has joined #zig
Stephie has quit [Ping timeout: 240 seconds]
<andrewrk>
pixelherodev, nice!
Stephie has joined #zig
<andrewrk>
in other news, the compile error "TODO: type coercion of anon struct literal to struct" is gone
<daurnimator>
yay!
<daurnimator>
there's a couple of verbose places around dealing with std.json.StringifyOptions and std.LinearFifo.LinearFifoOptions that should be made terse
waleee-cl has quit [Quit: Connection closed for inactivity]
<mq32>
it *should* pass the right args, but it doesn't
<ifreund>
what'd git do this time?
<tgschultz>
I'm sure it's doing what it is supposed to do, that's just not what I need it to do for my simple use case. I worked it out though by just forcing the push.
<pixelherodev>
andrewrk: would I encounter any issues trying to use ZIR for e.g. C?
factormystic has quit [Read error: Connection reset by peer]
shakesoda has quit [Quit: Connection closed for inactivity]
factormystic has joined #zig
<ifreund>
hmm, how far along is the testing framework for stage2? Would turning all the open issues for stage1 bugs into stage 2 tests be a helpful thing to do?
<ifreund>
i mean they would be disabled by default until stage2 supports the features of course
<pixelherodev>
ifreund: as of this morning, pretty good :)
<pixelherodev>
But no, that's not useful yet
<pixelherodev>
We need the Zig AST -> ZIR PR merged first
<pixelherodev>
Once that's done, I'll extend the test harness to support testing Zig source instead of ZIR
<pixelherodev>
Then we can worry about stage1 tests
<ifreund>
ah yeah right, we're still in ZIR land
<pixelherodev>
Not for long :D
<pixelherodev>
Andrew has the AST -> ZIR PR open
<ifreund>
i know, things are moving!
<pixelherodev>
Yeah, it's really nice
<pixelherodev>
I'm going to try to get function calls with arguments finished today
<pixelherodev>
Then any other PRs I may have open
<pixelherodev>
Then I'm going to alternate between tackling more ZIR work, finishing and simplifying the testing framework (adding convenient API wrappers), and my alternate stage1
<scientes>
pixelherodev, in C++?
<pixelherodev>
No.
<pixelherodev>
C.
factormystic has quit [Read error: Connection reset by peer]
<pixelherodev>
I'm not using LLVM for this, I'm using ZIR.
<scientes>
oh gotcha
<pixelherodev>
and I want a compiler that doesn't depend in >4M lines of C++
<pixelherodev>
s/in/on
<ifreund>
heh, found myself a nice workaround for the c_void issue https://paste.rs/iSM
<pixelherodev>
I have an intense dislike for LLVM after the LLVM 10 nonsense
<scientes>
pixelherodev, but then you don't have an optimizing compiler
<pixelherodev>
Unless, and here's a thought
<pixelherodev>
a) I write basic optimizations myself
<scientes>
pixelherodev, and the CPU has far more lines than that....
<pixelherodev>
b) I don't care to optimize all that much
<pixelherodev>
and c) it's only intended to build stage2, so performance is irrelevant
<ifreund>
i mean the goal of stage 1 is just to build stage2 right
<pixelherodev>
The idea is to do only very basic optimizations
<pixelherodev>
Enough that the build stage2 is at least reasonably useful
<pixelherodev>
And can then build itself in a reasonable timeframe
<ifreund>
leeward: only in zig can you do shit like this to work around compiler bugs :D
<pixelherodev>
Here's the kicker though
<pixelherodev>
This is going to be part of my project tricarbon
<pixelherodev>
Which means, any optimizers I write for this will be usable for my other projects
<pixelherodev>
and vice versa
<ifreund>
nice so it's gonna be ZIR -> RISC V in C?
<pixelherodev>
I might do that
<pixelherodev>
It's multiple components
<pixelherodev>
First, Zig parser / AST builder
<pixelherodev>
Second, AST -> ZIR
<pixelherodev>
Third, comptime executor
<pixelherodev>
Fourth, ZIR backend
<ifreund>
right, comptime
<pixelherodev>
Each one will be usable on its own
<pixelherodev>
So the comptime executor will be able to be integrated into stage2 for instance
<vroomerify>
Sorry to interject here -- I'm a new-comer attempting to build zig from source. When I run "cmake .." it says (missing: CLANG_LIBRARIES), I'm running Arch Linux and I've installed "llvm", "clang", and "lld", so I thought I had everything installed, but apparently not. Do I need to set an environment variable?
<scientes>
leeward, yeah I've done similar stuff
<pixelherodev>
vroomerify: That's the LLVM 10 stuff I was whining about earlier
<pixelherodev>
You need to set CLANG_somethingorother_DYLIB in CMake
<scientes>
leeward, also its invalid because you need to do *align(4) u32
<scientes>
oh nvm
<pixelherodev>
Or LLVM_somethingorother_DYLIB maybe?
<scientes>
I mean ?*align(4) c_void
<scientes>
or *align(1) u32
<ifreund>
vroomerify: from the arch PKGBUILD you need -DZIG_PREFER_CLANG_CPP_DYLIB=ON
<ifreund>
idk why you need it on arch, i don't need it on void
<ifreund>
well i do know why, llvm 10 is slightly broken
<vroomerify>
ifreund / pixelherodev, thanks for the heads-up. When you say PKGBUILD, are you referring to a file in/associated with the zig package for arch?
<scientes>
basically regexp-style optimizations in LLVM which means that the speed does not slow down so much as you add more optimizations
<rom1504>
I'm following the project and wondering what's the thing that could make zig really used by people. It seems having a package manager would be a good feature. I see it's planned but apparently a second priority to the self compiler. A bit confused about that. What does self compiling provides ? (In addition to being cool)
<scientes>
rom1504, a cmopiler is a really good proof that the language is in decent shape
<scientes>
go-lang is one of the few that seriously delayed self-hosting
<pixelherodev>
self-hosted compilation is a must for any language that wants to be taken seriously
<ifreund>
also there's good reason to prefer writing code in zig over c/c++
<rom1504>
Ok, so you'd say being able to self compile is a blocker for people starting to build things with zig ?
<rom1504>
I can imagine along the path of building a self compiler the language might change and it could explain the blocking part
<rom1504>
One of the biggest weakness of c and c++ is how annoying it is to use and combine dependencies (and publish new packages), so that's definitely something that would make people consider using zig (to have a package manager)
<rom1504>
And all new languages have some kind of package manager (with more or less success)
<rom1504>
But I see zig is developing quite nicely, I guess Andrew has a big plan :)
<pixelherodev>
Eh, I actually prefer that C projects tend to have fewer dependencies
<pixelherodev>
A package manager is all well and good, as long as we don't turn into Cargo / NPM / etc
<afontain_>
also, I'd appreciate if it coud play well with distribution package managers. For example, it shouldn't try to download dependencies from the internet (python and cargo tend to do that). It also shouldn't be too anoying about version requirements: breaking ABI "just because you can" isn't nice, nor is using an outdated version of the dependency just because you can ask the package manager to use the old version.
<afontain_>
(note that using outdated dependencies is also a problem in the C world)
<pixelherodev>
Working with distribution package managers is a must for me
<pixelherodev>
I won't touch any packages that don
<pixelherodev>
't
<ifreund>
yeah same
<afontain_>
(breaking ABI is also something that exists in the C world, but soname differences mitigate that)
<ifreund>
C packaging is pretty messy tbh, theres a reason there are so many different takes on package managment
<scientes>
ifreund, not as messy as it is diverse
<ifreund>
but yeah I want distro packagers to be pleasantly surprised by zig packaging not cursing it
doublex has quit [Ping timeout: 244 seconds]
<ifreund>
scientes: it could be argued that the diversity stems from the fact that there's no knockdown way to do it well
<pixelherodev>
ifreund: it could also be argued that it's because there *is no right way*
<pixelherodev>
Some languages try to enforce their "correct way"
<pixelherodev>
it never ends well.
<ifreund>
fair
<scientes>
pixelherodev, the problems come with naming too many namespaces in too many places
<pixelherodev>
?
<scientes>
like how C developed a need for header files (which isn't part of the language), because of how declarations need to be forward declared
<scientes>
which was all about supporting extremely-low-memory systems
<leeward>
C needs header files because interfaces shouldn't live with specification, and tooling didn't exist in the '70s to auto-generate documentation from code.
<scientes>
leeward, but it isn't part of the language
<leeward>
That's a matter of semantics.
<leeward>
Or are you talking about the preprocessor's #include?
<ifreund>
that's how headers work yeah
<ifreund>
headers are part of the preprocessor not C
<scientes>
sometimes I write C with #include "foo*.c*"
<scientes>
just to make it simpler
<leeward>
CPP is specified in the standard.
<leeward>
That's how C99 got to have variadic macros.
<pixelherodev>
scientes: that's... questionable, to say the least
<andrewrk>
xackus, yes, one maps to the text format, one is an in-memory format, but can be serialized to the text format
<pixelherodev>
Ooh, idea
<pixelherodev>
A zig build system port to C
<pixelherodev>
It's straightforward enough to be pretty simple
<pixelherodev>
Better yet, @export it
<pixelherodev>
A C API wrapper
<ifreund>
the point is to be able to write a build.c instead?
<pixelherodev>
Yeah
<ifreund>
idk, i'd rather just write it in zig :D
<pixelherodev>
The idea is for my stage1 compiler
<pixelherodev>
and potentially the official one
<pixelherodev>
Remove the dependency on CMake
<leeward>
I don't think the world needs another build system, but I don't write code on Windows so I can just use Make.
tdc has quit [Ping timeout: 256 seconds]
<companion_cube>
or ninja
<pixelherodev>
^
marnix has joined #zig
<leeward>
If I'm using ninja, it's wrapped in Make and I don't have to know about it.
<leeward>
:P
<pixelherodev>
Uh, what?
<scientes>
make is gross
<pixelherodev>
That's... yeah
<pixelherodev>
Make is awful
doublex has joined #zig
<pixelherodev>
Ninja is waaay better
<leeward>
Make is good at its job; it's just very old.
<companion_cube>
leeward: you can genrate ninja from zig
<pixelherodev>
The idea is a simple build system with no dependencies other than a C compiler - no CMake, no python (Meson), etc
<pixelherodev>
leeward: ninja is much better at Make's job
<pixelherodev>
lol
<scientes>
but ninja can't call ffi
<scientes>
anyways, its about data structures and algorithms
<scientes>
not names of things
<leeward>
pixelherodev: Ninja is much newer than Make, and it's not as good at the job of having humans edit it.
<pixelherodev>
True
<ifreund>
make isn't bad at all for simple projects
<leeward>
It's fine, but when I write a 20-line C program it comes with a Makefile.
<ifreund>
i quite like meson for larger C/C++ things though
<scientes>
I like writing zig where you don't need any build system
<scientes>
just a build-exe or build-lib
<scientes>
THAT is the way it should be done
<pixelherodev>
lol
<pixelherodev>
no
<pixelherodev>
For the same reason cproc shouldn't be invoked directly
<fengb>
If we adopt gopath way, that could be achieved :P
<pixelherodev>
Nobody wants to repeatedly type out `$COMPILER $SOURCES -o $OUTPUT $FLAGS $LIBRARIES` repeatedly
<leeward>
pixelherodev: Yeah, I get why we have zig build, and I'm not too cranky about it (still a little cranky) but the "no extra programs" thing is kinda weak. You can always just build the program that builds your code along side the compiler, or as part of it, and use a DSL for specifying DAGs.
<pixelherodev>
`ninja` / `make` / `zig build` is totally fine
<scientes>
except build.zig is equilivent to wget foo.sh; sh foo.sh
<pixelherodev>
scientes: how so?
marnix has quit [Ping timeout: 256 seconds]
<pixelherodev>
leeward: what "no extra programs" thing?
<leeward>
pixelherodev: build.zig only depends on the zig compiler, right? Make only depends on a C compiler if you have a source distribution.
<ifreund>
scientes: if you're doing that you could just add the #!/bin/zig run shebang and chmod +x
<pixelherodev>
leeward: the build system, yeah, but you *can* depend on other programs too if you need to
<ifreund>
i think you need slightly more that in the shebang though
<pixelherodev>
For sure
<pixelherodev>
That wouldn't work correctly, I don't think
<pixelherodev>
Yeah no
<leeward>
Shebangs don't like lots of command line arguments.
<pixelherodev>
You need `zig build` because you need the build_runner
<leeward>
#!/bin/zig-repl though
<pixelherodev>
#!/usr/bin/zig-build
<ifreund>
this works for me:
<ifreund>
/bin/zig run $0 ; exit
chapl has joined #zig
<ifreund>
oops, should be one more / at the beginning
<chapl>
andrewk, are you there?
<chapl>
I misspelled his name. Omg. @andrewrk
<andrewrk>
hello
<chapl>
You just were in the Discord. I wanted to ask you if you could help us solve the Zig + JNI issue for Windows.
<chapl>
@andrewrk
<andrewrk>
you have my divided attention
chapl has quit [Quit: Leaving]
riba has quit [Ping timeout: 256 seconds]
vroomerify46 has joined #zig
vroomerify46 has quit [Remote host closed the connection]
vroomerify has quit [Remote host closed the connection]
vroomerify has joined #zig
redj_ is now known as redj
<vroomerify>
Where is the current code for building glibc, I'm assuming it's all in glibc.cpp? I'm trying to get a feel for this issue: https://github.com/ziglang/zig/issues/4313
<vroomerify>
Full-disclaimer, I know nothing about this topic, but I figure the best way to learn is to attempt to solve the issue.
haliucin1s has quit [Read error: Connection reset by peer]
haliucinas has joined #zig
wootehfoot has joined #zig
<pixelherodev>
andrewrk: what's the progress on AST -> ZIR? Estimated timeline for merge?
Barabas has joined #zig
<Barabas>
Good evening!
<ifreund>
o7
<Barabas>
I'm having trouble finding my way around getting the command line arguments and opening a file.
<Barabas>
and now I found that we have a `getCwd` in `std.process` but there's also `cwd` in `std.fs`
<ifreund>
for getting the args your program is passed `std.process.args()` will return an iterator
<ifreund>
for opening a file you generally do `std.fs.cwd().openFile()
<Barabas>
Thanks
<ifreund>
if you're on a posix system you can also get the args directly with std.os.argv
<Barabas>
I am not.
ur5us has joined #zig
<leeward>
So I'm trying to cross compile an SDL application for Windows, and it looks like I'm missing a library called Mmtimer. It's the one with timeBeginPeriod and timeEndPeriod. Is this a thing the Zig distribution should provide? It seems like it might be part of mingw.
<Barabas>
It feels like the error on the `std.process.ArgIterator.next` is at the wrong level. I expect to be able to do `while (try it.next(allocator)) |next_arg|` not ehm... whatever it is I have to do now :P
<ifreund>
that looks awkward indeed, i always us posixNext() cause my stuff doesn't support windows. Let me try and find a clean way
<Barabas>
ifreund: Thanks! That looks better indeed.
<Barabas>
Apart from relative paths not really working on windows I just have to figure out why my json that was in a static string and now in a file suddenly doesn't work anymore.
<Barabas>
Oh cool, that was just me.
puzzleddev has quit [Quit: Leaving]
dermetfan has quit [Ping timeout: 272 seconds]
nikita` has quit [Quit: leaving]
xackus has quit [Ping timeout: 265 seconds]
return0e[m] has quit [*.net *.split]
hamoko[m] has quit [*.net *.split]
<Barabas>
Thanks guys and good night :)
<ifreund>
night!
sammich has quit [*.net *.split]
pltrz has quit [*.net *.split]
Snektron has quit [*.net *.split]
ky0ko has quit [*.net *.split]
rom1504 has quit [*.net *.split]
Barabas has quit [Ping timeout: 245 seconds]
<andrewrk>
pixelherodev, hopefully today, workin on it
ky0ko has joined #zig
sammich has joined #zig
Snektron has joined #zig
rom1504 has joined #zig
pltrz has joined #zig
<ifreund>
who needs @Type(.EnumLiteral) when you have @TypeOf(.foobar) :D