ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
Ichorio has quit [Ping timeout: 250 seconds]
<MajorLag>
Ah, I see.
andrewlmurray has joined #zig
<MajorLag>
Would what I was thinking even be possible? Having comptime struct fileds that are only exposed at comptime? I imagine no, for the same reason we don't have global comptime vars.
<andrewrk>
I'm not sure I understand what you're describing
<MajorLag>
A field that is a comptime var. As far as runtime is concerned it doesn't exist, it can only be set, read, and modified at compile time, if that makes any sense.
<andrewrk>
I see. Hmm, let me think for a moment
<andrewrk>
I'm having trouble understanding the implications of this concept
<andrewrk>
I suspect that the the problem it would solve could be solved a simpler way
francis36012 has joined #zig
<MajorLag>
I could just pass the comptime value separately. I dunno, I'm probably trying too hard to make the api feel right while solving all use cases.
_whitelogger has joined #zig
wootehfoot has joined #zig
<MajorLag>
it's annoying because casting everything in a runtime version of an interface feels dirty, but so does using `var` everywhere. #1669 would help with the latter I think, but it would mean that you have to write special adapters for runtime-dispatch... which is probably ok since I'm assuming they're an edge case. I think I'm just overthinking it.
<MajorLag>
I may have had too much sugar at the company holiday party.
<andrewrk>
it's a really tough problem. the way I'm approaching it is to solve the other language problems first where we can be sure the solution is the right idea. Then hopefully this leads us down the best path for this particular issue
andrewlmurray has quit [Ping timeout: 268 seconds]
<MajorLag>
I figure I should at least try working on it now because a) its relevant to what I'm planning on doing with serialization (in a new image lib and std zlib implementation if no one beats me to it), and b) the sooner we start trying things and finding out why they're a problem (or not) the more information we'll have when it comes time that we need to have it solved.
<andrewrk>
that sounds reasonable
diltsman has joined #zig
<diltsman>
Is there some pastebin somewhere that I can put some code for a question on?
<diltsman>
andrewrk, some of my issue was having _start be naked. It was using the stack but not reserving space on it. Once I removed nakedcc it is at least not faulting.
<diltsman>
Everything appears to be working right, but it is attempting to load _data_begin, _data_end, _bss_begin, and _bss_end from uninitialized flash, so all are reading as 0xffffffff.
steveno__ has quit [Quit: Leaving]
<diltsman>
andrewrk, at least it isn't faulting now. I still have to figure out the variables, though. Do they get put in a special section?
<andrewrk>
diltsman, the extern variables? I believe that is determined by the linker
<diltsman>
andrewrk, Yeah. The code is trying to load them from addresses that appear to be in the .got section.
IntoxicatedHippo has joined #zig
<diltsman>
andrewrk, in the ELF file, it has the .got section initialized with the correct data, but it is not initialized when it is loaded on the device.
<andrewrk>
hmmm
<andrewrk>
you're just looking at the addresses of them though
<andrewrk>
this won't be necessary after that issue is resolved, but try passing `--static`, or change your build script to addStaticExecutable
<andrewrk>
yeah, try replacing b.addExecutable with b.addStaticExecutable
<andrewrk>
(after the issue is solved you'll have to revert this change because it will be done automatically for freestanding and won't be an option)
<diltsman>
andrewrk, after making that change, it no longer produces a .got section (which is where the linker constants were loaded from) and just produces the constants by loading immediate values. So, this works, but doesn't explain why the .got isn't loaded. I'm going to explore that some more.
<andrewrk>
diltsman, got stands for Global Offset Table which has to do with Position Indepenent Code, which is irrelevant for freestanding targets, according to my understanding
<andrewrk>
it's for dynamic linking
<diltsman>
andrewrk, that makes sense. However, if I dump the .got section into the .text, then everything works, too.
<andrewrk>
diltsman, that makes sense - but you definitely want to make this change because the Position Independent Code is slightly worse than static code
<diltsman>
Ok, I will do that. Thanks!
<andrewrk>
(this will happen automatically in the freestanding target once #1828 is fixed)
<andrewrk>
no problem, glad we got it sorted
<andrewrk>
it's good to know that the 2 problems you had are open issues
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
so presumably it would have "just worked" in zig 1.0.0 :)
<diltsman>
Or maybe even Zig 0.4.0.
<diltsman>
andrewrk, the only other issue (at least with the build of Zig that I am using) is some of the ARM EABI intrinsics, which is also a known issue.
<andrewrk>
if it's just a few of them, I can prioritize those to unblock you
<MajorLag>
hmm, so another issue with comptime-dispatch interface: if you want to store it in a struct (`ArrayList(T)` for example) you have to pass the interface type too, and then any other structure that wants to use an arraylist has to do that too. That seems like a pretty significant downside of that method.
_whitelogger has joined #zig
<reductum>
I'm getting "unable to evaluate constant expression"
<reductum>
Ah. Because calling math.log2() ruins the const-ness
emekoi has quit [Ping timeout: 246 seconds]
<andrewrk>
reductum, I suggest: const ShiftInt = math.Log2Type(T); const result = a << @intCast(ShiftInt, b);
<andrewrk>
or maybe you can make `b` actually be a smaller int size so the cast isn't necessary
<reductum>
Ah. Because calling math.log2() ruins the const-ness
<zachcarter>
I'm probably doing something wrong / stupid, but I'm not sure why I'm getting the error message I am. I've included the error message in the gist.
<reductum>
andrewrk: Thanks for your help. This is currently working: @shlExact(@intCast(T, 1), @intCast(math.Log2Int(T), i));
<andrewrk>
reductum, I suggest `T(1)` instead of `@intCast(T, 1)`
<andrewrk>
you can implicitly cast comptime-known integers to any integer type
<zachcarter>
nevermind - I understand why that code is failing.
<zachcarter>
well - I got around that error, but ran into some more - `no member named 'SOCK_CLOEXEC' in '/usr/local/lib/zig/std/os/darwin.zig'`
<zachcarter>
wondering if threads are supported yet on darwin, or if I'm just doing something fundamentally wrong
<IntoxicatedHippo>
Is there a way to loop over an enum?
<zachcarter>
okay - I just ran another program that uses threads and it worked fine, so something is up with mine.
<reductum>
andrewrk: Indeed T(1) works as expected.
<reductum>
I currently have a few asserts at the beginning of this function enforcing requirements about `T`, that it's an unsigned int, that it has a minimum number of bits, etc.
<reductum>
I'm looking for a way to replace those asserts with compile-time errors.
<reductum>
Ohh I just realized comptime is documented now. For some reason I had thought it wasn't. Maybe I was mixing that up with allocators.
<zachcarter>
not my threading code that's failing - it's some code that's relying on std.event.net
<reductum>
Comptime is so cool
<zachcarter>
I see now the error message in the test I was pulling code from :P
reductum has quit [Quit: WeeChat 2.3]
_whitelogger has joined #zig
Ichorio has joined #zig
<sjums>
boiled down my 80 lines of crashing code to what can fit in a tweet (the oldschool 140 char tweet that is).
<sjums>
The zig compiler stands no chance against me!!
<Hejsil>
Basically, the default ArrayList will use a dynamic dispatch Allocator (because this is the simplest to work with)
<Hejsil>
And then there is different degrees of freedom depending on what you need
<Hejsil>
You can have an ArrayList that doesn't store it's allocator (useful for when multiple ArrayList can share an allocator and you wonna save space)
<Hejsil>
Or you can have an ArrayList where you have a custom allocator, no dynamic dispatch
<Hejsil>
I think this is the same thing andrewrk wanted to change about the BigInt implementation
Zaab1t has joined #zig
<MajorLag>
In the case where not storing the allocator you could keep it in a struct var and wrap the same interface functions over that struct.
<MajorLag>
One thing I'd like to avoid is having to implement everything twice, once for runtime and once for comptime dispatch. This would get particularly annoying on any struct that wants to hold a handle to an allocator. Maybe that shouldn't be the pattern, but for a mere @sizeOf(usize) bytes it does prevent accidentally using the wrong allocator.
<MajorLag>
I'm still hopeful that if I stare at the problem long enough a more elegant solution will reveal itself.
<Hejsil>
Lol
<Hejsil>
Idk, the solution i present does not have two implementations for a ArrayList (one for static and one for dynamic dispatch)
<Hejsil>
The only annoying thing is, that the ArrayList with an allocator have to wrap the non allocator ArrayList and expose the same functions
<MajorLag>
I'm not sure you don't need two separate allocator interfaces (convenience function collection) in your example. One that erases type and one that doesn't.
<Hejsil>
Well, the dyn dispatch allocator implements the same small interface that the static ones do
<Hejsil>
Basically allocators only have alloc, realloc, free (all only working on []u8). Then I implement the helper functions as free functions (mem.alloc(allocator: var, comptime T: type, num: usize), mem.create(allocator: var, init: var), mem.realloc(allocator: var, comptime T: type, old: var, new_size: usize)
<MajorLag>
In a way, mem has become the interface. `allocator` may as well be @OpaqueType to the callee, it's just a handle. There's definitely an advantage to that conception of an interface, but it means the callee applies the interface to some handle instead of being passed an interface. I don't think there are any real limitations to that, but I'd have to think on it.
<Hejsil>
Alright go for it
<MajorLag>
Also, not that I can think of abetter way to do it yet but your vtable implementation freaks me out a little. reminds me too much of my typeclass experiment.
<MajorLag>
All that checking of function types for compatibility.
<Hejsil>
MajorLag, yea it is a little much. I'm basically doing the type systems work
<Hejsil>
If i could easily generate wrappers that casts the "self" ptr to the concrete type, then that might be better
<MajorLag>
I think there might be a way to make the type system do the work and then erase, which should give us the saftey we want. Working out how to do that was where I left off last night.
<Hejsil>
That could be nice
<MajorLag>
It would also be nice, re #1669, if there were an easy way to generate a traitFn for checking an interface from its definition.
<MajorLag>
Possibly traitFns for interfaces could just do nothing and act soleley as documentation in the function signature too.
<IntoxicatedHippo>
Has there been any discussion about adding an architecture specific byte type rather than using u8 everywhere so Zig can target architectures with non-8-bit bytes?
<MajorLag>
Even if an architecture has a different byte size `u8` is explicit about what the programmer actually wants so in theory it will still work, it'll just waste some bits somewhere. I don't think LLVM supports or has any plans to support an architecture that defines a byte as something other than 8 bits anyway. I think there was an issue regarding adding a `c_char` type: https://github.com/ziglang/zig/issues/875
IntoxicatedHippo has quit [Ping timeout: 240 seconds]
<zachcarter>
I'm trying to work with this in zig - and I'm failing miserably
<zachcarter>
the error I'm running into, is when I'm comparing the `type` field on the union, with one of the enum values - `if (ev.type == sfml.sfEvtClosed)`
<zachcarter>
`integer value 0 cannot be implicitly casted to type 'sfEventType'`
<zachcarter>
I tried doing `if (@enumToInt(ev.type) == sfml.sfEvtClosed)` - however that causes my application to crash
<zachcarter>
that actually had nothing to do with my crash
MajorLag has quit [Ping timeout: 250 seconds]
MajorLag has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
emekoi has joined #zig
<emekoi>
is there a way to return a slice to an array without allocating the memory for the slice or the array?
<j`ey>
where would the array live in memory?
Zaab1t has quit [Quit: bye bye friends]
reductum has joined #zig
<emekoi>
you make a good point.
<emekoi>
i'll just pass an array and the actual length instead.
_whitelogger has joined #zig
<emekoi>
can anyone tell me why my program crashes with "access of inactive union field" when i switch over the union fields?