<tgschultz>
error: container 'generateStructFieldFn(generateStructFieldFn(generateStructFieldFn(generateStructFieldFn(EndMarker,usize,usizeEqual).FieldFn(u8,0),usize,usizeEqual).FieldFn(u10,1),usize,usizeEqual).FieldFn(i16,2),usize,usizeEqual).FieldFn(void,3)' has no member called 'field_id'
<tgschultz>
The joys of comptime type construction
<daurnimator>
tgschultz: and that's why I name my intermediaries :)
<tgschultz>
This isn't a complaint, I know I've brought this on myself through practicing whitchcraft
<tgschultz>
This type is recursively constructed, so that isn't possible.
<daurnimator>
tgschultz: are you sure?
<daurnimator>
tgschultz: can't call it MyStruct1, MyStruct2, MyStruct3, etc as you build it?
<daurnimator>
tgschultz: show me the witchcraft you're using :)
<tgschultz>
there's a base struct of functions, wrapped by a struct that's generated by (and contains) a FieldFn generated by another function. you chain generated FieldFns together to built a recursively defined struct
<tgschultz>
pub const Field = generateStructFieldFn(Self, Id, equal);
return0e has quit [Read error: Connection reset by peer]
<daurnimator>
==> that was a request for the body of generateStructFieldFn :P
<daurnimator>
I thought you might have done it with `use` abuse
<tgschultz>
the hardest part about this is that if something goes wrong there's about an 80% chance the compiler just asserts
<tgschultz>
this is mostly an experiment, but I did find a use for a less extreme version: typing together a group of type-specific things into one object.
<tgschultz>
*tying
<tgschultz>
when/if use starts working in structs I might try that. I don't really want to deal with a bunch of different files to do it.
<tgschultz>
it would also be nice if I didn't have to create a struct just to store a function that I then return.
<daurnimator>
tgschultz: I think `use` at the moment only imports functions? not variables?
<daurnimator>
oh... nope :(
<tgschultz>
namepsaces are structs now
<tgschultz>
you can have top level fields in a file.
<tgschultz>
and do this: const std = @import("std"); const std_inst = std(undefined); @typeOf(std_inst).os.exit(0);
hoppetosse has quit [Ping timeout: 246 seconds]
return0e has quit [Read error: Connection reset by peer]
return0e_ has joined #zig
jjido has joined #zig
jevinski_ has joined #zig
jevinskie has quit [Ping timeout: 248 seconds]
reductum has quit [Quit: WeeChat 2.4]
bugabinga has joined #zig
wootehfoot has joined #zig
Sahnvour has joined #zig
rivten has joined #zig
bugabinga has quit [Ping timeout: 248 seconds]
qazo has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
<daurnimator>
hrm. what would you shorten "Reverse Variable-length Integers" too?
<daurnimator>
the existing code I'm looking at uses 'rbits' => reverse bit strings
<daurnimator>
I started writing "packed" instead..... but that has another meaning in zig
porky11 has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bugabinga has joined #zig
slugm has joined #zig
slugm has quit [Read error: Connection reset by peer]
slugm has joined #zig
tane has joined #zig
porky11 has quit [Ping timeout: 248 seconds]
porky11 has joined #zig
porky11 has quit [Ping timeout: 252 seconds]
jjido has joined #zig
slugm_ has joined #zig
slugm has quit [Read error: Connection reset by peer]
return0e_ has quit [Ping timeout: 248 seconds]
return0e has joined #zig
porky11 has joined #zig
slugm_ has quit [Read error: Connection reset by peer]
slugm has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
qazo has quit [Ping timeout: 258 seconds]
bugabinga has quit [Ping timeout: 248 seconds]
scientes has joined #zig
porky11 has quit [Ping timeout: 252 seconds]
slugm has quit [Remote host closed the connection]
slugm has joined #zig
bugabinga has joined #zig
porky11 has joined #zig
hio has joined #zig
<daurnimator>
oh fun
<daurnimator>
Debugging the failing test in #2424 I found some buggy code in the parser
<daurnimator>
(that was the cause of the bug)
<daurnimator>
I hate to say it; but this was a bug that rust would have found really easily
<daurnimator>
instead of taking 3 hours >.<
<daurnimator>
the 'nocopy'/'fixed' annotation may have helped though
TheLemonMan has joined #zig
Zaab1t has joined #zig
<TheLemonMan>
how lovely of llvm to silently "upgrade" all the f16 to f32 for targets that do not natively support them
<daurnimator>
TheLemonMan: oh I didn't realise you were in here (I'm assuming you're LemonBoy?)
<scientes>
I have to agree that using mlock() on the stack by default is a good idea
<scientes>
like i just ran into that git clone crashes on a system with 512MB of ram
<scientes>
like 512MB is not small....
<TheLemonMan>
daurnimator, yup
<scientes>
and linux already supports this, up to 64MB (per user?)
<scientes>
or is it 64K
<TheLemonMan>
ulimit -l says 65536 here
<scientes>
ulimit -a says that is kb
<TheLemonMan>
yup
<scientes>
probably the default would be to mlock() but continue if it fails
<daurnimator>
scientes: hmm? where is this discussion continuing from?
jjido has joined #zig
<scientes>
It was a suggestion by andrew, i can't find it, and it depends on #157
<scientes>
without #157 it would waste memory
bugabinga has quit [Ping timeout: 248 seconds]
<scientes>
but few test with low memory systems, and it isn't fun when you use them
<scientes>
even 512MB is "low-memory" these days
<daurnimator>
scientes: I don't see a reason to mlock the stack.... if the OS wants to page in stack frames, let it...
<daurnimator>
*page out
<scientes>
that isn't the problem
<scientes>
actually it would be nice if there was a mlock that could allow that
<scientes>
the problem is OOM when extending the stack
<scientes>
due to overcommit
<TheLemonMan>
sometimes you don't want to have the stack contents spill on disk as that may leak some secrets
<scientes>
the oom killer is this ominous black box of uncertainty
<scientes>
yeah swap subsystem should have encryption support
<scientes>
but then you can't hibernate
<scientes>
it is done with dm-crypt
<daurnimator>
TheLemonMan: well the obvious answer there is that you shouldn't have secrets on the stack.... should be in their own heap with MADV_DONTDUMP and MADV_WIPEONFORK
<daurnimator>
(yes I know that isn't always, or even mostly, the case for programs today)
<TheLemonMan>
that's a nice idea for a SecureHeapAllocator
<daurnimator>
TheLemonMan: can just use the direct allocator and madvise yourself....
<TheLemonMan>
but I love the idea of stacking allocators :(
<andrewrk>
"The binary format of half, float, double, and fp128 correspond to the IEEE-754-2008 specifications for binary16, binary32, binary64, and binary128 respectively."
<andrewrk>
well, as long as it makes the memory model work, I'm fine with it
<andrewrk>
I would love to unconditionally mlockall() by default but unfortunately the resource limits in practice make that not an option
<daurnimator>
andrewrk: so this isn't finished yet and I need to go to bed.
<daurnimator>
andrewrk: do you want to have a look now in incomlete state?
<daurnimator>
currently trying to fight: unreachable: /deps/zig/src/codegen.cpp:gen_const_val_ptr:6010
<andrewrk>
as long as they make bitcasts / ptrcasts work correctly it should be ok
<andrewrk>
it's a shame because the zig project is willing to add library calls for such things
<andrewrk>
related: https://github.com/ziglang/zig/issues/1485 - the only reason this doesn't work is because llvm doesn't emit lib calls, which zig would happily add to compiler_rt
<TheLemonMan>
it's yak shaving all the way down heh
<andrewrk>
daurnimator, any time I have today I want to spend on copy elision
<daurnimator>
k, go for it :)
* daurnimator
still isn't sure what to call "Reverse Variable-length Integers" structure
<daurnimator>
or which file to put it in in std/
<scientes>
daurnimator, what does it do?
<scientes>
daurnimator, cause unsigned little endian numbers can be extended in-place
<scientes>
daurnimator, don't call it "reverese" just call it little-endian. If you read Jane Austen she uses that "four-and-twenty", and in Arabic, arabic numerals are little-endian (cause it is a right-to-left language
<daurnimator>
scientes: its 'reverse' because you have to seek backwards in memory to find the 'end' bit
<daurnimator>
if the high bit isn't set, you have another byte to seek backwards to
<scientes>
daurnimator, oh I did something similar once for AVR programming
<daurnimator>
scientes: its used in my allocator so that I can store data before the user's pointer and find it again
<scientes>
but there are much cleverer ways of stuffing bits
<scientes>
you could also use something similar to utf-8
<daurnimator>
scientes: it sort of is like utf-8. but in reverse :)
<daurnimator>
/bed
<scientes>
what time zone you in?
<scientes>
I might go swimming at the beach in a sec as a break :)
<scientes>
daurnimator, ^
<andrewrk>
scientes, are you still working on #2240?
<andrewrk>
ball's in your court
<scientes>
yeah i'll update it
rivten has quit [Ping timeout: 248 seconds]
<scientes>
I wanted a FMA, so i'll do more work on getting all the llvm intrinsics added
<TheLemonMan>
iirc LLVM will generate FMAs by itself if you enable -ffast-math or however the flag is called
rivten has joined #zig
<scientes>
TheLemonMan, sometimes FMA is correct however
<scientes>
not just faster
<scientes>
thats why it was added to the instruction set
<scientes>
it does a single rounding instead of two
<TheLemonMan>
yeah, but reordering the fp instructions is a big no-no if you care about accuracy
<scientes>
i could them update some of our std/math.zig too
<scientes>
cause we take from musl and musl took from some arm (non-arm specific) stuff after it was brought into glibc
<scientes>
so we are using the old code
<scientes>
What does llvm do when you don't have a fma instruction if you use that intrinsic?
<scientes>
do we need to add feature flags to zig?
<TheLemonMan>
possibly call an intrinsic, that's what it usually does when the lowering pass chickens out
<scientes>
but i don't think compiler-rt has a soft-float library
<scientes>
and that is the only way to do it with the same accuracy
<scientes>
so it would probably have to bail
reductum has joined #zig
<TheLemonMan>
right, X86ISelLowering.cpp seems to suggest that the expression is just rewritten as a + b * c
<scientes>
ouch
<scientes>
well, for 64-bit IEEE you might be similar accuracy if it used 80-bit IEEEE, but it still wouldn't be the same
<scientes>
thats nasty, cause like i've seen library use differn't tables when fma is available or not
<andrewrk>
I think it's going to be up to the Zig project to propose an extension specification to compiler-rt to enable more LLVM stuff to work, and then potentially even contribute the code to LLVM to take advantage of it
<scientes>
that should be a -ffast-math only thing
<andrewrk>
I would love for someone other than me to drive this
<TheLemonMan>
meh, that's too much work for little or no return IMO
<andrewrk>
TheLemonMan, I think your std/os/linux/tls.zig file is a good example of system level code that is a lot cleaner in zig than C
<andrewrk>
a lot of little things add up. being able to have that CustomData thing to show how future code can be modified, actually helps readability. good stuff
<andrewrk>
I'm ready to merge it unless you wanted to do any modifications to the branch
<TheLemonMan>
I was sooo happy not to have a thousand #ifdef and #define heh
<TheLemonMan>
I only wanted to ask you a small question about the Thread type
<andrewrk>
sure what's the question
<TheLemonMan>
right now we're packing everything in a struct that's passed around
<andrewrk>
right now -> master branch?
<TheLemonMan>
but we may also go the pthread route, stash all we need to know about the thread in the CustomData and return the user a pointer to it
<TheLemonMan>
yeah
<TheLemonMan>
this way we can also "introspect" the current running thread since the CustomData structure is relative to the tp register
<andrewrk>
it's more fresh in your mind than mine right now; which way do you prefer?
<andrewrk>
ahh I see
<andrewrk>
that seems beneficial
<TheLemonMan>
scientes, I remember reading you were getting a ppc64 machine, is that right?
<scientes>
nah, i'm just using a VPS
<scientes>
but yeah i'm using it right now
<andrewrk>
one could argue that matching the pthread ABI for threads would also make tools "just work". So if there weren't any downsides, that might be worth doing
<TheLemonMan>
ppc64 is one of the few arches using a slight variation of the TLS variant I, it'd be interesting to port Zig to it heh
<TheLemonMan>
andrewrk, I'll experiment a bit in a separate branch and report back