<pixelherodev>
Better than saving a reference to the type just for this
<pixelherodev>
.... huh. Well this is weird. If you do `const a = @import()` *within a function's scope* and then refer to a private member, it's valid.
<pixelherodev>
The weirdest part is that if I have `var a = @import("blah.zig").init(blah);` where blah.zig has a private member named whocares and blah.init returns an object of type blah (@This()), `@TypeOf(a).whocares is a valid access
<pixelherodev>
s/valid/invalid
<pixelherodev>
*But*, if you store the type as `const b = @import("blah.zig");var a = b.init(blah);` then *the exact same access line* is valid
<frmdstryr>
Is there a way to get the path of the current file, like python's `__file__`?
<frmdstryr>
Nvm @embedFile works with relative paths
<pixelherodev>
___file___ wouldn't be useful in that scenario anyways
<pixelherodev>
Well
<pixelherodev>
I mean, I *guess*, since @embedFile is comptime
<pixelherodev>
That does provide for an intriguing idea of comptime-*only* Zig
<pixelherodev>
Which leaves basically just an interpreted / scripting language
<pixelherodev>
If there was an "instantaneous" compiler for that (the intended debug compiler perhaps?), I'd use that in a heartbeat over e.g. Bash
<pixelherodev>
(not that I use bash all that much as is; I try to stick to POSIX-compatible shell code)
<pixelherodev>
Is there a way to make structure functions fully private?
<pixelherodev>
By the Java definition of private
<pixelherodev>
Such that other structure functions can call it, but outside code cannot?
<pixelherodev>
I want to hide implementation details to ensure that client code doesn't become reliant on highly volatile (in the sense of constantly changing, not the technical sense) functions
<fengb>
Java private can still be called via reflection 🙃
<pixelherodev>
The fact that Java has a lot of flaws isn't germane to this discussion.
<pixelherodev>
Weird idea thought thing I just had: I know there was a discussion on adding integer properties, but what if there was e.g. a "power of two" property? Such that a runtime value can be of a type requiring a power of two?
<pixelherodev>
Or a more generic "power_of(n)" property
<pixelherodev>
This would be a pretty simple thing to check for
<pixelherodev>
The only valid operation on it would be multiplying by n
<pixelherodev>
Example use case: hashmap at present uses `assert(math.isPowerOfTwo(new_capacity))`
<pixelherodev>
It's called in three ways: 16, the previous capacity * 2, and `math.ceilPowerOfTwo(usize, expected * 5 / 3)`
<pixelherodev>
Such a property would allow for the assertion to be removed and one less point of runtime failure
<daurnimator>
pixelherodev: I've thought about that..... and you end up wanting functions for all sorts of limitations on values
<pixelherodev>
Such as?
<daurnimator>
e.g. why only power of two? we already have `min` and `max` on the way. But why not `multiple_of_3` and `prime`?
<pixelherodev>
Because prime is utterly impractical
<pixelherodev>
Power of is effectively trivial
<pixelherodev>
multiple of 3 would be power_of(3)
<pixelherodev>
Power of two *specifically* has the further added advantage of requiring less memory
<daurnimator>
multiple != power.
<pixelherodev>
Though power_of(n) could probably have an optimized in-memory representation, power of 2 would be easiest in that you'd need to store the power
<pixelherodev>
Ah right
<pixelherodev>
again, power of is trivial and has practical advantages both in the standard library and in compiled binaries
<pixelherodev>
Generally, I think if it's trivial and doesn't have any real downside it's worth it
<pixelherodev>
Though adding in a hundred trivial features would be problematic too...
<pixelherodev>
Ooh, better idea
<pixelherodev>
Implementing such types *within the language*
<pixelherodev>
Instead of in the compiler
<pixelherodev>
At the very least, if used at compile time, that could be useful
<daurnimator>
isn't only power of two vaguely efficient? and others not?
<pixelherodev>
Right, but I'm saying a power of two
<daurnimator>
you said `power_of(n)`
<pixelherodev>
As a hypothetical extension
<pixelherodev>
The main idea was just Po2
cshenton has joined #zig
<cshenton>
I'm writing a vector math lib and have run into an issue. I have a generic vector type with a cross product method that compile errors when called on a non 3d vector. For some reason, calling std.testing.allEqual on an unrelated operation is causing that method to get hit even when I don't call it so my code won't compile.
<cshenton>
Can I conditionally declare a member function to get around this?
<cshenton>
Yep allEqual does a switch on typeInfo so that's not surprising.
<cshenton>
So it's a bug and I should work around, I'm not fundamentally doing things incorrectly?
<daurnimator>
yeah. its been known about for a while. I recall that @memberCount was kept in existence because it worked without this issue while `@typeInfo(x).XYZ.fields.len` didn't.
<cshenton>
I'm thinking I should actually just remove that compileError for now, since I use @typeInfo on my vector types for some other stuff (automatically formatting an opengl vertex buffer)
<cshenton>
Unrelated, the argument signature for a non mutating member method is `self: *const Self`, not `self: Self` right?
<fengb>
self: Self is preferred. Zig will probably pass a const pointer under the hood, but it may pass by value if it’s faster
<daurnimator>
pixelherodev: btw, my reply on #2428 is sort of for you
<pixelherodev>
Could've pinged me there :P
<pixelherodev>
To respond though:
<pixelherodev>
Yes, I mentioned in that thread that they could be closed and modified afterwards
<pixelherodev>
The question was whether to return an error if someone closes it and then tries accessing it without opening it
<pixelherodev>
The answer that was decided upon was "no."
<cshenton>
Has anyone had issues with `inline` on generic structs? I'm getting an 'unable to inline' compiler error on a pretty innocuous vector add method.
<cshenton>
Specifically, if I copy paste the code inside the generic struct, the compiler does not complain about inlining.
<cshenton>
oof, you're not going to like this. That error only occurs when I call `expectEqual`, not if I manually `expect` on each field
<cshenton>
Going to file a bug
cshenton has quit [Remote host closed the connection]
lygaret has joined #zig
cshenton has joined #zig
dimenus has quit [Remote host closed the connection]
cshenton has quit [Remote host closed the connection]
cshenton has joined #zig
<cshenton>
Yeah I referenced that issue in mine, but I thought I'd make a new issue since it's not immediately obvious they're related.
lygaret has quit [Quit: Leaving.]
<cshenton>
And also for discoverability for people with the same problem.
cshenton has quit [Remote host closed the connection]
nephele has quit [Ping timeout: 248 seconds]
nephele has joined #zig
adamkowalski has joined #zig
protty has quit [Remote host closed the connection]
muffindrake has quit [Ping timeout: 246 seconds]
muffindrake has joined #zig
<adamkowalski>
:q
<adamkowalski>
whoops
adamkowalski has quit [Quit: Lost terminal]
scientes has quit [Quit: ZNC 1.7.5+deb1 - https://znc.in]
dingenskirchen has quit [Ping timeout: 248 seconds]
frmdstryr has quit [Remote host closed the connection]
<pixelherodev>
ah, the delightful feeling of auditing 3KLOC :P
<pixelherodev>
There a better way to check bytes from bits than `(bits + if (bits % 8 != 0) @as(u8, 8) else 0) / 8)`?
<pixelherodev>
It's better than the way I had it earlier, but it still looks *wrong* (even though I'm 99% certain it's accurate)
<pixelherodev>
With a line like `var a = []u8 { a(), b() };`, is there any guarantee that a will be called before b?
lygaret has joined #zig
<pixelherodev>
and yes I realize that would be a name collision
_whitelogger has joined #zig
leeward has quit [Disconnected by services]
leeward has joined #zig
lunamn has quit [Ping timeout: 265 seconds]
_whitelogger has joined #zig
_whitelogger has joined #zig
_whitelogger has joined #zig
_whitelogger has joined #zig
D3zmodos has joined #zig
<D3zmodos>
Am I missing something obvious here? If I try to switch on a runtime value where all the branches result in comptime values, I get a compiler error... https://hastebin.com/imoqexumiv.cpp
<pixelherodev>
Compiler bug\
<pixelherodev>
Integer literals are implicitly of type comptime_int
<pixelherodev>
If you change any of those branches to be `@as(u8, val)` it should work\
<pixelherodev>
As is, bar is being given the type comptime_int
<pixelherodev>
Which isn't a type a runtime value can have
<pixelherodev>
If you change e.g. `0 => 10` into `0 => @as(u8, 10)`, it'll result in the switch expression gaining type u8
<pixelherodev>
Setting the type of bar to u8 manually won't help either, because the switch expression would still have the wrong type
<pixelherodev>
D3zmodos, hope this helps!
<D3zmodos>
aaaah ok yes that makes sense. I guess I'd just assumed that comptime_int would be automatically resolved to a runtime type as necessary. Thanks pixelherodev !
<pixelherodev>
No problem!
<pixelherodev>
I think it's *supposed* to be automatically resolved, but that's not yet implemented
<adamkowalski>
that way people can just import the main file and get access to everything that I want exposed?
<adamkowalski>
it seems like that is what the standard is doing
MarquisdeFalbala has joined #zig
<andrewrk>
yes the way your package will expose an API is via a "root" file, so you'll need one file that exposes everything that you want to be in your API
<andrewrk>
sentinels should feel pretty ergonomic to use now
<adamkowalski>
I was thinking that if I do that the compile times will be faster because other tests that don't need those imports won't even look at them
<andrewrk>
zig is already pretty lazy, I don't think it will make a difference
<adamkowalski>
Yeah and the compiler already seems really fast. I feel like 90% of the time is spent in generating code using LLVM. At least that's what the terminal output sugests
<adamkowalski>
I'm curious if we can get similar speeds to something like D if bypass LLVM for non release builds
fifty-six has joined #zig
<fifty-six>
Sorry to bother but how do you debug a zig build failing because of `broken LLVM module found: Call parameter type does not match function signature!`
TheLemonMan has joined #zig
<TheLemonMan>
yo andrewrk, is the proposal in #1917 still accepted?
<TheLemonMan>
because I need weak refs for the PIE patchset and am gonna dust off the branch where I've implemented @externWeak
<TheLemonMan>
I'm still not 100% sold on introducing a new builtin, I'd just slap `weak` on VarDecl and make `&` return `?*T` pointers for such variables
muffindrake has left #zig [#zig]
dewf has joined #zig
Aransentin has joined #zig
fifty-six has quit [Ping timeout: 260 seconds]
adamkowalski has quit [Quit: Lost terminal]
<andrewrk>
TheLemonMan, I'm about to hop on a plane, but let me take a look
<andrewrk>
@externWeak is a lot easier to automatically rewrite users' code if we end up changing it to something else later
<andrewrk>
the proposal is still planned, yes
<TheLemonMan>
roger that, I'll send a PR later
Akuli has joined #zig
<Aransentin>
Writing an win32+user32 file for zig, and I have some ideas for a "cleanup" of the API. Tell me if my ideas are dumb:
<Aransentin>
Trash the confusing naming scheme, i.e. no more LPCSTR and just `[*:0]const u8` everywhere. Same for the opaque types: HINSTANCE -> *InstanceStrip the polish notation from the arguments and struct members and rename them to zig style: e.g. "lpClassName" -> class_nameReplace integer arguments/return values with enums of the same size when it makes
<Aransentin>
sense; e.g. "dwExStyle" in CreateWindowExA should be an `extern enum(u32)` with the valid arguments instead of a DWORD.Wrap the raw win32 API calls in zig functions that take e.g. slices and translate them to pointer-and-length arguments, error codes to Zig errors, and perhaps converts unicode strings to UTF16 like Windows wants.
<Aransentin>
Whoops the newlines got stripped out there...
<Aransentin>
sorry about that. Lemme try again :)
<Aransentin>
Strip the polish notation from the arguments and struct members and rename them to zig style: e.g. "lpClassName" -> class_name
<Aransentin>
Trash the confusing naming scheme, i.e. no more LPCSTR and just `[*:0]const u8` everywhere. Same for the opaque types: HINSTANCE -> *Instance
<Aransentin>
Replace integer arguments/return values with enums of the same size when it makes sense; e.g. "dwExStyle" in CreateWindowExA should be an `extern enum(u32)` with the valid arguments instead of a DWORD.
<Aransentin>
Wrap the raw win32 API calls in zig functions that take e.g. slices and translate them to pointer-and-length arguments, error codes to Zig errors, and perhaps converts unicode strings to UTF16 like Windows wants.
<Aransentin>
... and by "Polish notation" I meant Hungarian notation 😖
<Snektron>
Aransentin, maybe its best to create sone wrapper API that uses the current functionality
<Snektron>
That was my plan for something else
<Snektron>
<Snektron "My largest c++ project wasnt eve"> Though i have a sneaking suspicion some of it could maybe be improved by utilizing more of c++
<Snektron>
Of ir.cpp, that is
Wallbraker has quit [Ping timeout: 268 seconds]
MarquisdeFalbala has quit [Remote host closed the connection]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<daurnimator>
ooo, I wonder if thelemonman is writing a loader in zig...
<daurnimator>
andrewrk: FWIW the pie executables I know are files that are simultaenously executables and libraries. The most famous one being /lib64/ld-linux-x86-64.so.2 the second most famous one being /usr/lib/libc.so.6
<daurnimator>
==> try running those as executables :)
<pixelherodev>
"This is the gcompat ELF interpreter stub. You are not meant to run this directly."
<pixelherodev>
:P
<daurnimator>
pixelherodev: sure..... but thats still weird: you just executed a library
<pixelherodev>
I've made libraries like this before
<pixelherodev>
It's not overly difficult
<daurnimator>
correct. but it requires -fpie doesn't it?
<pixelherodev>
IIRC yeah
<pixelherodev>
It's been at least a year since I played with that