ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
mahmudov has quit [Remote host closed the connection]
seoushi_ is now known as seoushi
ur5us has quit [Ping timeout: 240 seconds]
marijnfs_ has quit [Remote host closed the connection]
metaleap has quit [Quit: Leaving]
ur5us has joined #zig
<fengb> I’m really disliking the term “friction”. It keeps being applied to “things I don’t like”
<andrewrk> alright, I finally caught up on issue triaging
seoushi has quit [Ping timeout: 272 seconds]
_Vi has quit [Ping timeout: 272 seconds]
<mikdusan> andrewrk: re: assert comment for #4389, I'm a little unclear as to the worry. I (don't think) I replaced assert -- I replaced 1 assert that masked side-effects and caused release-builds to segfault. unmasking the effects via new macro expressAndAssertNoError is very limited, has only 12 use sites
<mikdusan> my wording is bad. I replaced 1 non-standard macro to no longer hide side effects that a debug build experiences. now both release/debug builds get the same side effects, and it fixed some segfaults in release build.
<andrewrk> mikdusan, oh is the #undef assert / redefining to zig_assert still there somewhere?
<andrewrk> I blame myself for this confusion. it's bad practice to replace standard defines with different semantics
<mikdusan> wo. wait, I don't think I meant to do anything with assert() macro. jeeez
<mikdusan> let me look into this
<mikdusan> oh wow. what a clusterf. Ok so I inadvertantly dropped `#define assert` instead of just moving it to src/util_base.hpp, and that explains why side-effects became an issue.
<mikdusan> ok this is good, I can add that back,
<andrewrk> yeah I saw that expressAnd and figured you might not have seen it
<andrewrk> that or it was intentional
<mikdusan> and I can restore expressAnd to whatever it was originall
<mikdusan> thanks for catching this
<andrewrk> np
<andrewrk> that should be good for this PR. I think the end game is: codebase updated to use zig_assert or the other kinds of asserts that print source location, and leave `assert` alone since it has an expected meaning
<mikdusan> "luckily I keep my git worktrees numbered for just such emergencies" -- foghorn leghorn
<andrewrk> lol
<fengb> https://news.ycombinator.com/item?id=12847576 seems like a vocal minority hates that wasm optimizes for code size?
<daurnimator> andrewrk: no emails on milestone change.
adamkowalski has joined #zig
<andrewrk> probably a good thing, unless you wanted to receive 150 emails today
<adamkowalski> what is the fastest way to put something in a hashmap if it doesn't exist, or update the existing entry by adding it to the new entry?
<daurnimator> "adding it to"
<daurnimator> your element type is an array?
<daurnimator> adamkowalski: see the http.headers module; it does something like that.
<andrewrk> there's a getOrPut function
<adamkowalski> yeah it's an nd array. but that doens't matter. the thing that matters is that I want to take the new entry and the old entry and merge them. or put the new entry in if it's empty
<daurnimator> also does your key type require allocation?
<daurnimator> that required some... thinking to the order of operations
<adamkowalski> my key is a union(enum) of different types, but they don't require allocations yet. They will soon
<adamkowalski> andrewrk: getOrPut looks promising thanks!
<adamkowalski> so I could look at the GetOrPutResult and check if found existing is there? Then if I modify the kv will that modify it in the hashmap?
<mikdusan> adamkowalski: it's a pretty slick API. you get back a kv pointer no matter if there or not; and `found_existing` flags it for you, just remember to initialize if !found_existing
adamkowalski has quit [Remote host closed the connection]
seoushi has joined #zig
<daurnimator> mikdusan: the problem is if you need to allocate the key; and that allocation fails; then you end up needing to delete the entry that was created...
<mikdusan> if you have allocated-keys, don't you have to allocate one before calling getOrPut()
<daurnimator> mikdusan: no. because if the get succeeds... then you'd have allocated for nothing
<mikdusan> how's the get going to succeed without a key
<mikdusan> ah right the old string dupe
<mikdusan> i realy hate the "have to copy it because we're not sure of its lifetime" business
<daurnimator> mikdusan: often the source of `name` will be a network buffer: receive http header over the wire -> append it to the header structure
<daurnimator> that network buffer would be discarded; and the header structure lives on as it moves through whatever web-framework we end up with
<daurnimator> i.e. the copy is necessary for most of our use cases.
<daurnimator> and when its not... *some* headers would be in e.g. the data section; and others would not: the book-keeping for that is more expensive than just doing a copy!
<mikdusan> what you need is a union key... { short: [31]u8, long: *u8 } and hedge your bets
<daurnimator> mikdusan: no what we need is an enum of common headers :)
<daurnimator> which is kindly provided by http2
<daurnimator> which I have an open contributor friendly issue for....
urluck has quit [Remote host closed the connection]
urluck has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<mikdusan> andrewrk: #4389 CI (Windows platform) is on extended vacation, other platforms passed; and my local Windows tests passed; may I merge to master?
<andrewrk> yep go for it
<andrewrk> in general, I trust your judgement
<andrewrk> that's an exciting PR merge too :)
<andrewrk> it might be worth opening a PR to enable more freebsd tests in the CI and see what works now
<andrewrk> good night
<mikdusan> 'night
<fengb> Good night
<fengb> So... bare union has a secret enum in safe modes, but it's removed in release-fast?
<mikdusan> yup
<companion_cube> nice.
<fengb> Great thanks
ur5us has quit [Ping timeout: 240 seconds]
seoushi has quit [Ping timeout: 240 seconds]
livcd has quit [Ping timeout: 260 seconds]
dddddd has quit [Ping timeout: 240 seconds]
return0e_ has joined #zig
return0e has quit [Ping timeout: 260 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 265 seconds]
return0e has joined #zig
return0e_ has quit [Ping timeout: 265 seconds]
livcd has joined #zig
ur5us has joined #zig
_Vi has joined #zig
jasom has quit [Ping timeout: 260 seconds]
jasom has joined #zig
return0e_ has joined #zig
_Vi has quit [Ping timeout: 246 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 265 seconds]
waleee-cl has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
<daurnimator> wtf... why does io.BufferOutStream even exist
<daurnimator> pretty sure *every* use case is someone accidently using it instead of BufferedOutStream
_Vi has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
<betawaffle> is it not just an alias?
marmotini_ has quit [Remote host closed the connection]
<betawaffle> fwiw, i still don't know what's going on with streams because there is no documentation at all
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
<daurnimator> betawaffle: similar to allocator pattern right now
<betawaffle> i've run into situations where i want a "stream" but i've been a bit scared to figure them out
<daurnimator> betawaffle: essentially: always take the address of a stream member
<betawaffle> what's a stream member?
<daurnimator> betawaffle: stream objects tend to have a .stream field
eddyb[legacy] has joined #zig
<mq32> <betawaffle> is it not just an alias?
<betawaffle> that's what i asked
<mq32> I assume that BufferOutStream is a stream that allows writing into a buffer/slice object and BufferedOutStream is a stream that buffers writing into another stream into
<betawaffle> oh, i didn't even notice the -ed
<betawaffle> lol
<betawaffle> unrelated: i find myself wanting the equivalent of newtype often. like being able to define a type that behaves like say a u32, but has methods and other declaration-y things
<fengb> Wrap it in a struct or exhaustive enum :)
<betawaffle> but then i have to give the field a name
<betawaffle> it doesn't really behave the same
<mq32> betawaffle: what usecase? "different unit" or "unique identifier"?
<fengb> .@“” 🙃
<betawaffle> mq32: units would be one thing, another could be something like annotating a type with how to marshal/unmarshal it in some format'
<mq32> andrew really killed a lot of issues the last two days
<betawaffle> i agree there can be other ways to address both of those use-cases in other ways
<fengb> Tags are a semi hot topic for the latter
<betawaffle> whatever it is, i want it to not feel tacked-on or too heavy
<fengb> Struct wrapping isn’t heavy, but it does feel a bit tacked on >_>
<betawaffle> no, struct wrapping is totally fine, except for the ergonomics of it sometimes
<fengb> I’ve started liking it more since it feels better than the distinct type proposals
<betawaffle> a non-exhaustive enum comes really close, but that only works for int types, and it still has the "explicit unwrapping" problem
<betawaffle> i suppose if we just make a really fluent way to deal with "units" and tags can solve the encoding/decoding use-cases, that might be enough
<fengb> Units just got closed :P
<betawaffle> darn
<mq32> i don't think units are a good idea to have on language level
<mq32> the semantics of units is just way too complex to be expressed in a language like zig
<betawaffle> i mean... a unit is just a different type, you want the compiler to complain if you try to mix units without doing the conversions
<fengb> It’s not that simple
<mq32> is kilo byte another unit than byte?
<mq32> is gram the base unit or kilogram?
<mq32> or even pound?
<fengb> Or radians, which is unit less but not exactly
<betawaffle> what i mean is, i want to say: "let me add these two things (same unit) fluently, but make me do something special if i try to add it with some other unit"
<mq32> yeah that's what the distinct type proposal is proposing
<fengb> Yeah but it only works on addition and subtraction. How does bit shifting meters work?
<mq32> @Distinct(u32) will yield a new u32-type
<betawaffle> fengb: it'd be the same...
<fengb> Oh they’re not units. Just distinct
<mq32> yes, but i think that will solve exactly betawaffles problem
<betawaffle> right, the "units" themselves should be something the programmer needs to deal with
<betawaffle> the separation should be enforced by the compiler, though
<fengb> Yeah I like distinct types, but then there’s talk saying they are only scalars and no methods
<fengb> So I got bored and decided a struct wrapper isn’t so bad
<betawaffle> don't get me wrong... having the compiler automatically understand that two units are related by some scaling would be cool, but not that important
<mq32> fengb: i think it's a good thing to either have methods or operators
<betawaffle> i'd want methods
<mq32> because methods are pretty much custom operators / overloads
<betawaffle> something like newtype(u32) { ... struct/enum/union body ... }
<betawaffle> and all the operators on T would work for newtype(T), but only with other values of newtype(T)
<betawaffle> it would be up to the author to define helpful methods for converting to/from other types
<mq32> yeah but this can also be made freestanding
<betawaffle> so that you don't need to do MyType{ .value = a.value + b.value }
<betawaffle> you can just do a + b
<mq32> yeah, but that would also be possible without methods:
<fengb> Sounds like operator overloading 🙃
<mq32> const dist2 = dist1 + distanceFromMeters(345);
<betawaffle> fengb: except we'd not let you change the behavior of the operators
<mq32> const dist3 = dist2 + distanceFromNauticMiles(33);
qazo_ has joined #zig
<betawaffle> mq: but then you can do distanceFromNauticalMiles(33) + distanceFromMeters(345) and get the wrong result
<mq32> why?
<mq32> distanceFromNauticMiles would return the same type as distanceFromMeters, but will convert on your base type
<mq32> which could be "inch" or whatever
<betawaffle> well, not if you use a consistent "distance" unit returned by each of those
<mq32> that was the idea behind that ;)
qazo has quit [Ping timeout: 260 seconds]
<mq32> otherwise i could've just written "33 + 345"
<betawaffle> but at that point they are just plain numbers again and can be misused
<mq32> why that? i have to explicitly cast into "Distance"
<betawaffle> right, that's what i want from newtype
<mq32> @as(Distance, 10) // would return a value with Distance=10, whatever Distance may be
<mq32> and "fn distanceFromNauticMiles(miles: f32) Distance" would convert miles to the abstract distance unit
<mq32> it doesn't need custom methods or your "newtype" syntax, but just the builtin "const Distance = @Distinct(f32)"
<betawaffle> perfect, that's what i want. but we'd need newtype for that
<betawaffle> though it would be nice to have methods, imo
<fengb> const Distance = struct { meter: u32 }
<fengb> Distance.fromNauticMiles(33)
<betawaffle> fengb: but then how do you add them fluently?
<fengb> I suppose wrapping the types after operations is a little annoying
<mq32> this would crash as 33 nautic miles aren't good expressible as a u32 *grin*
<fengb> d.plus(d2) :P
<mq32> d.@"+"(d2)
<betawaffle> you have to agree that's pretty awkward
waleee-cl has quit [Quit: Connection closed for inactivity]
dddddd has joined #zig
<fengb> Hmm, wasm doesn't have computed goto
<fengb> Or technically forward goto of any kind
metaleap has joined #zig
FireFox317 has joined #zig
<betawaffle> how does llvm deal with that?
<fengb> Standard wasm generates "blocks" that you can break out of similar to Zig
<fengb> So it can represent all the same problems, but I'm curious what the performance ramifications are
<betawaffle> that probably depends entirely on the execution environment
<fengb> Oh this makes sense. Wasm execution memory does not exist to the binary, so it'd make no sense to have any sort of offset based goto
<fengb> I'm just discovering this stuff as I work my way through implementing it :P
davidkrauser has left #zig [#zig]
waleee-cl has joined #zig
return0__ has joined #zig
return0e has quit [Ping timeout: 260 seconds]
<companion_cube> wait, are you implementing a wasm execution machine?
<fengb> Yep
<companion_cube> that's some serious shaving of yacks ;)
<companion_cube> (or, seriously cool thing)
<fengb> Just learning more about VMs in general
<fengb> And Zig :)
<mq32> ah, fengb :)
<mq32> i'm implementing a VM as well
<mq32> but not for WASM
<fengb> I'm half-done with my Gameboy emulator. So in the honor of all my existing projects, I'm moving on 🙃
<betawaffle> fengb: where do you find the time?
wilsonk has quit [Ping timeout: 272 seconds]
<fengb> That's a good question
<fengb> There's a reason I never finish anything :P
<betawaffle> yeah, i mean i started trying to implement a wasm VM too, but didn't get very far. something distracted me
<fengb> I'm done with most of the instructions. That was by far the hardest brute force in Gameboy, and it was really simple with wasm
<fengb> Of course... I still need to figure out all the block / jump instructions
<mq32> fengb, wasm has no dynamic types like "string", right?
<betawaffle> not currently, no
<fengb> No, there's only 4 types in wasm
wilsonk has joined #zig
<fengb> i32, i64, f32, f64. It's surprisingly minimal yet function
<betawaffle> don't they have signed/unsigned too?
<betawaffle> and then there's the "function" types table...
<fengb> * i32, i64, f32, f64. It's surprisingly minimal yet functional
<betawaffle> oh right, signed-ness is a property of the instructions?
<mq32> ah yeah
<mq32> my VM will have dynamic types on the stack like array, enumertors and such
<fengb> Yep
<mq32> right now i'm just copying like a mad man, but first step is to get everything running with unit tests again
<mq32> <= doesn't have unit tests for version 1 & 2
<shakesoda> wasm hasn't got any u/i8's?
<fengb> The "registers" are at minimum 32 bits wide, but you can extend load i8/u8 from memory
<shakesoda> makes sense
return0e_ has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Ping timeout: 246 seconds]
seoushi has joined #zig
_Vi has quit [Ping timeout: 246 seconds]
<betawaffle> thanks, now i want a milkshake
<metaleap> scanning std.thread: one can `spawn` one and `wait` on one. "killing" one / aborting it isnt in there yet however
<dingenskirchen> I've encountered what I thought a really weird issue. It turned out much simpler: running things via `zig build run` causes std.io.readLine to fail instantly. Why is that?
<metaleap> would this be via some sig to handle/id? probably crossplatform ramifications?
<metaleap> dingenskirchen: i had that issue at the start with a most-minimalist readliner https://github.com/meta-leap/zigbag/tree/master/tmp/tmpstdioloop --- tried it again, still an issue via `zig build run` vs direct binary execution. `error.EndOfStream`. didnt bother me back then as my builds put all proggies some standard place in my PATH. but dig through std.build(.zig) if there's some tweak to pass the `zig build run`'s current stdin on to the binary that
<metaleap> the runstep runs
<metaleap> as for my threads, I'll have them monitor a custom "abort: bool" atomic across all their loops + iterations instead of digging through the earth to find out how to cross-platform-brute-force-kill them, hehe
<dingenskirchen> metaleap, thanks for the headsup! ^^
<dingenskirchen> aw, doesn't look like it's possible - RunStep.make() directly sets that behavior before executing the child process
<mikdusan> what would you expect tools like `make` or `ninja` to do with stdin? iirc, make doesn't drop stdin, and ninja does
_Vi has joined #zig
seoushi_ has joined #zig
seoushi has quit [Ping timeout: 260 seconds]
seoushi_ is now known as seoushi
<mikdusan> andrewrk: in this packed struct, what would you see llvm's <{ ... }> defined as?
return0e has joined #zig
return0e has quit [Client Quit]
mahmudov has joined #zig
Akuli has joined #zig
<dimenus> andrewrk: libsoundio works nicely with libmpg :)
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
ur5us has joined #zig
FireFox317 has quit [Quit: Leaving]
notjones has joined #zig
andybainbridge has joined #zig
<andrewrk> I'm taking a 2 day vacation to spend some time with my girlfriend. Be well everybody, see you on Friday
<mikdusan> audios amigos
<fengb> Take care
dimenus has quit [Quit: Leaving]
wilsonk has quit [Ping timeout: 268 seconds]
dalobstah has joined #zig
_whitelogger has joined #zig
wilsonk has joined #zig
<seoushi> is there a way to "hide" a member variable in a struct? I want to be able to access the variable inside a struct method but not elsewhere.
<BaroqueLarouche> I don't think so
<seoushi> one thing I can think of is to make a non public struct and the member variable would be in that.. will see if that gets the desired results
<seoushi> nope :(
<fengb> No private fields
<seoushi> I guess I'm resorting a a comment saying, don't access this. which is kinda crappy
<metaleap> seoushi most stdlib structs seem to expose enough methods so users never have to deal directly with the fields. not a bad convention but you can also settle on your own convention here, maybe prefix "private" with __ or put them all in some "internal" sub-struct.. whatever will help you later deal with your own apis. assuming you're not writing a lib for a currently-non-existing audience of millions of ziggers right now :P
<seoushi> yeah I planed on writting functions to expose the things I want. a naming convension for private does make a lot of sense tho
<metaleap> it is a given that in zig data types represent memory regions you get full access to --- also at comptime. should "private" fields not be processed in comptime funcs that may make alloc decisions or such based on what they can reflect on
<shakesoda> for other languages that don't do private and i don't particularly think the user should mess with a field i just single underscore prefix
<shakesoda> not much a fan of hiding stuff though, and this comes up a lot less if you don't have an oop design to begin with (just say no!)
<companion_cube> hiding stuff exists also in non-OO languages
<shakesoda> certainly
<companion_cube> it's the basis of having clear abstraction boundaries…
<shakesoda> i said only that it comes up less, not that it's not a thing
<companion_cube> idk, I feel like it comes up all the time for me :)
<seoushi> There are two reasons for me to want private. 1, so I can change the interface without breaking people. if they can't access it to begin with I can't break them. 2) to hide unsafe access. I only want write access in certain conditions but I can't store a const because there are some cases writes are needed
<shakesoda> you could hide the data at the module level instead of the struct
<metaleap> shakesoda: how would this support multiple "instances" of the struct?
<shakesoda> metaleap: passing in an index of the thing you want (or if it's more convenient, store said index in your struct)
<shakesoda> metaleap: this solution can have some caveats, namely adding an indirection that may not already be present
<shakesoda> most of the time i reach for this one there was already an indirection somewhere and i'm not doing it just to hide anything
<fengb> Export an opaque handle and expose functions to fiddle with that >_>
Akuli has quit [Quit: Leaving]
<seoushi> I wish I could generate anonymous functions. or perhaps some sorta function currying. That way I could pass a struct with function pointers to the methods I want to call.
<seoushi> rather the functions I want users to be able to call.
<metaleap> who are these users, i wanna learn about the "market" for zig code artifacts
<fengb> Changing struct fields also breaks the ABI in general. What you want seems to be interfaces, which don't really exist yet
<seoushi> Yeah interfaces could work
<metaleap> i mean if i were sharing some lib I wrote in C i'd fully expect 99.9% of the target audience to be "fully in the know" about the implications of wanton field accesses vs the benefits of instead investing only in the "interfaces" (functions) exposed and more likely to remain backwards-compatible for longer, right. why would a zig audience need more handholding or protecting..
<companion_cube> because safety is good? :)
<metaleap> but there's already rust/go/.net/java/etc for the anxious types :D
<mikdusan> this won't work today but maybe it should? https://hastebin.com/ekusumayiw.cpp
<fengb> Private != safe
<companion_cube> no, but it helps
<companion_cube> especially in a team, not everyone might be aware of what's safe or not in another part of the codebase
<fengb> mikdusan: struct memory layout is undefined so there's no guarantee that would work. And it'd definitely break if my randomization idea is a thing
<metaleap> in a team especially all need to be on the same page with regards to "conventions" anyway. again, conventions are all thats needed.
<metaleap> and if need be, some automatic linting tooling to guard against accidental violations. thats an ecosytem question tho, not a compiler burden then.
<metaleap> you can walk up and down the memory in unsafe languages so "private" is just a silly toy. you can also usually easily without restrictions "reflect" in most stacks on "private"s so really whats the point. its an annotation, nothing more. so lets bring in (non-noisy-looking, calm) free-form annotations and thatll take care of it, with community written linters providing assurances that many seem to long for
<metaleap> in fact pub/extern/packed i gather could be seen as existing "annotations" that the compiler knows about because it cares about them. as far as i care, it could allow and ignore any other monikers in that usually-prefix-location. all words before fn/const/var become "annotations". the wellknown ones the compiler uses, the rest maybe other tooling or comptime code picks up on :D funky evening ideas, too stuffed to do clean work tonight
<metaleap> (as well as before enum/struct/union i guess, you get the idea, probably a bit too unbaked right now)
<fengb> Get baked 🙃
<metaleap> probably should
dalobstah has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<metaleap> which one (or combination) of the 8 std.hash-es would you guys prefer when it comes to keeping track of (usually over 100 and under 1000) files identified by their abspath that is to be reflected via a hash/id. so searches dont strcmp all the time.
<metaleap> StringHashMap seems to default to Wyhash
<metaleap> from my amateur background i kinda have wy+xx as the top perf performers in my head. by combining both collisions are even more unlikely. anything im missing?
<BaroqueLarouche> Use the hash as the key and add functions that take strings but intenally hash it
<BaroqueLarouche> *internally
<mikdusan> fengb: another overlay variation: https://hastebin.com/janutataco.php
adamkowalski has joined #zig
<fengb> Two-way bindings now? :P
<metaleap> BaroqueLarouche: yeah the question is for "the best hash for the purpose, out of 8 exposed in std"
meraymond2 has joined #zig
lunamn_ has quit [Ping timeout: 272 seconds]
lunamn has joined #zig
meraymond2 has quit [Remote host closed the connection]
adamkowalski has quit [Quit: Lost terminal]
andybainbridge has quit [Remote host closed the connection]
FireFox317 has joined #zig
<FireFox317> I submitted #4435, but it's not compelety working yet. It doesn't resolve the decls slice when doing `decls.len` whereas doing `decls[0]` resolves the type and it works fine. Maybe someone (mikdusan?) knows how to make sure the type is actually resolved when doing `decls.len`.
return0__ has quit [Ping timeout: 272 seconds]
<mikdusan> FireFox317: take a peek at ir_analyze_instruction_array_type, and how it resolves LazyValueArrayType.length . maybe that's a hint
<FireFox317> mikdusan, Thanks. however in that case the lazy value is used for the array type, the length is resolved immediately. in my case the whole slice is lazy and thus the length is not known yet when generating the typeinfo.
wilsonk has quit [Ping timeout: 272 seconds]
<FireFox317> if that makes sense
metaleap has quit [Quit: Leaving]
wilsonk has joined #zig
dddddd has quit [Ping timeout: 265 seconds]
<mikdusan> FireFox317: an array access creates IR { GenElemPtr, GenLoadPtr }, and .len access { GenStructFieldPtr, GenLoadPtr }
mahmudov has quit [Remote host closed the connection]
<mikdusan> if my lldb session was correct, the GenElemPtr lead to a ir_resolve_const_val()
<mikdusan> and the GenStructFieldPtr doesn't seem to do that
<mikdusan> the corresponding functions are ir_analyze_instruction_elem_ptr() vs. ir_analyze_struct_field_ptr()
<FireFox317> and ir_resolve_const_val() calls ir_resolve_lazy indeed
<FireFox317> thanks mikdusan! I think I can solve it with this information