<mikdusan>
error: integer value 18446744073709551616 cannot be coerced to type 'usize'
<daurnimator>
hmmm. does that mean `allowzero` slices need to be bigger in `len` as well?
<pixelherodev>
No?
<mikdusan>
no
<pixelherodev>
Len can still be zero I think
<pixelherodev>
Well, depends how this is fixed
<pixelherodev>
Slices w/o allowzero could have "zero" set as maxInt(usize) + 1
<pixelherodev>
and then allowzero slices have zero as zero and require an extra bit
<daurnimator>
pixelherodev: well a length of `maxInt(usize)+1` would only be possible if the pointer was `allowzero`.
<pixelherodev>
Why?
<mikdusan>
i was trying to model memory and got irked thinking... ok idiom of `while (i < end)` is kinda bad. end has to be size_bits + 1 if we talk full range. and for loops/compares that sucks when it exceeds machine word size
<Kingsquee>
`while i > prev_i`
<Kingsquee>
although any loop that exceeds machine word size would be quite a loop indeed
<mikdusan>
xackus_: O dpm
<mikdusan>
xackus_: I don't know if it matters but ZigTypeIdUnreachable,
<Kingsquee>
@cInclude("foo") seems to be equivalent to #include <foo>, is there an equivalent to #include "foo"?
<mikdusan>
sorry, ZigTypeIdInvalid wasn't in error condition before, now it is
<xackus_>
i think you are looking at the wrong switch
<xackus_>
i deleted the second one because it was pointless
<xackus_>
zig type invalid is checked earlier in the function
klltkr_ has quit [Ping timeout: 272 seconds]
<Kingsquee>
so there's no current way to include a local file?
* Kingsquee
crickets :(
<xackus_>
mikdusan
frenata has quit [Quit: Leaving]
<pixelherodev>
Kingsquee: you want to addIncludeDir
<Kingsquee>
aaaAAA
<Kingsquee>
a skinner box
waleee-cl has quit [Quit: Connection closed for inactivity]
kevsmith has quit [Remote host closed the connection]
<Kingsquee>
can anyone help refine my best guesses?
<mikdusan>
`.install()` means from command line what is done during `zig build install`. so takin an artifact and `foo.install()` means foo registers to be installed
<pixelherodev>
Don't install the obj I think?
<pixelherodev>
Oh impd
<pixelherodev>
:P
<mikdusan>
zig_layer.run() ... hmm I'm not sure that makes sense.
<mikdusan>
not everything is "runnable" . don't equate run to "generic step.make()"
<mikdusan>
yes --> "Defines the zig run command?" ; without that "zig build --help" is not going to list any top-level step calle "run"
<mikdusan>
each run of an executable is setup as something "run" depends on
<mikdusan>
a sub-step
<mikdusan>
in turn, the exe.run() step depends on exe being installed (the exe's install step).
<mikdusan>
heh I'm thinking the default `zig init-exe` might have a quirk.
<mikdusan>
`run_cmd.step.dependOn(b.getInstallStep())` <-- the `run_cmd` is for 1 exe; 1 exe doesn't _have_ to depend on all installs being done, but it is safer and less trouble. but not as optimized if you know the exe is standalone in which case it's run only depends on it's own install
<Kingsquee>
mikdusan: thanks, I've commented out all the installs, the zig_layer_run, and all depends except the default_step
<Kingsquee>
and it seems to be giving me non-build-related errors now
<Kingsquee>
looking forward to zigbuild documentation o.o;
<Kingsquee>
pretty sure I have this relative path right
<xackus_>
mikdusan: thanks for the review. you're right, i was kinda lazy with the test
<Kingsquee>
is there a limitation imports with parent dirs?
<mikdusan>
xackus_: omit "note: referenced here"; they add little value and iirc, the expect-logic for compile-errors can tolerate skipping such things
<xackus_>
thanks, i didn't know that
<xackus_>
i saw them in other tests
<mikdusan>
imo an example of a good note to include in test scraping is "tmp.zig:1:17: note: consider 'union(enum)' here", even "note: Foo declared here" but "reference here" can be noisy
<xackus_>
yeah, i agree
<xackus_>
thank god for git rebase
<mikdusan>
git rebase is magic.
aerona has quit [Remote host closed the connection]
<Kingsquee>
went out on a limb ,but addIncludeDir doesn't seem to help
<Kingsquee>
so I guess import only works for absolute paths or subdirectories
<Kingsquee>
that's a pita
<mikdusan>
Kingsquee: @import is based on a main package root location. parents outside do not work. you can adjust main pkg root dir
<mikdusan>
Kingsquee: can you paste build.zig somewhere
<mikdusan>
in this case you have "src/engine/app/app.zig" as object,
<mikdusan>
so default mainpkgpath is "src/engine/app/"
<Kingsquee>
mikdusan: so by setting `zig_layer.setMainPkgPath("src")`, I should be able to just write "@import("game/start.zig")", right?
<mikdusan>
hmm... I think it has to be c_main.setMainPkgPath
<mikdusan>
whatever your main step is
<Kingsquee>
as in, the step that defines 'main()'?
<Kingsquee>
what's a main step
<mikdusan>
addExecutable
<Kingsquee>
I'm compiling C code as the executable and linking the zig object to it
<mikdusan>
oh wait one sec
<Kingsquee>
the @import in question is within the zig object
<mikdusan>
yeah it can be Library, Exe or Object. duh.
<mikdusan>
try it with zig_layer
<Kingsquee>
I've added both c_main.setMainPkgPath("src"); and zig_layer.setMainPkgPath("src");
<Kingsquee>
and in app.zig, const game = @import("game/start.zig");
<Kingsquee>
and I get "unable to find game/start.zig"
<mikdusan>
which file is importing "game/start.zig"
<Kingsquee>
app.zig
<Kingsquee>
the idea is main.c is the exe entry point, app.zig is the root of the engine-related code on the zig side, game.zig is the root of the game-related code
<Kingsquee>
app.zig is compiled to an object, main.c is compiled to an exe which links to the app.zig.o
reductum has joined #zig
<Kingsquee>
I'm doing it this way since sokol-app defines platform-specific main()'s, so all the zig stuff has to run on callbacks emitted from it
<Kingsquee>
I could just nest game/ inside app/, but finagling the filesystem is an odd hiccup to bow to
<mikdusan>
all build.zig stuff is via `zig build ...`
<mikdusan>
`zig run` is a lesser thing altogether. so `zig run` != `zig build run`
<Kingsquee>
oh, alright
<mikdusan>
if you want to manually run the artifact of a zig build,
cole-h has quit [Quit: Goodbye]
<mikdusan>
default install location iirc is zig-build/bin/ for executables
<Kingsquee>
I just wasn't clear on the difference
<Kingsquee>
and yeah, I'm a little perplexed about that right now
<mikdusan>
typo --> zig-cache/bin/
<Kingsquee>
because it's not putting it in the zig-cache/bin/ dir
ur5us has quit [Ping timeout: 260 seconds]
<Kingsquee>
it's putting it in the zig-cache/o/.../ dir
<mikdusan>
the object yes. but how about executable?
<Kingsquee>
yes, the executable
<mikdusan>
oh. heh; `zig build install`
<Kingsquee>
wat
<Kingsquee>
nope, no /bin/ dir
<Kingsquee>
oh there we go
<Kingsquee>
c_main.install();
<Kingsquee>
seems funny the exe is in the /o/ dir as well
<Kingsquee>
but...I guess this is success? :V
Patrice_ has joined #zig
<Kingsquee>
swing low sweet documentation
<mikdusan>
`zig build install` is like `make install` so it's duty is to always copy
<Kingsquee>
seems a bit pointless if all I'm doing is installing it to a peer directory
<mikdusan>
micro optimizations like `zig build no-install-run-foo` aren't really a priority yet
<Kingsquee>
kk
<mikdusan>
s/micro//
<Kingsquee>
one last thing, could you explain what stuff like default_step.dependOn implies?
<mikdusan>
`zig build` <-- what does that do?
<Kingsquee>
one step depending on another seems pretty obvious, but I have b.default-step.dependOn(zig_layer.step) and b.default-step.dependOn(c_main.step), which I would assume means c_main and zig_layer are compiled independently of each other
<Kingsquee>
obviously c_main depends on zig_layer completing first, but I haven't described that anywhere
<Kingsquee>
and yet it works
<mikdusan>
c_main.addObject(zig_layer);
<Kingsquee>
it's intelligent enough to detect that dependency?
<Kingsquee>
that's...nice
metaleap has joined #zig
<Kingsquee>
that's really nice :V
<mikdusan>
and it all takes advantage of zig's caching system;
<mikdusan>
zig's caching system is solid... and is pronounced "Chuck Norris"
<Kingsquee>
heh
<Kingsquee>
so in this case, I have the main.c including sokol.h, which defines the sapp_event struct
<Kingsquee>
in app.zig I have a fn to convert that sapp_event struct to an internal type, which means I cInclude sokol.h there as well
<Kingsquee>
this games me many redefinition errors
<Kingsquee>
(sokol_app.h, to be precise)
<mikdusan>
I think what's happening is you are forcing a sep compile of just .zig sources
<mikdusan>
which may or may not include c headers
<Kingsquee>
sure, but how is that a problem?
<Kingsquee>
should I just compile the c headers into their own object files and use them that way, instead of including? :I
<mikdusan>
hmm one sec. is .c or .zig responsible for the "main" symbol for executable?
<Kingsquee>
.c
<Kingsquee>
since they're included as headers in different binary files I didn't really expect conflicts
<Kingsquee>
(abstract situation: main.c includes foo.h, bar.zig includes foo.h, bar.zig is compiled into bar.o, main.c is statically linked with bar.o and compiled to main.bin)
<mikdusan>
i've done the inverted; .zig for main, and then exe.addCSourceFile to that exe
<Kingsquee>
(result is foo.h redefinition errors)
<mikdusan>
does c_main.addObject(..., "app.zig") work? and you'd need the c_main.setMainPkgPath too
<mikdusan>
oh never mind.
<mikdusan>
hmmm... I heard mention of this symbol thing before
<Kingsquee>
brb
_Vi has joined #zig
Amun_Ra has joined #zig
<Kingsquee>
and back
<Kingsquee>
...how do I write to stdout again
<Kingsquee>
std.debug.warn is invisible in my text editor build output by someone's infinite wisdom
metaleap has quit [Quit: Leaving]
cow-orker has quit [Ping timeout: 260 seconds]
reductum has quit [Quit: WeeChat 2.8]
marler8997_ has joined #zig
doublej472 has quit [Read error: Connection reset by peer]
CommunistWolf has quit [Ping timeout: 260 seconds]
iwq has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
drp has joined #zig
marijnfs1 has joined #zig
waleee-cl has joined #zig
dimenus has quit [Remote host closed the connection]
marijnfs_ has quit [Ping timeout: 260 seconds]
CommunistWolf has joined #zig
drasko has joined #zig
marijnfs_ has joined #zig
marijnfs1 has quit [Ping timeout: 272 seconds]
<oats>
I found the idea of kakoune really cool, but it was just too different from my cozy vim to make the change quickly and that was enough to send me back :P
marijnfs1 has joined #zig
cole-h has joined #zig
<oats>
huh, the logo changed a bit :P
marijnfs_ has quit [Ping timeout: 256 seconds]
<oats>
the icon is less squat and the G is stylized
<oats>
looks cool
<BaroqueLarouche>
which means my tshirt is now vintage
<ikskuh>
nooo
<ikskuh>
good thing i only printed Zero stickers
xackus_ has quit [Ping timeout: 265 seconds]
<Snektron>
hm, riot is still showing the old logo in the preview
<Snektron>
I wonder if thats some form of caching or if theres an old logo somewhere
<tdeo>
anyone want to review #5268 for me? :) it has a treewide zig fmt, which i hope i don't have to rebase too much
marijnfs_ has joined #zig
<grayhatter>
does zig have runtime introspection?
dingenskirchen has quit [Remote host closed the connection]
<tdeo>
what do you mean exactly? i don't think so
<marler8997_>
tdeo: async a callconv now, is there an associated proposal with that? If so, could you link to it in the PR?
<tdeo>
async callconv was already true
marijnfs1 has quit [Ping timeout: 264 seconds]
<ikskuh>
grayhatter: zig has no hidden types or fields except for debug mode
<marler8997_>
ok, so just removing "async fn" syntax, was that also in a proposal?
<ikskuh>
so for runtime introosepection, you have to write that in your code
<tdeo>
yesterday `19:35 <andrewrk> tdeo, yes it should be removed in favor of callconv(.Async)`
<tdeo>
i'll add that to the PR
<grayhatter>
can I list the members of a struct without enumerating them?
<marler8997_>
in your second example of "extern fn", you also have a function body...was that a typo?
<ikskuh>
grayhatter: huh, what do you mean?
<alexnask>
grayhatter, zig has compile time introspection, see @typeInfo
<tdeo>
yep, that is, thanks
<grayhatter>
context; I'm planning to write a lib that will at runtime generate a new binary logging format
<marler8997_>
so proposal is to remove "extern" as well
<tdeo>
no, you still need extern to import functions from c libraries
CantrellD has quit [Ping timeout: 260 seconds]
<tdeo>
oh mine
<tdeo>
yes, that's removing a feature without a proposal to do so
<marler8997_>
why do you still need "extern"? If you specify callconv(.C) and there's no function body how does "extern" further modify the prototype?
<tdeo>
i really don't think it was intended to stay in, after removing nakedcc and stdcallcc
<tdeo>
i don't think non-extern functions without a body are accepted
<tdeo>
but removing extern and allowing that makes sense imo
<marler8997_>
oh I see
<marler8997_>
so that woudl be another change
<tdeo>
i think i'll make a proposal to just remove extern entirely yeah
<marler8997_>
ok that makes sense
<marler8997_>
but
<marler8997_>
that might make your change ALOT bigger
<marler8997_>
harder to review
<marler8997_>
and more likely to get merge conflicts
<alexnask>
grayhatter, The docs on this are not great, I would suggest looking in builtin.zig for the full definition of TypeInfo and std.meta for example usage
<tdeo>
but i think an @import() would be more consistent with the rest of the language
<marler8997_>
that would work, is there a benefit to that over extern "..."?
<tdeo>
not really
<tdeo>
though you wouldn't always need the import
<tdeo>
just not having a body would be enough if it's not dynamically linked, which would be simpler
dingenskirchen has joined #zig
companion_cube has quit [Quit: WeeChat 2.3]
companion_cube has joined #zig
dimenus has joined #zig
<pmwhite>
how do I use a `const [125:0]u8` where a `[*c]const [*c]const u8` is expected?
<pmwhite>
taking the address of the first one yields `*const [125:0]u8`, which doesn't coerce to the second one.
<pmwhite>
Is @ptrCast all I can do?
<alexnask>
assuming 'a' is a [125:0]u8, `&[_][*c]const u8 {&a}` will coerce to `[*c]const [*c] const u8`
<alexnask>
I think that is the simplest way
<pmwhite>
it works if you remove the inner &
<pmwhite>
perhaps because `a` is actually a `const [125:0]u8`
<pmwhite>
Ah, I get it, this thing is asking for an array, not a single item.
<alexnask>
Yeah
<alexnask>
I don't think it should work without the inner '&' (and it doesnt in a simple godbolt example) since 'a' is an array, it cannot coerce into a pointer-to-array
<alexnask>
aka error: expected type '[*c]const u8', found '[125:0]u8'
<andrewrk>
marler8997, btw, maybe you want release-safe? crashing on unexpected errno is only enabled on debug builds
<marler8997_>
thanks for the quick merge
<andrewrk>
also I appreciate the explanation of why ETIMEDOUT can happen + story of it happening in the commit - that will be nice later when trying to figure out why certain errors are possible using git blame
<marler8997_>
I didn't actually mean crash, I mean, my program can't handle the unexpected errno and recover
<marler8997_>
sure thing
<andrewrk>
it seems like you're on board with the way zig does error sets and stuff, it's cool to see your project taking advantage of it
<marler8997_>
you learn to always include details like that when you've been doing this for over a decade :)
<marler8997_>
yeah the error control flow really helps create robust software
<andrewrk>
getting the error sets correct at the std.os level is doing the lord's work
<marler8997_>
lol
<andrewrk>
fuck that `error.Unexpected`, its very existence is a compromise
<andrewrk>
IMO the error set of OS syscalls should be part of the ABI
<marler8997_>
I'll keep that in mind when I get to writing my own OS :)
<andrewrk>
:D
<marler8997>
using zig error sets to define the kernel function interface would be interesting, of course, you'd have to use zig
<marler8997>
you'd have to define an ABI though...hmmm
<marler8997>
by the way, that qemu bug with mremap, been in qemu for 10 years
<andrewrk>
wow
<fengb>
Maybe it popped into existence retroactively after you found it
<marler8997>
It's specific to qemu user-host processes, makes me think it's not a very common usage of qemu
<andrewrk>
the zig project has been doing a pretty decent job exposing bugs in LLVM, qemu, wine, WSL...
<marler8997>
yeah, zig is actually using these tools. Before zig, things would just go wrong and no one knows what to do so they just give up
<marler8997>
I've had to give up so many times trying to do things with LLVM/qemu/wine/WSL
<andrewrk>
marler8997, should ETIMEDOUT be added to the other read functions as well? readv, preadv
<andrewrk>
maybe not the pread ones
<marler8997>
pread yes
<andrewrk>
you can pread from a socket?
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<marler8997>
For pread I'm just going off docs, it says it can fail, but I've never seen it
<marler8997>
haven't used readv/preadv so don't know
<tdeo>
what documentation? posix spec says pread can't return the network errors like wouldblock/timedout
<marler8997>
it specifically excludes pread from ETIMEDOUT and a few others
pystub has joined #zig
<ifreund>
my man says you can't pread from a socket
<marler8997>
yeah to be clear, I was wrong, you cannot call pread on a socket
<ifreund>
well, actually I think you technically can with a 0 offset
<ifreund>
but it's not really a pread then
benjif has joined #zig
<fengb>
andrewrk: do the upstream projects appreciate our bug reports? Or do they roll their eyes at us — "oh these guys again"
<marler8997>
actually, offset is supposed to be from "start of file", so pread with a 0 offset would be different than a read
<marler8997>
which makes it clear why it makes no sense on sockets
<andrewrk>
fengb, high quality bug reports with small reductions are seen as valuable contributions
<andrewrk>
this is a fairly universal truth afaik
<andrewrk>
it's certainly true for zig bug reports
<fengb>
I definitely agree Zig welcomes all sorts of bug reports. I've had some mixed results with other projects
<marler8997>
I find appreciation to be based on change quality. Does it explain what problem it's solving? Is it focused on a single issue? Has it been tested?
poga has quit [Ping timeout: 265 seconds]
<marler8997>
It can also be quite frustrating as a maintainer to waste time reviewing/dealing with poor quality pull requests
<fengb>
I have no idea how andrewrk stays sane going through some of the stuff on Zig :P
<andrewrk>
plot twist, I was never sane to begin with
ifreund has quit [Ping timeout: 265 seconds]
<marler8997>
"Let's make a new language"...said no sane person ever
<fengb>
But... "C++ sucks" says every person ever
<tdeo>
posted a new proposal about extern fn
<tdeo>
`extern extern fn foo() callconv(.C) void {}` is currently valid zig :)
ifreund has joined #zig
<fengb>
Hmm, with 1717 this probably makes the most sense: `pub extern "c" const foo = fn() allconv(.C) void;`
<fengb>
I typoed callconv
<tdeo>
still doesn't solve the function pointer problem though :(
<fengb>
Oh?
<fengb>
Oh shoot I see
<tdeo>
i really want 1717 soon
<tdeo>
but i don't have a solution to the function pointer problem either
<tdeo>
i think changing function pointers to *fn explicitly makes the most sense, but still has some drawbacks as mentioned
<tdeo>
in the issue
<fengb>
We should do it the C way: `int (*)()` == `int (********)()`
<fengb>
All the indirections are the same!
drasko has quit [Ping timeout: 246 seconds]
<alexnask>
Every subset of C++ that does not match the subset I use is grabage /s
wootehfoot has quit [Ping timeout: 260 seconds]
drasko has joined #zig
[RMS] has joined #zig
drasko has quit [Quit: Leaving]
ifreund has quit [Ping timeout: 256 seconds]
ifreund has joined #zig
metaleap has quit [Quit: Leaving]
Kingsquee has joined #zig
lanodan has quit [Ping timeout: 256 seconds]
lanodan has joined #zig
ifreund has quit [Ping timeout: 272 seconds]
ifreund has joined #zig
<Kingsquee>
so, I'm trying to use the platform-specific main()s defined by sokol_app.h
<Kingsquee>
cImport related stuff doesn't seem to work, if only because it doesn't translate properly
<Kingsquee>
so I'm trying to find alternate ways of making this work
<Kingsquee>
the best solution I've come up with is to make a 'main.c' which just #includes sokol_app.h and forwards the callbacks to 'everythingelse.zig'
<Kingsquee>
but 'everythingelse.zig' can't cInclude sokol_app.h without getting redefinition errors
<alexnask>
You could try defining SOKOL_NO_ENTRY before the import and using zig's main instead AI think
<Kingsquee>
which seems to imply I'll have to wrap all the C types in order to use them from Zig
<Kingsquee>
but wrap them using the C abi, so any zig-friendly tagged enums etc would require wrapping them *twice*
<Kingsquee>
so I'm obviously trying to find another way to do this
<Kingsquee>
alexnask: but does zig's main do emscripten and android and ios and all that with zero effort?
<Kingsquee>
because that's the desirable result of offloading to sokol_app
<Kingsquee>
I've already written some of those before and I'm keen to avoid repeating the experience
<alexnask>
Not sure about android but I think the rest works fine. If you look in start.zig you can see all the logic, if you are linking libc zig provides a regular main function that calls into the zig main
<Kingsquee>
Wanted: Android Developers Flesh out the standard library for Android. Streamline the process of using Zig to build for Android and for depending on Zig code on Android.
<Kingsquee>
so it sounds like zig's android entry point is intended to be minimal-bullshit
<Kingsquee>
so guess I'll trust that
ifreund has quit [Ping timeout: 272 seconds]
Chris660 has quit [Ping timeout: 272 seconds]
ifreund has joined #zig
Akuli has quit [Quit: Leaving]
Snetry has quit [Quit: left Freenode]
Snetry has joined #zig
dddddd_ has joined #zig
dddddd has quit [Ping timeout: 258 seconds]
dimenus has quit [Remote host closed the connection]
ifreund has quit [Ping timeout: 246 seconds]
pystub has quit [Ping timeout: 256 seconds]
jmiven has quit [Quit: bye]
jmiven has joined #zig
marijnfs_ has quit [Quit: Lost terminal]
<Snektron>
<andrewrk "also I appreciate the explanatio"> I think i ran into a case with another syscall that has incorrect handling
<Snektron>
let me look it up
reductum has joined #zig
<Snektron>
oh nevermind, it is handled correctly
kevsmith has joined #zig
<Snektron>
<tdeo "still doesn't solve the function"> It seems to me that Spex_Guy's latest comments resolve all problems
<kevsmith>
does zig have anything like the __FILE__ and __LINE__ macros in C?
<Snektron>
i don't think so
<kevsmith>
i didn't see anything in the docs or in code so i thought i'd ask make sure i didn't miss something obvious. thanks!