hnOsmium0001 has quit [Quit: Connection closed for inactivity]
tefter has joined #zig
<ifreund>
andrewrk: no problem! I'm looking at SliceOpen and Slice next :)
wootehfoot has quit [Ping timeout: 256 seconds]
jokoon has joined #zig
Swahili has joined #zig
zags has joined #zig
<ifreund>
slices done, probably look at catch in hour or two
Kiori has joined #zig
tefter has quit [Ping timeout: 265 seconds]
<Kiori>
Hi all, has anyone used zig to compile C apps?
<ifreund>
sure
<ifreund>
just do CC="zig cc"
<Swahili>
Learning; trying to figure out how to convert string to int and vice-versa; so found fmt and digitToChar; and tried> const chr = std.fmt.digitToChar(65, false); const result = [_]u8{ chr }; print("Result is {s}\n", .{result}); and get thread 441451 panic: reached unreachable code
<Swahili>
what should I learn to figure this out?
<Kiori>
I'm trying to figure out how to compile sdl with zig as a c comp. Does zig behave like llvm?
<ifreund>
Swahili: for string to int, see std.fmt.parseInt()
<ifreund>
for the other way, std.fmt.bufPrint() or std.fmt.allocPrint()
<ifreund>
Kiori: indeed, zig relies on libclang to compile C code
<Swahili>
ifreund: thanks for looking! yeh, I saw a github comment showing std.fmt.bufPrint(buf, "{}", .{int}); but I think I should really go through the basics to figure this things out myself, as my bg is as3, php, then javascript...did some swift in the past :~))
<Swahili>
I had a quick look on comptime yesterday, but I haven't yet reached that point yet :)
<Kiori>
@ifreund is there any special setup i should know about before trying to link any lib, or should it just work? thanks for the reply btw.
<ifreund>
Kiori: the intention is that it is a drop-in replacement. Barring any bugs you shouldn't need to do anything special
<ifreund>
just give it a try and see if it works
<Kiori>
ok, i'm figuring it out atm. I'll come back if I hit any walls.
<Kiori>
thanks again
<zags>
I wonder if it would be possible a Zig optimizer to encode the length of a slice in the upper pointer bits when it can prove the slice doesn't escape.
<zags>
And it can prove the length fits in the bits. Highly arch dependent of course.
<Gliptic>
that would add masking to every operation
<Gliptic>
not obviously an improvement
<zags>
even intel cpu's are getting support for that
<ifreund>
note that's for master though, you might be using 0.7.1
<Swahili>
latest 0.8.0 :) Thanks, I'll read
<Swahili>
So, in the future, we'd find the documentation for fmt in the main web docs and figure this out without having to check the source code. Right?
mikdusan has quit [Quit: WeeChat 2.5]
<Swahili>
I think yesterday it was mentioned that is a good practice to check the source code
<ifreund>
Indeed, autogenerated std docs are not yet ready for usage
<ifreund>
this is certainly something that will be done sometime before 1.0 though
<Swahili>
It'll look great I'm sure :)
<Swahili>
I had a look on ( https://ziglang.org/documentation/master/#Doc-comments ),since this is documented; I guess that this same tool that'll be used for "autogenerating std docs" can be used for the rest of us? : )
<mikdusan>
oh yeah you just did correct what I was trying to suggest. lol
<mikdusan>
btw I also tried converting inline_for to inline_while and bug still persists
<ifreund>
that usually only helps when the values of the container being iterated are runtime known but the length is comptime known
<mikdusan>
sure just checking on the chance
<ifreund>
fair enough, you never know with stage1 :D
marijnfs has joined #zig
<marijnfs>
what happened to @TagType
<ifreund>
marijnfs: std.meta.TagType() i'd guess
<marijnfs>
thanks!
<mikdusan>
marijnfs: nice. Is the meta info rich enough to apply a integer literal style? like FILE_ATTRIBUTE_INTEGRITY_STREAM = 32768 looks much better in our existing windows bits.zig as 0x8000
<ifreund>
I think you mean to tag marler8997 :P
<mikdusan>
whupsee. marler8997 ^^ 2 lines above was meant for you.
<marler8997>
@TagType?
<mikdusan>
I mean hey I did the first 3 chars and tab-completed :|
<marler8997>
oh the integer stuff
<marler8997>
the metadata just contains the raw values, we'd have to apply our own rules/tricks to do that
<mikdusan>
any way to heuristic that it's flags? flags usually want to be hexed
<marler8997>
good question, not that I'm seeing in the metadata
<marler8997>
we could go through all the values of an enum and if they are all powers of 2 them assume they are flags and print them in hex
<marler8997>
ilspy prints them as hex, should find out what ilspy is doing
<mikdusan>
ah ok. was hoping for something we could key off from meta. not very important but if you see a straightfwd way...
<marler8997>
looks like ILspy might print all powers of 2 >= 16 as hex
<marler8997>
right now I'm trying to deal with the UnicodeAlias part, I'm getting a dependency loop
<ifreund>
hopefully it's not #131
<marler8997>
nah
<marler8997>
current solution is to check if the root modules defines UNICODE=true/false...then set the aliases accordingly
<marler8997>
I shouldn't be getting a dependency loop from it
<ifreund>
andrewrk: bounced of for/if statements for now, partially due to an issue I found with lastToken() on blocks. Poking at error set decls now
<ifreund>
s/of/off/
zags has quit [Ping timeout: 272 seconds]
<andrewrk>
roger that
<andrewrk>
I'm still on asm
<ifreund>
cool, have fun :)
<andrewrk>
I think we have enough implemented to run a small zig fmt benchmark and see how this pays off, if at all, for zig fmt
<andrewrk>
noting however that the main speedup is intended for the main pipeline, not this one
<ifreund>
I don't think it's ready for any real code yet tbh, but some artficially selected code sure :D
<ifreund>
RE the issue with blocks, if the last statement ends in a semicolon lastToken() is off by one
<ifreund>
I guess we need to add BlockTwoSemicolon and BlockSemiColon?
<andrewrk>
yep guess so
<andrewrk>
it's kind of annoying, but, in terms of what the hardware is doing I think it's pretty ideal
<v0idify>
how does zig plan to address the chicken and the egg problem: what minimal compiler can we start off that's humanly auditable, or will it always depend on an initial C++ compiler? i'm thinking in the line of this: https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/
<ifreund>
that may realistically never happen though, the current plan is to depend only on C not C++ for the bootstrap compilier by 1.0
<v0idify>
"the evil plan to replace C" I love it
<v0idify>
but I agree, starting off from a C compiler is not that bad
zags has joined #zig
<v0idify>
is there a good explanation of the two stages? does stage 1 not depend on LLVM? I'm confused
<ikskuh>
stage0: 100% c++
<ikskuh>
stage1: part zig, part c++
<ikskuh>
stage2: 100% zig
<ikskuh>
stage3: stage2 compiled with stage2
<v0idify>
that makes sense
<v0idify>
stage0 uses LLVM right now but it's supposed to not do that in the future right?
<ifreund>
stage2 has non-llvm backends in progress
<ikskuh>
v0idify: the idea is that stage2 will output stage2 as C code
<v0idify>
oh, so it also skips steps!
<pixelherodev>
I'm also working on an alternate compiler in C99 that's completely self-contained ~~and wipes the rootfs if it detects that it is linked againsts LLVM~~
<pixelherodev>
Not much to see there just yet, as I spent a month or so just focusing on design, but I'm hoping to pick up the pace this week :)
<zags>
:)
<ifreund>
andrewrk: error set decls and the slice/slice sentinel split are up, going to take a look at splitting out BlockSemicolon and BlockTwoSemicolon now
<v0idify>
pixelherodev, awesome!
<motiejus>
hi folks. I am trying to compile `Yelp/dumb-init` with `zig cc`, and am getting: `zig: error: argument unused during compilation: '-s' [-Werror,-Wunused-command-line-argument]`
<motiejus>
if I remove `-s`, it works; but both clang and gcc happily accept that option
<motiejus>
`0.8.0-dev.1039+bea791b63`
<motiejus>
is it just missing a flag? If yes, I can go ahead and submit a patch; but perhaps I am misunderstanding something here
<andrewrk>
it was documented, I just didn't see it at first
<v0idify>
andrewrk, wow i understand nothing on that website
<v0idify>
my question was more on the line of: "I have no clue what atomic I/O is"
<v0idify>
I think I'll just use a Mutex for now though
<andrewrk>
I have never heard of atomic I/O
<andrewrk>
if this atomics docs don't make sense to you, then yes I suggest to stick to the higher level concurrency primitives
<v0idify>
sorry I don't know what's the name for this.. thing
Akuli has quit [Quit: Leaving]
<motiejus>
andrewrk: I compiled it and retried, same result: https://paste.mozilla.org/ss2FEjPQ ; I used the 'mkdir build ; cd build; cmake ..; make' ; do I need to wipe caches?
<g-w1>
yep, im getting that too with the latest version
ur5us has joined #zig
<g-w1>
oh wait, zig cc is broken now :(. `zig cc test.c` results in a bunch unused argument -s for me where test.c is int main() {return 0;}
<mikdusan>
sounds like -s should only be spec'd for link
<andrewrk>
I see the problem
<andrewrk>
ok fixed in latest commit, sorry about that
<andrewrk>
motiejus, I tested dumb-init, it builds cleanly now
<andrewrk>
thanks for the report
<ifreund>
fixed Tree.lastToken() for blocks :)
<andrewrk>
wonderful
<andrewrk>
and I see Vexu did some work on introducing an intermediary AST for translate-c which is going to make that part of the task straightforward
<andrewrk>
finally, astgen should be a piece of cake since we can call those same ast "full" functions
<ifreund>
yeah, though someone called the namespace for those "Full" instead of "full"... basically unusuable :P
<ifreund>
I think the API they provide is even nicer to use than what the old code had :)
<andrewrk>
oh right, oops, I violated the style guide=
<zags>
I have a function taking function ptr, argument is callback: anytype - I then try to query it's RETURN type through @typeInfo(@TypeOf(callback)).Fn.return_type.? ... unfortunately, I get `error: unable to unwrap null` Ideas?
<ifreund>
We want to snake_case the token and node tag enums too right?
<ifreund>
probably push off all the style bikeshed untill everything works right before merge
<zags>
oh wait, I can introspect anytype can I?
<zags>
can't"
<ifreund>
zags: you can introspect the concrete type that actually gets passed to the function
<zags>
So basically I need a way to pass any two-arg function to a generic function and introspect the return type, hmm
<ifreund>
does null mean void or something? not sure
<zags>
i never pass functions returning void though
<ifreund>
notice that you aren't getting an error saying it's not a function
<zags>
yep
riba has quit [Ping timeout: 246 seconds]
craigo has quit [Quit: Leaving]
ur5us has quit [Ping timeout: 258 seconds]
jeyr has joined #zig
jeyr has quit [Client Quit]
<andrewrk>
ifreund, yeah I'll do a style pass right at the very very end before merging
<ifreund>
cool :)
<ifreund>
I'm looking at break now by the way
<andrewrk>
got it
wootehfoot has quit [Quit: Leaving]
<andrewrk>
we'll want to do a pass to look for TODO comments too I think
<ifreund>
indeed, I've left a few myself
<ifreund>
though I don't think the many still-commented test cases will pass without most or all of them being resolved
<andrewrk>
got it
cole-h has joined #zig
notzmv has quit [Remote host closed the connection]
<andrewrk>
man, we could have saved a lot of time by doing it this way from the beginning, heh
<andrewrk>
but all in all this is only going to eat a couple weeks, peanuts in the lifetime of the project
<andrewrk>
one of the nice things about zig is that we don't have a deadline for 1.0 and we also don't have a big debut. we can slowly start to stabilize more and more, and support more and more use cases. declaring 1.0 will feel like nothing is actually changing
Kiori has joined #zig
notzmv has joined #zig
<ifreund>
I mean, 1.0 will be pretty exciting nonetheless :D
<ifreund>
but yeah, we have the rare oppurtunity to iterate as much as we want and dodge those pesky local maxima
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]