qbradley has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
tines9 has quit [Ping timeout: 240 seconds]
<hoppetosse>
How do I declare a null terminated array of null terminated strings?
<hoppetosse>
argv: [*:0] const [*:0]const u8
<hoppetosse>
fails with error: expected type '[*:0]const u8', found 'comptime_int'
<hoppetosse>
argv: [*]const ?[*:0]const u8 compiles, but then we take it that the first null value is the terminator by convention?
<fengb>
argv: [:null] const ?[:0]const u8
<fengb>
argv: [\*:null] const ?[\*:0]const u8
<fengb>
... I can't win against this formatter
<fengb>
argv: [*:null] const ?[*:0]const u8
frmdstryr has joined #zig
<hoppetosse>
fengb: thanks, makes sense
<cncl>
zig fmt doesn't have any configuration options, correct?
groovestomp-aaro has joined #zig
groovestomp-aaro has quit [Quit: Quit]
groovestomp-aaro has joined #zig
<Cadey>
cncl: it lets you disable coloring in the terminal
<cncl>
yeah :)
<cncl>
i'm a pretty heavy user of clang-format in C/C++ land. i usually set it up to format a file one way when i'm editing it, and then format it back to the project's standard when i'm done and making a commit. but i get the impression zig fmt is more like gofmt, where it only has 1 style and enforces it
daurnimator has quit [Ping timeout: 246 seconds]
<Cadey>
cncl: what setting are you looking for?
<cncl>
usually in C i will have block-opening braces on the next line. it's just a personal preference.
<cncl>
obviously that is not the zig standard style
mahmudov has quit [Remote host closed the connection]
<fengb>
There’s been quite a few breaking changes lately so that’s not unexpected
<cncl>
ah, ok
<fengb>
Yeah the big one in the past week is format functions / varargs
<cncl>
should i be learning with 0.5.0, or master?
nephele has joined #zig
<torque>
probably master
<cncl>
the error i got using master on that solution.zig file: /bin/lib/zig/std/fmt.zig:97:13: error: type 'u64' does not support field access
<cncl>
if (args.len > ArgSetType.bit_count) {
<cncl>
^
<mikdusan>
cncl: my guess - need to use new syntax. varargs is gone. look up stack see what is calling format or print and the varargs need to become something like .{ 1, 2, "hello" }
<torque>
yeah, that's due to the vararg removal
<torque>
yeah, almost certainly in the last line, something like `try out.print("{}\n", .{ sum })` should work
<cncl>
ok, thanks
muffindrake has quit [Ping timeout: 276 seconds]
muffindrake has joined #zig
<cncl>
that does indeed work!
frmdstryr has quit [Remote host closed the connection]
nephele has quit [Remote host closed the connection]
nephele has joined #zig
ur5us has quit [Ping timeout: 250 seconds]
marmotini_ has joined #zig
dddddd has quit [Remote host closed the connection]
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotin_ has joined #zig
marmotini_ has quit [Ping timeout: 250 seconds]
marmotin_ has quit [Remote host closed the connection]
knebulae has quit [Read error: Connection reset by peer]
xvilka has joined #zig
traviss has joined #zig
nephele has quit [Remote host closed the connection]
nephele has joined #zig
<cncl>
kind of an open ended question. how should i learn to accomplish things with the std lib? like if i want to read in a text file to a buffer and loop over the characters in memory, i don't know where i should start to figure out what to call.
<cncl>
like if i click on something, some of them open up to just a few entries. others are huge and look machine generated (like https://ziglang.org/documentation/master/std/#std;PackedIntArray )
<cncl>
also, the comment/description column ends abruptly if the string is too long, it seems, and there's no ellipses indicator that it was truncated
<cncl>
which makes reading it kind of confusing
<cncl>
since the clipping isn't occurring at a visual boundary, it's not obvious that it was truncated until you've read to the end of the text and the reading comprehension part of your brain has sat there for a few moments failing to parse the sentence
<Snektron>
<fengb "... I can't win against this for"> Try using ` ` to mark a snippet of code
groovestomp-aaro has quit [Ping timeout: 250 seconds]
<Snektron>
Neat, matrix inserts that reply in irc
frmdstryr has joined #zig
mahmudov has quit [Ping timeout: 240 seconds]
mahmudov has joined #zig
Snektron has quit [Ping timeout: 250 seconds]
dimenus|work has joined #zig
dimenus has quit [Killed (adams.freenode.net (Nickname regained by services))]
dimenus|work is now known as dimenus
Guest66640 has joined #zig
adamkowalski has joined #zig
scientes has quit [Ping timeout: 265 seconds]
benjif has quit [Quit: Leaving]
FireFox317 has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
return0e has quit [Ping timeout: 276 seconds]
return0e has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
lunamn has joined #zig
dimenus has quit [Ping timeout: 276 seconds]
marmotini_ has quit [Remote host closed the connection]
<adamkowalski>
is there an equivalent to a move in C++ here in Zig?
<adamkowalski>
Can you "transfer ownership" of a resource?
<fengb>
No, Zig doesn’t have ownership semantics
<adamkowalski>
Whats the appropriate way to think about the problem then?
<fengb>
There’s some patterns, like ArrayList.toOwnedSlice
<adamkowalski>
Does assigning x to y do a shallow copy? So in a sense x = y is the same as x = std::move(y)
<adamkowalski>
it will copy all the stack memory and make the pointers point to the same data as in y
<fengb>
Yeah
<mikdusan>
if you desire to tell the compiler a pointer is no longer valid, just assign "= defined" to it. this may in the future offer safe-builds with some extra smarts.
<mikdusan>
sorry i meant `= undefined;`
<mikdusan>
so you get 2 things from this today; it documents your code. and in safe-built I believe the pointer address becomes "0xaaaaaaaa" behind the scenes
<fengb>
It’s a shallow copy, but that doesn’t mean anything special to the compiler, unlike Rust or C++ RAII
marmotini_ has joined #zig
<adamkowalski>
What would you all say the advantage is of this model over RAII or lifetimes + Drop
<fengb>
Makes the language smaller
Snektron has joined #zig
<Snektron>
less complexity, and more flexible in some sense
<Snektron>
while raii is good for safety and structure
<Snektron>
less hidden functionality
lunamn has quit [Ping timeout: 246 seconds]
<adamkowalski>
can you elaborate on that? it sounds counter intuitive to me. maybe it's just because i'm really used to those systems
<fengb>
I sort of feel like Rust is RAII done “right” but I also can’t understand it
<Snektron>
It also integrated well across language boundaries
<Snektron>
Take Vulkan for example, or even OpenGL
<Snektron>
Many Vulkan objects have a create and destroy function
<Snektron>
most of these also take the device the functions work on, but don't store the device internally
<Snektron>
this meanst that you need to pass the device in every function, including the destructor
lunamn has joined #zig
<Snektron>
in the C++ headers and the rust bindings, this is either nasty (in which case you need to manually call the destructor to pass the device) or the device is stored internally without your consent, which makes it a more complex wrapper
<Snektron>
while in Zig, this can be implemented as `const image = vk.createImage(device, ...); defer vk.destroyImage(device, ...);`
<fengb>
90% of the time I’m managing lifetimes within scopes and defer does all of that with much less cognitive load. and most of the remaining cases I can attach to a context lifetime, so that’s solved by an arena of sorts
<adamkowalski>
Snektron: it sounds like you're not comparing against RAII though
<Snektron>
like i said, with RAII, this would require implicitly storing the device
<adamkowalski>
the create function would become a constructor, and the destroy function becomes a destructor
<Snektron>
in fact, this is exactly what the Vulkan-Hpp headers do
<adamkowalski>
and yeah you store context necessary for destruction in the struct itself
<adamkowalski>
then you define a move constructor, which in my eyes gives you more flexibility then defer
<adamkowalski>
because how do you handle the case in Zig where you don't necessarily want to destroy at the end of scope
<Snektron>
some Rust bindings (vulkano) even go as far as wrapping every Vulkan type into an atomic shared pointer
<adamkowalski>
you may want to give the resource to somebody else at the end instead
<Snektron>
which adds a lot of overhead
<Snektron>
adamkowalski, you simply dont write the defer
<Snektron>
you can also add errdefer, which is also very nice
<Snektron>
furthermore, defer accepts an expression
<Snektron>
so there is nothing stopping you from adding a condition
<fengb>
It’s still a proposal. We can’t have sound async cancellation without something new
<adamkowalski>
It's not pretty, you need to first say var graph = undefined
<adamkowalski>
then you need to call init with the allocator
<adamkowalski>
it seems like some really strange 2 phase initialization and I would like to get rid of it somehow
<fengb>
I personally think RAII is like switching the hammer in your toolbox for a sledge. Sure it works but it’s overkill most of the time
<Snektron>
adamkowalski, why dont you write init as a static function of Graph
<Snektron>
that is generally the preferred way in zig
<adamkowalski>
If you all can recommend something, or even just point me to some books, videos, anything that gets me into the right mindset coming from C++/Rust
<adamkowalski>
Can you give me an example?
<fengb>
Ctors/dtors were recently removed from Jai for similar reasons
<Snektron>
adamkowalski, its actually not too much different from Rust
<fengb>
I don’t remember if JBlow explained in detail
<Snektron>
Rust doesn't have constructors at all
<Snektron>
and drop is a hack
<companion_cube>
why is it a hack? what would replace it?
<Snektron>
in Rust you would write a static member to initialize
<Snektron>
in Zig you can do the same (just dont write the self)
<adamkowalski>
Yeah thats what I had a couple days ago
<adamkowalski>
The recommendation was to switch to this, since the tests were failing as the arena allocator was failing when trying to allocate
<Snektron>
You can sneak around it for the time being
<Snektron>
You can allocate the arena allocator using the parent allocator
<fengb>
The bug was copying an a pointer out of the stack, not because it was static
marmotini_ has quit [Remote host closed the connection]
<adamkowalski>
Snektron: isn't that what I'm doing? I just wrap whatever allcator you pass in so it should use it for the actual allocations? But the arena will allow me to ensure the entire graph has the same lifetime
<fengb>
Ah I see you’re emulating result location by providing the pointer
<adamkowalski>
fengb: I guess I'm confused because I would have assumed that the shallow copy would copy all pointers to the heap
<adamkowalski>
I'm not sure where I have a pointer to the stack
<adamkowalski>
The arena itself is on the stack, so it should get copied over when you return the struct
<adamkowalski>
but the memory that it's pointing to is on the heap
<fengb>
Doing &arena.allocator is probably a pointer to a stack variable
<fengb>
So it gets pointed to garbage when you return
<fengb>
Your current code “solves” it by providing a more fixed spot, but that’s probably another bug waiting to happen
<adamkowalski>
fengb: i'm all ears about how to approach it differently
<fengb>
I... can’t take that pastebin seriously
<Snektron>
heheh
<adamkowalski>
Yeah me too, I was really scared to go to that link, thank god for incognito
<fengb>
If you allocate the arena on the heap, that’s guaranteed to last the lifetime
<Snektron>
I once handed in an uni assignment using that
<adamkowalski>
okay yeah I see what you did there. but what is the performance cost of that?
<Snektron>
Not much
<adamkowalski>
and it seems strange to need to do that
<adamkowalski>
I feel like I should be able to just allocate the arena in the struct on the stack
<adamkowalski>
but allocate the struct not in the function call but just at the callers memory location
<adamkowalski>
just like in C++
<fengb>
But then you can’t use pointers
<adamkowalski>
so theres no way to do stack + arena without being able to talk about the result location
Akuli has joined #zig
<Snektron>
you can't do that in c++ either
<Snektron>
Not without some intricate move constructors
<fengb>
There’s no way to return pointers to stack memory safely
<adamkowalski>
I feel like you can
<adamkowalski>
well I wouldn't point to stack memory
<shakesoda>
that pastebin address lmao
<adamkowalski>
it would use named return value optimization
<fengb>
That’s still stack
<adamkowalski>
the graph would never have been allocated on the stack of the function
<fengb>
You’re just kicking the bug upward
<adamkowalski>
the graph and the arena would both have been allocated at the caller location
<adamkowalski>
then you're pointing to something allocated there not at the local function
<fengb>
Which is still in stack memory
<adamkowalski>
but I see what you're saying that if you now "move" the graph then you're gonna have the same bug
<adamkowalski>
so it seems like allocating the arena on the heap means the graph is really just a handle to some heap memory and then I can move all that around with ease
<adamkowalski>
okay awesome, i'm gonna implement that right after I get off work! thanks for the help
<adamkowalski>
now just one more hard one haha. Right now my graph is parameterized by some element type T, but I can't have that be the case anymore. I need to be able to store different kinds of tensors (nd arrays) inside of my graph
<Snektron>
allocate them on the heap as a slice
<adamkowalski>
for example you can add a float tensor with a int tensor by just converting to floats and returning that. Or maybe you want to have a bunch of u8 because you want to represent a string
<THFKA4>
adamkowalski: is this a general workflow framework, or are you trying to reimplement TF? just curious
<Snektron>
page and arena allocators are really fast
<fengb>
I wonder if having a vtable of sorts would make this more obvious. fieldParentPtr makes it too easy to have a hanging reference
<adamkowalski>
THFKA4: i'm stealing tensorflows API because I want it to be famaliar to Python data scientists at my job. But theres no reason you can't use it for general purpose compute graphs
<andrewrk>
I do think we can achieve debug mode safety for @fieldParentPtr
<adamkowalski>
you would still get many benefits, because i'm going to do a topological sort of the graph nodes based on the operation you want to evaluate
marmotini_ has joined #zig
<adamkowalski>
then we can understand the dependencies and schedule them to run in parallel
<adamkowalski>
or if you can give me a network topology you can schedule them on a clustor of nodes.
<THFKA4>
very cool. i can't stop seeing graphs everywhere, i bet it could come in handy in many places
<adamkowalski>
but thats down the road. step one is just get a compute graph working with basic reverse mode auto diff
<adamkowalski>
so it will be really specialized for the domain of machine learning
<Snektron>
i feel like every computer science related problem can be reduced to a graph problem
<adamkowalski>
hopefully you will feel that way about tensors instead when I finish here.
<adamkowalski>
tensors are just nd arrays. So scalars are 0d, vectors are 1d, matrices are 2d, cubes? are 3d, etc
<adamkowalski>
so an image is width x height x color channel
<fengb>
Well since all NP problems are the same and some are represented as graphs... they all can be. That’s how proofs work right?
<adamkowalski>
but it's 4d because usually we deal with "batches" of images so we can leverage the GPU more efficiently
<Snektron>
fengb, thats true
<adamkowalski>
and if you have a time axis (movies) then it's 5d space
<adamkowalski>
if you don't want to model just images, but 3d scenes you have a 6d space
<adamkowalski>
etc etc
<Snektron>
im not too much of a fan of machine learning
<Snektron>
i've been actively trying to avoid those classes in my master
<Snektron>
that and datascience
<adamkowalski>
I'm curious why?
<Snektron>
i just don't think its that interesting
<adamkowalski>
I think if you gave it a chance it can be an incredibly fascinating field
<fengb>
I thought that’s all of graduate programs nowadays >_>
<fengb>
All = data science or ML, not all = not that interesting
<adamkowalski>
Machine learning is not just neural networks. Those just get all the hype. We use a lot of statistical models, differential equations
<Snektron>
I feel like datascience is just writing a bunch of python and machine learning is throwing a bunch of matrices at a problem
<adamkowalski>
Snektron: yeah that is the bootcamp graduates haha
<fengb>
But this time it’s different! 🙃
<Snektron>
i did a few classes in my bachelor, it didnt impress me much
<adamkowalski>
We can't do that where I work
<adamkowalski>
We are trying to predict when different parts of an oil refinary will fail, and if we mess up you get an oil spill
<adamkowalski>
or worse if there is an explosion, people can die, a greusome death
<adamkowalski>
you need to build models which are "explainable" and that can provide models that can be verified by a domain expert that can agree with our work
<adamkowalski>
You mainly use matrices because they allow you to operate on lots of data in parallel
<Snektron>
im glad to hear you enjoy it
<adamkowalski>
Once I get farther along, you'll have to be my critic ;) i'll try and put some tutorials up and if they are boring to you then I failed
<adamkowalski>
What domain do you work in, if you don't mind me asking?
<fengb>
andrewrk: stupid question— would it be useful for a “relative” pointer? In this case it’s be nice if the allocator pointer was stored relatively to the parent struct
<Snektron>
adamkowalski, i'm not employed outside of being teaching assistent
<andrewrk>
fengb, I believe there is an open proposal for that. which pointer would be relative?
<fengb>
The array list allocator would be relative to the parent — i.e. Graph
<fengb>
I'm just making stuff up. I don't know anything about language design
<Snektron>
i don't think that would work well
<andrewrk>
I don't understand how it would work at all
<Snektron>
i suspect syntactic sugar over @fieldParentPointer
marmotini_ has quit [Remote host closed the connection]
<fengb>
Yeah me neither. nvm
<fengb>
It made more sense in my head
<andrewrk>
what we can do is a simple type id safety check after doing a @fieldParentPtr
<andrewrk>
"did we find the type we expected to find?"
<andrewrk>
same thing with @ptrCast for types with no well defined memory layout
<andrewrk>
which is most structs
<Snektron>
is that a thing?
<andrewrk>
not yet
<andrewrk>
but I think this will actually be a pretty straightforward safety feature to implement. it will be augmented by assigning undefined properly
<Snektron>
That would require extra storage per structure, right?
<andrewrk>
sometimes
<andrewrk>
it's also planned to annotate structs with the desire to optimize for space efficiency
<andrewrk>
which mostly will be useful in debug builds
adamkowalski has quit [Ping timeout: 265 seconds]
adamkowalski has joined #zig
<adamkowalski>
Snektron: I'm looking at the pastebin you sent me and I think there will be a leak right? The memory held by the arena will be freed but nobody frees the arena itself. So now do you have to hold a pointer to the parent allocator, and then during deinit clean up the arena?
darithorn has joined #zig
<bgiannan>
andrewrk, trying to figure out what's the minimal use case but i have weird bug where the semantic analysis is growing endlessly until i have no ram left
<Snektron>
adamkowalski, you're right
Guest66640 has quit [Read error: Connection reset by peer]
Guest66640 has joined #zig
<Snektron>
you can extract the allocator from it and free it with that i suppose
<andrewrk>
mikdusan, microsoft released a new version of azure or something and now you can see CI logs before the job completes
<andrewrk>
bgiannan, sounds like an annoying bug
leeward has joined #zig
<frmdstryr>
daurnimator: Requests/sec: 280974.43 was my max so far today
<frmdstryr>
with "wrk -t8 -c256 -d10"
<leeward>
I just noticed that errdefer blocks are silently ignored if they're unreachable (because the function's type doesn't have a !). Is that a known bug?
<adamkowalski>
andrewrk: I gotta give it to you, Zig is a beautiful language, both the core and the APIs.
<adamkowalski>
Working on this project (even though it's really new) has been really fun. And I feel like thats a big thing in maintaining motivation to keep working on something longer term
<pixelherodev>
Is it possible to use a target-specific calling convention from Zig?
<pixelherodev>
LLVM IR supports specifying `cc N`. N >= 64 is a target-specific calling convention
<Snektron>
pixelherodev, i think you need to implement that in the compiler
<adamkowalski>
fengb: that isn't a issue with the language though, you can clean up the API to make it simpler
<pixelherodev>
I mean since Zig already has e.g. `nakedcc`, I was wondering if Zig already supports e.g. `cc(N)`
<adamkowalski>
I think there is a difference between something fundamental about a language that you cannot change, and just an api that needs to be cleaned up
<Snektron>
That would tie Zig to llvm
<pixelherodev>
Snektron, no more than e.g. `nakedcc`
<andrewrk>
pixelherodev, more control over calling conventions is in scope but the abstractions LLVM gives us are not great
<Snektron>
not really
<andrewrk>
this is something I'd like to address, but don't really have the time or motivation to deal with it anytime soon
<Snektron>
nakedcc is perfectly defined in normal terms, cc(123) is just a magic constant
<pixelherodev>
How so?
<pixelherodev>
How is this any different from e.g. linksection?
<Snektron>
What does the 123 even mean
<pixelherodev>
Literally just the number 123
<pixelherodev>
`linksection(".bss") cc("1")` - or even `linksection(".bss") cc("nakedcc")`
<leeward>
fengb: There are several examples of that, where there's some generic-ish interface being implemented. It feels like the kind of problem that can be solved.
<Snektron>
How does 123 represent a calling convention
<andrewrk>
pixelherodev, I'm pretty sure 123 is meaningful only to llvm
<pixelherodev>
The calling convention name - 123, nakedcc, whatever - has no meaning to anything other than the backend
<pixelherodev>
Zig doesn't care, LLVM doesn't even really care
<andrewrk>
but imagine that you were trying to build that code with a gcc backend instead of llvm, how would that work?
<pixelherodev>
How would nakedcc work with GCC?
<andrewrk>
or even self-hosted for that matter. with self-hosted we could come up with a nice way to describe calling conventions, and have some powerful features. but with llvm/gcc backends we're limited to what they support and expose in the API
<andrewrk>
the gcc backend supports naked and it matches zig's semantics
<pixelherodev>
Right, I'm looking at that already...
<pixelherodev>
Yeah, okay; I can see why this specifically would be problematic
<pixelherodev>
Thanks
<andrewrk>
I think there are 2 related questions here and I got confused about which one pixelherodev was asking about. I do want to add support for more target specific calling conventions. they'll need meaningful names rather than numbers though. see https://github.com/ziglang/zig/issues/661
<andrewrk>
(2) is if zig code could define a calling convention in userland, and use that. that's an interesting use case that would be worth looking into, but may not ultimately be compatible with supporting non-self-hosted backends
<pixelherodev>
Right...
<pixelherodev>
Okay, real goal: the current ABI I'm working with has a rather... *unusual* CC
<pixelherodev>
The output of my parser can of course call *itself* without issue8
<pixelherodev>
issue*
<pixelherodev>
But to work with e.g. the firmware-provided function table requires a special calling convention
<pixelherodev>
I was thinking something like `cc(64)` in LLVM would be an easy enough fix
<pixelherodev>
But for now I'm doing all the shifting around *manually* in userspace Zig code
<pixelherodev>
(with a DragonFruit.Call function)
<Snektron>
I think that should be the preferred approach
<pixelherodev>
The problem is it's impossible to really optimize away, and is fully target dependent regardless
<Snektron>
Zig's inline assembly is made in such a way that you can do that pretty easily
<Snektron>
in contrary to C assembly, where you can't specify what register a value should go
<pixelherodev>
Uh
<pixelherodev>
You can do that in inline asm in C...
<pixelherodev>
Like, 99% sure
<pixelherodev>
Anything you can do in Zig's inline asm you can do in e.g. GCC/Clang
<pixelherodev>
I claim no credit for any of the low level code in there
<pixelherodev>
Rather, I accept no blame :P
<Snektron>
thats something else by the looks
<pixelherodev>
It's slightly different, but ultimately the same
<pixelherodev>
'a' there means the A register
<pixelherodev>
Since it's 8-bit, it expands to %al
<Snektron>
oh i see
<pixelherodev>
(for the first functions, inb/outb)
<Snektron>
at&t syntax gives me goosebumps
<pixelherodev>
Nd means "unsigned 8-bit integer constant in D register"
<pixelherodev>
Honestly, the fact that I have to try to understand this generated asm is a pain - not the one I linked, the custom calling convention one
<pixelherodev>
On its own, the CC isn't really bad
<pixelherodev>
It's interfacing with a Forthy language, so it uses a separate stack for data than for code
<Snektron>
One thing that could help with this is making assembly templates strings
<pixelherodev>
But it's basically doing this: load values from parameter into temporary, push temporary to that stack *using a function call*, call the function *using a different function call* because it's a pointer and that was the most convenient / readable way to define it in Zig
<Snektron>
then you could define a function calling foreign code with something like `const func = dragonfruitcc(fn(i32)void, 0xABC);`
<pixelherodev>
A table of FirmwareFuncs where a FirmwareFunc is a struct containing only an address in the form of an integer, and a function used to call that address
<pixelherodev>
^ is what I'm using now
<pixelherodev>
Ultimately it has the same effect, except it's a bit easier to read
<pixelherodev>
In Zig form that is
<pixelherodev>
e.g. `DragonFruit.push("Hello");API.Puts.call();`
<pixelherodev>
I was planning on building a higher abstraction over this, but for now I'm still so busy working on fixing up the backend that worrying over the Zig code just distracts me
<pixelherodev>
I mean, another option is to define dragonfruitcc as external
<pixelherodev>
Then have the backend provide it in the form of an intrinsic
<pixelherodev>
Then any calls to `@dragonfruit.cc` in the IR can be replaced with an inline call
<pixelherodev>
But again, this is still distracting me from the real work :(
<pixelherodev>
Unrelated question:
<pixelherodev>
There a way to override max_depth for e.g. std.debug.warn?
<pixelherodev>
I mean, I cheated and just modified the default in std/fmt.zig locally :P
<frmdstryr>
error: 'std.fs.file.OutStream.writeFn' cannot be async
<FireFox317>
<Snektron> One thing that could help with this is making assembly templates strings: I'm pretty sure daurnimator added that already
adamkowalski has quit [Quit: Lost terminal]
leeward has quit [Read error: Connection reset by peer]
odc has quit [Ping timeout: 276 seconds]
kristoff_it has joined #zig
<Snektron>
oh cool
<Snektron>
Zig evolves fast when you dont pay attention
odc has joined #zig
<fengb>
Move fast ; break things
vexu has joined #zig
Akuli has quit [Quit: Leaving]
squeek502_ has joined #zig
squeek_ has quit [Ping timeout: 276 seconds]
squeek_ has joined #zig
squeek502_ has quit [Ping timeout: 276 seconds]
FireFox317 has quit [Ping timeout: 265 seconds]
GrooveStomp has quit [Remote host closed the connection]