<tgschultz>
man, errorsets are so broken. It's hard to make any significant changes to the interface pattern because of it.
<tgschultz>
can't be inferred if they're empty. can't be inferred sometimes for no apparent reason. Sometimes they just assert the compiler.
<tgschultz>
to be fair, some of these are just comptime related type checking errors. Like they way it likes to assert when it encounters an undefined symbol
ijneb has joined #zig
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 268 seconds]
MajorLag is now known as tgschultz
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 244 seconds]
MajorLag is now known as tgschultz
<tgschultz>
great, integration tests won't even give me traces with a debug build.
redj has quit [Ping timeout: 255 seconds]
redj has joined #zig
<tgschultz>
narrowed the problem down to combining error sets in a return type. Which is great, since I can't refer them.
<tgschultz>
*infer
<tgschultz>
I think I'm just going to have to take a break from working on zig before I start hating it.
<andrewrk>
tgschultz, I think the problem is you're trying to improve zig while avoiding bug fixing. it's not really possible at this stage of maturity
<andrewrk>
I wouldn't be able to do any significant features/improvement without fixing bugs along the way either
<andrewrk>
I mean I don't blame you
<andrewrk>
but that's why it's not working
<andrewrk>
bugs also meaning design flaws such as the empty error sets situation that you identified
<tgschultz>
I'd fix the bugs if I could. I just don't have the familiarity with how compilers are structured so I can't really follow what's going in.
<tgschultz>
yeah, I know, it's nobody's fault really, zig is still early days, it's just frustrating.
<andrewrk>
yeah, big time
<andrewrk>
even I'm frustrated that I can't progress as fast as I want to
<andrewrk>
I wish I could hire somebody
<scientes>
I'm having the same problems with coding LLVM, but its that I can write the feature far faster than I can write it in a maintainable way
<scientes>
and a reviewable way
kristoff_it has joined #zig
<tgschultz>
ok this is strange. stage1.zig in `stage2_render_ast` it appears to have switch prongs that I can't tell where they're coming from. It should only be possible for the errorset of COutStream or Allocator to be produced from its call to render(). I don't think it is a coincidence that this is where the assertion failure happens
kristoff_it has quit [Ping timeout: 246 seconds]
<tgschultz>
ah, ok. It's my fault for making a bad assumption about the error set of COutStream.
<tgschultz>
I'm ok with this. I can accept problems that are my fault as long as they make sense.
adsr has joined #zig
_whitelogger has joined #zig
scientes has quit [Ping timeout: 245 seconds]
<tgschultz>
well I'm feeling a lot better now that I'm making progress again. that'll probably change when I have to deal with async allocators again, but I've got a good feeling about plan C for tackling them. worst case I'll just not rewrite Allocator until after coroutines are redone.
_whitelogger has joined #zig
_whitelogger has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
redj has quit [Ping timeout: 268 seconds]
redj has joined #zig
coolreader18 has joined #zig
qazo has joined #zig
kristoff_it has joined #zig
jjido has joined #zig
kristoff_it has quit [Ping timeout: 255 seconds]
qazo has quit [Ping timeout: 268 seconds]
qazo has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
Aransentin has joined #zig
mikdusan has quit [Read error: Connection reset by peer]
Aransentin has quit [Ping timeout: 256 seconds]
Sahnvour has joined #zig
qazo has quit [Ping timeout: 245 seconds]
qazo has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mikdusan has joined #zig
qazo has quit [Read error: Connection reset by peer]
scientes has joined #zig
kristoff_it has joined #zig
wootehfoot has joined #zig
wilsonk has joined #zig
kristoff_it has quit [Remote host closed the connection]
Sahnvour has quit [Quit: Leaving]
Aransentin has joined #zig
wootehfoot has quit [Quit: Leaving]
wootehfoot has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 252 seconds]
<Aransentin>
I have questions ( or perhaps complaints :) ) about epoll in Zig's standard library. I wanted to make an event loop with it on Linux for my program, so I used std.os.linuxEpollCreate and friends:
<Aransentin>
1. Why are they located in std.os and named linuxFOO? Seems odd to me when there's os.linux.
<Aransentin>
2. linuxEpollWait catches EINTR and restarts the loop with the same timeout, which was kinda unexpected. If SIGINT is raised I wanted it to quit so I can quickly cleanup my resources, not have to wait twice as long (worst case) for the timeout to expire.
<Aransentin>
3. linuxEpollWait calls posix.epoll_wait and handles a few errors, but I'd like to use seccomp which can (in theory, though I only want EPERM) return any error.
<Aransentin>
4. posix.epoll_wait then actually calls linux.epoll_pwait! If I can't guarantee that only the syscalls I want are emitted I can't make reliable seccomp filters, and this makes me sad :(
<Aransentin>
Basically the ideal thing for me would be to have a fairly thin Zig wrapper around all the kernel syscalls that converts any returned errors to Zig errors. Is something like that planned?
<BitPuffin>
mikdusan: yes, is that [0..] necessary?
<BitPuffin>
Either way
<BitPuffin>
can just wrap this into a function and it should be handy
<mikdusan>
yes because []Foo{ foo } is an array of size 1 -> [1]Foo; and to convert that to slice the syntax is array[0..] or array[0..array.len-1] equiv. or your range choice.
<mikdusan>
iirc there was talk of making []Foo{ foo} syntax change to avoid confusion. it's really just a convenience and this is equiv [1]Foo{ foo }; but by inferring array size it's a bit confusing looks like slice
<BitPuffin>
hmm I thought zig did implicit cast where it was safe and unambiguous
<BitPuffin>
also doesn't foo get copied into the array in your version maybe
<mikdusan>
BitPuffin: i think you're right. i'm an idiot.
<BitPuffin>
But yeah I wonder why zeroes was removed
kristoff_it has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<BitPuffin>
mikdusan: maybe I should make a proc that takes a type and does zero init and returns the struct
<Aransentin>
Question about build.zig: I'm running a (slow) external tool to preprocess a couple of files. Can you get a addSystemCommand step to only run when some specific file(s) have changed?
SamTebbs33 has joined #zig
kristoff_it has quit [Ping timeout: 252 seconds]
jjido has joined #zig
<scientes>
Aransentin, I don't use builder, but that sounds like a feature that ninja has
<scientes>
I never understood why Zig has to have to much NIH
<scientes>
*so
<Aransentin>
Yeah, nautrally I could use a makefile or something
<scientes>
Make is really bad
<scientes>
but IMHO builder should really use ninja
<Aransentin>
Eh, make works well enough. I know how to use it fairly well too, which is a big plus :)
<scientes>
but i guess builder has higher aspirations
<scientes>
Zig is structured a little differn't where the whole source is compiled at once
<scientes>
so it kind of has to do its own build system, and it will need alot of work in LLVM to do multi-threaded compiles
<scientes>
like C has header files to reduce memory usage, but computers don't really need that any more
<scientes>
zig's approach makes sense, but it means alot has to be redone
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<scientes>
perhaps it could still use ninja to build c stuff.
<Aransentin>
Ah, okay. I'm fairly ignorant how builder works under the hood, mostly mashing together examples I found on github right now
<scientes>
Like I think zig could benifit a bunch if glibc's libm was make usable without glibc
wootehfoot has quit [Quit: Leaving]
<scientes>
I've never used it, I can just use build-exe
wootehfoot has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
jjido_ has joined #zig
<BitPuffin>
scientes: once you make a programming language you've already swallowed the NIH pill :)
<Aransentin>
Another question: Can you force-import a file that has some test/export that you want to run, but you don't want to do anything with directly?
<Aransentin>
(since the files are lazy-loaded means the "export" function in it will never be parsed)
<Aransentin>
I guess I can put and call some noop() function in it that'll get optimized away in the end, but there has to be a nicer way of solving it
<andrewrk>
if you want to unconditionally import, replace `test "std"` with `comptime`
<Aransentin>
Yep, that worked brilliantly
<Aransentin>
Thanks!
<andrewrk>
Aransentin, as for your question about epoll earlier - I have an in progress very breaking (sorry!) change to address that which is so far 29 files changed, 3510 insertions(+), 3224 deletions. See https://github.com/ziglang/zig/issues/2380 for more details
<scientes>
yeah I did some of that too, but it wasn't ready for release
<scientes>
but I felt it should use @typeMember() so that the all the syscalls still work
<andrewrk>
scientes, yes I'm solving that problem as well
<andrewrk>
scientes, I recognize it's not really fair - if you had submitted exactly these changes as a PR, it would have been very difficult to review & merge
<scientes>
yes I realized that as well
<scientes>
I also wanted to fix getError's excessiveness, in most syscalls (but not mmap()) you can just do < 0
<scientes>
or rather a direct switch()
<andrewrk>
I'm fixing that too
<scientes>
cause success always returns 0
<andrewrk>
here I'll push my wip branch
<scientes>
and then I do want to do mapping of zig errors to errno, but that is tricky to do cleanly
<andrewrk>
that's a whole separate proposal which may or may not work
TheLemonMan has joined #zig
<BitPuffin>
andrewrk: how come zeroes was removed?
<andrewrk>
`system` is mapped to `c` when linking libc
<scientes>
andrewrk, that write() bug actually isn't like that, I looked at the source code
<scientes>
i will accept any value, but only write/read that much
<andrewrk>
BitPuffin, zero initialization makes the not-always-correct assumption that the bit pattern of all 0's is a useful and valid state
<scientes>
so there is nothing to fix
<scientes>
if it did exist, it was only like <2.6.32
<andrewrk>
scientes, that's good to know, thanks
<BitPuffin>
andrewrk: well it's very useful to code that assumes zero is initialization. Partially because it's very cheap to init to zero
<andrewrk>
BitPuffin, for example if you had any pointers in your struct, and you initialized it to zeroes, your pointers which are never supposed to be null are now null
<BitPuffin>
Yeah it doesn't work for pointers
<andrewrk>
init to undefined is even cheaper
<andrewrk>
plus, if you init to undefined, zig can provide safety protection
<BitPuffin>
Yeah but you can't write code that assumes undefined is properly initialized
<andrewrk>
well yeah that's entirely the point
<scientes>
it will never be slower to explicitely initialize
<BitPuffin>
However I can write programs where most objects can be valid when initialized to zero
<scientes>
because if hardware shows up that initializes it for you (and there are proposals as such) the compiler will optimize out the initializations
<BitPuffin>
Either way. It's a surmountable thing
<TheLemonMan>
andrewrk, you probably want to pull the trigger on #2493 too
<scientes>
well, actually I don't think the compiler knows that mmap() returns zero-initialized data.....
<BitPuffin>
Can just make a function that inits a struct to zero from a comptime type argument
<andrewrk>
TheLemonMan, yeah, sorry I wanted to try to finish up my PR and then do around of reviews
<andrewrk>
if it's blocking you I can take a look
<andrewrk>
TheLemonMan, oh neat did you use ir_print_instruction in the debugger?
<TheLemonMan>
yup
<andrewrk>
to make you aware, ConstPtrMutRuntimeVar & friends are a flawed way to represent comptime mutability. I believe the "root cause" fix is going to be representing this information with scopes: https://github.com/ziglang/zig/issues/1487
<andrewrk>
this fix is good though, thanks! trigger pulled
<BitPuffin>
andrewrk: can even compile time refuse to init to zero if the type contains non nullable pointers I think :)
<TheLemonMan>
comptime pointers are a hassle in pretty much every language I've worked on heh
<andrewrk>
TheLemonMan, do you have a project you're working on in zig or are you contributing to the compiler for its own sake?
<TheLemonMan>
I like to work on compilers, for me it's a way to relieve some stress while doing something productive heh
<andrewrk>
well your contributions have been very valuable so thanks
<andrewrk>
BitPuffin, in summary: zig has scopes for variables, which is compile-time enforcement of only using a value when it is well-defined and intended to be used. however this is coarse grained - sometimes it's only known at runtime whether a value is well-defined or not
<andrewrk>
for this case we have the concept of `undefined`. you can assign `undefined` to a value and then zig's runtime safety mechanisms can help prevent accidental use
<andrewrk>
there are some such safety mechanisms in place already - writing 0xaa, valgrind-aware annotations - but more are planned
<scientes>
its also using llvm's UndefValue if it gets that far, on --release-fast mode
<andrewrk>
`zeroes` is in conflict with these safety protections. it comes down to one of the "zen" statements: Communicate intent precisely.
<andrewrk>
this precision gives both safety/debuggability in the safe build modes and performance in the unsafe build modes
<tgschultz>
speaking of unusable files, re: DOS and freestanding generating elfs, objcopy can convert to a format I can almost use, but it doesn't seem to translate the relocation table (either that or the PE capable DMPI loader I'm usuing doesn't pay any attention to them). That's ok, I don't need relocation, but I don't know how to tell the compiler to output everything without relocation and assuming a base address.
<tgschultz>
--disable-pic didn't seem to work
<andrewrk>
tgschultz, what are you looking at to determine that it is in fact generating PIC?
<andrewrk>
can I see the linker line that it ends up using?
<tgschultz>
the disassembly of the result. the addresses it references are not valid. I don't usually work at this level so I may be doing one or several things wrong.
<andrewrk>
are you looking at the output of build-obj or build-exe?
<scientes>
look at objdump --all tgschultz
<andrewrk>
looks like you're using build-obj which is going to produce a relocatable object. I don't think it's possible to create a non-relocatable object. try using build-exe
<tgschultz>
andrewrk: build-exe, though the .o file doesn't seem any different. scientes: objdump just says file format elf32-i386
<andrewrk>
ah my mistake
<scientes>
--all
<scientes>
that gives you a high-level overview of the contents of an elf
<tgschultz>
scientes that was with all, there's only one file, which is a very short bit of assembly to call DPMI and switch to protected mode... In fact, the zig file I'm using is completely empty so I'm only engaging the assembler.
<tgschultz>
I suspect there's something relatively obvious I'm missing about all this
<andrewrk>
that could easily be true but I don't see it either
<scientes>
then you could try --disassemble
<andrewrk>
my approach would be to try to come up with an example that does work, and try to see what's different about it
<scientes>
--disassemble --all
<andrewrk>
e.g. with msvc or whatever other people do to make these dos exes
<tgschultz>
well for starters they don't output ELFs.
<tgschultz>
but yeah, I'm still looking in to how this is supposed to work. Once I get get into protected mode and verify I can talk to the DPMI host, then thigns should go more smoothly (I hope).
<andrewrk>
they output COFFs?
<andrewrk>
I think we can do that
<tgschultz>
I'm not sure what the object format would be, but the end result is a DOS MZ (not PE) exe I think. I've found surprisingly little documentation about 32bit dos programs.
<tgschultz>
But I do think starting with COFF output instead of ELF would probably be smoother.
<scientes>
tgschultz, what are you trying to do?
<tgschultz>
scientes: my bad, I used -all instead of --all, I am indeed getting a more informative dump.
<tgschultz>
scientes: a side project, exploring the ability to build 32bit DOS programs with zig. Possibly even stdlib support. Personally I'd just like to make a DOS game with it, mode 13h and all that.
TheLemonMan has quit [Ping timeout: 258 seconds]
<scientes>
cause DOS can't run without an emulator on 64-bit machines
<scientes>
its kinda dead
<tgschultz>
I'm aware of that.
<tgschultz>
I'm using a debuger enabled build of DOSBox for now
<tgschultz>
I'll switch to a serious emulator later on
<tgschultz>
like qemu
<scientes>
do those work with games?
<scientes>
I thought DOS games had timing stuff that didn't work with emulators
<tgschultz>
Old DOS games used a lot of tricks, though according to the demoscene, who would know, DOSBox is actually not very good at emulating a lot of the trickier things. I just mean using a more complete emulator to prove to myself that it is likely to work on real hardware, well, without lugging out some hardware I have that actually runs DOS anyway.
<scientes>
but this is new development.....
<scientes>
maybe you should do baremetal ARM
<tgschultz>
That's not intereting to me at this time.
<scientes>
or AVR-8, llvm has some support for that (although gcc's is better
<scientes>
ok, it not my business
<tgschultz>
This is really just for my personal amusement, though if it becomes reasonable to do so, it's possible zig could support DOS-i386 as a target. There's a surprising amount of DOS still running in the world.
shritesh has joined #zig
<scientes>
Zig on baremetal is really exciting for real work...
<scientes>
so anyone hacking on it can push zig forward
<tgschultz>
Eventually I'd like to do that, but there's nothing about that right now that really interests me. If a completely open platform comes along, I may be interested in building a new OS on it, but that seems unlikely in the near future. RISC-V is taking off, apparently, but there's no such thing as an open GPU for instance.
<scientes>
ARM-M is pretty good, there are a bunch of proprietary implementations of it
<scientes>
well actually not the M version, more the high-power versions
<scientes>
there are like 4 differn't high-performance completely independent implementations of ARMv8 instruction set
<scientes>
and Mali open driver just got merged into Linux kernel
<scientes>
or maybe the next one, its in drm tree
<tgschultz>
the driver is open, but Mali isn't.
<tgschultz>
and if I was using the linux kernel then it wouldn't be bare metal anyway.
<scientes>
doing 3d bare meta would be pretty intense
<scientes>
i don't think anyone could pull that off
<jjido_>
...
jjido_ is now known as jjido
<scientes>
anyways, a MMU is nice
shritesh has quit [Quit: segfault]
<andrewrk>
tgschultz, something to try: hack up codegen.cpp init() function. look for LLVMSetTarget. hack that triple_str to be "i686-unknown-none-coff" and see if that changes anything
<BitPuffin>
andrewrk: Yeah that makes sense. Especially with the emphasis on safety. While I do think there is room for a version of zero init that only allows it when it is safe to do so. I don't think it's strictly necessary to have it as an officially supported thing as it appears I can just make a procedure that does exactly what I want.
<scientes>
BitPuffin, you can just wrap an allocator
<scientes>
its quite simple
<scientes>
and if you use arena allocator...oh wait I think we write 0xaa now...
<BitPuffin>
Since I mainly wanna use Zig for games (and surprisingly maybe some web dev for fun) my concern skews a bit towards getting out of my way more than safety at times.
<BitPuffin>
scientes: can't I just instantiate a struct on the stack from a type parameter and return it?
<andrewrk>
"safety" also means "find your bugs quickly so you can iterate faster"
<scientes>
low level stuff really needs to get this right
<BitPuffin>
Yeah and the times when it does I'm really happy about it
<BitPuffin>
Which is part of why I'm excited about zig
<BitPuffin>
Cuz it seems like more than rust it seems to buy time thanks to safety without costing time fighting with the safety mechanisms
<BitPuffin>
andrewrk: true! Except when I'm interacting with C types :)
<scientes>
you can do that with c types
<scientes>
there is no reason it wouldn't work with c types
<andrewrk>
scientes, in auto generated @cImport output you don't have access to the definitions
<scientes>
but you could just redefine it
<scientes>
with an extern
<andrewrk>
the type?
<scientes>
yes
<scientes>
C code does this all the time
<scientes>
not so much in C++, because its so complicated
<BitPuffin>
Yeah but I don't wanna redefine them
<BitPuffin>
That's friction I can live without
SamTebbs33 has quit [Quit: leaving]
SamTebbs33 has joined #zig
<scientes>
BitPuffin, you might be able to do it with @typeInfo so that it is safe
<BitPuffin>
The super handy interop with C is a killer feature for me. One of the main reasons I hopped from nim is because I don't wanna sit there writing bindings or fighting with c2nim
<scientes>
this could be totally automatic
<scientes>
you could just iterate through the namespace and add initializers
<BitPuffin>
scientes: yep exactly my thinking. Basically any plain scalar type can safely init to zero I think
<scientes>
requires fixing a few bugs
<BitPuffin>
Hmm didn't know I could mutate namespace at compile time
<andrewrk>
I'm not aware of that being possible
<tgschultz>
writing a metafunction that iterates through a struct's member and sets everything to a reasonable "zero" value where it makes sense to do so is possible. Look at serializer/deserializer for how it inspects a type all the way down to the primitives, then just set them to 0 instead of writing/reading them from a stream.
<scientes>
oh, i thought you could monkey patch
<scientes>
guess i hadn't tried it
<andrewrk>
if it were possible to monkey patch, I would change things so that it became not possible
<BitPuffin>
Macro hater :p
<andrewrk>
yes
<scientes>
that is a good thing
<BitPuffin>
So other than monkey patch. Can you make new code?
<andrewrk>
BitPuffin, have you read about how formatted printing works?