return0e has quit [Remote host closed the connection]
return0e has joined #zig
cncl has quit [Read error: Connection reset by peer]
return0e has quit [Remote host closed the connection]
strmpnk has quit [Read error: Connection reset by peer]
tracernz has quit [Read error: Connection reset by peer]
return0e has joined #zig
zfoo has joined #zig
tracernz has joined #zig
cncl has joined #zig
strmpnk has joined #zig
<daurnimator>
What's the elf header with the stack size again?
<shachaf>
For what platform?
<shachaf>
I think GNU_STACK nominally has it but Linux ignores the value and I don't know anywhere where it's used.
dch has joined #zig
<daurnimator>
shachaf: I'm chatting with linux people now and seeing if they want to fix that
<daurnimator>
anyone remember what the field is?
<daurnimator>
PT_GNU_STACK seems to just be a flag for executable or not?
<shachaf>
I think there was some idea of using the size field to specify the stack size.
<shachaf>
But as far as I know no one actually does that and it's just left blank.
<daurnimator>
oh found an LLVM patch that adds it to p_memsz in PT_GNU_STACK
tracernz has quit [Ping timeout: 258 seconds]
dch has quit [Ping timeout: 246 seconds]
cbarrett has quit [Ping timeout: 252 seconds]
cncl has quit [Ping timeout: 268 seconds]
gonz_ has quit [Ping timeout: 260 seconds]
BaroqueLarouche has quit [Ping timeout: 245 seconds]
guan has quit [Read error: Connection reset by peer]
odc has quit [Ping timeout: 245 seconds]
karrick has quit [Ping timeout: 260 seconds]
wjlroe has quit [Ping timeout: 245 seconds]
eddyb[legacy] has quit [Ping timeout: 248 seconds]
jzelinskie has quit [Ping timeout: 252 seconds]
strmpnk has quit [Ping timeout: 260 seconds]
euantor has quit [Ping timeout: 248 seconds]
frmdstryr has quit [Remote host closed the connection]
<andrewrk>
daurnimator, I completed the application for software freedom conservancy
<daurnimator>
andrewrk: great :) I'll poke karen
<daurnimator>
andrewrk: also I think GSoC applications opened today; are you okay to fill out an application?
<daurnimator>
steph is around here somewhere so I can ask her questions
<andrewrk>
how does that work? does a project fill out an application, rather than a student?
<daurnimator>
shachaf: linkers appear to have a `-z stack-size` argument to fill it in. Just finished talking to kees and he thinks he can add support for it on the linux side
<andrewrk>
oh brilliant. I would love to see linux honor that
<daurnimator>
andrewrk: you apply to be a GSoC org, you can then put out a request for students who apply to work for our org; GSoC then allocate us X students based on our recommendations/number of slots available. first time orgs usually get 2 slots.
<andrewrk>
ok filling that out now
<daurnimator>
andrewrk: awesome.
zfoo has quit [Remote host closed the connection]
<andrewrk>
daurnimator, would you be interested in being in charge of the GSoC organization application?
<daurnimator>
andrewrk: sure
epmills has joined #zig
epmills has quit [Remote host closed the connection]
epmills has joined #zig
lqd has quit [Ping timeout: 248 seconds]
<epmills>
sure i'm missing something here but banging my head...
<epmills>
on a mac, what is the diff between 'zig build-exe --name works hello.zig' and 'zig build-exe --name vomits -target x86_64-macosx hello.zig'?
<epmills>
specifying the target results in 'dyld: Symbol not found: ___error'
BaroqueLarouche has joined #zig
<daurnimator>
epmills: 1. you're missing the third part of that triple? 2. without a target it compiles specifically for the host CPU's features (vs generically for "all" x86_64 macs)
<epmills>
would that be 'gnu' (iirc the default) or something else?
<epmills>
and for (2) since i *am* the host, why would there be an issue?
<andrewrk>
epmills, macos has proven to be the most problematic target to cross compile for
<andrewrk>
when you don't provide -target, it's native. when you do provide -target, it's cross compiling
<andrewrk>
with -target, zig does not implicitly depend on any system things
<daurnimator>
andrewrk: if linux supported the stack-size; what would the major wins be for us?
<epmills>
thx andy and daurnimator. in light of that, i was trying to create a build.zig that would loop over an inline for to generate binaries for mac and linux...
<epmills>
but was unable to come up with the build.zig equivalent of 'zig build-exe hello.zig'
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
return0e has quit [Ping timeout: 240 seconds]
swoogan has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
BaroqueLarouche has quit [Ping timeout: 268 seconds]
dddddd has quit [Ping timeout: 265 seconds]
euandreh has quit [Ping timeout: 272 seconds]
ur5us has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
epmills has quit [Remote host closed the connection]
<andrewrk>
daurnimator, given that zig knows how big of a stack it needs, and it might exceed the 8 MiB that linux gives us, it would allow us to avoid putting code before main() that checks if we need more than 8 MiB, mmaps it separately, and switches the stack pointer to it. Basically, linux is allocating a stack for us but it sometimes allocates a too-small stack
<daurnimator>
andrewrk: don't stack probes take care of that for us?
ur5us has quit [Ping timeout: 260 seconds]
gonz_ has joined #zig
<andrewrk>
no; we need to preallocate the entire stack
<daurnimator>
Why doesn't stack probing take care of it for us?
<andrewrk>
with stack probing, function calls can cause OOM crashes. this is not acceptable
<andrewrk>
we need to be able to preallocate resources and then have them guaranteed to be available
<andrewrk>
consider an embedded use case, for example
<fengb>
I didn't even think that I was somehow installing into the build dir
<andrewrk>
fengb, yeah that's the problem with cmake not letting us run a command on install :(
<fengb>
Ah okay
<fengb>
I was really confused why make was copying the lib folder into build but it makes some sense when that’s the install path
<andrewrk>
basically because of the cmake limitation, we don't have `make`, we only have `make install`
epmills has quit [Remote host closed the connection]
<daurnimator>
andrewrk: okay so this is aiming for the overcommit_memory=2 usecase?
<andrewrk>
daurnimator, yes. also: it improves determinism of timing of code. for example you wouldn't want to be performing a live music show, and have a function call which needed to allocate stack memory take longer than the effects processing budget
<andrewrk>
it also affects the "99 percentile" of e.g. web servers
<daurnimator>
andrewrk: so does that mean we can turn off the stack probe for such situations?
<andrewrk>
yes, it's intended to turn off the stack probe in release-fast mode for example
eddyb[legacy] has joined #zig
<mikdusan>
andrewrk: I seem to have gotten this to work for non-windows builds. Not sure what to do for Windows:
rageoholic has quit [Remote host closed the connection]
<hryx>
mikdusan: don't let me distract/bore you, but if you are interested, I'm trying to figure out my new fix caused an even newer problem: https://github.com/ziglang/zig/pull/4155
<hryx>
(I left a comment there explaining the situation)
<mikdusan>
i'll take a look shortly; just need to hack cmake a bit more
<hryx>
sweet, at your leisure
<mikdusan>
hryx: zig0 crashes on a barebones hello.zig
<mikdusan>
ie: no need to go as far as libuserland
<hryx>
oh dang, that is good to know. I should learn how to build zig0 and debug it alone
<mikdusan>
so zig0 is always built
<hryx>
good find - I'll take a quick look at this
<mikdusan>
just remember zig0 is not fully functional. whatever zig relies on libuserland for, zig0 panics
<hryx>
gotcha. I've reproduced what you mentioned with an empty `export fn main() void {}`
return0e has joined #zig
return0e has quit [Write error: Connection reset by peer]
return0e has joined #zig
<mikdusan>
just added a reduction; this one helps when using --verbose-ir ... really removes a lot of cruft
<hryx>
awesome, thanks a ton! Now I gotta figure out why this instruction->child has become a nullptr. I'll check out --verbose-ir here
<hryx>
weirdly, it crashes when checking an enum switch case, not an integer as I would have guessed
<mikdusan>
re: the base (master) logic. I'm just not grok'ing it:
<mikdusan>
using the reduction; first it checks 1...10, and let's assume TRUE. then it completely jumps past CheckProncheckSwitchProngs
<hryx>
mikdusan: that happens on master? Hm, I thought that would be covered by the compile-error test case
<mikdusan>
well it's working but I'm not understanding why... ie. not understanding the IR
<hryx>
Also, I have confirmed this new segfault is not because of the tautology elision. I reverted that part and still crashes. So this splitting up of CheckSwitchProngs was naughty somehow
<hryx>
I see
<mikdusan>
oh so wait... the IR dump of entry() (IR first pass, aka IR0) can be read as runtime, and then during IR analysis is where the comptime eval is causing @checkSwitchProngs to be skipped
doublex has joined #zig
<hryx>
is that with your reduction on master? if so then that should be a bug
lluchs has quit [Ping timeout: 252 seconds]
<hryx>
the thing with my branch is that `some_u8 < 100000` will become comptime true even before we get to second-phase analysis
<hryx>
(which also results in skipping prong check, hence this whole exploration)
<mikdusan>
I mixed it up. that's what was happening with your branch couple of days ago
<hryx>
ah, whew! same number of bugs as originally expected then :>
<mikdusan>
so how's this sound: tautological-comparison should be hooked into the analysis of switch
<hryx>
I am really starting to think it belongs there
<hryx>
the deal is, there was already other tautological comparison stuff before I ever touched it, it was just for stuff like `false == true`; I only extended it to consider type sizes
<hryx>
so I added code below there. it would probably all have to move
shakesoda has joined #zig
<hryx>
but I agree, if I understand you correctly mikdusan -- those resolutions/elisions could be moved to the analysis phase
<mikdusan>
that's my current thinking, also false == true, heh, I doubt there are overlapping unit tests for that; which is why tautological for false == true never caused any test to fail
<mikdusan>
but i'd say try to move tautological to analysis if that is possible, and as a followup move the false/true tautological in another PR
<hryx>
ha, right. It also already resolved expressions like `some_u8 <= -1`, fwiw
<hryx>
ok, that sounds good, I'll go down that path for now. Thanks so much for your input, it was super helpful!
<mikdusan>
so sorry I forgot about something; looking over your PR
ur5us has joined #zig
<mikdusan>
it's really strong that you put this elision in ir_analyze_bin_op_cmp_numeric
<hryx>
what do you mean?
<mikdusan>
is there something that can be done with build and/or analyze switch_br to make it work?
<hryx>
hm, maybe yeah. but actually, I don't grasp what switch_br is yet
<hryx>
what is "br" an abbreviation for?
<mikdusan>
branch(es) I suppose
<mq32>
Do i understand the proposal in #4151 right that it would allow pretty much arbitrary unicode identifiers?
<hryx>
mikdusan: sounds obvious now that you mention it, ha
<mikdusan>
i am not sure yet but... the last `continue;` condition -- could that be where the comptime comes into play?
<mikdusan>
IrInstructionSwitchBr has switch_prongs_void
<mikdusan>
i'm going to try something real quick
<hryx>
Ohh, I think I'm starting to see this a little better now. For some reason I thought that by the time a SwitchBr is analyzed it's already too late. But it retains information about the expressions (ranges, cases) it seems
<hryx>
holy cow there's a lot to learn just for a pretty small change to ir.cpp, ha
<mikdusan>
I know... andrew is a machine for writing all this
<hryx>
'tis legendary
<mikdusan>
the other day I was making reductions for test cases and his fixes were outpacing me. lol
<hryx>
haha, I love it
<hryx>
mq32: I think so - is there something that seems ambiguous in that regard?
<mikdusan>
I really don't want to see any kind of whitespace allowed for identifiers
<mikdusan>
or digits of any kind for first char/codepoint
bheads has quit [Quit: bheads]
bheads has joined #zig
<mikdusan>
oh boo; an idea didn't pan out
<hryx>
;_;
<hryx>
I'll have to come back to it again tomorrow. sadly I can only work on zig nights and weekends for precious wee moments at a time
<hryx>
I am already a pumpkin
<mikdusan>
np. ttyl.
<hryx>
later
<mikdusan>
hryx: I think it's even simpler...
SimonNa has quit [Remote host closed the connection]
<mq32>
hryx: no, but i had some problem grasping the basic idea of the proposal as i don't know unicode ranges by codepoint ^^
<mq32>
mikdusan: i don't even want to see non-ascii-characters in identifiers
<mikdusan>
hryx: i'll add comments to PR
<s-ol>
hey, im trying to parse enums from string values
<s-ol>
with @memberCount() and @memberName() I can get the string representations
<s-ol>
but once I have a match, how do I get the enum value? I can't assume that the member index is the integer representation
<s-ol>
ah, I should just iterate over @typeInfo(T).Enum.fields instead I guess
<s-ol>
hm, but now i'm having trouble getting this to build: 'values of type 'std.builtin.EnumField' must be comptime known, but index value is runtime known'
marijnfs has quit [Read error: Connection reset by peer]
<mikdusan>
s-ol: std.meta.stringToEnum()
<s-ol>
hah, there we go :P thanks mikdusan
<s-ol>
ouf, so all I was missing was 'inline' in front of for
ur5us has quit [Ping timeout: 260 seconds]
shakesoda has quit [Quit: Connection closed for inactivity]
dddddd has joined #zig
bheads has quit [Quit: bheads]
bheads has joined #zig
alexpana has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
alexpana has quit [Ping timeout: 268 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 272 seconds]
_Vi has joined #zig
mikdusan has quit [Ping timeout: 248 seconds]
epmills has joined #zig
alexpana has joined #zig
alexpana has quit [Quit: WeeChat 2.5]
alexpana has joined #zig
tane has joined #zig
<tane>
hodwy
<mq32>
hey tane
epmills has quit [Remote host closed the connection]
dimenus|home has quit [Remote host closed the connection]
<tane>
https://ziglang.org/documentation/0.5.0/#Exporting-a-C-Library following that section I (i) built a static archive libmathtest.a and (ii) a shared lib libmathtest.so. Building the test.c with gcc and linking to (i) failed due to __zig_stack_probe missing, while it did not fail with (ii). How can I build a static lib (i) and link to it with a traditional C compiler?
<tane>
__zig_probe_stack is the symbol name, sorry
frmdstryr has joined #zig
<wilsonk>
tane: hmm, strange I thought that used to work for me. Just tested and got the same result. Something must have changed recently, I suppose
<wilsonk>
tane: I linked with libuserland.a and it seems to work, just so you know. Someone else can probably explain in depth why...I just assume that the new-ish pre-calculated stack size code is the reason (there was a change to handle recursion issues, IIRC)
TheLemonMan has joined #zig
<TheLemonMan>
tane, you need --bundle-compiler-rt
zfoo_ has joined #zig
<tane>
wilsonk, TheLemonMan thank you
<tane>
works!
_Vi has quit [Ping timeout: 260 seconds]
recombinant has joined #zig
<leeward>
tane: -fno-stack-check will get you the same result, but with a different set of tradeoffs.
<tane>
nice, thanks
doublex has quit [Ping timeout: 260 seconds]
alexpana has quit [Ping timeout: 272 seconds]
<TheLemonMan>
yeah no, you lose the protection against stack overflows
<tane>
sure, "nice" wrt. have the option :)
<fengb>
scientes: you really should push hard on the lld removal. Gotta win the reds
<leeward>
TheLemonMan: Protection against stack overflows is nice, but smaller binaries are sometimes nicer.
<TheLemonMan>
given that they only work on x86/x64 and only on linux I'd say that's not true
<TheLemonMan>
the handful of bytes you're losing is *nothing* wrt .. well wrt everything else
<leeward>
Oh, the stack protection stuff doesn't work on freestanding?
<TheLemonMan>
nah, you need a MMU (or PU) to make it work
bheads has quit [Ping timeout: 272 seconds]
<TheLemonMan>
just mark the end of the stack as RO and you're done
bheads has joined #zig
<leeward>
Well that's different then.
adamkowalski has joined #zig
doublex has joined #zig
doublex has quit [Client Quit]
bheads has quit [Quit: bheads]
bheads has joined #zig
mikdusan has joined #zig
<BaroqueLarouche>
TheLemonMan, andrewrk: so lib/special/compiler-rt doesn't need to be a 1:1 port from LLVM ?
<TheLemonMan>
BaroqueLarouche, I only take inspiration from their implementation
<TheLemonMan>
I always try to understand the problem, the general algorithm, the way it's implemented and then hammer out some pure Zig code that passes the tests
<TheLemonMan>
alright, mrc is not valid in thumb mode
<TheLemonMan>
that has nothing to do with linux :P
<BaroqueLarouche>
I looked at the "faulting" commit and was only used for Linux
<BaroqueLarouche>
I'll add the test for thumb and the new implementation tonight
<TheLemonMan>
I can probably slip a fix for that in #4198 if you want
tane has quit [Quit: Leaving]
<BaroqueLarouche>
oh nice!
<TheLemonMan>
are you porting all the GBATEK definitions too? :)
<BaroqueLarouche>
that's the plan
<TheLemonMan>
I'd love to write some GBA/NDS homebrew using Zig
<BaroqueLarouche>
NDS is quite a beast compared to the GBA
<BaroqueLarouche>
My plan: Finish porting/adapting the TONC tutorial, fill the missing pieces, do a 1.0 tutorial. Then go back to zigimg and implement most popular image format and then finish the asset baking pipeline
<BaroqueLarouche>
s/tutorial/release
<TheLemonMan>
sounds good, if you stumble across ARM-related bugs and/or missing intrinsics feel free to CC me and I'll have a look ASAP
<BaroqueLarouche>
TheLemonMan: will do :)
<leeward>
I'm getting error messages as strings from a C library, and trying to print them out shows me the pointer's address. This must be a thing that's happened before.
<leeward>
std.debug.warn("{}", .{u8Ptr})
<TheLemonMan>
leeward, try "{s}"
<leeward>
TheLemonMan: nope
<TheLemonMan>
what's the type of u8Ptr ?
<leeward>
const char*
<leeward>
is what the C library returns
<TheLemonMan>
yeah, I mean what's the type in Zig
<leeward>
How can I tell?
<TheLemonMan>
@TypeOf ?
<leeward>
I got gdb attached and managed to print out the message I needed.
<leeward>
I guess that would work :P
<TheLemonMan>
or just run `zig translate-c <file>` and examine the output
<leeward>
type
<leeward>
sigh
<leeward>
I guess I could run that on the header.
<leeward>
Nope, that's a deeper rabbit hole.
<leeward>
When I print @TypeOf the message, it prints "type"
<TheLemonMan>
the type should be `[*c]const u8`
bheads_ has joined #zig
<leeward>
Ah, so I should cast it to a sentinel-terminated array?
bheads has quit [Ping timeout: 272 seconds]
bheads_ is now known as bheads
<leeward>
Hey, that did it.
<TheLemonMan>
yeah, if you scavenge trough the typeinfo properties and cross-reference fmt.zig you'll see that C pointers ignore the format string
<TheLemonMan>
the problem is that `u8Ptr` has a pointer type of .C and not .Many
<fengb>
Oh good point
<fengb>
Shoudl we coerce `[*c]` to `[*:0]`?
<TheLemonMan>
I think that's the correct way to go, once you write @ptrCast you swear up and down that you know that pointer is zero-terminated
dimenus has joined #zig
mahmudov has joined #zig
<metaleap>
afternoon! so you cant import relative files from parent dirs '../../foo.zig' without "setting up packages" but neither the wiki nor langref has a section on doing so. in fixed-issue #2024 andrew says: "So the idea here is that you'll have to map your packages in as packages". anyone got a sample? std.build is under-documented/-commented to the newb (most matches for 'pkg' seem related to `pkg-config`). say your repo is a lib with a `build.zig` and a
<metaleap>
`src/` dir but also has subfolders `cmd/foo/main.zig`, `cmd/bar/main.zig` that import the lib in `[reporoot]/src/`
<TheLemonMan>
andrewrk, BaroqueLarouche said he's gonna update the PR later today
<BaroqueLarouche>
as soon as I arrive home tonight
<TheLemonMan>
for some reason #4199 is stuck in the CI limbo (the Azure mark is green even though it cannot find any build when you click on it) so feel free to blindly merge it :)
<TheLemonMan>
I have no idea why it happens nor how to unfuck it
<andrewrk>
TheLemonMan, it's probably a transient problem with azure. if it doesn't go away in a day or two I'll look into it
<andrewrk>
I have a windows computer here that I run the windows tests on if the CI is unavailable for whatever reason
<TheLemonMan>
it looks more a problem with GH as the sr.ht build is stuck too
<andrewrk>
ah
squeek502_ has joined #zig
squeek502 has quit [Ping timeout: 240 seconds]
<BaroqueLarouche>
andrewrk: @ptrCast doesn't work to call naked function in non-naked function: https://godbolt.org/z/Ldg2t6
shakesoda has joined #zig
return0e has quit [Remote host closed the connection]
<andrewrk>
BaroqueLarouche, it's a regression, let me fix it in master real quick
<BaroqueLarouche>
Thanks :)
<leeward>
Sounds like a test case!
swoogan has joined #zig
<TheLemonMan>
nah it never worked
<TheLemonMan>
you have to do `var foo = my_naked_fn; var bar = @ptrCast(fn () callconv(.C) void, foo); bar();`
<TheLemonMan>
if you ptrCast a comptime-known fn the old ZigFnEntry (or whatever it's called) is not forgotten
<BaroqueLarouche>
Ohh
<TheLemonMan>
so once you try to call the casted fn the compiler is too smart and picks the original fn definition
return0e has joined #zig
<andrewrk>
ok well I have a patch running through the tests
<andrewrk>
but yeah good point the `var` will work around this
return0e has quit [Ping timeout: 260 seconds]
<TheLemonMan>
if the patch is a silly one-liner I'll eat my hat~
<andrewrk>
I should probably go through and understand why the type from the fn ref can't be unconditionally used, but instead this patch only uses the calling convention from the type
<andrewrk>
hmm this test case should have args
<BaroqueLarouche>
You should test return values as well
<andrewrk>
yeah this is no good. I'll open an issue, the solution is more involved
<TheLemonMan>
I'd always trust the fn_type (and shouldn't the fn_entry type always be the same ?)
<companion_cube>
oooh, looking at the old stream about comptime, it's great
<BaroqueLarouche>
andrewrk: done
return0e has joined #zig
<andrewrk>
thanks
<andrewrk>
companion_cube, I evolved the contents of that stream into the "road to zig 1.0.0" talk
<companion_cube>
which I've watched, but this is more detailed (the IR! fun!)
<TheLemonMan>
(for some definition of fun, heh)
marijnfs has joined #zig
mikdusan has quit [Ping timeout: 268 seconds]
<TheLemonMan>
BaroqueLarouche, hmm, are you getting a call to __clzsi2 when targeting thumb? I can't get LLVM to emit it when targeting the ARM instruction set
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<tane>
what's the difference between pub fn and fn struct methods?
<BaroqueLarouche>
it's similar to public vs private in C++, you can't access non-pub fn from outside the struct
<tane>
this is not how it behaves here, that's why I asked :)
<tane>
I have a `pub const X = struct { ... fn foo(self: Self) ... }` and can still call `foo` from another site
<metaleap>
tane: every member in a pub type is pub, cant hide them afaik
<metaleap>
(ie there's no priv(ate) keyword =)
<tane>
so, non-pub methods are only worth anything in comptime generated types in the user code and in my own module?
<metaleap>
essentially pub-or-not visibility is for your top-level decls, not nested members these are all visible
<tane>
works for comptime-generated types
_Vi has joined #zig
ur5us has joined #zig
<tane>
ok, so "methods", i.e. functions taking "Self" ignore "pub", but all other functions in the struct, e.g. `init` do adhere to it
<metaleap>
ah was only thinking of the former, so the "static methods" (to use oop slang) need pub or else are hidden? funky
<tane>
yes, source of my confusion
<tane>
I wonder what the rationale is, from my POV this is maximally confusing :)
<mikdusan>
I think it's more an evolved thing. Good reasons led to `pub` modifier for decls... and the reasons for `pub` modifier for fields was not as convincing/clean/straightforward. Fields inevitably leads to talk about protected, private, and to compare, Swift even has a 4th (package?) or somesuch.
<tane>
well, I don't mind something missing, but that feels inconsistent
ur5us has quit [Ping timeout: 260 seconds]
<metaleap>
fields and self-methods need the actual "instance" / self, so these methods might be sugar turning into fn-typed fields or so whereas the "static" methods are sugar for merely namespacing what turns into top-level funcs. just guessing at how this could have occurred. but yeah, "inconsistent" in a way, at least for the "lang end-user"
<metaleap>
although the "instance members are always visible to the consumer" could be a somewhat-more-consistent-feeling rule-of-thumb easy to remember
<tane>
hm
marijnfs_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
<fengb>
Fields need to reserve memory so it's not actually encapsulated well. Trying to hide it can bring other troubles (see C++ private fields)
<mikdusan>
fengb: but how to hide `_NSAKEY: []const u8,` :P
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
return0e has joined #zig
lunamn has quit [Ping timeout: 240 seconds]
BaroqueLarouche has joined #zig
lunamn has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<metaleap>
iterating down-to-0 is a chore: `var i = myslice.len - 1; while (i > -1) : (i -= 1) {...}` -> integer overflow. fine, @intCast to iSize, then for the [indexer] need to @intCast back to usize...
ur5us has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
henbr has quit [Quit: WeeChat 2.6]
return0e has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<metaleap>
std.fmt --- are there plans for a sort-of string-quoting (e.g. by zig rules) param such as {q} (similar to go's `fmt.Sprintf("%q", "Hi") == "\"Hi\""`) or does it exist elsewhere?
<metaleap>
i mean i could steal std.json's WriteStream.writeEscapedString for my purposes but there might have in the `zig fmt` or self-hosted compiler (or other) efforts already been the need and now hidden somewhere I'm not aware of
<Snektron>
metaleep, consider `var i = myslice.len; while (i > 0) { i -= 1; ... }`
<Snektron>
metaleap*
<metaleap>
Snektron: thats a cool approach! i went with while(true) and decremented-or-break in sub branch but yours is neater & safer
marmotini_ has quit [Remote host closed the connection]
zfoo_ has quit [Read error: Connection reset by peer]
metaleap has quit [Quit: Leaving]
dimenus has quit [Read error: Connection reset by peer]
tane has quit [Quit: Leaving]
adamkowalski has joined #zig
metaleap has joined #zig
<adamkowalski>
is there some trick to passing anonymous list literals to a function which expects an fixed sized array?
<andrewrk>
adamkowalski, that's a weakness in the language right now which I hope to address
Akuli has quit [Quit: Leaving]
<andrewrk>
the workaround is to @as(T, .{foo})
<andrewrk>
oh that might not actually be a workaround
<fengb>
Could Zig recognize that it's a homogeneous tuple?
<andrewrk>
it's not actually fixed size arrays that is the problem, it's casting to a slice I believe
<andrewrk>
@as([]const u8, .{"foo", "bar"})
<andrewrk>
that's what I was thinking of anyway. coercing to arrays already works
<fengb>
Oh
<andrewrk>
problem is zig lost the ability to automatically take a reference behind your back
<fengb>
Yeah that makes sense. I was trying to do that with `&.{}`... which didn't work
<andrewrk>
maybe it should though
<andrewrk>
especially since if you do it without & it tells you to put a & on it
<frmdstryr>
I'm confused... why even have any code in a suspend block then vs just putting it before a suspend statment?
<andrewrk>
frmdstryr, in single-threaded applications it does not matter. in multi-threaded applications, because of a race condition of another thread resuming
<andrewrk>
mikdusan, nice! I couldn't figure out how to do this
<mikdusan>
if you're ok with MSVC continuing with ZIG_SKIP_INSTALL_LIB_FILES, but make/ninja generators using `make` vs `make install` I'll PR this.
<andrewrk>
as far as msvc is concerned, I agree, let's have it do the skip thing. I don't think it even needs to be a setting
<andrewrk>
uh, hmm. scratch that. it matters for the CI creating the .zip file
ur5us has joined #zig
<mikdusan>
for my own confirmation then: keep ZIG_SKIP_INSTALL_LIB_FILES behavior but only for MSVC ?
<andrewrk>
yes. make default be ON. ci script will want to turn that OFF
<andrewrk>
one more thing -
<andrewrk>
ah I see what you did
<andrewrk>
it's a little bit messy since it will do the building libuserland thing twice
<andrewrk>
but it should be fine
<mikdusan>
yeah... this was my second attempt at solving. first one ended in head shaking ... lots of head shaking
<andrewrk>
nice work
<andrewrk>
cmake can be incredibly frustrating
<andrewrk>
we can't really rely on the CI to test this
<mikdusan>
yeah i'll go through the 3 platforms manually
<andrewrk>
not all heroes wear capes
<pixelherodev>
Is it worth giving meson (or some other build system) a try instead of CMake?
<andrewrk>
in my opinion, not really, it would just be churn
<andrewrk>
we're stuck with cmake basically forever, due to it being the most ubiquitous option
<andrewrk>
although if https://github.com/ziglang/zig/issues/853 turns out successfully, I could see there being a single posix shell script that can build a tar.xz into a fully operational zig bundle for any target
<fengb>
Let's just reintroduce autotools 🙃
<andrewrk>
well, llvm depends on cmake. so that's another reason to not deviate
<andrewrk>
anything other than cmake is "another" dependency when bootstrapping
<BaroqueLarouche>
I use VS CMake integration to build Zig from source
<leeward>
That's the first time I've read the Grand Plan for Bootstrapping the Universe, and I like it.
swoogan has joined #zig
<leeward>
It will make package maintainers' jobs super simple. It's almost like you have experience with the kinds of headaches maintainers get.
<Snektron>
build.zig for llvm
<leeward>
I feel like there should be a make clone for Zig that's called move, so you could have command lines like "move zig" "take_off_every" is an option too, but pretty verbose.
<Snektron>
why should there be a make clone? theres already build.zig
<pixelherodev>
toe
<leeward>
Solely for the name. No other reason.
<leeward>
pixelherodev: People would just call it toe though.
<andrewrk>
you can make arbitrary step names: zig build main screen turn on
<leeward>
Too contrived.
<BaroqueLarouche>
imagine now recreating the Zero Wing intro in Zig on Genesis/Megadrive
<leeward>
I want a tutorial for the package manager that instructs one on setting up us the bomb.
<BaroqueLarouche>
leeward: hahahahaha
<shakesoda>
can you spit out working zig binaries for any particularly ancient cpus?
<leeward>
Does x86 count?
<shakesoda>
like m68k, 6502, z80
<shakesoda>
or like old mips
<andrewrk>
shakesoda, are you aware of `zig targets` ?
<shakesoda>
this thought is just prompted by the phrase "zig on genesis/megadrive"
<shakesoda>
andrewrk: i am not!
<shakesoda>
let's have a look...
<andrewrk>
this matches LLVM
<leeward>
`zig targets` includes, among others, scarc, riscv32, mips...
<leeward>
That is a long list of C ABIs.
<BaroqueLarouche>
shakesoda: no, LLVM should at least have a m68k in my opinion, being used in a lots of computers, consoles and arcade board
epmills has joined #zig
<BaroqueLarouche>
6502 is not very suited for stack-based languages
<leeward>
BaroqueLarouche: But does Apple make products with it?
<shakesoda>
an actually affordable arm laptop, with about the specs i want :D
<leeward>
Ooh, fancy
<shakesoda>
looks like a great little dev machine
<leeward>
Holy carp, $200?
<shakesoda>
yes!
<pixelherodev>
` zasm support is basically a prerequisite for any non-llvm-supported architecture` I consider this a challenge to have my backend working first :)
<pixelherodev>
How does the pinebook pro compare to a 3rd-gen i5 with 8GB of RAM? Not sure how to compare ARM vs x86
<pixelherodev>
Specifically for working with Zig
<shakesoda>
that i5 would murder it
<pixelherodev>
Figured as much
<shakesoda>
if it were a snapdragon 8cx model or something it'd be faster than the i5, though
<fengb>
Probably easier to cross compile and copy over the binary
<pixelherodev>
Might be worth it anyways
<shakesoda>
fengb: nah - should be fine to build on it
<pixelherodev>
It's cheap enough anyways, and zig builds faster
<fengb>
Fine sure. But it's really slow :P
<shakesoda>
the performance gap is almost negligible on higher end socs than the rk3399
<fengb>
I started testing my stuff on my "server" Linux running Celeron. I ended up compiling on my mac and copying stuff over because it's so bad
<pixelherodev>
Oh god yeah
<leeward>
The performance per watt is up there, which is a thing that servers care about.
<shakesoda>
leeward: i suspect it will be pretty soon
<pixelherodev>
I had a $150 Celeron laptop for a while there
<pixelherodev>
Perf per watt was really *really* good
<fengb>
Also a testament of how great Zig's cross compiling is, where I didn't even have to do much work
<pixelherodev>
Battery life was nearly 20 hours
<pixelherodev>
(once I swapped to Linux ofc)
<pixelherodev>
But performance was a joke
<fengb>
I mean, I bought it for dirt cheap. It's for serving files so it does the job, but it's also the only native Linux box I'm running
<pixelherodev>
If my current worst-case compilation time is ~7 seconds with Zig, what would be a reasonable time to expect on a PineBook?
<pixelherodev>
The other advantages of it might be worth it
<pixelherodev>
I mean, self-repairable laptop for $200
<shakesoda>
i can't give any kind of reasonable estimate, but i'd be somewhat surprised if it were worse than 10s
<Snektron>
Alright, so some Vulkan calls return a result which is either an error code or a success code. I wanted to adopt VkResult into an error set, such that Vulkan calls can be neatly handled by Zig's error mechanism
<shakesoda>
if i had a pi 4 on hand i could give a pretty reasonable number, since they're both a72 designs
<Snektron>
However im not quite sure what to do with calls which can return different success codes
<Snektron>
For example, vkAcquireNextImageKHR can return VK_SUBOPTIMAL_KHR, which is not an error
<daurnimator>
> for example you won't find RISC-V chips in practice without integer multiplication
<Snektron>
Anyone have an opinion?
* daurnimator
looks at his newly acquired usb device
<shakesoda>
although the pi might be unnaturally slow because of the sd, compared to anything else
<fengb>
Pinebook uses eMMC, which isn't exactly fast
<shakesoda>
the pinebook pro's emmc would be way faster, and it supports m.2 drives
<shakesoda>
emmc isn't super fast, but it's faster than sd lol
<fengb>
Ohhh m2
<leeward>
Snektron: Return an enum?
<Snektron>
leeward, thats one of the solutions i considered yes
<leeward>
Seems like a reasonable one: !SuccessMode
<Snektron>
basically i had one of these in mind: 1) treat success results as error, as anything but VK_SUCCESS probably needs to be handled. 2) turn functions returning both success codes (other than VK_SUCCESS) into !SuccessCode, which is what you propose 3) Don't do any of this and just return a VkResult enum value
<fengb>
`error.NotError =>`
<Snektron>
yeah pretty much
epmills has quit [Remote host closed the connection]
<leeward>
My visceral reaction to error.NotError is not a happy one, but it comes from people abusing exceptions as control flow. Errors in Zig don't have the same drawbacks as exceptions, so it's worth thinking about.
<andrewrk>
Snektron, I have an opinion. anything that is "it worked" should not be an error. if you're trying to make something have a more zig friendly API, wrap it, give it capability to set flags or other state, and only return error when the thing didn't work
<andrewrk>
you could also have a wrapVkErr() function which does `VK_SUBOPTIMIAL_KHR => unreachable` and equivalent for the "it still worked" codes. for functions where these things are possible, handle those cases explicitly before calling wrapVkErr()
<Snektron>
Hmm
<pixelherodev>
shakesoda, oh right thanks - I think I know someone with a Pi 4
<leeward>
Yeah, assume that people will call the function with try. If it succeeds but their program crashes, they'll be displeased.
<andrewrk>
or maybe `VK_SUBOPTIMAL_KHR => return error.SuboptimalSettings` but still take the strategy to handle it explicitly before calling wrapVkErr
<pixelherodev>
Oh wait right, the discussion after that is valid
<leeward>
pixelherodev: You might be able to use an in-ram FS to get past the whole SD card thing.
<pixelherodev>
eMMC is definitely better than, say, a HDD, right?
<pixelherodev>
Might not be SSD fast, but it's not *slow*
<andrewrk>
I have an eMMC file system. it's fast
<leeward>
pixelherodev: Do you care more about bandwidth or latency?
<Snektron>
leeward, i'm pretty sure that anything not VK_ERROR_* won't cause the program to crash
<leeward>
Snektron: So probably don't put your limited successes in an error then.
<Snektron>
andrewrk, im not sure where that case statement might be applied
<Snektron>
To be clear, my implementation idea was as follows:
<pixelherodev>
leeward, ?
<Snektron>
there will be two "parts": the raw Vulkan calls, which are extern and all that
<pixelherodev>
That sounds like what I'm doing for my C UI library
<Snektron>
Then a Zig-wrapper on top of that, part of which maps a VkResult error enum code into a Zig error
<pixelherodev>
Instead of rewriting it in Zig, it has a 1:1 binding layer and then a Zig wrapper built on top of it
<leeward>
pixelherodev: Spinning disks can still be fast for sequential reads.
<Snektron>
The main reason for that is that Vulkan calls have a specified set of errors they can return, but which cannot be expressed through the C ABI of course
<Snektron>
Anyway, i'm also considering what to do with return values
<Snektron>
Most Vulkan return values are passed via out parameters. I was considering doing something similar to how Vulkan-Hpp works: If there's only one out-parameter, wrap the function and make it a return value instead
<Snektron>
Together with the error mechanism and some wrapping, that could make for a pretty nice binding
lunamn has quit [Ping timeout: 260 seconds]
<andrewrk>
a useful and possibly fun project for a zig community member to make, once #3927 lands, would be a program that you run on a computer to have it report the "native" CPU name and feature set