<daurnimator>
andrewrk: not sure why this doesn't work (isn't this how `comptime var` works?) ... https://godbolt.org/z/cUZPZ5 but if this sort of thing worked; would @typeOf throw an error?
<andrewrk>
daurnimator, global vars can't be comptime. global side effects are not allowed in comptime code
<andrewrk>
top level decls have order-independent analysis
protty has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
marijnfs has quit [Ping timeout: 245 seconds]
marijnfs has joined #zig
ky0ko has quit [Remote host closed the connection]
<daurnimator>
andrewrk: what about @export?
<andrewrk>
that's ok because it can not be observed by other comptime code, and multiple colliding @export will be an error
<andrewrk>
but a global comptime var could have different behavior depending on top level declaration evaluation order
<daurnimator>
andrewrk: however it does mean that you could make it an error to `@typeOf(MyFunc())`
<daurnimator>
andrewrk: potential solution is to turn off @export and any other global side effect having built-ins in @typeOf?
frmdstryr has quit [Ping timeout: 265 seconds]
<daurnimator>
looking through the list.... I think @export is the only one?
Ichorio_ has joined #zig
Jezza__ has quit [Ping timeout: 246 seconds]
muffindrake has quit [Ping timeout: 246 seconds]
muffindrake has joined #zig
<fengb>
Is github syntax highlighting broken? I'm seeing everything in red or orange
<daurnimator>
andrewrk: when to use os/windows/bits vs os/bits/windows ?
<andrewrk>
fengb, emekoi is the maintainer of https://github.com/ziglang/sublime-zig-language. I believe that issue is fixed but github linguist has not rolled out a new version in some months
<fengb>
Ah okay
<andrewrk>
daurnimator, os/bits/windows is the posix layer. os/windows/bits is the windows layer
lattis_ has joined #zig
<daurnimator>
andrewrk: what do you mean "posix layer" and "windows layer"?
<daurnimator>
e.g. sockaddr is currently in os/bits/windows... but it is part of the kernel driver ABI
<daurnimator>
the layers for win32 application on winnt are: kernel drivers (many drivers! and are on a sliding scale from ubiquious to single deployments) -> core kernel pieces -> ntdll -> kernel32 -> userspace "helper" system dlls.
<daurnimator>
note that there are 4 different "posix layers" for windows.... the old subsystem, the win32 bare minimums, mingw on top of win32, and WSL
<daurnimator>
*most* of them share *most* of the ABI; but not all of it...
<daurnimator>
(I'm asking because for a little bit today I have access to a windows machine; and am working on porting my AFD code)
<andrewrk>
daurnimator, os/bits/windows is stuff that is compatible with POSIX
<andrewrk>
sockaddr_un is a good example
chemist69 has quit [Ping timeout: 250 seconds]
chemist69 has joined #zig
<daurnimator>
andrewrk: 'compatible'?
<daurnimator>
e.g. os/bits/linux/* is full of architecture specific constants....
<daurnimator>
many of which are not posix constants, but linux-specific ones
<andrewrk>
yes but they are still part of the same "layer"
<andrewrk>
e.g. O_LARGEFILE and SO_NOSIGPIPE
<lattis_>
Hello. I'm really excited about zig but I'm having trouble building it on my i686 Gentoo machine. error: http://sprunge.us/CWt9PC. I'm hoping its due to the fact that I have built llvm without support for all targets (and modified Findllvm.cmake), but I just wanted to confirm before rebuilding llvm, since it takes a really long time (overnight).
<daurnimator>
std.mem.asBytes doesn't seem to return a slice as it says in the docs...
lattis_ has quit [Quit: WeeChat 2.5]
pixlark has joined #zig
pixlark has quit [Ping timeout: 268 seconds]
FireFox317 has joined #zig
FireFox317 has quit [Remote host closed the connection]
return0e_ has joined #zig
samtebbs has joined #zig
lunamn_ has quit [Quit: leaving]
return0__ has joined #zig
return0__ has quit [Remote host closed the connection]
return0e_ has quit [Ping timeout: 240 seconds]
slice has quit [Ping timeout: 250 seconds]
slice has joined #zig
return0e_ has joined #zig
samtebbs has quit [Ping timeout: 245 seconds]
bjorob has joined #zig
bjorob has quit [Ping timeout: 276 seconds]
<mq32>
heyhoh
<mq32>
is there a solution for the following error:
<mq32>
cimport.zig:686:5: error: enum tag value 1 already taken
<mq32>
the header i'm importing has enum fields with aliases
<mq32>
workaround would be: copy cimport.zig to custom file and modify it by hand
husho has joined #zig
<gonz_>
The latter is what I've done in this situation
<mq32>
yeah, i'm doing that now
<mq32>
but with a full "by-hand" conversion
<mq32>
because if i have to touch this, why not make it right in the first place
<Sahnvour>
andrewrk: that would be cool. I'm making a document with the various things that are bothersome on this topic and getting a better understanding of the topic in the process
husho has quit [Remote host closed the connection]
<leeward>
I was looking at adding docs to math.zig, and it would take an awful lot of duplication, which is not how things should be.
keithdc has joined #zig
doublex has quit [Ping timeout: 250 seconds]
doublex has joined #zig
<Pistahh>
in zig do arrays need to have their sizes known at compile time? / What data structure to use if I want to allocate space for n pieces of "things"?
<mq32>
Pistahh, arrays are "values" with multiple elements inside
<mq32>
so yes, their size is comptime known
<mq32>
there are slices that allow dynamicly sized ranges
<mq32>
[]u8, <<= slice of mutable u8
<mq32>
[2]u8, <<= array of 2 u8
<Pistahh>
ok but what to use if I know the size I need only during runtime?
<mq32>
var slice : []MyItem = allocator.alloc(MyItem, 10);
<mikdusan1>
also see std.ArrayList
mikdusan1 is now known as mikdusan
adamkowalski has quit [Client Quit]
<Pistahh>
mq32: thx
<Pistahh>
mikdusan: ArrayList is what I was looking for, thx
return0e_ has quit []
<mikdusan>
tip: a.toSlice() and a.toSliceConst() are super convenient
doublex has quit [Ping timeout: 268 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Client Quit]
adamkowalski has joined #zig
doublex has joined #zig
porky11 has joined #zig
clktmr has joined #zig
doublex has quit [Ping timeout: 250 seconds]
clktmr has quit [Ping timeout: 240 seconds]
clktmr has joined #zig
wootehfoot has joined #zig
doublex has joined #zig
adamkowalski has quit [Quit: Lost terminal]
vexu has quit [Quit: WeeChat 2.6]
<Pistahh>
how to print a number right aligned to n chars where n is a variable?
doublex has quit [Ping timeout: 250 seconds]
jjido has joined #zig
doublex has joined #zig
lunamn has joined #zig
porky11 has quit [Quit: Leaving]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mq32>
Pistahh, i don't think there's a function for that yet
<mq32>
the format API is limited to "one value per formatter"
<mq32>
do you need arbitrary sized formats or only a limited range?
jjido has joined #zig
<andrewrk>
I think anon struct literals / anon list literals are really going to open up some nice fmt api
<mq32>
yeah true
jjido has quit [Client Quit]
<andrewrk>
for example there could be fmt.Pad{.before = runtime_value1, .after = runtime_value2, value = runtime_value3} (with defaults for the pad fields)
mahmudov has joined #zig
clktmr has quit [Ping timeout: 265 seconds]
<andrewrk>
FireFox317, did you figure out how to make drawing to the framebuffer faster?
<andrewrk>
I got it working on real hardware using markfirmware's repo but it's real slow to clear and redraw
<andrewrk>
so if I put the buffer offscreen, then tried to "swap" that would mean iterating over each pixel and storing it to fb.words right? that would actually be doing more work
<mq32>
is this address "wild" or hardware defined?
<andrewrk>
I believe the hardware gives the address on line 117
<andrewrk>
back in a bit, lunch break
jjido has joined #zig
<mq32>
huh
<shakesoda>
i wonder how difficult it is to program the videocore to do these kinds of operations instead of doing it on dumb buffers on cpu
<mq32>
i thought you could change the framebuffer pointer
<andrewrk>
"mailbox Set virtual offset Tag: 0x00048009." -> there it is
<shakesoda>
mq32: wow, excellent
<mq32>
if you can change that, you can probably allow faster memory access
<mq32>
also i noticed that having volatile on "framebuffer memory" is bad
<mq32>
you should treat that as normal memory, as it's not MMIO per se (not every write *must* be done)
<mq32>
only the last write should have it's effect "applied"
<andrewrk>
hmm, I see
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jaredmm>
I think I saw it mentioned by someone (maybe FireFox317), but is there a repo where people were working on a language server?
<mq32>
andrewrk: also one general tip: try not to do stuff "nice", but efficient
<mq32>
don't multiply, use accumulation with another variable
<pixelherodev>
mq32, wait really?
<pixelherodev>
(fbram volatile)
<mq32>
yes
<mq32>
pixelherodev: i now have the smoothest 60 FPS + vsync you can imagine
<mq32>
framebuffer is "standard memory"
<pixelherodev>
Not on x86 it isn't.
<pixelherodev>
It's MMIO to the GPU in VGA emulation mode IIRC
<shakesoda>
not on rpi :)
<mq32>
doesn't matter, pixelherodev
<mq32>
you don't need every write you make to the memory in the same order
<mq32>
as you write it in code
<pixelherodev>
shakesoda, rpi != x86
<shakesoda>
exactly
<pixelherodev>
I'm asking why that comment is helpful...
<andrewrk>
hm, the video core chip has opengl built into it? that's a surprisingly high level API
<pixelherodev>
mq32, ah right, that makes sense
<mq32>
you only need to make sure your writes actually happen eventually before switching bit planes
<shakesoda>
are we not talking about doing things on a pi
<mq32>
andrewrk: that's not quite right as an "API", but you have the same level of functionality
<pixelherodev>
I literally said "on x86" :P
<pixelherodev>
Multiple separate discussions can occur in tandem ;)
<shakesoda>
ok
<andrewrk>
mq32, are you testing on real hardware?
<mq32>
yes
<mq32>
the stuff i've sent a video some days ago runs also on real hardware
<mq32>
and: i would call that even a "first try" on real hardware! *proud*
<andrewrk>
mq32, really impressive!
<mq32>
yeah i just have to find motivation to continue coding :D
<andrewrk>
interesting this videocore chip even supports shaders, if I can figure out how to use them + using memory on the gpu, I should be able to draw real fast
<mq32>
i had a bad day today. running from one annoyance into the other
<andrewrk>
damn
<shakesoda>
yeah everything is shaders on em
<mq32>
yeah, so i stopped coding and started watching youtube :D
<andrewrk>
mq32, thanks for helping me today though!
<shakesoda>
btw i see you use some serial uploading stuff, have you also tried usb booting it entirely with rpiboot
<shakesoda>
* for clashos etc
<mq32>
andrewrk: you're welcome
<mq32>
i'm going to bed now
<andrewrk>
mq32, maybe I could run your thing as a demo? it's a lot more exciting than my shitty slow redrawing logo
<keithdc>
It seems like comptime struct fields aren't allowed, unless I made a silly mistake
bjorob has joined #zig
<andrewrk>
keithdc, there's a proposal #3677 for comptime struct fields, but it wouldn't be compatible with your pseudocode. The proposal requires specifying the comptime value as the default field initialization value and that's the only value it could ever be
<FireFox317>
andrewrk: did you figure it out to make it faster? Because I know that markfirmware's own repo draw much faster on actual hardware even for a debug build
<keithdc>
andrewrk: I see, thanks
<FireFox317>
jaredmm: Someone was working on that yes, but I also don't remember who
<FireFox317>
shakesoda: I got a version where the serial bootloader is working and its only Zig code, which is pretty nice