<andrewrk>
what, how did allowzero get into std.hash.murmur?
<andrewrk>
somebody (me) didn't review this code carefully
<mikdusan>
ah right. that's not a c-interop layer. that's zig userland
<mikdusan>
*std
<andrewrk>
this main loop of murmur hash looks like it should be rewritten with simd
<andrewrk>
also IMO the API should accept aligned slices
ave_ has quit [Quit: Connection closed for inactivity]
<andrewrk>
wow mikdusan it was a 1 liner that fixed all the rest
<mikdusan>
nice.
<mikdusan>
oh yeah I can see how that 1 liner has a huge effect
benjif has joined #zig
ur5us has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
jmiven has quit [Quit: bye]
jmiven has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
<andrewrk>
ir-clean-up-vars branch takes std lib tests from 3.378 GiB (4.59 GiB peak with time -v) down to 3.19 GiB (4.52 GiB peak with time -v)
jicksaw has quit [Ping timeout: 265 seconds]
<andrewrk>
we can narrow the gap between the measured-with-profiler and actual peak usage by freeing IrInstGen instructions after rendering them to LLVM, before calling emit module
<daurnimator>
What is your non-peak number there?
<mikdusan>
daurnimator: zig src/ C++ manual heap alloc/free counting/statistics. ie: doesn't include LLVM heap usage
<andrewrk>
peak is the real thing. the other thing is to help figure out what would be useful to work on
<andrewrk>
GenConst: 10342808 items, 64 bytes each, total 631.275 MiB
<andrewrk>
pretty sure none of these are referenced after each ir analysis
<andrewrk>
would be worthwhile to track down what these are:
<andrewrk>
Unknown_64: 2968513 items, 64 bytes each, total 181.184 MiB
<andrewrk>
Unknown_40: 3180098 items, 40 bytes each, total 121.311 MiB
<daurnimator>
40 byte allocations... wat
<andrewrk>
(they're "unknown" when the allocate<Foo>(...) calls don't have the string annotation)
<daurnimator>
shachaf: any more thoughts around implementing b+trees in zig?
<mikdusan>
also there's some alignment padding we don't account for. not terribly important just sayin'
<shachaf>
daurnimator: Is it clear what the API for this sort of thing should be?
<shachaf>
I could port my C code but right now it's just for u64 keys/values. It has a cursor API for iteration but it's a little ad-hoc, I'll probably work on that.
<daurnimator>
shachaf: any data structure like that should be parametized by Type
<daurnimator>
shachaf: similar to ArrayList or HashMap
<shachaf>
Sure, but it requires a little more thought how to do this for for more complex types.
<mikdusan>
Unknown_8: 37022601 items, 8 bytes each, total 282.460 MiB actually occupies twice that. if we found those and fwd'd them to a slab or arena allocator (that isn't even deinit'd) we'd get back 282 MiB
<andrewrk>
that's all pointers though, probably not a single type
<andrewrk>
every un-annotated T* is Unknown_8
jicksaw has joined #zig
<mikdusan>
but they're still malloc'd which on x86_64 does 16-byte allocations?
<daurnimator>
mikdusan: I'd be more concerned about overhead of allocation metadata
<andrewrk>
I do think there are several uses for an slab/arena allocator in stage1
<andrewrk>
oh I see what you're saying though
<andrewrk>
simply avoid overhead of unfreed things
<daurnimator>
shachaf: does it?
<andrewrk>
something that's kind of fun... once self-hosted is what we ship, and stage1 can be simplified to only be required to build self-hosted, we can make memory allocation decisions that are optimized for that use case
<mikdusan>
profile it and ship it :)
<andrewrk>
e.g. if we know that all of self-hosted source .zig files adds up to 9 MiB, then the memory allocation strategy is to allocate 9 MiB slab, and that's where source code goes
<mikdusan>
makes perfect sense. stage1 literally has 1 use case to tune for
<daurnimator>
five 2MB huge pages. done. :P
<daurnimator>
or I guess you can just have a huge buffer on the stack and allocate out of that
<mikdusan>
on macos re some malloc options: MallocScribble: "0x55 is written upon free and 0xaa is written on allocation"
<mikdusan>
there might be value for zig to write a different value than 0xaa to free'd areas?
<andrewrk>
there's value in having 0xaa be the bit pattern of `undefined` - we can use it for runtime safety to detect whether things are undefined
<andrewrk>
it would be a bit weird to introduce 2 different kinds of undefined states
<daurnimator>
mikdusan: sounds like it's already a perfect match
<mikdusan>
yeah I can see benefits of single undef value
<daurnimator>
mikdusan: mem-belongs-to-OS (segfault) -> malloc (0xaa) -> zig sets to undefined (0xaa) -> zig uses -> zig sets to undefined (0xaa) -> free (0x55) -> back to OS (segfault)
<mikdusan>
true. the option is still there isn't it
<andrewrk>
sometimes might have stronger detection of undefined, where 0x55 would also register as undefined
<andrewrk>
*some types
<andrewrk>
e.g. there can be a "not undefined" canary value
<andrewrk>
and 0xaa would clobber that
<andrewrk>
so would 0x55
<andrewrk>
it felt like a long dark tunnel this morning, but I think I may actually be able to merge #4152 today
<andrewrk>
that's a good sign that this actually has paid off some tech debt
<shachaf>
daurnimator: For example the tree stores multiple copies of keys at different levels, which I guess is probably fine.
<shachaf>
Depending on implementation it might store keys that have been deleted (though I don't do that right now).
<shachaf>
And you might want to minimize comparisons if comparison is expensive, etc.
<daurnimator>
shachaf: those first points don't matter; and the last one sounds like an optimization we could provide tuning options for in the future: not worry about it for a first implementation
dddddd has quit [Remote host closed the connection]
<shachaf>
I mean, if you have a tree of strings, and you delete a string from a tree, and free the string's memory, you probably don't want it to stick around as a key?
<shachaf>
Maybe that's not an expected use case, I don't know.
<daurnimator>
how would it stick around as a key?
<shachaf>
Keys that aren't used in the leaves might still be valid separators in internal nodes.
<shachaf>
I mean, maybe that doesn't matter.
<daurnimator>
to me it sounds like it doesn't matter...
mooch2 has joined #zig
adamkowalski has joined #zig
<andrewrk>
alright I'm giving up on #4152 for today but hopefully will be able to merge tomorrow
<andrewrk>
it's quite close
<shachaf>
I should probably finish making my C library nicer before thinking about porting it, really.
<fengb>
Nah, ditch C already >_>
<shachaf>
Can you easily do something like C's struct Header { ... }; struct A { Header hdr; ... }; struct B { Header hdr; ... }; union AorB { Header hdr; A a; B b; };?
<shachaf>
(Where you're not always allocating A and B through a union, I guess I should add.)
<fengb>
Yeah you can use a packed union or extern union to share the data bits
<shachaf>
I don't particularly want these to be packed, just to share the header. I guess I can pad them manually.
<fengb>
They both mean well-defined memory layout. Sounds like extern union would be good since it emulates the C ABI
<wilsonk>
anybody know of a good terminal app/debugger that highlights the line of C and shows the dissassembly beside it? I thought someone here recommended one a few weeks back
<wilsonk>
I think I even installed it but now I can't remember what the name of it was...duh...
<wilsonk>
maybe it was mentioned as an alternative to remedyBG?
<shachaf>
But making quicksort use logarithmic stack space is a 2-line change.
<fengb>
Wiki sort is constant stack
<fengb>
So it’s impossible to overflow
<shachaf>
(Just use the stack for the smaller half and then loop for the bigger half.)
lunamn has joined #zig
<shachaf>
Anyway I should learn how this block sort works probably.
<companion_cube>
anyway it's not like it's urgent
<fengb>
It’s a fancy in place sort
<companion_cube>
someone will rewrite it into timsort by 1.0, I'm sure
<fengb>
In place merge sort
<andrewrk>
shachaf, if you want less code and less theoretical properties use std.sort.insertionSort
<andrewrk>
it's real simple
<shachaf>
Fair enough! Or just write your own insertion sort.
<andrewrk>
9 lines
<shachaf>
Yep.
marmotini_ has joined #zig
<fengb>
"The memory.grow instruction grows memory by a given delta and returns the previous size, or −1 if enough memory cannot be allocated." ... why is the spec so vague
<andrewrk>
maybe the wasm spec is less vague
<fengb>
That's wasm spec from W3c. I have no idea how to return pages above u31 because the return value is i32
<fengb>
I guess I'll just ignore it!
mooch2 has quit [Ping timeout: 248 seconds]
<shachaf>
wasm only supports 32-bit pointers as far as I know.
<daurnimator>
that same branch is now a candidate for merge again
<daurnimator>
I guess I have to open a new PR?
nofmal has quit [Remote host closed the connection]
<andrewrk>
I don't have a re-open button either
<daurnimator>
Replacement pr sent. (#4304).
<betawaffle>
is the byte-boundary thing still an issue for packed struct bit fields?
<daurnimator>
time to head to bed
<fengb>
Is the correct way to declare a named tuple to use `@"0", @"1"` ?
<daurnimator>
fengb: not sure I've considered that before.... `const foo = @TypeOf(.{@as(T, undefined), @as(T2, undefined)});`
<daurnimator>
I get the feeling that sort of code may end in compiler segfaults :P
<Snektron>
this gives me std::declval vibes
<Snektron>
The correct zig-type for a zero-terminated char* in C is `?[*:0]` right?
<novaskell>
as with error unions `||` is there an equivalent for structs such that `.{ x: u8 } <> .{ y: u8 } = .{ x: u8, y: u8 }`?
<daurnimator>
novaskell: no.
<daurnimator>
novaskell: there's a couple of open proposals that could result in that though
<novaskell>
nice, will try looking for them again
<andrewrk>
fengb, naming the fields as integers won't make zig consider the type to be a tuple. there's arguably a hole in the syntax for declaring tuples
<andrewrk>
it would make sense to be something like: tuple {i32, bool}
<waleee-cl>
the last commit to master (926a7adb3), wasn't the sentence identical before and after (doc/langref.html.in) ?
dingenskirchen1 has joined #zig
dingenskirchen has quit [Client Quit]
dingenskirchen1 is now known as dingenskirchen
<waleee-cl>
oh, my bad. The font I use apparently have crap difference between a and o in tig
<novaskell>
thanks daurnimator
<novaskell>
seems to be enough to emulate row polymorphism to some extent
metaleap has joined #zig
<metaleap>
novaskell: what more "row polymorphism" than the already existing `var` could you possibly want? curious :D
<metaleap>
(the "type" placeholder, not the var-decl keyword of course)
dingenskirchen has quit [Remote host closed the connection]
<daurnimator>
okay really bed now :P
naltun has joined #zig
<Snektron>
no c_char?
dingenskirchen has joined #zig
<novaskell>
Just ease of use since sometimes the combination of two structs would satisfy the type and repacking isn't usually that much fun (as in Idris (type machinery can but it's heavy), Haskell, etc) along with generating types based on DSLs. Though I probably need to explore zig more in depth than I currently have for it
<companion_cube>
row polymorphism and monomorphization together might not be that simple
<fengb>
Zig is much lower level than either of those languages. Struct fields need to map to memory directly
<metaleap>
i was only thinking of the duck-typing scenario `var` allows, but a join of 2 structs is sth else
<novaskell>
Sure, it's closer to ATS
<andrewrk>
the way I think of it is: zig is as high level as possible, without ignoring the reality of memory as a limited resource
<andrewrk>
and without giving up the ability to match ABIs
<metaleap>
can anyone explain me the whole "traits" design (seems too much in flux to make it into langref?) wrt this scenario: my struct-type is to have both an instream and an outstream field. whether socket or file or buffer etc (assume OSes where not "everything is a file" if that helps =) so far I temporarily declared them explicitly `*std.io.InStream(std.os.ReadError)` and `*std.io.OutStream(std.os.WriteError)` to be able to take stdin/stdout's
<metaleap>
`&.<in/out>Stream().stream`. but is that the whole idea or is there a more interface-like notation without specific error sets? there could be instream impls having different errors. does the struct itself need to be generified/type-parameterized? hoping not, would become a cumbersome api
<fengb>
Oh duh, I can't access fields through the type
<fengb>
user error!
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<metaleap>
whats with using "@memberName(tupletype, idx)" =)
<andrewrk>
beautiful. the solution to fixing a test case in the ir-clean-up-vars branch was to delete result location code special handling of 0 bit types
<mq32>
andrewrk: those are the best fixes
<mq32>
deleting code means removing possible bugs :)
<andrewrk>
then you can change it from /usr/include/curl/curl.h to curl/curl.h as well
<andrewrk>
I'm guessing for you it will be -I/usr/include -L/usr/lib
<naltun>
So add the -l and -L onto what I already have?
<andrewrk>
that's a capital i
<naltun>
Ah
<andrewrk>
this tells zig where to find headers and library files, respectively
<andrewrk>
after #2041 is solved, then adding any -l option when building natively will trigger zig to detect your native system paths
<Snektron>
dimensus, now i am
<naltun>
andrewrk, I'm getting `Invalid argument: -I/usr/include' as a result
<Snektron>
dimenus i mean
<andrewrk>
naltun, what zig version?
Snetry has quit [Quit: left Freenode]
<naltun>
0.5.0
<andrewrk>
-isystem /usr/include
<naltun>
trying
<andrewrk>
btw there was an overhaul of translate-c between 0.5.0 and master branch, which relates to using @cImport with curl
<andrewrk>
next release is in april
<naltun>
Awesome, thanks for that info.
<naltun>
Also, I just compiled successfully and was able to access the curl symbols. Thanks!
Snetry has joined #zig
<naltun>
Thanks andrewrk.
<andrewrk>
I'm expecting that issue to be solved by 0.6.0, so you wouldn't need this workaround then
<naltun>
Awesome.
dingenskirchen has quit [Remote host closed the connection]
<metaleap>
do any of you know whether anonymous struct literals can today (or are planned to eventually) support the following (minimal repro gist) use-case?
<metaleap>
dont think there's a field mismatch, they're easy to see as compatible with signature. as per "structural typing" I'd feel the struct compat between the literal and its corresponding arg decl should be there?
<metaleap>
(err msg in gist title, same as described earlier)
Snetry has quit [Quit: left Freenode]
dingenskirchen has joined #zig
<dimenus>
Snektron: trying to setup a post processing shader in a second render pass
<dimenus>
and i'm running into issues with SubpassDependencies
Snetry has joined #zig
<andrewrk>
metaleap, this code looks like it should work to me
<metaleap>
andrewrk: indeed, if one extracts the struct into a named-def, it compiles. so for "structural typing" i suppose I'll open an issue then
<andrewrk>
thanks
<Snektron>
dimenus, what kind of issues? Not that i've done much with render passes
<Snektron>
in my project i cheekily used the feature that you can render directly to a framebuffer from a compute shader
<Snektron>
so i could skip all that
<dimenus>
the image layout transitions from the first pass, i'm going to re-read the spec on subpass dependencies
<Snektron>
you can manually transition the image to another layout iirc
<Snektron>
i had to do that quite a lot
TheLemonMan has joined #zig
<TheLemonMan>
andrewrk, what's the correct way to check if a given feature is available for the current target?
<andrewrk>
TheLemonMan, here's an example: std.Target.current.cpu_features.features.isEnabled(@enumToInt(std.Target.arm.Feature.neon))
<andrewrk>
it might be nice to have some helper functions for that
mahmudov has joined #zig
<andrewrk>
for example: std.Target.hasArmCpuFeature(.neon)
<andrewrk>
which would return false for non-arm arch
<andrewrk>
err it would be std.Target.current.hasArmCpuFeature(.neon)
alexpana has quit [Ping timeout: 265 seconds]
<andrewrk>
TheLemonMan, I think you're going to be happy with the changes made by #4152. it's a significant improvement in debugging experience
<andrewrk>
all these fixes haven't been hacks, they've been sensible improvements
<TheLemonMan>
yeah I was scrolling trough the commits, lots of nice stuff
<TheLemonMan>
"bitcast sandwich" hah
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<betawaffle>
is it possible to get the value of a const declaration from TypeInfo?
_Vi has quit [Ping timeout: 272 seconds]
forbjok has joined #zig
<andrewrk>
betawaffle, are you aware of @field ?
<forbjok>
Is there any way to generate a set of function calls at compile time that take a non-compile time variable from the containing function?
<betawaffle>
does that work for declarations too?
<andrewrk>
it's equivalent to `a.b` syntax where `b` is a compile-time known string
<betawaffle>
ok, so if `a` is a `type`, it should let me get the declaration then?
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
yes
<betawaffle>
awesome
knebulae has quit [Remote host closed the connection]
metaleap has quit [Quit: Leaving]
metaleap has joined #zig
Akuli has joined #zig
metaleap has quit [Quit: Leaving]
<mikdusan>
well I tracked down those stage1 8-byte allocations -- they're pointers; and mostly via ZigList<IrInstSrc*> -- so there's no easy malloc overhead to be clawed back :(
<TheLemonMan>
andrewrk, so, should we compile compiler-rt in release mode everywhere (but in tests) (and beside ReleaseSmall) ?
<andrewrk>
I support that
<andrewrk>
the code for that is in link.cpp calling create_child_codegen
<andrewrk>
mikdusan, ah yes, I briefly banged my head against c++ trying to address this
<andrewrk>
I keep admitting to people yeah zig's comptime parameters are basically the same as c++'s template parameters. but then I try to use c++ template parameters and it's a complete shit show
<companion_cube>
"basically the same, except usable"
<TheLemonMan>
BaroqueLarouche, I see you have some memset32/memcpy32 versions in your code. If you specify the right align() parameter llvm will automagically generate a call to a function that takes advantage of the alignment
<mikdusan>
and this (typename -> const char*) business is truly sad. I mean the symbols are there, the linker knows about it, and yet we *MUST* turn on -frtti to get typeid() in C++. oh my. and that's a no-go because then LLVM has to be -frtti'd too. what a loss. and boost's type_index module which apparently can get typenames without rtti is just-say-no. it brings in about 10 other modules of spaghetti.
<BaroqueLarouche>
TheLemonMan: where do I put this align parameter ?
<TheLemonMan>
BaroqueLarouche, on your pointers
<Snektron>
mikdusan, you can recreate that functionality pretty simple
<Snektron>
but
<Snektron>
its not for the faint of heart
<BaroqueLarouche>
TheLemonMan: I'll try it soon
<TheLemonMan>
right now our compiler-rt uses a generic 1-byte-a-time memcpy/memset but it's very easy to fix that :P
<mikdusan>
Snektron: well I thought about hacking __PRETTY_FUNCTION__ lol
<Snektron>
yeah that is the hack
<Snektron>
its disgusting but it works, and if its only for diagnostics it might be viable
<Snektron>
on compilers not {clang, gcc, msvc} it could just output "unknown"
<TheLemonMan>
maybe you can use some constexprs to ease the pain
<Snektron>
yeah you need to use constexpr to extract the type name after
<Snektron>
But you cant get it in a raw way
<Snektron>
anyway
<mikdusan>
Snektron: we basically only need it for platforms where a developer is identifying what needs to be worked on so that's not the issue. but it is an issue needing another fricken llvm build just for rtti . grrr.
<Snektron>
Does anyone know how align() works on packed structs
<Snektron>
i mean, what does align(a:b:c) mean?
<mikdusan>
yes!
<mikdusan>
i actually know. or I think I know :)
<mikdusan>
a = align in bytes. b = bitsize of type. no padding. c = "host integer" byte size. the size of what LLVM load instructions will be.
<mikdusan>
oh sorry b = offset in bits from host integer
<Snektron>
aha
<Snektron>
thank you
<mikdusan>
it's andrewr's clever way of making all sub-byte pointers work without needed any more bits in the pointer -- all the info is in static type system
<Snektron>
I ran into it before but i couldn't find any information about it
<andrewrk>
forbjok, this use case may be better solved with generating zig code at build time. or, better yet, maybe you don't need meta programming at all. maybe you can solve the problem with programming
<forbjok>
fengb: Yeah, I saw that before. I'm already using @Type to generate an arbitrary-sized integer at compile-time, but would this allow creating struct fields at compiletime if it was implemented?
<forbjok>
Yeah, there are probably ways to avoid it. I'm just trying to figure out what can be done and what can't, as I haven't used Zig until today.
<fengb>
Possibly? But it's not defined or scoped out. I remember tgschultz having something in userland
<tgschultz>
It involves some advanced comptime usage.
<forbjok>
I was trying to create a simple Entiy Component System that takes a set of component and systems in a comptime variable and generates an ECS struct
<tgschultz>
The implementation is linked within, but has not been updated since 5.0
<forbjok>
Ideally, I'd want it to do as much of the setup as possible at compiletime
<mq32>
forbjok, for a simple ECS you don't need much meta programming
<tgschultz>
The basic technique is: take a struct type as input and a new field type, then return a struct with the previous struct as a field and the new type as another field. Use a bunch of helper methods to set and get fields.
<mq32>
Each component "class" must provide an array of all components, each component must know it's entity and you need to know all possible component types
<mq32>
that should be easily doable in Zig with a little bit of comptime :)
<mq32>
like
<forbjok>
mg32: I know it isn't strictly needed. I've implemented a similar one in C# before, where every component array field was just hardcoded in. I could probably also use a multi-dimensional array for the components to store them all in a single field
<forbjok>
since code generation doesn't seem possible anyway
BaroqueLarouche has quit []
<mq32>
just don't go the C# way of "inheritance"
BaroqueLarouche has joined #zig
<mq32>
use array-of-data instead of data-with-array
<forbjok>
I didn't use inheritance in my C# ECS. That would kinda undermine the point of an ECS.
<forbjok>
If you mean use an array for each component type, then that's already what I was intending
<dimenus>
how do i ensure that a bool is 4 bytes?
<forbjok>
as opposed to having an Entity struct
<forbjok>
entities will just be an index into the component arrays
<mq32>
yeah, kinadish that's the idea
<forbjok>
so the entity ID is effectively just the index
<TheLemonMan>
dimenus, turn it into a u32?
<dimenus>
was just curious if there was a more idiomatic way
<dimenus>
i spose that's it lol
<mq32>
forbjok: use a double-indirection of ID→Index
<mq32>
because otherwise you have to reuse indices which is bad
<mq32>
make entity IDs unique
<forbjok>
I kinda wanted to avoid the indirection for performance reasons
<forbjok>
but it might end up being necessary
<forbjok>
I can see how it might result in some weird bugs if indexes are reused and there is a reference to an entity ID in some other entity's component
<mq32>
yep
<mq32>
with unique ids you can check liveness
<forbjok>
Yeah. Another option might be to keep a generation number separate from the component bitmasks
<Snektron>
you can also use a generational id
<forbjok>
That way I could keep both index and generation wherever entities are referenced and check them when retrieving a specific entity
decentpenguin has quit [Quit: decentpenguin]
<forbjok>
The main iteration loops in systems wouldn't really need the check, so it'd be a lot of overhead if it was done universally
<TheLemonMan>
andrewrk, re TTY.Config in debug.zig, why do you want a file payload for windows_api? isn't out_stream enough?
<naltun>
Question on navigating between types. When working with CURLoption, I get `error: expected type '.cimport:13:17.CURLoption', found 'comptime_int''. https://gist.github.com/naltun/cc7924a6f8f421a94cd7713b06bff543. Question is, how do I keep Zig from setting this as a comptime_int?
<naltun>
when working with libcurl's CURLoption*
<andrewrk>
TheLemonMan, GetConsoleScreenBufferInfo and SetConsoleTextAttribute are using the stderr_file global, which is not available via the stream arg
<andrewrk>
if you called dumpStackTrace with an out stream that is not stderr, that code is incorrect
<andrewrk>
btw fengb I realized that fixing missing async spill bugs is easy
<TheLemonMan>
oh well, it'd be incorrect anyway since supportsAnsiEscapeCodes is always called on stderr_file
<andrewrk>
turns out I made this really convenient SpillScope thing. the hardest part is just looking at the llvm error, looking up the !1234 thing into source locations, figuring out where in the source that is referring to
<andrewrk>
TheLemonMan, at all detectTTYConfig() callsites, the code is using stderr as the stream
<andrewrk>
I agree the code would be more clear to accept a file parameter
<andrewrk>
detectTTYConfig and TTY can probably be usefully moved out of std.debug to become generally useful
<TheLemonMan>
naltun, I guess you need a @intToEnum(libcurl.CURLoption, libcurl.CURLOPT_URL)
<TheLemonMan>
or just .CURLOPT_URL if it's really an enum
<TheLemonMan>
andrewrk, yeah all the callsites use stderr, that's why I asked
<andrewrk>
but for example writeCurrentStackTrace is public
<naltun>
TheLemonMan thanks, I'll review that function now.
<TheLemonMan>
yeah, making sure the titty config and the out_stream refer to the same stream is up to the caller then
<TheLemonMan>
we could just shove both in a context struct but that's not a big deal atm
<fengb>
Ah cool, I was planning on trying to tackle the optional spill
<andrewrk>
TheLemonMan, detectTTYConfig could be a nice member function of std.fs.File
<TheLemonMan>
*shrug*, it just calls supportsAnsiEscapeCodes/isTty, it'd feel redundant
<andrewrk>
I do think it would be nice to figure out some convenient way to make the easiest way to write data to a terminal, to properly terminal escape text, but also support intentional terminal escapes
<forgot-password>
andrewrk: Did you read my message about the `zig translate-c` thing on sunday?
<andrewrk>
e.g. if you did std.debug.warn("{}\n", blah), and `blah` contains terminal escape codes, and the output is a terminal, they should be escaped
<andrewrk>
I'm using the word "escape" ambiguously here but I think you get the idea
<andrewrk>
forgot-password, no, can you remind me?
<forgot-password>
It was about translating the CoreAudio headers on macOS
<forgot-password>
You replied to me about that, but I only saw that in the evening and you were offline
<andrewrk>
can you repeat the question
<forgot-password>
Sure – I got errors about some seemingly swift-wrapper-related code when using `translate-c`, but compiling with clang works fine
<forgot-password>
I thought that clang maybe detected it as objective-c, where it worked fine, but even using `clang -x c $file` didn't throw the error
<forgot-password>
Okay, I'll need to get the build process up and running then, thanks a lot! :)
Akuli has quit [Quit: Leaving]
companion_cube has quit [Quit: WeeChat 2.3]
companion_cube has joined #zig
<andrewrk>
#4152 merged! I expect there to be a few regressions - with reasonable fixes - and also quite possible a bunch of seemingly unrelated bugs fixed
<TheLemonMan>
andrewrk, how did you solve the problem with the sr.ht machine?
<andrewrk>
TheLemonMan, the problematic behavior had this algorithm: if cpu matches exactly, assume the cpu features based on the static set of cpu features in the list we have hard coded for that CPU
ltriant has joined #zig
<andrewrk>
now, master branch behavior has this: if the cpu matches a known cpu, initialize feature set with the list we have hard coded for that CPU. next, iterate over the provided cpu features, respecting the + and - affecting the set. finally, chase the dependencies
<andrewrk>
so, on sr.ht if you inspect the target CPU at comptime it will be wrong. but the detected cpu features correctly override the feature set, so that everything works
<andrewrk>
basically, detected cpu features override detected cpu model
<andrewrk>
which is the same reason why gcc and clang work on that machine
<TheLemonMan>
have you tried running clang with --march=native ?
<andrewrk>
no
<andrewrk>
well, kind of. zig is passing that when building libcs from source in the test suite
<TheLemonMan>
I still think this is a (unneeded) workaround
<andrewrk>
I don't consider it to be a workaround; I consider it to be the correct way to detect the cpu feature set
<TheLemonMan>
you're throwing away a piece of information (the cpu name) because of this
<andrewrk>
that's not true - the cpu name is kept, and available at comptime, and it is used to initialize the set of cpu features
<andrewrk>
`std.Target.current.cpu_features.cpu.name` is always available - it's a struct field, not union, and it's non-optional
<TheLemonMan>
who cares, LLVM doesn't get it so it's just a useless string
<andrewrk>
llvm does get it
<TheLemonMan>
it should crash and burn with the "athlon-xp" + 64bit features combo
<andrewrk>
llvm also has the logic, that makes the cpu features override the model
<andrewrk>
one other thing that was pointed out to me in #llvm is that the cpu model name is not unique - there are pieces of hardware that match model name yet have different sets of features enabled
<andrewrk>
maybe in the bios, for example
<TheLemonMan>
the cpu name specifies more than a set of features
<andrewrk>
I double checked, we're passing the cpu name to llvm unconditionally, and also to clang for translate-c/cimport
<TheLemonMan>
then why it's not blowing up like it did before?
<TheLemonMan>
the cpu is indeed wrong, but that's a problem with qemu
<andrewrk>
because before, llvm was not getting +64bit, but now it is
<andrewrk>
detecting invalid combinations of cpu model and features is an interesting and probably useful concept, but it's more complicated than simply not taking into account detected cpu features. it would be more involved to add this detection
<andrewrk>
it is correct to take into account detected cpu features
<andrewrk>
the knowledge that detecting "64bit" on an "athlon-xp" cpu is a strange situation, is extra-cirricular
<pixelherodev>
andrewrk, what's the short summary of the effects of that tech debt merge?
<pixelherodev>
That is, from a user's perspective :P
<pixelherodev>
Changes in speed / RAM usage? or is it fully behind-the-scenes?
<TheLemonMan>
if llvm is fine with such cpu/+64bit combo then I rest my case
<andrewrk>
it is; and so is gcc. that's why gcc and clang both work on that box
<andrewrk>
pixelherodev, (1) fixing bugs in the most complicated parts of the compiler is now significantly easier (2) there may be some new regressions, but also I expect that to have fixed a handful of other nasty bugs (3) small reduction in RAM usage (4) meaningful progress towards #2765 and #2761
<pixelherodev>
Gotcha, neat! "Small" meaning "a couple KB" or "1%" or?
<fengb>
Yeah, I'm trying to annotate my function so I can do some metadata analysis
<fengb>
But structurally it should be a tuple since order matters. I could make a fake tuple struct
<andrewrk>
I think it would make sense to have tuple syntax probably. the language has the type and it's not exposed. that's weird. it would be less weird to just expose the type with syntax like every other type
frmdstryr has joined #zig
jessermeyer has quit [Remote host closed the connection]
jessermeyer has joined #zig
<fengb>
Struct field order is well defined right? It's only memory layout that's undefined
<jessermeyer>
Would leveraging the build system be the most natural place to systematically implement profiling blocks?
<andrewrk>
fengb, correct
<sirnaysayer>
TheLemonMan: compiling as release-small seemed to work just fine, ill play with those settings. I am still curious why those errors happen on the default mode.
<TheLemonMan>
sirnaysayer, yeah you're disabling some security features
<TheLemonMan>
try with -target x86_64-windows-msvc
<Snektron>
how often does godbolt update the trunk compiler?
<andrewrk>
TheLemonMan, stack traces in stage1 panics stopped working for me btw
<TheLemonMan>
same here, I'll have a look after I finish this PR
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<jessermeyer>
Does translate-c translate strictly more than the input provided?
<jessermeyer>
I tried translating a very simple macro and the output was ... well.. a lot more than the macro.
<TheLemonMan>
it tries its best at interpreting what the macro is trying to do
<andrewrk>
yes translation of macros are heuristic at best
<jessermeyer>
#define macro(param)\ (param)
<jessermeyer>
gives me...
<andrewrk>
consider that you're asking zig to look at arbitrary text substitution (which may not even be valid C), with no context, and convert that to zig