<andrewrk>
metaleap, I'm sorry for breaking your code
<andrewrk>
jaredmm, I see the master branch problem, working on it
<jaredmm>
Yeah, apparently copypaste has forsaken me. Was trying to ask about it.
<metaleap>
no prob, just a matter of rehabitualizing i guess. i think there's a danger for newcomers to easily take to automatically/habitually associating any occurrences of OutOfMemory with "couldnt alloc heap/ram from OS". as a result a pattern evolves where all those are just bubbled up to the top-level main. "what does this or that return, ah just oom, give it a try-and-forget then". but by using the error name for not-merely-allocator.alloc-failures, maybe
<metaleap>
such "convenient-but-ultimately-sloppy" mind habits are broken early and maybe thats a good thing. so i'm fine if it stay such for now, around 1.0 intro/langref docs can probably make a lil side-note of such things in appropriate place
<andrewrk>
metaleap, with for example std.heap.FixedBufferAllocator it's pretty similar - you have a slice and when you run out it returns error.OutOfMemory
<andrewrk>
errors are contextual; they can mean different things coming from different functions
<metaleap>
yeah i get the reasoning, i can buy that =)
euandreh has joined #zig
metaleap has quit [Quit: Leaving]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
<jaredmm>
Is there any documentation on the expected scope of translate-c? The docs mention compatible macros. Anything that can be done within what context?
alexnask_ has quit [Ping timeout: 240 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
marijnfs has quit [Ping timeout: 240 seconds]
marijnfs_ has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
<pixelherodev>
Anyone able to @cImport X11?
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
<pixelherodev>
Think there might still be a bug or two
<pixelherodev>
Going to try updating first though, as my Zig is a bit out of date
<pixelherodev>
Problem is I think it needs C varargs and some complex macros / compiler feature detection stuffs
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
<LakeByTheWoods>
Yeah, currently RootWindow fails. You can do it manually with `const root: Window = (opaquePtrCast(_XPrivDisplay, display).*.screens[@intCast(usize, visual_info.*.screen)]).root;`
<LakeByTheWoods>
See issue #4328
<LakeByTheWoods>
Oh, and opaquePtrCast is just `return @ptrCast(To, @alignCast(@alignOf(To.Child), from));`
<pixelherodev>
Thanks for the info; I think I'll try to spend tonight fixing that
<pixelherodev>
Idea regarding the backend debate from a while back: self-hosted should build backends on-demand the same way we build libcs
<pixelherodev>
That way, only native compilation needs to be built-in, and cross-compiled targets can be generated on-demand
<pixelherodev>
Practical too: can be generated as either shared libraries or tiny self-contained static executables and either dlopen()ed or exec()ed
marijnfs has joined #zig
<pixelherodev>
Requires more modularity than is currently present, but it's definitely feasible
marijnfs_ has quit [Ping timeout: 260 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 258 seconds]
<pixelherodev>
Huh, that translate-c bug *appears* to be gone
<pixelherodev>
Having entirely different ones now :P
<pixelherodev>
For instance, translating an array of strings gives a compile error
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 255 seconds]
<pixelherodev>
Ah, type is translated wrong
<pixelherodev>
As `[*c][*c]const u8` instead of `[3][*c]const u8`
<pixelherodev>
Of course, knowing that isn't going to be enough to quickly fix the bug in source I've never read :P
<pixelherodev>
Given that I actually want to work on this project, I'm going to just build Sokol as C source and use extern to build the wrapper for now
<pixelherodev>
Then later, switch the wrapper to be a @cImport when either I have time to fix the bugs or someone else fixes them
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 255 seconds]
daurnimator has joined #zig
<pixelherodev>
How do you set musl as libc when using build.zig?
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
<pixelherodev>
`/usr/local/lib/zig/libc/glibc/sysdeps/unix/sysv/linux/include/bits/syscall.h:3:10: fatal error: 'misc/bits/syscall.h' file not found`
<pixelherodev>
When compiling with libc :(
<jwh>
looks like it wants musl srf
<jwh>
src*
<jwh>
oh hm actually no, thats not the correct path either
<pixelherodev>
(the error is unrelated to building with musl; can't build with glibc on Zig trunk :( )
<jwh>
o
<jwh>
well bits/ is glibc, is it not honouring your libc choice?
<pixelherodev>
I didn't choose one
<jwh>
o
<pixelherodev>
Not sure how to set to musl
<pixelherodev>
Just did linkLibC()
<jwh>
I can't build atm, haven't switched to trunk
<jwh>
zig release disapproves of llvm10 heh
<pixelherodev>
Going to do a bisect, have a hunch I know what the problem is
<pixelherodev>
"Thank you Microsoft" :P nice commit message
<jwh>
lol
<jwh>
CMake Error at cmake/Findllvm.cmake:49 (message):
<jwh>
LLVM is missing target AArch64. Zig requires LLVM to be built with all
<jwh>
default targets enabled.
<jwh>
aw
<pixelherodev>
Yeah, that's what I was mentioning earlier
<pixelherodev>
Ideally, it shouldn't need all targets built in to LLVM
<jwh>
I changed our packaging to only build native targets a while ago
<pixelherodev>
You can fix it locally
<jwh>
since xc is not worth the effort
<pixelherodev>
Just disable the error message
<pixelherodev>
Zig xc takes no effort though, that's kinda the point :P
marijnfs_ has joined #zig
<jwh>
well sure
marijnfs has quit [Ping timeout: 256 seconds]
<jwh>
but things you typically xc (c, c++) do
<pixelherodev>
Unfortunately, this can't really be fixed for stage1 because LLVM is much much harder to compile on-demand than e.g. glibc
<pixelherodev>
True
<jwh>
hm
<jwh>
it can still use an already installed llvm right
<pixelherodev>
Yeah
<pixelherodev>
Just point it at it
<jwh>
well its in /usr, so
<jwh>
doesn't really have a choice, its llvm or nothing heh
<pixelherodev>
For *now*
<jwh>
well I mean, thats all thats on the system
<jwh>
theres no (lib)gcc
<jwh>
or binutils for that matter
<pixelherodev>
No, I mean; as a compiler backend, LLVM is the only option for Zig for now, but the goal is to change that eventually
<jwh>
but why
<jwh>
even with all the shortcomings, the llvm suite is still nicer
<jwh>
[165/167] cd /root/m/devel/zig/src/zig...e-gen-h --bundle-compiler-rt -fPIC -lc
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
Not to GCC
<pixelherodev>
To a self-hosted backend
<jwh>
is it supposed to build in a pure-llvm environment?
<pixelherodev>
Should
<pixelherodev>
I think
<jwh>
unless I'm missing something I need to bootstrap it
<jwh>
oh its oom
<jwh>
helpful
<pixelherodev>
Yeah, the glibc thing is a regression
<pixelherodev>
Bisecting now, ~6 steps left
<pixelherodev>
Hmm... unrelated bug: this is in C source being called externally: `assert(src && dst && (max_len > 0))` passes, but *src gives: segfault at 0x0
slurpie has quit [Ping timeout: 258 seconds]
<pixelherodev>
Ah, the address reported was wrong.
<jwh>
oh hm, this appears to have worked
<jwh>
good good, will just have to wait until its released now
<jwh>
moved to llvm10 and broke a whole load of projects that haven't bumped yet, patched rust but it seems pointless and we may as well just wait
<jwh>
spoke to soon :(
<jwh>
Unable to determine path to libstdc++.a
<jwh>
sigh
<wilsonk>
pixelherodev: are you still having trouble with that missing misc/bits/syscall.h problem
<jwh>
whats with this default assumption thing, rust does the same
<jwh>
detect whats available
<jwh>
also failing during install after successfully building
* jwh
rollseyes
<pixelherodev>
wilsonk, bisecting; it's a problem on trunk but not on certain older commits
<pixelherodev>
It's a recent regression AFAICT
<wilsonk>
andrew told me to 'rm -rf build/lib/something or other' and that fixed it...one sec let me see if I can find the command
* jwh
thwacks andrewrk
<pixelherodev>
wilsonk, this was from a fresh build
<tdeo>
shouldn't "dest.ptr must be <= src.ptr" in the std.mem.copy docs have an "if the memory regions overlap" after it?
* pixelherodev
shrugs
<pixelherodev>
I remember having a similar question at one point
* jwh
stashes zig package
<jwh>
another day maybe
<jwh>
when these issues are fixed
<wilsonk>
pixelherodev: fresh build from master today? Seems really strange that the exact same error would happen...let me rebuild a fresh one here
LakeByTheWoods has quit [Remote host closed the connection]
karelb has joined #zig
<karelb>
hey. I am playing with zig for 1st time, just writing hello world. I write, on master, `var one_plus_one = 1 + 1;warn("1 + 1 = {}\n", .{one_plus_one});` - it fails with ` variable of type 'comptime_int' must be const or comptime`. That is expected? :)
<mq32>
hey karelb
<mq32>
yes, this is expected
<karelb>
ok :) thx
<karelb>
I will ask dumb questions I guess.... I go through the docs now :)
<mq32>
literals in zig have a special type "comptime_int" or "comptime_float"
<mq32>
these are special as they are "just any value allowed"
<mq32>
so you could do: "var x: u8 = 256;"
<karelb>
:+1:
<karelb>
oh this isn't slack. nvm
<mq32>
and the compiler will tell you that 256 does not fit into u8
<mq32>
but you can do "256 - 1" and it will fit then
<mq32>
if you need a typed literal, you have to cast that with @as()
<karelb>
got it
<karelb>
thx
<mq32>
oh, and another thing: you may not store a comptime_int or comptime_float in a var, only in const values
<metaleap>
it's basically what I'd call a quirk that "const" can be comptime without needing to declare it so but "var" if assigned a comptime_foo value must be explicitly declared "comptime var". even though then of course you can still use it in runtime exprs
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 268 seconds]
karelb has quit [*.net *.split]
alichay has joined #zig
frett27_ has quit [Ping timeout: 258 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 255 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
mzigora has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 260 seconds]
RagingDave has joined #zig
nikoala has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
Barabas has joined #zig
<Barabas>
Hi, is there a way to fail a test without aborting? I'd like to run all my tests, regardless of whether some fail or not.
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 256 seconds]
* daurnimator
is going to try and stream some zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
<alexnask_>
@Barabas, I don't think so (unless you manually modify the test runner source code but this is obviously not recommended)
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
<Barabas>
Hmm too bad, would be nice to have that option.
mzigora has quit [Quit: mzigora]
redj has quit [Read error: Connection reset by peer]
dingenskirchen has quit [Ping timeout: 256 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
dingenskirchen has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
marijnfs has quit [Ping timeout: 260 seconds]
Akuli has joined #zig
marijnfs has joined #zig
mikdusan has quit [Quit: WeeChat 2.6]
mahmudov has quit [Ping timeout: 256 seconds]
mahmudov has joined #zig
waleee-cl has joined #zig
mikdusan has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
adamkowalski has joined #zig
reductum has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 268 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 258 seconds]
frett27_ has joined #zig
nrdmn has joined #zig
marijnfs has joined #zig
<nrdmn>
hello! I'm having some trouble with the .{} tuple syntax. I'd like to create a tuple type and then declare variables of that type and assign values to it.
<alexnask_>
fengb, nrdmn, I'm planning on adding the propsoed syntax this week (along with improvements to tuples like slicing, support for if and switch expressions insede etc)
alexnask_ is now known as alexnask
<alexnask>
I will try at least :P
<TheLemonMan>
it was added and then removed :\ but they support OpenBSD... that may be interesting to support
<nrdmn>
alexnask: nice
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<TheLemonMan>
alexnask, are you still on WSL1 ?
<alexnask>
Yes
<TheLemonMan>
can you reproduce the problem in #4689 ?
<alexnask>
Sure I will check it out
<TheLemonMan>
gah, the ticket count skyrocketed again past 1000
slurpie has joined #zig
<alexnask>
A fair amount are proposals
<andrewrk>
and most proposals will be rejected 😈
<alexnask>
Ofc :)
<alexnask>
Glad you approved the tuple slicing though, I think it will be really useful ^^
<andrewrk>
yes I think it's consistent with the other design decisions such as indexing
<andrewrk>
you might say it makes the language smaller to be consistent in this way
<TheLemonMan>
andrewrk, is `zig targets | jq .native` supposed to match what's in `zig builtins` ?
<nrdmn>
huh, tuple indexing is possible?
<alexnask>
Yes, with comptime indexes
<andrewrk>
TheLemonMan, yes
<TheLemonMan>
oh no
<andrewrk>
oh no? it's just a missing call to the detection code rigth?
<TheLemonMan>
*shrug*, I assumed it was already wired up correctly
RagingDave has quit [Quit: quit]
<andrewrk>
I thought it was too, but there was a lot of churn there recently, i probably made a mistake
<andrewrk>
I also noticed an accidental hard coded " (native)" string yesterday
<nrdmn>
is there an |= operator for bools?
<alexnask>
TheLemonMan, I have basically the same output as Rocknest (with a different glibc version)
<shakesoda>
"When [struct, union, array] types are passed as parameters, Zig may choose to copy and pass by value, or pass by reference, whichever way Zig decides will be faster."
<marijnfs>
I'm confused by why my code doesn't work, I'm trying to wrap some stuff in a struct.
<shakesoda>
if you're trying to modify it in the function, pass by pointer.
<metaleap>
marijnfs: the usual stdlib init funcs like in Buffer ArrayList AutoHashMap etc dont return a pointer so they can return their local value they just initialized. if they were to return a pointer, it would have to be to their local stack space but shouldnt! as it expires upon return. often you also dont want that sort of structure to be placed on the heap and if you did you can do it yourself afterwards.
<shakesoda>
oh, am I talking about the wrong thing
<metaleap>
so assume a copy and you can pass it around via pointer afterwards for the lifetime of the "obj". or place it on the heap for much longer lived such instances
<marijnfs>
metaleap: yeah i figured things like a Buffer can be passed by value, and properly keep their underlying data in place
<metaleap>
what, their "underlying" data lives elsewhere
<metaleap>
thats why they take an allocator for their inner slices
<metaleap>
assume an ArrayList to be the sizeOf: (1x usize) + (1x slice (aka 2x usize)) + (1x pointer-to-allocator (aka 1x usize))
<metaleap>
thats what init returns as "a copy" (potentially, or ref behind the scenes unbeknownst to the caller, depending on inliner / optimizer too i'd guess)
<metaleap>
ah yeah now i got your comment, yah ur right
<andrewrk>
TheLemonMan, `var x: ?*T = &T{};` should result in a non-null x
<andrewrk>
regardless of @sizeOf(T)
<TheLemonMan>
that doesn't play that well with how ?*T is represented in memory as a zero-sized value has no address
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 258 seconds]
marijnfs_ has quit [Read error: Connection reset by peer]
<marijnfs>
alexnask: no I assign it to a member, wouldn't know where to put a consts
<alexnask>
Right I understand now.
<alexnask>
Basically a by value parameter is const, so you were passing self by value in serialize and couldnt call self.serializer.serialize
<alexnask>
The correct thing to do is only pass self by pointer in functions that will modify the state
<marijnfs>
alexnask: ok so I can use values, but can use the self: *Something in the functions
<alexnask>
Exactly
<alexnask>
You rarely want to return or store pointers (unless they are explicitly heap allocated or in some other rare cases)
<marijnfs>
and why was the StdSerializer on the stack previously?
<marijnfs>
Ok now because it's returned by value, llvm doesn't remove it?
<alexnask>
Well, you were intializing it like `.serializer = &StdSerializer.init(...)`
<alexnask>
This implicitly makes a StdSerializer variable on the stack and returns the address to it
<pixelherodev>
Unless you use an allocator, it's going to be on the stack
<pixelherodev>
And once you leave the scope in which the variable is created, it ceases to exist
<pixelherodev>
So you're storing the address of a variable that no longer exists
reductum has quit [Quit: WeeChat 2.7.1]
<marijnfs>
ah I see
<frett27_>
Hi, i can't find any efforts for coding antlr4 runtime for parsing ? any one know someone started somthing ? it's always more comfortable to join before starting a new effort
<frett27_>
any pointer ?
<BaroqueLarouche>
I haven't seen any
<marijnfs>
alexnask: I still have an issue with that code though. If I take your code and run it I still get a segfault:O
<alexnask>
I should have tested it let me see :p
<marijnfs>
haha
<marijnfs>
might be my pc who knows
<pixelherodev>
Doubtful
<pixelherodev>
The only two times I've seen segfaults were a) coding mistakes and b) OOM (on a laptop with 2GB of RAM) causing random crashes
<nrdmn>
the alignment of an extern struct should depend entirely on its first member, right?
<TheLemonMan>
the most aligned one
<alexnask>
marijnfs, Same issue really, just didnt catch it, let me correct the code
TheLemonMan has quit [Ping timeout: 240 seconds]
<marijnfs>
alexnask: maybe the var buffered_stream is local and gets removed?
<jaredmm>
"unable to evaluate constant expression"
<jaredmm>
What should that be translated as? It works if the return type is explicitly defined.
lunamn has joined #zig
ave_ has joined #zig
<jaredmm>
Maybe the correct question would be "is that intentional in translate-c or a bug"
<jaredmm>
#4328 marks it as a stage1 bug, but not a translate-c issue.
<jaredmm>
Based on what I read there, it sounds like that is the intended translation (along with some of the other suggestions I saw for how Zig code should be structured after translation).
return0e_ has quit [Ping timeout: 240 seconds]
return0e has joined #zig
euandreh has left #zig ["ERC (IRC client for Emacs 26.3)"]
tane has quit [Quit: Leaving]
TheLemonMan has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
LakeByTheWoods has joined #zig
<TheLemonMan>
andrewrk, #4614 is also ready for review
<Snektron>
frett27_: i realized that it can probably be done pretty neatly with Zig, but i haven't worked anything out besides that
<Snektron>
Would be nice to specify a grammer as a comptime string, and be able to generate a parser from that
<Snektron>
Definitely beats boost.spirit
<fengb>
jaredmm: file isn’t comptime so it can’t be passed around like a comptime var
<fengb>
It looks like a macro expansion gone too far
<fengb>
At comptime, the best you’d be able to do is @TypeOf(file) and pass that extracted type around
frett27_ has quit [Ping timeout: 256 seconds]
rjtobin has quit [Ping timeout: 265 seconds]
<fengb>
Oh I guess it’s marked as a bug so maybe it’s fixable
<metaleap>
Snektron: "Would be nice to specify a grammer as a comptime string, and be able to generate a parser from that" --- or even just a comptime structure. then you can express the parser for that "comptime string" also in it, and can have it both ways
<Snektron>
I wrote a small thing for Go like that when i was learning it
<Snektron>
it was basically a series of function (pointers), each representing a parse rule
<metaleap>
with a codegen at the receiving end i guess (written too many go codegens myself =)
<Snektron>
No it's really simple
<TheLemonMan>
andrewrk, is `noasync a.b().c()` supposed to be correctly parsed? right now it's rejected as that's a mix of SuffixOp and FnCallArguments
<Snektron>
a rule is a function, and combinators are functions that accept a rule and return another
<Snektron>
the rule itself is a function that accepts some parsing context and returns a bool, whether parsing was successful
<Snektron>
calling other rules happens through the context (which also has the parse functions like peek/consume). When a rule returns false, the input position gets restored
<metaleap>
ah like that, thought you were thinking in terms of "parser generator from <some_grammar_def>"
<Snektron>
i can't imagine it being very efficient
<Snektron>
but it works
<Snektron>
Well the grammar is essentially the combinators and rules
<metaleap>
yeah true
adamkowalski has quit [Quit: Lost terminal]
<LakeByTheWoods>
Anyone know what breakage #4569 (align-casts and grouping for c-casts) did on master?
<andrewrk>
TheLemonMan, hmmm. currently it's attached to a function call. But I think it may be better to behave more like `comptime` which takes an expression, and makes a new scope in which the expression is evaluated, and within that scope fn calls are assumed to be non-suspending
<Snektron>
The advantage of using structs to specify the grammer is that you can more easily traverse the structure of it. My go thingy was pretty much limited to LL(k), but with structs you can generate code from the grammar however you'd like
<andrewrk>
TheLemonMan, that's a language change that I just proposed just now, but I'm pretty sure it's a good idea. I'll open a formal proposal
<andrewrk>
that would answer your question because it would be parsed as `a.b().c()` being an expression in which all fn calls are noasync
<TheLemonMan>
yeah, that makes sense
<Snektron>
is there a quick way to jump to a github # or do you need to manually figure out if its an issue or a pr first?
<andrewrk>
how I do it: I've looked at literally every single issue and so it's all cached in firefox's address bar
<Snektron>
ah, thats how i look up Zig source
<andrewrk>
github redirects issues/prs to each other if you get the number right but the urls mixed up
<Snektron>
oh, i tried that but i missspelt issues
<Snektron>
that works good enough
<jaredmm>
Yeah, they're linked, so if you go to issues and it is a PR, it redirects you.
<jaredmm>
fengb: right, I wasn't sure what the direction to fix it should be.
<andrewrk>
TheLemonMan, I think you're correct on #4614, and the other code I was looking at is wrong
<andrewrk>
I must have added that reset_result() to ir_build_cast_result_loc and then missed deleting it at one or more callsites
<TheLemonMan>
that's to make sure the slot is really reset heh
alexnask has joined #zig
<andrewrk>
lol
<andrewrk>
spill_harder
<TheLemonMan>
hah, yeah like that
<alexnask>
Comptime regex's also would be pretty useful and fun to implement
<alexnask>
Like, compiling an efficient matcher based on a comptime matching string
_Vi has quit [Ping timeout: 272 seconds]
<alexnask>
Pretty sure D does this in their standard library
<andrewrk>
yeah it's a good use case. will require a more resource efficient, better-performing, robust implementation of zig
<TheLemonMan>
D hit a huge roadblock due to the inefficient CTFE
<alexnask>
Yes for sure
<andrewrk>
I think we should be able to accomplish CPython perf for CTFE in zig
<TheLemonMan>
the old one was an AST-walking engine, the new one is a faster bytecode-based one
<TheLemonMan>
the whole dmd compiler is really well-made
<alexnask>
Is the plan for stage2 to implement some kind of JIT or go ahead with a much more efficient interpeter?
<andrewrk>
not planning to do jit in stage2
<andrewrk>
some of the challenges we face are: guaranteed caching of functions when there are no comptime side effects (e.g. ArrayList(i32)), and code generation via constructs such as inline while
<TheLemonMan>
one suggestion for the stage2 is to "split" the compiler in several small passes, the current "monolithic" two-pass design has some limitations
<andrewrk>
I'll gladly take such suggestions. what would such smaller passes do?
<andrewrk>
btw the recent splitting into IrInstSrc and IrInstGen did open up the possibility of more passes even in stage1
<TheLemonMan>
you go from AST -> IR -> IR -> IR ... -> Codegen, right now we go straight from AST to IR and eg. we lose every info about the "structure" of a while construct as that's directly exploded into a scope + branches + instructions
<TheLemonMan>
with a multi-pass design we can perform several optimizations on a rich and typed AST
<pixelherodev>
JIT would definitely improve performance for comptime, but would *also* require *much much* more effort
<pixelherodev>
But whether or not a JIT is used shouldn't matter for anything besides maintainability and performance. Interpreters are simpler but slower, JITs are faster but more complex
<pixelherodev>
However, JITs also have startup overhead, so for most of the comptime code I've seen the performance improvement of a JIT vs a good interpreter would be negligible
<pixelherodev>
I'd definitely argue *against* using a JIT for comptime code; performance with a good interpreter is *good enough* and keeps the compiler *much* simpler
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
LakeByTheWoods has quit [Remote host closed the connection]
metaleap has quit [Quit: Leaving]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
alexnask, what do you think about the use case of the Allocator interface giving a comptime alignment parameter to implementors of shrink and realloc?
<alexnask>
I don't think it's possible to implement currently, correct me if I'm wrong
<andrewrk>
that's a use case I was considering when thinking about possible language features
<andrewrk>
about a possible language feature for interface
<alexnask>
I'm struggling to think about how such a design would work. If the implementation type does not know about the callsites of the virtual functions
<alexnask>
It may in principle error or generate incorrect code for some set of comptime parameters
<alexnask>
Unless we are not talking about runtime polymorphism anymore
<andrewrk>
I'm also thinking about inferred error sets for interface functions
<alexnask>
That would be nice. I guess if we are guaranteed to know about every implementation type at comptime
<alexnask>
It is possible to infer error sets and check the implementation functions
<andrewrk>
I believe we do have access to that information
<alexnask>
I guess one issue with such an approach is that the amount of function pointers in the vtable (or whatever mechanism is used for the dispatch) then becomes dependent on the combinations of comptime parameters at the callsites
<pixelherodev>
If every instance is comptime known, is any method of dispatch even needed?
<alexnask>
Also a language feature would probably need to provide enough control (e.g. allow you to combine a vtable pointer with any kind of storage of the implementation objects, not embed a vtable pointer in an object or force you to use non owning fat pointers)
<alexnask>
Otherwise people will just roll their own implementations