ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
jfo has joined #zig
jfo has quit [Ping timeout: 265 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 255 seconds]
hopppetosse has joined #zig
hoppetosse has quit [Ping timeout: 240 seconds]
jfo has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jfo has quit [Ping timeout: 276 seconds]
hopppetosse has quit [Ping timeout: 256 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 240 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 252 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 265 seconds]
izabera has joined #zig
<izabera>
zig looks cool :)
<andrewrk>
thanks izabera
jfo has joined #zig
jfo has quit [Ping timeout: 276 seconds]
cenomla has quit [Quit: cenomla]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 255 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 260 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 255 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 240 seconds]
jfo has joined #zig
Thalheim has joined #zig
jfo has quit [Ping timeout: 240 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 255 seconds]
davr0s has joined #zig
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 265 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 276 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 260 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 276 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 276 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 240 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 265 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 252 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 240 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jfo has quit [Ping timeout: 260 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 240 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 252 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 255 seconds]
jfo has joined #zig
davr0s has joined #zig
jfo has quit [Ping timeout: 260 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 252 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jjuran has quit [Remote host closed the connection]
<GitHub177>
zig/master 227ead5 Andrew Kelley: back to malloc instead of aligned_alloc for c_allocator...
vegard_ has joined #zig
vegard has quit [Ping timeout: 256 seconds]
vegard_ has quit [Ping timeout: 268 seconds]
vegard has joined #zig
ofelas has quit [Ping timeout: 240 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ofelas has joined #zig
davr0s has joined #zig
ragge has quit []
ragge has joined #zig
hoppetosse has joined #zig
vegard_ has joined #zig
vegard has quit [Ping timeout: 240 seconds]
vegard has joined #zig
vegard_ has quit [Ping timeout: 264 seconds]
Hejsil has joined #zig
hoppetosse has quit [Ping timeout: 256 seconds]
l1x has quit []
l1x has joined #zig
<Hejsil>
andrewrk, I think I got the gist of you and MajorLag_ discussion on deref from yesterday. Did you discuss just having [1]u8 be a pointer to one u8, and then having deref be `[0]ptr`? Aka, no special syntax for pointers to single values.
<Hejsil>
ptr[0]
<Hejsil>
*
hoppetosse has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
hasen_judy has quit [Remote host closed the connection]
<MajorLag_>
Hejsil, andrewrk brought it up. My thought was that it makes ptr look like a block when it isn't. Doesn't mean it might not be an acceptable solution though, since all of the ones proposed so far have issues.
<Hejsil>
Maybe keep `*ptr` to mean `ptr[0]`. Then the access doesn't look like block access
<Hejsil>
Though idk if we want
<Hejsil>
* for slices and all that
<Hejsil>
Hmmm
<Hejsil>
Ooh well, that was my 2 cents
<MajorLag_>
andrewrk: re: array syntax issue. What about using the `**` operator for this? var array: i32**4 = i32{0}**4; If we use a different deref operator than `*`, Then the operator could be extended to allow syntax like this without ambiguity (I think): const c = 4; var array: i32**4*c = i32(0)**4*c;
<MajorLag_>
Personally, I still lke my `.` operator idea, but I get that it is a bit strange coming from C tradition, and it would force 2 other operators to change.
<Hejsil>
My only real problem with `.`, is that it kinda just disappears in code. I can imagine missing it easily, if it is at the end of some large function
<MajorLag_>
Taht is also true.
<Hejsil>
Btw isn't const c = 4; var array: i32**4*c = i32(0)**4*c; ambiguous? If i32(0)**4 is an array of 4 0's. Then is i32**4 an array of 4 types or the type "array of 4 i32"
<Hejsil>
Or maybe he ment i32{0}**4
<Hejsil>
Because, then it is not
<MajorLag_>
What's wrong with `i32**4` meaning "an array of 4 i32s" and `i32(0)**4` being "an array of 4 0s (that are i32)"?
<Hejsil>
What if you want to have an array of types at comptime
<Hejsil>
does i32**4 give you [4]type{ i32, i32, i32, i32}
<Hejsil>
or [4]i32
<MajorLag_>
Ah, I see
<Hejsil>
But (i32**4){ 0 } ** 4 isn't ambiguous i think
<Hejsil>
I
<MajorLag_>
Ok, no, actually I don't see it. comptime var arrayOfTypes: type**4 = i32**4;
<Hejsil>
I'm kinda jumping between syntaxes
<Hejsil>
Ok, if i32(0)**4 is = [4]i32{ 0, 0, 0, 0}. i32(0) is the value, and 4 the size. Then wouldn't i32**4 be [4]type { i32, i32, i32, i32 }
<Hejsil>
Because i32 is the value and 4 is the size
<MajorLag_>
yes
<MajorLag_>
Ah, ok. Yeah, I see it now.
<Hejsil>
:)
<MajorLag_>
drat
<Hejsil>
Anyways, I don't mind the ** syntax for array types too
<Hejsil>
Because there are ways to avoid this ambiguity
<Hejsil>
Aka (i32**4){ 0 } ** 4
<Hejsil>
So <type>**<comptime_int> is an array type
<Hejsil>
and <array_lit>**<comptime_int> is array repetition.
<MajorLag_>
Yeah, that makes sense.
<MajorLag_>
currently <array_lit>**<comptime_int> doesn't work if <comptime_int> is an expression without (), but I don't see why not since operator precedence could make it unambiguous.
<Hejsil>
Ye, that should probably just work
<MajorLag_>
well, that assumes deref isn't prefix '*'
<Hejsil>
But then again, I would probably write u8**(4 * 1024) no matter what
<MajorLag_>
well yeah
<MajorLag_>
assuming you didn't hate whoever had to read it
<MajorLag_>
which in my case is usually me
<Hejsil>
Who knows :)
<Hejsil>
One thing to keep in mind is, that ** should probably evaluate from right to left
<Hejsil>
I actually don't know if it already does that
<Hejsil>
Hmmm
<MajorLag_>
Here's another thought for the pile: [*]T //ptr to block of unknown size; [*N]T //pointer to block of comptime known size; [5]T //array
<Hejsil>
Uuuh
<MajorLag_>
Falls down if N is an expression
<Hejsil>
Ooh ye
<Hejsil>
...
<Hejsil>
Looked good for a second there
<Hejsil>
Well. If we throw away * deref, then is there a problem?
<Hejsil>
Other than [*4*1025]u8 being a little weird
<MajorLag_>
maybe not. * is still used for multiplication, but since there's no value to the left it would be unambiguous?
<Hejsil>
No?
<MajorLag_>
It does look funny, but I don't think there's a way out of that for this problem.
<Hejsil>
I like the logic in this syntax though. [*] pointer to block. [*5] pointer to block of size 5. [5] block of size 5
Hejsil has quit [Quit: Page closed]
Hejsil has joined #zig
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 252 seconds]
<andrewrk>
That's pretty good
<MajorLag_>
Would this be valid? [N]null T;
<andrewrk>
no
<andrewrk>
I spoke too soon. I am just now understanding the implications of this question
<andrewrk>
a related question is, what is the type of string literals
<Hejsil>
[N]const u8?
<Hejsil>
As it's probably global data?
<Hejsil>
Or...
<Hejsil>
Hmm
<Hejsil>
If that's the case. Then the user is required to mem.copy onto the stack to modify the literal
<andrewrk>
that's currently true today and it is true in C
<andrewrk>
I think string literals should be [*N]null const u8
<Hejsil>
Ooh, you can't do this today? var str: [1]u8 = "1";?
<andrewrk>
Hejsil, ah, you can in fact do that
<andrewrk>
and check this out, that type - [*N]null const u8 - would implicitly cast to [*]null const u8
<andrewrk>
so we wouldn't need c"string literals"
<andrewrk>
normal zig string literals could be passed to C functions
<Hejsil>
That's pretty convenient
<MajorLag_>
So that would mean all Zig string literals are null terminated?
<andrewrk>
yeah that's the idea
<andrewrk>
so you get both - knowledge of the length and null termination. if you slice a string, though, the null termination is removed from the type
<andrewrk>
and most functions should still accept normal slices - not force the caller to pass a null terminated slice
<Hejsil>
Ye, null terminated stuff is only for calling C
<MajorLag_>
Well, what I'm wondering is if I say: const string = "Text"; then string.len is 5?
<andrewrk>
hmm I think the string literal type needs to be an array literal though - we can't just make it be a pointer
<andrewrk>
no the len would not include the null
<andrewrk>
"null" as part of the type system would mean "the length is short by 1"
<Hejsil>
I would assume accessing the null terminator would assert? At least for anything that isn't [*]null
<Hejsil>
Out of bounds I mean
<andrewrk>
yeah out ouf bounds would work the same way
<MajorLag_>
I feel like some naive copy using .len would remove the null and that would be a problem if the result was passed to C.
<andrewrk>
the naive copy would use the normal types without the "null" in the type, and the C function prototypes would have the "null" in the type, so there would be a type mismatch
<andrewrk>
e.g. extern fn puts(text: [*]null const u8) void;
<andrewrk>
if you try to pass a [*]const u8 to that, you get a compile error
<andrewrk>
this is the main point of having a pointer type that understands it should be null terminated
<MajorLag_>
yes, that should allow it to be caught. Then my only remaining thought is that it means I have extra bytes in my binary which might be a concern on embedded, but that's pretty edge-case and there are ways around it I guess.
<andrewrk>
you mean all the string literals that don't get passed to C?
<MajorLag_>
Yeah, very edge case
<MajorLag_>
Like, if you wrote a pure Zig OS for something.
<andrewrk>
if you do please make all the syscalls accept lengths with strings :)
<Hejsil>
Would [N]null cast to [N] (casting between array types)? For code like this: var a: [1]u8 = "1";
<Hejsil>
If they did, then you could probably avoid the null terminator if you stored all your strings in your program this way
<andrewrk>
I don't want people to have to worry about whether or not they're saving a null terminator byte
<andrewrk>
these are the kinds of things I want to be non-issues
<andrewrk>
so that people can not be distracted from the actual problems they're trying to solve
<MajorLag_>
I dunno. I guess I just like the explicit difference as a matter of personal preference.
<Hejsil>
Did we even reach a conclusion on deref *? Seems like we embrace [*N] with open arms :)
<andrewrk>
MajorLag_, explicit diference of what?
<MajorLag_>
c"" vs ""
<andrewrk>
ahh
<andrewrk>
yeah maybe we can keep that
<MajorLag_>
it is admittedly bikeshedding as far as I can tell.
<andrewrk>
Hejsil, [*N] lets us keep existing array syntax right? but we still have the deref problem to solve
<GitHub27>
zig/master b4e44c4 Andrew Kelley: self hosted parser tests every combination of memory allocation failure
<andrewrk>
^ example of the arena allocator being useful
SimonNa has quit [Remote host closed the connection]
SimonNa has joined #zig
dd3 has joined #zig
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 276 seconds]
skyfex has quit [Quit: Page closed]
<andrewrk>
Hejsil, just saw your build.zig TODO
<Hejsil>
Well, it seems things changed in Zig at some point, because I can now run tests with the newest Zig build
<Hejsil>
Though non of my test code uses the "crc" package
<andrewrk>
I'll add a test to zig's test suite to ensure it continues working
<Hejsil>
I assume all the windows goodies comming with llvm6 will also allow profiling on windows?
<andrewrk>
Hejsil, I think so! what profiling tools?
<andrewrk>
msvc?
<Hejsil>
Well anything that works lol
<andrewrk>
the problem that is fixed with llvm6 is proper debug info
<Hejsil>
Kinda have to figure out why writing nds roms back to disk is really slow on windows after my latest PR :)
<andrewrk>
it slowed down recently?
<andrewrk>
Hejsil, the llvm6 branch does work if you build llvm6.0.0rc2 on windows (instructions in the wiki)
<andrewrk>
I just tested it this morning
<Hejsil>
Well, I'm now reading file systems inside files systems (Nitro and NARC in the nds rom), and my writing functions does alot of seekTo then write
<Hejsil>
Which I think is probably the bottleneck
<Hejsil>
But wonna be sure
<Hejsil>
I'll test the llvm6 branch tomorrow
<andrewrk>
you're seeking and writing, and not writing an entirely new file?
<Hejsil>
I am, but nds roms are structured weird. I have to write some tables that knows the offsets of the file in the nds rom
<Hejsil>
But I could probably just have these tables in memory until I've written all files, and then write the tables
<andrewrk>
one thing to watch out for, std.io.OutStream is not buffered
<Hejsil>
Which will remove most of the file seeking
<Hejsil>
Oooh
<andrewrk>
you can wrap it in a std.io.BufferedOutStream
<Hejsil>
I still need to eliminate alot of the seekTo's though :)
<andrewrk>
yeah be careful using buffered out stream with seeking
<andrewrk>
you'd want to flush before seeking every time
<Hejsil>
Ye, I can imagine
<Hejsil>
I wonna make the nds loading and writing code simpler anyways
<Hejsil>
Maybe even eliminate recursion
<andrewrk>
my favorite hobby
<andrewrk>
recursion is super useful... and harmful to static analysis
<Hejsil>
Indeed, and those stack overflows too
<andrewrk>
someday we're gonna have a feature to opt in to having the compiler determine maximum stack upper bound
<andrewrk>
and then we'll even put on our sunglasses and tell the linker, "I only need 80 KB."
<Hejsil>
And be able to spawn tasks/coroutines
<andrewrk>
yeah that's a huge win
<andrewrk>
I learned more about coroutines though, and I don't think you have to create a stack for them. they share the stack of the caller
<Hejsil>
How does that work?
<andrewrk>
you allocate heap memory for the stack frame and registers of the coroutine you're calling. this memory is called the coroutine frame. when the coro suspends it saves that information in the coro frame, and the current stack frame and registers are replaced with a different one's coro frame
Jezza has quit [Quit: Leaving]
Ichorio has joined #zig
<andrewrk>
the coroutine can only suspend in its own frame, so for example if it calls a function, that function has to return before the coro can suspend
<andrewrk>
there's kind of a secret component to making coroutines useful, which is a userland scheduler, which would create all the coroutines, and then when one suspends, decide which one to resume
hasen_judy has joined #zig
<Hejsil>
And then it's the schedulers job to spread these coroutines over a number of threads then if some parallelism is wanted?
<andrewrk>
yes
<Hejsil>
Make sense. And Zig would ofc allow for different user level schedulers, like allocators :)
<andrewrk>
of course :)
<Hejsil>
Nice
hasen_judy has quit [Ping timeout: 252 seconds]
<andrewrk>
there's a problem to solve regarding what it will look like to call a coroutine
<andrewrk>
currently the semantics of LLVM coroutines are: inside the coroutine, you ask how many bytes it needs. then you have to somehow allocate that memory.
<andrewrk>
currently zig language has no dependencies on the standard library and it does not define any error codes
<andrewrk>
to maintain this we'd have to have something like this: @coroCall(context: var, alloc: fn(context: var, byte_count: usize)?[]u8, args: ...) ?CoroHandle
<andrewrk>
I think this is an llvm limitation though. it would be way better if we could ask the coro size from outside
<andrewrk>
then it could be: const need_bytes = @coroFrameSize(coro_fn); const bytes = try allocator.alloc(u8, need_bytes); const handle = @coroCreate(coro_fn, bytes, args...);
hoppetosse has quit [Ping timeout: 252 seconds]
<Hejsil>
Aaah, so the size of the frame is only available from inside coro, and it requires a callback to allocate memory
<andrewrk>
yeah. this is so important I think I might submit a patch to LLVM
hoppetosse has joined #zig
Hejsil has quit [Read error: Connection reset by peer]
cenomla has joined #zig
MajorLag_ has joined #zig
t4nkf33der has joined #zig
dd3 has quit [Ping timeout: 240 seconds]
<andrewrk>
I just glanced through the code, it looks to be fundamentally possible. so it's just a matter of doing the work and convincing LLVM to accept it