<mikdusan>
and remember zig is lazy. so you'll only see stuff that is needed. consider line 6. if it's not used, .json will not contain it.
<ceymard>
I can see that
Ichorio has joined #zig
<ceymard>
this is a nice step
<ceymard>
I think that to provide something really helpful, we'd need to add symbol location in the output
<mikdusan>
it is there
<ceymard>
I mean line/col or offset in the file ?
<mikdusan>
look for elephant and you'll see line/col
<ceymard>
I can't see it
<ceymard>
oh right
<ceymard>
the only thing we need now is for zig to be forgiving :)
<ceymard>
can't ask the symbols when I'm in the midst of typing a malformed expression
<ceymard>
also, could it be possible to call the analysis without building anything ?
<ceymard>
and have it output on stdout ?
<daurnimator>
andrewrk: I don't think your json writer handles unicode correctly.... and I'm not even sure it can
<daurnimator>
e.g. what if I have a symbol with a non-utf8-valid name?
<ceymard>
well actually the real question I have is ; should I keep my own parser, or do I wait for zig to provide all the needed facilities ?
<ceymard>
I'm making decent progress actually
<daurnimator>
ceymard: my answer would be to contribute to the zig one to add what you're missing
<ceymard>
daurnimator: that would mean editing both the stage1/2 compilers
<ceymard>
right ?
<daurnimator>
ceymard: no. just std.zig.parse I think
<mikdusan>
stage2 has a good recursive-descent parser . what daurnimator just mentioned. it's used by `zig fmt` too.
<ceymard>
daurnimator: the dump analysis one is done by cpp
<ceymard>
for what I'm gathering
<ceymard>
from*
<mikdusan>
yes, but you could use the stage2 parser, and load .json
<daurnimator>
mikdusan: I think the issue ceymard is talking about is that the cpp parser is non-resumable
<ceymard>
so I should create an executable of my own in zig that uses the stage2 parser ?
<ceymard>
and modify what I need in std ?
<daurnimator>
ceymard: yeah that's what I was thinking
<ceymard>
well right now my thinking was ; the parser does not seem to be priority number 1
<mikdusan>
ceymard: i'm not sure you need to modify std. you can just use the parser as a library and add your own main code
<ceymard>
distributing an executable along my vscode plugin seemed off / complicated
<mikdusan>
oh i see.
<daurnimator>
ceymard: its not andrew's priority; but it can be yours
<ceymard>
mikdusan: I would need to modify it to not crash and burn on invalid input
<ceymard>
I think the modifications are somewhat heavy
<daurnimator>
ceymard: you have a few options; e.g. zig can compile to wasm.... then include that in your plugin?
<ceymard>
oh this is actually a pretty good idea
<ceymard>
the only thing for me is speed of implementation
<ceymard>
I'm not very proficient at zig for now
<ceymard>
the parser seems to be a huge chunk
<daurnimator>
ceymard: you can iterate on that. but a parser in wasm should have a pretty high performance ceiling
<ceymard>
that's true
<ceymard>
there's an argument for making another parser like I'm doing though
<ceymard>
my parser is not even trying to parse zig correctly
<daurnimator>
ceymard: and maybe you can then add that to std too :)
<ceymard>
it recognizes stuff
<ceymard>
but it bails pretty fast
<ceymard>
for instance, the grammar makes a distinction between if exprs and if statements
<ceymard>
I don't, because I don't need to
<ceymard>
my ast is minimal and really just needs to resolve types when asked
<ceymard>
it bails if it doesn't make sens
<ceymard>
e
<ceymard>
as in, the parser to resolve declarations and their type is not as complicated as building a zig lib / executable
Ichorio has quit [Ping timeout: 250 seconds]
<daurnimator>
ceymard: if we had a "lax" parser in std we could probably use it for e.g. generating better compiler errors/warnings too.
<ceymard>
my goals are as follow : identify declarations, their type and their locations
<ceymard>
daurnimator: clearly
<ceymard>
now, the thing is that with my own parser, I'm free to pollute as I want and be dirty :)
<ceymard>
if I'm to commit in std, the bar is higher
<daurnimator>
ceymard: the bar for std isn't too high < 1.0.0
<ceymard>
that said, I think there'd be a case for keeping my approach for now
<daurnimator>
ceymard: sounds like you're convincing yourself to not write zig ;)
<ceymard>
hm
<ceymard>
it's possible
<ceymard>
that this is a factor
<ceymard>
the thing is I'm making good progress
<ceymard>
let's call it a "prototyping phase"
<ceymard>
so here is what I'm probably going to do ; to avoid frustration with dealing with a whole new language to me (well, less new since I'm spending time learning it), and maybe not get where I want as fast as I want, I'm going to keep doing what I'm doing for now until I have something somewhat usable
<mq32>
ceymard, join me and code stuff in zig even if it's not our main language! :)
<ceymard>
this will help me get experience on what I need / want
<ceymard>
*THEN*
<ceymard>
I will switch to zig
<ceymard>
plus, I'll have completion to help me on that !
<mq32>
oh btw
<mq32>
do we already have some vector math library for games?
<mq32>
with matrices and stuff?
<daurnimator>
ceymard: dive in head first; you're shivering now as you're up to your knees :P
<ceymard>
daurnimator: I'm honestly not that scared
<ceymard>
I just want a working prototype, fast
<ceymard>
I peeked at the parser code, it's several thousand lines long
<ceymard>
code that I didn't write, and that I'd have to grok
<ceymard>
the parser I'm writing is way more simple
<daurnimator>
if its hard to grok then we've failed :(
<ceymard>
because it has fewer requirements
<ceymard>
no it's not :)
<ceymard>
it's actually pretty readable
<ceymard>
look, I promise I'll get to it in zig :)
<ceymard>
you said I was scared, and it's true ; I'm scared that it will take me too long and too much effort to get to a basic point of starting completion
<ceymard>
this will be frustrating
<ceymard>
so I'd like to have something basic, not 100% accurate, but a little better than what I did already (because I have a first basic prototype that's funky and does stuff)
<ceymard>
I just hope I won't get ostracized because of that :-| I kinda feel judged
<mq32>
just use your completer already
<mq32>
it's good enough!
<ceymard>
mq32: it at least needs some tweaking then
<mq32>
nah
<mq32>
i'm actively using it and it's good enough to code zig with
<ceymard>
I mean Struct{ .field } is not handled, @This() is not resolved
<ceymard>
it should at least recognize @TypeInfo and stuff
<ceymard>
to be really useful
<ceymard>
also .union expressions
<ceymard>
that's what I feel is really missing right now
<ceymard>
I don't mind that it ignores pointers/optionals/arrays
<ceymard>
oooh
<ceymard>
and also, generics :-|
fgenesis has joined #zig
<ceymard>
anyhoo, daurnimator, mq32, I *will* put my hand into the zig parser in stage 2
<ceymard>
definitely
<mq32>
:)
<ceymard>
I pretty certain that what I'm doing right now is not a waste of time
donpdonp has quit [Read error: Connection reset by peer]
<ceymard>
besides, I think that for zig to be able to provide completion stuff and all, it should go towards implementing LSP directly
<mikdusan>
cripes. the release rate of c/c++ compilers is really rapid these days. seems like every month now there's a new vstudio update or preview, and xcode is rapid-firing releases or betas almost weekly for last month
<ceymard>
not some half assed "let's communicate by json" between zig and the ide
<ceymard>
I mean json files
<ceymard>
since LSP is json :)
<mq32>
ceymard, yeah, but it's a good first step :)
donpdonp has joined #zig
<ceymard>
:)
<mq32>
how could i turn off zig fmt again?
<fgenesis>
delete the exe
<mq32>
then i don't have a compiler anymore .D
<mq32>
nah, i meant for some specific lines to increase readability
<fgenesis>
protip is not to use autoformatting then
<mq32>
andrewrk, i've read some stuff about zig fmt control via comments
walac has quit [Remote host closed the connection]
kllr_sbstn has joined #zig
ibutra has joined #zig
<ibutra>
Hi, I am trying (again) to get zig to compile for a stm32 microcrontroller. For this I have an assembly file which does the necessary initializations and this is added in the build system just fine. But I can't reference zig functions from inside the assembly file. I declared them extern but I always get undefined symbol from the linker
LargeEpsilon has joined #zig
rifkik has joined #zig
<rifkik>
Anyone up for a live coding stream of my SNESemulator?
<mq32>
if you give me an hour, i'll be watching :)
<ibutra>
can somebody tell me where I find the code for the builtin module?
kllr_sbstn has quit [Ping timeout: 240 seconds]
<ibutra>
nvm
<ibutra>
'zig builtin'
<mq32>
sep
<mq32>
*yep
<ibutra>
If I compile a simple main.zig file for thumbv7em-freestanding-eabihf and look at the output with objdump I get an ampty .text section, which probable explains why the linker can't link my functions. But why would it be empty? Is there some kind of optimization going on that eliminates functions zig doesn't find a caller for?
<bgiannan>
ibutra, zig doesn't compile branches that can't be reached
<ibutra>
that is cool, how do i tell zig a function is called from a provided assembly file and not to eliminate it?
<mikdusan>
stick `export` keyword in front of it "export fn foo() void {}"
<ibutra>
did that already
meheleventyone has joined #zig
<ibutra>
If I just try to compile the main.zig by itself with the target thumbv7... the .text section is empty
<ibutra>
If I compile it with zig build-exe without a target it gets compiled just fine
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ibutra has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ibutra has joined #zig
ibutra has quit [Client Quit]
sammich has quit [Remote host closed the connection]
sammich has joined #zig
halosghost has joined #zig
<fengb>
ibutra: can you do `zig build --verbose`?
waleee-cl has joined #zig
dimenus has joined #zig
<tgschultz>
Oh this is new. Zig 5.0 has a new dependency on Windows. How unfortunate.
<halosghost>
lol
<fgenesis>
like what
<fgenesis>
finally a dependency on windows xp?
<tgschultz>
ok, so it isn't exactly new, but it has a different vcruntime dependency than previous versions
<tgschultz>
so really it's just annoying for me, not really a problem.
<fgenesis>
it's always possible to link in the vcrt statically...?
<tgschultz>
alright, I haven't actually written any Zig code in a while so maybe I missed something, but std.heap.DirectAllocator is private?
<tgschultz>
Oh, I think I get it. Has to do with the change to purely stateless DirectAllocator. I have to reference the global instance.
<bgiannan>
yeah std.heap.direct_allocator
<mq32>
is it possible to fully debug-print some struct values with std.debug.warn()?
<tgschultz>
what do you mean by "fully"?
<fgenesis>
down to the very last bit
<mq32>
ah, i just read std.fmt
<mq32>
it will not print arrays
<tgschultz>
it won't? I thought it only wouldn't print arrays of unknown length or pointers.
<mq32>
zigs comptime reflection and stuff is just great
<mq32>
"hey, i want to format this struct... oh, it just needs to implement this function and it will work? nice!"
<tgschultz>
It was a group effort, but actually I was responsible for that particular addition
<mq32>
neat!
<mq32>
thanks :)
<tgschultz>
Huh. I would have sworn we print out arrays of known length. But maybe we decided that if those arrays were arrays of structs it might be too crazy messy? I don't think there's a technical limitation or danger there.
<mq32>
well, probably most arrays were just *too* large to print usefully
<mq32>
but: time for a pull request to change that
<mq32>
{c} vs {p} for arrays with content or pointer
<tgschultz>
That kind of comptime reflection is also used in Serialize/Deserialize. It works well and is simple, but I worry about using it a lot because of collisions. That will be less of an issue once we can match on function signatures more accurately.
<tgschultz>
Or get some kind of annotation feature.
<tgschultz>
Though honestly I question the value of annotation, since it's just moves the problem to another namespace.
<mq32>
i think i also found a bug in format float :D
<mq32>
yeah, i know the annotation/attribute hell from the .NET XmlSerializer
<mq32>
you can actually project *ANY* xml structure to .NET class structures with that
<tgschultz>
aw, I've encountered a real problem in zig 0.5.0 now. "broken LLVM module found: Call parameter type does not match function signature!"
<tgschultz>
I feel like this issue is probably already known, but LLVM errors are opaque to me so I don't know what the actual problem is.
<dingenskirchen>
I got that error once when I was missing a try in front of a function call that could return errors
<dingenskirchen>
maybe that helps?
<tgschultz>
I'll check, but that'd be a regression in the compiler because it should check that right?
<mq32>
comment of the day
<mq32>
// 1.0 is 60° (assuming pi = 3)
<dingenskirchen>
tgschultz, seems that way
<tgschultz>
mq32 that sounds like the kind of thing I'd expect to see in some old dos game code.
<mq32>
hehe
<mq32>
but yeah, for graphics programming, it's a good measure to assume pi=3
<mq32>
doesn't hurt in most of the ways and makes stuff pretty easy :D
<tgschultz>
though it was more common to have 256 or 65536 'degrees' in a circle
<mq32>
yeah
<mq32>
i have made a demo for embedded hardware
<mq32>
it's full of such hacks
<mq32>
"why do you have angles from 0…3? … IN INTEGERS?!"
<tgschultz>
hmm... well, it does look like it could be the issue you're talking about but it's going to be a pain to find. This is code that was working as of sometime in 0.4.0.
<fengb>
Avoid rounding errors?
<fengb>
I suppose it'd make more sense to do degrees at that point
<mq32>
opening a window with sdl, render a rotating 3d triangle with OpenGL ES
<mq32>
most stuff in zig, except for opengl loader and SDL
LargeEpsilon has quit [Ping timeout: 268 seconds]
<tgschultz>
I just can't figure out what LLVM is on about with this error, but it's completely broken my bmp library.
<tgschultz>
which means it also broke my toy game engines
<tgschultz>
not that that is a big deal, other than it being, from my perspective, a pretty damning bug
<andrewrk>
tgschultz, I'd be happy to take a look
<tgschultz>
Alright, I'm going to work through my other libs and see if anything else broke, then come back to it.
<tgschultz>
Already looks like something with hashmaps or bufmaps might be broken too
<tgschultz>
"can't store runtime value in type" thrown inside a completely comptime block...
<tgschultz>
which is amazing since these supposedly runtime values are actually types
<andrewrk>
sorry tgschultz, that result location branch was pretty brutal to the stability of the advanced comptime stuff. we have more test coverage than ever now, but also the compiler's job has become increasingly complicated
<tgschultz>
that probably has something to do with the bmp lib breaking too then. There's some pretty advanced comptime stuff going on in there.
<andrewrk>
one goal to aim for that is looming on the horizon now, after package manager (or maybe even before?), is some kind of meta-repository that has everybody's active projects listed in it, and has a way to run all the tests
<andrewrk>
or at least build everything
<andrewrk>
to catch regressions in master branch faster
<tgschultz>
interestingly, PseudoStruct passes all tests.
<tgschultz>
that's the one that uses recursively generated types
<tgschultz>
I'm a little surprised
<tgschultz>
well anyways, i'll go through and see if I can't find minimal examples of these issues. I thought someone already mentioned the hashmap one but apparently not.
_Vi has quit [Ping timeout: 250 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<tgschultz>
andrewrk, is the debug allocator you've been working on part of std?
hasanyasin has joined #zig
<andrewrk>
tgschultz, not yet but I'm planning to stabilize it during this release cycle and add it
meheleventyone has joined #zig
<tgschultz>
oh wow, this isn't a buffmap bug at all, it's a compiler bug.
hasanyasin has quit [Remote host closed the connection]
<tgschultz>
yep, tries to read a null pointer. I'll have to build a debug compiler to get more info
hasanyasin has joined #zig
Ichorio has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
n_1-c_k has joined #zig
LargeEpsilon has joined #zig
THFKA4 has joined #zig
hasanyasin has quit [Remote host closed the connection]
hasanyasin has joined #zig
hasanyasin has quit [Ping timeout: 252 seconds]
Akuli has joined #zig
hasanyasin has joined #zig
hasanyasin has quit [Remote host closed the connection]
<tgschultz>
problem appears to occur during analysis of a conditional break
<tgschultz>
or codegen of a conditional break
LargeEpsilon has quit [Ping timeout: 276 seconds]
<tgschultz>
s/break/branch/ my brain is not firing on all cylidars, as usual
lunamn has quit [Ping timeout: 265 seconds]
lunamn has joined #zig
<tgschultz>
ok, looks like it is a switch expression inside an inline while
<mq32>
hm
<mq32>
i wanted to implement a fully-conforming OBJ parser
<mq32>
now i've taken a look at the spec
<mq32>
i don't want to implement that anymore
<andrewrk>
now that I've looked a bit more deeply into documentation generation, I think that a fully js/wasm implementation would be reasonable
<tgschultz>
alright, bug report incoming. a switch on a range in an inline while loop causes null pointer deref
<andrewrk>
e.g. there would only be 3 files: doc.html, doc.js/doc.wasm, and semantic-analysis-dump.json
<mq32>
so zig playground online?
<mq32>
or just doc display/live generation in zig? :D
<andrewrk>
thanks tgschultz
<andrewrk>
you already need something like this setup for searching to work well
<mq32>
oh yeah, right
<andrewrk>
and then with zig's tree structure (files are just structs) generating redundant .html for each file (or each struct?) is wasteful
<andrewrk>
so my argument is then: (1) you already need js for searching. (2) embracing this will lead to highest compacting of bytes and most flexibility of display
<andrewrk>
also there are people in rust community who believe that rust should go this direction
<andrewrk>
with the documentation
halosghost has quit [Quit: WeeChat 2.6]
<fengb>
wasm based docgen?
<mq32>
what is a good "generic purpose allocator" i could use right now?
lunamn has quit [Ping timeout: 265 seconds]
<torque>
counterpoint: javascript is evil
<mq32>
torque, that's why andrewrk proposed using wasm and write most of the logic in zig :)
<tgschultz>
on Windows, std.heap.HeapAllocator, on anything else you're out of luck unless you have a more specific usecase
<andrewrk>
mq32, yes that's a good idea when linking libc
<mq32>
yeah i know the ZGPA :D
<mq32>
but didn't know if it was in a usable state right now
<andrewrk>
torque, what would be your preferred way to browse generated documentation?
<andrewrk>
mq32, it's actually pretty close
<mq32>
nice!
<andrewrk>
you can see the rest of the todo items in the bottom of the readme
<fengb>
wasm doesn't really interact with the DOM so you'll probably spend more time writing JS plumbing to ferry the logic around
<fengb>
And... I don't imagine our docs will have really complicated logic either
lunamn has joined #zig
<andrewrk>
the logic is in rendering the docs themselves from the semantic analysis dump. it will either happen as a compilation step and generate a lot of html bytes, or happen on the fly with js/wasm
<fengb>
Oh I see. That'd be pretty cool
<torque>
unfortunately I don't think there's a realistic alternative to web-based documentation
<fengb>
The web is the least bad globally available UI engine
<torque>
this depends on how you classify "bad"
<andrewrk>
does it? pick any category
<torque>
engineered for and driven by advertising
<torque>
user customisability and control
<torque>
performance
mahmudov has joined #zig
<mq32>
fengb, i think Qt is actually a pretty strong contestant to the web
<mq32>
except for "its stupidly easy to write a web UI"
<fengb>
It requires install. That makes it much harder to just use :P
<fengb>
I'm curious if anyone will start exploiting canvas or webgl more
<fengb>
Probably not worth it since it'll probably just make accessibility terrible without too much benefits
<mq32>
what terms of "more" do you talk about? have you ever seen shadertoy.com?
<torque>
the web is certainly the best^W easiest platform for developers, but I'd argue it's the worst or one of the worst for users (as it turns out, most users don't care, though)
<fengb>
Using it for full UI building. Like Qt => wasm => canvas silliness
<fengb>
Users don't like to installing everything. That makes the web relevant and "good"
<torque>
anyway, from a design standpoint, generating docs on the fly from a unified dump sounds pretty cool to me
<mq32>
you cannot use std.heap.c_allocator with ArrayList
<fengb>
You can test out zee_alloc but performance is probably atrocious >_>
<mq32>
oh wait
<mq32>
i'm just stupid :D
kllr_sbstn has joined #zig
<THFKA4>
.md could be a good format to use as an intermediate step
<THFKA4>
lots of tools generate html from .md
<fengb>
I actually need to test out zee_alloc with real projects
<THFKA4>
and there are desktop clients as well, if you're into that
<andrewrk>
THFKA4, it could be interesting to have an alternative doc generation that did not rely on js/wasm. it wouldn't have search, but it would still serve a use
<andrewrk>
that could be a nice community project, now that we already have -fdump-analysis
<fengb>
lol... I just realized that FUNDUDE runs at 2.4x speed on 144hz monitors
<andrewrk>
yeah and hryx, I know you're busy these days, but you were interested in the doc generation. you will be pleased to know we now have -fdump-analysis
<tgschultz>
...did alignment rulse for structs change? Somehow I have a union with an alignment greater than both of its possible components.
<andrewrk>
tgschultz, major bugs in alignment of structs were fixed
<companion_cube>
torque: manpages are good for docs
<companion_cube>
but having local manpages is also super nice
<tgschultz>
major bugs were fixed, but how can I have a union with align(16), when neither component has align(16)?
<andrewrk>
tgschultz, yeah that seems wrong
<tgschultz>
it's an extern union if that makes any difference
<tgschultz>
something is deeply wrong here. @compileLog confirms that alignment of the struct is 8 as expected, but if I try to ptrCast to it from something (also align(8)) it complains that *Node is actually align(16)!?
<tgschultz>
And this is happening immediately after doing an alignCast to *Node
<tgschultz>
alignOf(*Node) that is
<tgschultz>
so it feels like alignCast is doing something wrong
<tgschultz>
No, I have that backwards, ptrCast is misinterpreting the alignment somehow
<tgschultz>
alignCast aligns the ptr correctly
<tgschultz>
but prtCast thinks *Node is 16
<mq32>
andrewrk, i'm trying to create a LoggingAllocator with this:
<mq32>
var logger = std.heap.LoggingAllocator.init(std.heap.c_allocator, try std.debug.getStderrStream());
<mq32>
getting an error: error: expected type '*std.io.OutStream(anyerror)', found '*std.io.OutStream(std.os.WriteError)'
<mq32>
is this an expected error or a bug?
hasanyasin has joined #zig
hasanyasin has quit [Ping timeout: 268 seconds]
<n_1-c_k>
I think I've succeeded in creating an array of strings, but I don't know how to read them - https://0x0.st/zwcV.zig - help?
THFKA4 has quit [Ping timeout: 246 seconds]
<mq32>
n_1-c_k, this code has some problems
<mq32>
first: you don't know how long your strings are
<n_1-c_k>
I do too! 5 and 6. So there.
<n_1-c_k>
Do you mean I have to construct something that remembers each string's length?
<tgschultz>
you can print c-strings IIRC, but I don't remember the fmt flag for it
<tgschultz>
of couse in this case those strings are not c-strings, so that'd end badly
<n_1-c_k>
mq32, tgschultz, thanks
<n_1-c_k>
oh that worked! thanks mq32
<mq32>
you're welcome!
<mq32>
i'm writing a OBJ parser right now and i'm very pleased about the zig experience
<mq32>
except for some stuff i didn't understand it all worked pretty well :)
<n_1-c_k>
I'm trying to write fizzbuzz...
<mq32>
good luck!
<mq32>
zig is really a well done language :)
<mq32>
i have a pleasant experience on more complex stuff
halosghost has joined #zig
traviss has joined #zig
<traviss>
m32: just a guess about your earlier // zig fmt: off and // zig fmt:on. did you try removing the spaces? ie '//zig fmt: off' and '//zig fmt:on'
<andrewrk>
I think it only works between declarations; not inside a function for example
<mq32>
andrewrk, that explains a lot
<mq32>
i wanted to prevent zig fmt to change my matrices
<mq32>
but i have to stop changing pretty much the hole test section
porky11 has joined #zig
<jaredmm>
Well, I was able to get libepoxy linking on Windows using the x86 library in a C program, but not the x64 lib. Visual Studio has a literal mess of settings, though, so I could've missed something. In short: I have not enjoyed my Windows time so I think I'll go back to doing Zig stuff on Linux.
<andrewrk>
jaredmm, package manager will entirely solve this
<mq32>
andrewrk, i'm so looking forward for finally making crossplatform games without having to think about "how to compile stuff for windows"
<jaredmm>
Yeah, but it will still bother me not knowing the why. There's a non-zero number of projects using epoxy on Windows. I can't imagine they're all x86.
<tgschultz>
this is crazy. `@compileLog(@alignOf(*Node)); const node = @ptrCast(*Node, aligned_ptr);` => 8| error: cast increases pointer alignment note: '*Node' has alignment 16. Literally the next line.
<tgschultz>
And it doesn't appear in a more minimal use case
<tgschultz>
*test case
<mq32>
is there a best practice for putting stuff with allocations into an ArrayList?
halosghost has quit [Quit: WeeChat 2.6]
<tgschultz>
Oh, I may have stumbled onto something. This is an extern union, but in trying to build a test case I get an error about the wrong field being set. Extern unions shouldn't have a tag.
Akuli has quit [Quit: Leaving]
stratact has quit [Quit: Konversation terminated!]
dimenus has quit [Ping timeout: 265 seconds]
mouseghost has joined #zig
<mouseghost>
how am i supposed to guess where do i look for a function that does a certain thing?
<mq32>
just use grep on the lib/std library :D
<mikdusan>
ask. right now searching lib/std/ for public decls like `pub fn` is the way to go. for now, avoid looking at `std.os` as that's a platform abstraction.
kahiru has joined #zig
<mouseghost>
mq32, but then i have to guess what should i tell grep to search for D:
<mq32>
yeah, that's true
<mq32>
i'm working with this scheme right now
<mq32>
also using the great "autocompletion" by ceymard
<mq32>
it helps a lot
<mouseghost>
well so ive been wondering about file reads mikdusan
<mouseghost>
theres std.os.read
<mouseghost>
and also something in event
<mq32>
i'm using std.fs.File right now
<mq32>
and it works pretty well
<kahiru>
hi, are there any exercises to get one to know the language? Something along the lines of clojure koans or rustlings for rust?
<mouseghost>
oooo i second that^!!
<mikdusan>
mouseghost: so std.fs for filesystem paths, std.fs.File for open/close, std.mem for byte array related helpers (like strings)
<mouseghost>
is there perhaps a parser to maybe get functions in a file thne or something :/?
<mouseghost>
ooh
<mouseghost>
its like grep pub fn <func>?
<mq32>
kahiru, mouseghost: do you have programming experience in other programming languages?
<mq32>
i started learning zig by reading the manual and implementing a raycaster
<mq32>
now my second project is a 3D game
<mouseghost>
yep i do have some experience
<mq32>
implemented a basic 3D math lib and an OBJ parser today
<mouseghost>
not with raycasting though
<mq32>
zig has a high "just works" experience factor
<kahiru>
I do have some experience, but lack pet project ideas :)
<kllr_sbstn>
you could also port another project to zig, especially libraries
<tgschultz>
the math is pretty basic trig
dimenus has joined #zig
<mouseghost>
tgschultz, is that a raycaster?
<tgschultz>
yes...? Or are you thinking of a raytracer?
<mq32>
raytracers aren't much harder actually :D
<mouseghost>
uh i still have trouble understanding how does a rt work
<tgschultz>
raytacing is a bit more complicated, but mostly it's just a much higher load
<mouseghost>
oh
<mouseghost>
i didnt notice this difference
<mq32>
mouseghost, for basic raytracing, you need three "hard" functions:
<mq32>
"intersect sphere with ray"
<mq32>
"intersect sphere with plane"
<mouseghost>
yeah i dont know about these :/
<mq32>
*"intersect plane with ray"
<mq32>
"create ray from screen space"
<tgschultz>
raycasting is the technique used by wolfenstein 3d. For taht you need 'intersect ray with grid cell'
<mq32>
the intersection functions are all pretty easy and can be found on scratchapixel or wikipedia
<mouseghost>
hm
<mouseghost>
i like exploring and understanding things myself though q-q
dimenus has quit [Ping timeout: 265 seconds]
<mouseghost>
oh yes i did raytracing then
<mouseghost>
i didnt figure out 2 things: how do i manage with things before my camera and how do i work out with depth
<mouseghost>
edit: it was perspective projection not rt
<mq32>
ah
<mq32>
so rasterizer
<mouseghost>
well i just took R3 points and made them into R2
<mouseghost>
with some rotations
<mq32>
hehe
<mq32>
then you divide xy by z and have projection!
<mq32>
*perspective
* mq32
is tired
<mouseghost>
its late here
<mq32>
here as well
<mouseghost>
a new day just started so i might just as well head off now; have a good night mq32, thanks for all the info too
<mq32>
are you in MESZ?
<mouseghost>
mq32, MESZ=CEST?
<mq32>
ah yeah :D
<mouseghost>
then yes
<mq32>
sorry, i think MESZ is german
<mouseghost>
yeah it seemed to me that it was so
<mouseghost>
mq32, here, i could call it, "ŚECL" :E
<mouseghost>
but thats my invention
<mouseghost>
(i think)
<mouseghost>
yeah well, goodnight!
mouseghost has quit [Quit: mew wew]
LargeEpsilon has joined #zig
<tgschultz>
well, I've found bugs that might be the source of my woes for everything but the bmp library, where I barely have a clue. Seems to be something with codegen and packed structs with non-mod8 bit widths. I'm going to have to put in some kind of automated testing of this stuff in the future.
LargeEpsilon has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
wootehfoot has joined #zig
<mq32>
tgschultz, what does your bmp library do?
<tgschultz>
it loads bmp files
LargeEpsilon has quit [Remote host closed the connection]
<mq32>
oh
<mq32>
my condolences
LargeEpsilon has joined #zig
<mq32>
bmp is a hell of a format
<mq32>
even if people always say "it's easy"
<tgschultz>
the complication is in how it allows you to load it to any pixel format you want from any supported format
<mq32>
yep
<tgschultz>
the bmp formats are mostly straight forward, the hard part was designing it for code reuse, not requiring an allocator, and implementing Huffman1D support.
LargeEpsilon has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
<tgschultz>
I had a png library too at one point, but I decided to rewrite it after 0.4.0 (so it didn't need an allocator, made it cleaner, etc), and I got busy with other things before doing that.
<mq32>
okay how do you do a png library without allocator?
<tgschultz>
the same way as a bmp lib without an allocator. You use a state machine that the caller can call repeatedly to fill buffers until the image data is completely read. Adam7 might complicate that, but I hadn't even gotten as far as rewriting the zlib decoder so I hadn't thought much about it.
<mq32>
ah neat
<mq32>
so you have a callback "setPixel" or simlar?
<mq32>
scientes: the obj loader is actually only 220 lines of code
<scientes>
mq32, if it doesn't have low resolution initial versions, its a totally linear decode
<scientes>
so except for remembering the zlib dictionary (which is very small), you can forget everything you have written
<mq32>
what do you mean by "low resolution versions"?
<scientes>
png supports progressive
<mq32>
ah, okay
<scientes>
in that case you probably want to skip to the highest resolution version
porky11 has quit [Quit: Leaving]
<mq32>
i though you were talking about the OBJ loader :D
LargeEpsilon has quit [Remote host closed the connection]
<tgschultz>
IIRC the high res version is still based on data only available in the previous passes with Adam7. The zlib decoder will require a static 30k ring buffer, but it is ok because it is static.
<scientes>
yeah interlacing is going to be complicated
<scientes>
i think you will need a full buffer of the result image
<scientes>
which is kinda obvious you will need anyways
<tgschultz>
I'll probably just make the caller handle that if they care. If they don't there will be a "load" that takes an allocator and does it for them.
<tgschultz>
almost certainly the caller will put the data into a full-image destination, but consider cases of just processing pixels to change colors or embed stegnographic data.
<tgschultz>
also, it can work at comptime if it doesn't call an allocator.
<scientes>
we need a comptime allocator...
<scientes>
actually, it can't
wootehfoot has quit [Read error: Connection reset by peer]
<scientes>
oh maybe
<scientes>
comptime is limited in what you can take a pointer to
<scientes>
this can be fixed
<tgschultz>
andrewrk and I have an open issue about comptime allocator
<tgschultz>
though my experimentation with loading a bmp at comptime proved ludicrously slow
<scientes>
I believe it
<tgschultz>
so in reality pre-processing in a build step is going to be much better anyway
<scientes>
JIT comptime is a LONG ways out ;)
<mikdusan>
_someone_ is on a coding tear. #3379 proof of concept of stage1 doc generation