<andrewrk>
it's also proposed to allow overriding the default test runner. that seems like a reasonable proposal
protty has joined #zig
<protty>
do variadic arguments use a different syntax on master? Getting an error similar to `expected type "ArgumentType" found (args)`
<andrewrk>
variadic arguments haven't been messed with in a while. but we're close to being able to delete them
<pixelherodev>
Oh noes - more changes!
<pixelherodev>
:P
<andrewrk>
they way I see it, there are a fixed number of breakages in zig's future. we can choose where to put them. and putting them all as soon as possible is the least pain
protty has quit [Remote host closed the connection]
<mikdusan>
andrewrk: re: arena for stage1. arena needs needs an allocator capable of accepting alignment param, and while some libc have it, I'm not sure it's that portable,
<mikdusan>
do you think it's also worthwhile to implement a PageAllocator and have stage1's arena make use of that? there will be some porting friction but I don't think too much
<mikdusan>
(well I'm not entirely sure arena needs an aligning allocator...)
<andrewrk>
mikdusan, we don't need alignment higher than malloc provides in stage1
<mikdusan>
good to know thanks
<andrewrk>
one good use for an arena will be all the pass 2 stuff that we can't free for a long time - but we can free it all right before the call to LLVMEmitMachineCode
<andrewrk>
and that will save on peak RAM usage, because LLVM will use memory
<andrewrk>
btw, it's looking like I'll be able to merge #3787 within the hour
<andrewrk>
this will add all those advanced debugging tools if you want to give them a shot
<daurnimator>
mikdusan: we can always provide a fallback for posix_memalign....
<andrewrk>
daurnimator, this is about an arena allocator in C in stage1
<andrewrk>
we can't use the hybrid strategy for this use case because the plan is to have zig0 build self-hosted, which means we want to cap the peak RAM usage of zig0 to a reasonable number, for bootstrapping purposes
<mikdusan>
I was thinking of setting up several global allocators. one general which is basically malloc, then a general arena which is free'd after every zig command-line cycle (there is only 1 right now, but maybe we can use that to run multiple consecutive compiler-error tests and such), and then well-defined lifetime arenas that code picks to use as appropriate. lofty goals I know :)
lunamn has quit [Quit: leaving]
<mikdusan>
I'll put in effort to maintain "everything is zero-filled" unless an explicit fn name with _nonzero is used (like today)
<mikdusan>
for interface
OmegaDoug has joined #zig
OmegaDoug has quit [Remote host closed the connection]
<andrewrk>
#3787 chops another 257 MiB off of peak RAM for std lib tests binary
<marler8997>
got a question for you andrew...
<marler8997>
when converting the type_info to the type
<marler8997>
we implicitly cast the comptime const value to a TypeInfo
<andrewrk>
btw marler8997 #3787 has some code that messes with that, you might take a peek
<marler8997>
but I don't think we're able to represent the sentinel type correctly
<mikdusan>
👍
<marler8997>
so when we cast it, it doesn't resolve the sentinel value correctly
<marler8997>
so we're left with a ZigValue that's not necessarily the right type
<andrewrk>
this sounds familiar, like something I had to solve in this branch
<marler8997>
but we also don't have an IrInstruction in order to cast it to the correct type
<marler8997>
should I create a temporary instruction to perform the cast?
<andrewrk>
we do have an IrInstruction
<andrewrk>
the code for type info incorrectly throws it away too early
<marler8997>
right
<andrewrk>
trace the call stack back, you'll find it
<marler8997>
so I should try to reach into the IrInstruction for type info for the sentinel value
<marler8997>
I can't just use ir_implicit_cast to convert the whole IrInstruction of TypeInfo to a ZigValue...I need to handle the sentinel field special, does that sound correct?
<mikdusan>
unrelated: boy has zig has spoiled me. here I jumped into C++ thinking it supported function aliases like it does type aliases. nope! I can do it but the new symbol is then handled by linker
<andrewrk>
from there you can get the sentinel field as an IrInstruction
<marler8997>
I see, you've modified it to evaluate each field individually
<marler8997>
I'll wait for this PR to be merged before completing mine
<marler8997>
You're PR fixes tests that my PR adds, so I'll have to wait for it
<marler8997>
I don't know if you say earlier, but I figured out the linker issue
<marler8997>
But it brought up another issue, that fatal error messages in lld don't get printed to stdout
<marler8997>
or stderr
adamkowalski has joined #zig
<marler8997>
to fix issue 3816 we'll need to encode the correct type for the sentinel value (rather than using `var`)
<daurnimator>
andrewrk: expecting to merge 3787 today?
adamkowalski has quit [Quit: Lost terminal]
muffindrake has quit [Ping timeout: 245 seconds]
muffindrake has joined #zig
<mikdusan>
std.heap.HeapAllocator tells me windows has private heaps, and macOS has malloc zones, does linux (glibc or musl) have anything comparable?
<daurnimator>
mikdusan: man mallopt
<mikdusan>
daurnimator: those are some great options for linux default heap, but I'm looking for something like arbitrary private heaps that can be created/destroyed all at once like zig's ArenaAllocator
<mikdusan>
(this is me being lazy for stage1... choice is to implement ArenaAllocator or just wrap an OS-functionally-equivalent one
<andrewrk>
damn, we have a flaky test failure in master branch windows
<mikdusan>
#3787 ?
<andrewrk>
I think it's master branch
<andrewrk>
3787 passed locally for me
<mikdusan>
I'll launch a local windows master build/test
<andrewrk>
mikdusan, ok let me know, I was about to press the merge button
<andrewrk>
especially since it is progress towards a smaller memory footprint, which is significant progress towards eliminating our hypothesis for the *other* cause of flakiness
<mikdusan>
github master is unclear which test is flakey, any test I should fast-track? #3787 seems to point at behaviour tests
<andrewrk>
I locally observed cross compiling x86_64-linux-gnu -lc behavior test failing on windows, but 10x times after that all succeeded
<andrewrk>
here you go everybody, you'll need these: &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
<daurnimator>
andrewrk: now PR reviews? :)
<andrewrk>
yes
<andrewrk>
`time -v ./zig test ../lib/std/std.zig --cache off --release-safe` on master branch, on x86_64-linux-gnu, reports 4.2 GiB peak resident memory
ky0ko has quit [Remote host closed the connection]
<mikdusan>
(fyi) on macOS "gtime" is macports package name for linux `time -v ...` tool
ky0ko has joined #zig
ky0ko has quit [Remote host closed the connection]
casaca has quit [Ping timeout: 265 seconds]
ky0ko has joined #zig
<mikdusan>
0.5.0+fecd54082 passes all tests for me: macOS, linux, windows
mahmudov has joined #zig
THFKA4 has quit [Ping timeout: 246 seconds]
LargeEpsilon has joined #zig
LargeEpsilon has quit [Read error: Connection reset by peer]
ky0ko has quit [Ping timeout: 246 seconds]
return0e has joined #zig
return0e_ has quit [Ping timeout: 250 seconds]
FireFox317 has joined #zig
FireFox317 has quit [Remote host closed the connection]
<daurnimator>
just finished advent of code for the day
<daurnimator>
I got a really weird traceback at one point
<mq32>
btw, andrewrk: thanks for allowing as "comma" after the last parameter in function calls. This is quite cool, especially the way it is used in zig fmt to format function calls single-line or multi-line
<mq32>
andrewrk: looks like there's a "-" missing in the tar call
<andrewrk>
nah that's not it
<mq32>
huh. the xz is outputting info, right
<adamkowalski>
andrewrk: You all should advertise the compile time reflection/introspection way more. You just have one section on it, and yet it's arguably one of the most amazing features of Zig. I've never seen any other language have that besides D
<andrewrk>
alright fixed, download page updated
<adamkowalski>
And the first class types, those are too powerfull to be so subtle in the docs haha
<andrewrk>
adamkowalski, fair enough :)
<adamkowalski>
I think it would be good marketing to write up some blog posts showing how people typically approach problems with template meta programming, and then we can highlight that it's essentially a second programming language embedded in the host (C++, D, etc)
<adamkowalski>
Then you can say that it would be really nice to just regular functions to manipulate types, and you can have a single set of libraries/functions that can apply to both
<mq32>
does someone know how to deploy files with Github Actions safely? I have no experience with CI and i wonder how i could upload a "master branch build" of a project to my website without exposing any credentials in the github repo
casaca has joined #zig
<andrewrk>
mq32, generally the way this works is you upload "secrets" to the CI server. the secrets are only available to CI scripts for branches, not available for pull requests
<adamkowalski>
you can pull them in from environment variables, then in your repo all people see is that you're reading form the env
<mq32>
ah!
<mq32>
have to look that up
adamkowalski has quit [Quit: Lost terminal]
adamkowalski has joined #zig
<adamkowalski>
andrewrk: I cloned the zig master branch and tried building it locally today, and while it successfully built I got a bunch of warnings https://pastebin.com/THy4ugDD
<adamkowalski>
It seems like the core issue is: This was likely caused by different translation units being compiled with different visibility settings.
<adamkowalski>
[100%] Built target zig
<adamkowalski>
I'm running macos catalina, with the version of llvm you wanted from brew. If I actually use llvm clang v 10 then it fails to compile entirely
<Snektron>
Does zig have a guaranteed execution order of expressions
<Snektron>
?
<scientes>
Snektron, it has an order of operations, yes
<scientes>
and also "and" and "or" have short-circuiting
<scientes>
it is also procedural
<scientes>
so yes, different expression happen *as if* they are sequential
<scientes>
but there is no guarantees against side-channel attacks
<scientes>
caused by out-of-order executing
<scientes>
llvm will probably add timing attack barriers at some point
<scientes>
and I don't know in what order, but I believe it is well defined
<scientes>
if you want to call fetchInc() once you have to use a tmp variable
<scientes>
but then there is of course no point, as you are assigning something to itsself
ManDeJan has quit [Ping timeout: 252 seconds]
<andrewrk>
Snektron, yes
<andrewrk>
generally, outer to inner, left to right
nooga has quit [Quit: Lost terminal]
adamkowalski has quit [Quit: Lost terminal]
<Snektron>
alright, thanks
<Snektron>
thats a step up from `a[++b] = a[b++ + ++b] + a[b];` which is so undefined it might as well make your computer explode
<Snektron>
I also joined the zig aoc btw
<mq32>
cool
CatButts has joined #zig
<mq32>
i started another zig project this morning...
* mq32
should stop forking his workforce into uncountable projects
<mq32>
but maybe someone wants to help, the idea is to create a zig-style SDL2 wrapper
<Snektron>
I wanted to do that for the Vulkan headers
<Snektron>
but uni ate my time
<mq32>
oh, nice
<Snektron>
ill do it in christmas break™
<andrewrk>
mq32, is that a distinct project from https://github.com/andrewrk/zig-sdl ? idea being to package up sdl2 with a build.zig so that it can be a zig package
<mq32>
andrewrk: yes, it is
<andrewrk>
nice
<mq32>
it's not "build sdl2 with zig", but "wrap SDL2 into a zig-style API"
<andrewrk>
makes sense
<mq32>
i can push an example to github :D
<Snektron>
My idea was to provide a generator (instead of just the translated headers) as a build-time dependency
<Snektron>
that way there is less maintainance cost (since most other such vulkan bindings are usually a few months behind the standard)
<mq32>
yeah, i had this idea as well, but a lot of stuff translates bad
<andrewrk>
I think someone here might have started that project, vulkan zig bindings from the xml
<mq32>
anonymous structs are really a nice addition to the language
<mq32>
i also just had a great idea on the use of mixins for an OpenGL wrapper
<Snektron>
andrewrk, so it seems, but according to the irc logs that was like a year ago
<Snektron>
and i didn't find any code
<dimenus|work>
i'm working on vulkan with zig, but i don't have an automatic binding generator
<dimenus|work>
i'm using translate-c for now
<Snektron>
yeah, i think thats doable now, but with a few changes zig and vulkan go pretty well together
<Snektron>
for example using default values for structure types
<dimenus|work>
i've been manually adding those so far
<dimenus|work>
it definitely makes things easier though
<Snektron>
i also had some other ideas
<Snektron>
one was the obvious vkResult => error translation, i think thats justifyable
CatButts has left #zig ["Here is my journey's end, here is my butt."]
<Snektron>
one might argue that these aren't all errors, but i believe that any VkResult that is not VK_SUCCESS would probably needs to be handled anyway
<Snektron>
to minimize impact of such opinions it might be best to divide it into the raw bindings and the "wrapped" bindings
<mq32>
Snektron: this example may also be of use for your wrapper layer
<mq32>
provide a root var with the API level on the version/extensions your wrapper should provide
<Snektron>
I'm still thinking about how i want to tackle that
<Snektron>
Since with Vulkan, its more idiomatic to load function points of extensions you want to use
<Snektron>
futhermore, function points of Device functions might differ depending on the Device (if youre using both an Nvidia and AMD GPU for example, if you even get that to work in the first place)
<Snektron>
The vulkan static library just provides an abstraction over this and internally keeps the loaded function pointer table for the instance and the device, but that introduces an overhead
<Snektron>
Not a large one, but i don't think its a valid solution to just discard that usage
<Snektron>
btw, mq32: I always find it hard to build an abstraction over opengl calls. Take for example how you upload data to a buffer (in pre-4.3 opengl): you bind a buffer to a specific register, then you upload data to whatever is bound to that register
<mq32>
Snektron: yeah this really sucked pre opengl-4.5
<mq32>
but i mostly use the GL_ARB_direct_state_access
<mq32>
that is a pure object oriented API
<Snektron>
(I wouldn't call it object oriented)
<mq32>
why?
<mq32>
i have objects i create with glCreateXXX and destroy them with glDeleteXXX
<mq32>
and i have member functions like glGetTextureParameterI or glNamedBufferSubData
<mq32>
pretty perfect information hiding, near-zero free functions (pretty much some global binds and the draw calls)
<Snektron>
but that introduces the problem that not every device has that extension (even in this day and age), so you severely limit your target audience. Not that i care when i'm making an OpenGL application, but i don't think thats viable as general OpenGL library.
qbradley has joined #zig
<Snektron>
mp32: object oriented isn't just member-based access of properties
<Snektron>
I think the most important distinction is inheritance
<mq32>
hm
<mq32>
for me that's a part of class based object orientation
<mq32>
also: OpenGL also has inheritance:
<mq32>
Texture2D and Texture3D share a lot of functions, but have their own SubData-function
<DutchGh0st>
today zig hit 16 gigs of ram when I did day 2 using comptime, oopsy
<andrewrk>
goodness
<andrewrk>
yes, the plan is to use a different resource management strategy for self-hosted. maybe we will end up backporting it to stage1
<DutchGh0st>
Now, maybe it was partially my fault for not providing a super fast impl hahaha, but then I decided I should just be a sane human and use ArrayLists and some allocation
<DutchGh0st>
I btw like `usingnamespace @import("std");`! its neat and clean
<fengb>
do not like :(
dimenus has quit [Read error: Connection reset by peer]
<DutchGh0st>
whats wrong with it?
dimenus has joined #zig
<Snektron>
redefinition errors
<fengb>
Pollutes the current namespace with a lot of stuff
<Snektron>
i just used a "large enough" buffer for day 2
<fengb>
... I wrote my own "readUntilDelimiterOrEof"
<fengb>
I think I need to familiarize myself with std more :P
<DutchGh0st>
I just use @embedFile
<andrewrk>
we need InStream.scan which takes a regex like format string and arbitrary number of arguments with pointers to where to put the values
<andrewrk>
this would avoid the "how much do I need to buffer" problem
<andrewrk>
DutchGh0st, yeah I think that's fair game for Advent of Code. using stdin is only if you want that additional exercise of making it a streaming solution
<DutchGh0st>
when I did the comptime thing, I first calculated trough a function how many "," 's where in the input, and then just set the bufferlength to that, so I could setup an uninitialized array with that length during comptime
<DutchGh0st>
but it felt like doing double work, as I now iterated twice over the initial input
<Snektron>
andrewrk, an idea like this could also be interesting:
<andrewrk>
oops, the int one was supposed to be given a pointer to capture the result
<Snektron>
i would rather argue for functions which describe the items to parse
<andrewrk>
Snektron, then you have the buffer size calculation problem
<Snektron>
how so? these functions could be comptime
<andrewrk>
fengb, if the alignment is less than page size, then there's nothing to do. for alignments larger than that, you can either yeah allocate enough pages that the alignment is guaranteed to be in there, or you can return error.OutOfMemory
<andrewrk>
since wasm pages are 64K I think returning OutOfMemory for alignments greater than page size would be quite reasonable
<fengb>
Okay, I'm trying to figure out the large allocations, thanks
<fengb>
Ah sure that's fine too. Not passing the tests but that'll be okay
<andrewrk>
might even be reasonable to define PageAllocator to return OutOfMemory when requested alignment is greater than page alignment
<fengb>
Large alignment tests*
<andrewrk>
it would be reasonable to say, this is what PageAllocator does, if you want more alignment, wrap it
<fengb>
Page alignment only. Makes sense 👍️
<andrewrk>
also I do think it is worth figuring out how to get our interfaces to be able to have comptime parameters, specifically with regards to alignment
<andrewrk>
that would allow PageAllocator to give a compile error if you asked for greater than page alignment
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
<andrewrk>
and reduce our malloc/free wrapper to zero cost
<DutchGh0st>
interfaces?
<andrewrk>
examples: Allocator, InStream, Random
<Snektron>
I think that mixin idea was pretty good, though i do feel like its somehow abusing usingnamespace
<fengb>
After fiddling with streams more, I agree it cleans stuff up. But I've never really liked mixins in general
<fengb>
Too easily abused
<Snektron>
General mixins is just an excude for multiple inheritance
<Snektron>
excuse
lunamn has joined #zig
<Snektron>
but its definitely a step up from just using a vtable everywhere
clktmr has joined #zig
<tgschultz>
except iirc the mixins are comptime-only in this case unlike a vtable
<Snektron>
i was referring to the existing solution of Random, Stream and Allocator interfaces
<andrewrk>
the existing solution allows non-comptime-only
<tgschultz>
same diff. The mixin-syle I saw only worked if the implementation was comptime-known.
<Snektron>
But the non-comptime version isn't always the most ergonomic
<Snektron>
its seems out of place to have that vtable for Random for example
<DutchGh0st>
Im sorry to ask, but whats a mixin?
<Snektron>
Are you familiar with traits?
ky0ko has joined #zig
<Snektron>
theyre kinda familiar
<DutchGh0st>
I am
<Snektron>
but basically, your implement some methods on your type and ask the mixin to provide the rest, based on those first methods