<andrewrk>
but you could build the assumption into your documented API. "Using this function asserts that the host operating system supports timers"
<protty>
hmm, alrighty. Have a worst-case work around in mind
<andrewrk>
I believe it is extremely rare for this case to happen, so if you had some simple degenerate handling of this case that had horrible perf, that would be OK IMO
<andrewrk>
"why is my perf crap?" -> "my OS does not support timers" -> this is a reasonable debugging experience
<andrewrk>
I'd also expect most applications that need this functionality to exit with an error message pretty close to main() if this functionality does not exist
adamkowalski has quit [Quit: Lost terminal]
<protty>
the TODO comment in `std.time.timestamp` is a bit hazy too. Could I assume that wouldn't fail either? If not, am not entirely sure how to tackle this without a timer... busy loop maybe?
bjorob has quit [Ping timeout: 240 seconds]
lunamn_ has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
quetzalb has quit [Ping timeout: 260 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
protty, throw a catch unreachable there for now, and open an issue to solve this design problem later
<protty>
will do
\u is now known as meowray
ur5us has joined #zig
<daurnimator>
andrewrk: saw your Dir.open commit: FYI there are a couple of things in #3715 you might want
<daurnimator>
also I'm not sure what happended with CI on #3715... the jobs just say "cancelled"; and not who by or why
<gruebite>
for casting ints, is @intCast the way to do it
<daurnimator>
gruebite: depends....
<gruebite>
@intCast(c_uint, some_c_int)
<gruebite>
C api has an unsigned int for its enum
<gruebite>
but only @intToEnum exists
<daurnimator>
gruebite: you probably want @bitCast for that
<gruebite>
so i have to do 2 casts
<gruebite>
gotcha
<daurnimator>
gruebite: @intCast is if you know the integer is valid in the new type. e.g. you have a u64 and you *know* that it can only be in the range 1-500. then its safe to cast it to e.g. a u16
<gruebite>
also, how do i ignore a reference removing const? the C code takes a non cost reference to a function, but a function pointer is *const
<daurnimator>
gruebite: @truncate is if you aren't sure it can fit and want to discard the extra bits
<gruebite>
so doing `&some_func` is an error
<daurnimator>
@as() can be used if you are casting to a super-set type
<daurnimator>
(e.g. u16 to u64; though you can also use @intCast for that; or even *nothing*)
<daurnimator>
and then you have @bitCast, which is for going between same-sized things, where the bits need to be re-interpreted. such as signed to unsigned.
<gruebite>
and regarding the const pointer passing to C?
<daurnimator>
gruebite: huh?
<gruebite>
i have a function i need to pass to C, but the C code doesn't take a const pointer, just a regular one
<daurnimator>
gruebite: ah zig makes this hard to get out of: I think you have to @intToPtr(*c_void, @ptrToInt(ptr))
<gruebite>
the C API is b0rked a bit and doesn't take a const pointer
<gruebite>
ahh
<andrewrk>
gruebite, your best bet is to not do this cast, and instead make your data mutable
<gruebite>
i'm passing it to a C api i do not control
<daurnimator>
andrewrk: but if the C function is e.g. documented as not modifying arguments, and the header just has it wrong.
<gruebite>
yeah
<andrewrk>
if the header file is wrong then you might consider writing correct extern definitions rather than auto-translating the incorrect .h file
<andrewrk>
better yet, send an upstream patch to fix the .h file
<daurnimator>
I've encountered this sort of thing quite a bit in respect to apis on windows, e.g. they'll have a function taking a LPWSTR and say it doesn't modify. because windows doesn't have a const-variant of LPWSTR
<gruebite>
is there a way i can import my own zig extern def with @cImport
<andrewrk>
gruebite, you can just declare the extern functions and types in a file
<andrewrk>
start with your @cImport version and then modify it to be more correct
<daurnimator>
#2383 is also relevant here
lunamn_ has quit [Quit: leaving]
protty has quit [Remote host closed the connection]
mahmudov has quit [Read error: Connection reset by peer]
ur5us_ has joined #zig
ur5us has quit [Ping timeout: 250 seconds]
<daurnimator>
andrewrk: I guess you need me to rebase 3715 now...
reductum has quit [Quit: WeeChat 2.6]
<daurnimator>
done.
<daurnimator>
so... um... iovec
<daurnimator>
its in os/bits.zig
<daurnimator>
but windows doesn't have it all the time
<daurnimator>
and in some situations where it does: it has the member order swapped
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 250 seconds]
Cucumbas has joined #zig
<Cucumbas>
Completely new to irc and zig, where do i go to ask questions about zig?
<daurnimator>
Cucumbas: you are here.
<Cucumbas>
In the documentation, under 'choosing an allocator' it says if you're making a library, you should pass an *Allocator as a parameter-- does that mean a param to every function?
<daurnimator>
Cucumbas: usually to your initialisers
<Cucumbas>
is there an article or somewhere I could look for tips about writing libraries in zig? like the general structure?
<daurnimator>
Cucumbas: e.g. `yourlib.SomeDataStructure.init(my_allocator, otherparam, anotherparam);`
<daurnimator>
Cucumbas: not really; best to look at the standard library. e.g. have a look at std/array_list.zig
<Cucumbas>
How are you tagging me? @?
<Cucumbas>
Ah, thanks! I didn't think of looking at std lib, oops.
<daurnimator>
Cucumbas: I'm just typing your name :P (actually I'm typing the first 3 letter then pressing <tab>)
<Cucumbas>
daurnimator: oh haha, cause it's showing up highlighted, I guess thats just the client doing that. cool, thanks. Is there a channel for learning irc?
ky0ko_ has joined #zig
<daurnimator>
not really. you've got it :P people use a lot of different clients
<Cucumbas>
daurnimator: well thanks so much for the help, I'm gonna go spelunking in the std lib now :)
ur5us__ has joined #zig
ur5us_ has quit [Ping timeout: 240 seconds]
<Cucumbas>
daurnimator: quick question, in the examples I see you store the allocator in the struct with the data. I want to write a vector math lib and it seems very inefficient to store an allocator in every vec. Am I missing something?
<Cucumbas>
They will all be fix sized so maybe I should just always used a fixed allocator and not give the option?
<andrewrk>
I don't think you'll need an allocator for a vector math lib, since the size of everything is always known at compile time
muffindrake has quit [Ping timeout: 250 seconds]
<andrewrk>
daurnimator, we don't yet have any cross-platform abstractions for writing to a file handle with more than 1 buffer
muffindrake has joined #zig
<daurnimator>
andrewrk: event/fs has WriteV...
<andrewrk>
daurnimator, all that is bit rotted and needs to be audited
<andrewrk>
similar to how std.event.net is gone now; properly merged into std.net, and works both for evented and blocking
ur5us_ has joined #zig
ur5us__ has quit [Ping timeout: 250 seconds]
ur5us__ has joined #zig
<daurnimator>
andrewrk: okay.
<daurnimator>
andrewrk: I'm struggling at the moment with windows/bits vs bits/windows.
ur5us_ has quit [Ping timeout: 276 seconds]
<andrewrk>
here's a flow chart: is the set of declarations you are adding defined by POSIX? if so, put it in bits/windows. is it defined by windows.h or related headers? if so, put it in windows/bits. otherwise, it does not belong in either
<daurnimator>
andrewrk: so e.g. AF_UNSPEC: it originates in afd (the windows kernel module), and is exposed normally via ws2_32 (winsock; the user mode dll), but is also defined by posix
<daurnimator>
which file gets the "source of truth"? bits/windows? and then I @import that from e.g. ws2_32?
<andrewrk>
os/bits/windows includes windows/bits, so if it's in both, put it in the latter
<andrewrk>
what is this afd thing anyway? is that the lowest level networking API on windows?
<adamkowalski>
How do I check objects for deep equality?
<adamkowalski>
I tried std.testing.expectEqual
<adamkowalski>
but that doesn't seem to work for custom types
<adamkowalski>
std.mem.eql also doesn't like custom types
<traviss>
adamkowalski, i am curious about this too. i tried making eql methods in my custom types and this works ok. but a general method be really nice.
<adamkowalski>
if everybody ends up adding .eql to their types aren't we just reinventing operator overloading all over again haha
<adamkowalski>
it would be nice to just say std.testing.expect(a == b);
<adamkowalski>
I might add a .eql method on my type for now though, thanks
quetzalb has quit [Ping timeout: 260 seconds]
<adamkowalski>
traviss: for comparing arrays of custom types did you actually write a for loop and check for equality element by element?
<adamkowalski>
or is there maybe a nicer way?
<traviss>
std.mem.eql will check for array/slice equality
<adamkowalski>
not for custom types though
<adamkowalski>
it works for f64
<adamkowalski>
but not for my date object
<adamkowalski>
even though my date is just a simple type with a year/month/day which are all ints
<traviss>
oic, sorry misundestood you. yes, i just used something like `for (std.meta.fields(T)) |f| along with @field(self, f.name) == @field(other, f.name)`
<adamkowalski>
hmm yeah I like that.
<traviss>
`inline for` i mean
<adamkowalski>
so what is the rational for not having == do that in the first place?
<adamkowalski>
I'm genuinly curious?
<adamkowalski>
i've heard the argument against overloading * because you can have a hidden allocation which may fail
<traviss>
of course, this will only work for simple types. i ended up with a switch on typeinfo and doing different things for .Array, .Pointer, ...
<adamkowalski>
is it just that you don't know the cost of the == anymore?
<adamkowalski>
because like you mentioned, even that solution is brittle
<adamkowalski>
and it isn't extensible to custom types
<adamkowalski>
what if I want to customize how equality is checked for my type and opt out of the generic version you provided
<traviss>
i'm not 100% sure. i know that for instance std.testing.expectEqual doesn't work with tagged unions.. but not sure why yet.
<adamkowalski>
I feel like we are really missing a trait/protocol/whatever you want to call it system
<torque>
operator overloading hides complexity and possible side effects in expressions that don't appear to be function calls
<torque>
there is absolutely nobody stopping you from always creating a function to perform an equality comparison, you just have to call it like an actual function
<adamkowalski>
I mean I get that to a point. But isn't the whole point of generic programming to seperate the definition of algorithms and the data that they operate on?
<traviss>
maybe you have to make you own equality method which checks if the type has an eql() method and uses that, otherwise, use std.meta.eql?
<adamkowalski>
So if I want to write a sort function that relies on < determine where to put the elements
<adamkowalski>
you don't want to limit your sort to only work on floats
<adamkowalski>
how do you handle arrays of custom types?
<torque>
you make a sort function that accepts a callback that it uses to compare the types
<adamkowalski>
okay how about now I want to relax my sort function to work on anything which supports random access?
<adamkowalski>
if I rely on [i] for indexing
<adamkowalski>
I can only operate on slices/arrays
<adamkowalski>
I can't make my own type which has an array like interface
<adamkowalski>
which is huge for linear algebra. Where for example I want to implement a sparse matrix
<adamkowalski>
now if I build a sparse matrix I can't leverage any of the existing code which is written in terms of slices.
<torque>
you don't need operators to perform any of those operations though is the thing
<adamkowalski>
torque: my point is that by operating on the concrete type we are dramatically limiting code reuse
<adamkowalski>
and we are driving a wedge between built in types and custom types
<adamkowalski>
there is no way for me to build a type that feels native to the language. It will always feel like a second class citizen compared to the standard arrays
<adamkowalski>
I can't implement slicing
<adamkowalski>
I can't implement array access
<adamkowalski>
comparsion
<torque>
you can implement all those things
<torque>
they just don't use operator syntax
<pixelherodev>
Literally, have you looked at the standard library at all?
<adamkowalski>
right they have to be defined as methods on the type
<torque>
would you prefer if the built-in types did not use operators as well
<adamkowalski>
yes
<adamkowalski>
100%
<pixelherodev>
The whole point is that it's separated by complexity
<adamkowalski>
because then there would be a uniform syntax for dealing with all types that behave a certain way
<pixelherodev>
i64 + i64 is simple
<pixelherodev>
ComplexType1 + ComplexType2 is not
<adamkowalski>
which I get
<adamkowalski>
but
<pixelherodev>
The problem is that you're assuming all types would in fact behave the same
<pixelherodev>
I've seen so many examples of people abusing operator overloading that's come back to bite them - or others - later
<adamkowalski>
suppose that now I want to change my inputs so that rather than dealing with just floats
<adamkowalski>
I want to have meters
<adamkowalski>
or I have a certain amount of uncertainty about each measurement
<adamkowalski>
so I want to say it's 3 +- 0.5
<adamkowalski>
now I need to refactor ALL my code
<adamkowalski>
everything that uses + directly will be useless
<pixelherodev>
Sure, but what if you change the type used without realizing that the overloaded operators behave subtly differently?
<adamkowalski>
and if you didn't write your algorithms in terms of vars you can't pass meters where f64 was expectd
<torque>
I think I generally agree that zig would benefit from formal interface definitions but I think your argument is falling flat because you're consistently conflating this with operator overloading which is Bad
<adamkowalski>
i'm not saying operator overload is the solution
<adamkowalski>
i'm saying I want to have a way of expressing algorithsm independent of concrete types they are dealing with
<pixelherodev>
There are ways to do that already
<adamkowalski>
and I think var is not satisfactory
<adamkowalski>
it communicates nothing about the requirements about the type
<pixelherodev>
Check out e.g. math.sqrt
<adamkowalski>
reading through the standard library whenever I see generic code I just see var everywhere
<adamkowalski>
or you pass in a compile time parameter T as the first one
<pixelherodev>
Example is shown of using comptime blocks to verify that passed in args are valid
<adamkowalski>
right thats on the implementation side
<adamkowalski>
thats not on the caller side
<adamkowalski>
so you can't easily look at the signature of the function and know what to pas sin
<adamkowalski>
you have to read the implementation
<adamkowalski>
which leaks the abstraction
<traviss>
for instance, many of the sorting algorithms in std/sort require a less than param: `lessThan: fn (T, T) bool`
<pixelherodev>
You don't need to read the implementation of math.sqrt to know that it takes in numbers of some sort
<adamkowalski>
then why not just use a dynamically typed language
<adamkowalski>
you can make that same argument
<adamkowalski>
we don't need types, just make the names clear enough
<pixelherodev>
And if you're deciding how to call a function purely based on the signature then there's deeper underlying problems
<pixelherodev>
If you're *assuming* the function's behavior from its signature, you will run into problems
<adamkowalski>
there are other concerns I have as well
<adamkowalski>
right now the way that you all seem to recommend solving equality checking for example is to make a function
<adamkowalski>
typically in Zig it seems like this happens as a method on the struct
<adamkowalski>
so you can call a.eql(b)
<adamkowalski>
now I have no mechanism by which to add behavior to a type I don't own
<adamkowalski>
suppose you write a library, and didn't provide equality checking
<adamkowalski>
now what do I do?
<Cucumbas>
quick question, what is the way to compare floats in zig? I'm getting unreachable code because of an assert thats failing but should be passing
<adamkowalski>
you can put that in a function called approximately equal or something
<pixelherodev>
Maybe write a method that's called as `type_eql(a, b)` ?
<torque>
the method syntax is just syntactic sugar
<pixelherodev>
There are solutions, but I think that generally this is true regardless of language
<adamkowalski>
pixelherodev: yeah but if you have the function you described it's a closed system
<adamkowalski>
I have no mechanism to extend it
<pixelherodev>
You really shouldn't be able to modify types you don't own in general, if the type is badly designed and you can't control it or work around it then the language can't be reasonably held at fault
<adamkowalski>
well I think that depends on your perspective and what other languages you've used
<pixelherodev>
If I give you the header for, say, a C++ class without explaining how any of the functions work, and after working around numerous bugs you realize it's missing features, you can't change it there either
<traviss>
Cucumbas, there is std.math.approxEqual
<adamkowalski>
thats why I think the notion of classes is broken
<Cucumbas>
traviss: sweet!! I was hoping there was a built-in way
<adamkowalski>
you shouldn't couple data and methods
<adamkowalski>
then if a type is missing something like equality
<adamkowalski>
I can easily add an overload and boom
<adamkowalski>
I move on
<pixelherodev>
but the methods are inherently linked to the data regardless
<adamkowalski>
with our system the way to solve it would be to create a new type, wrap the old type and add a method
<pixelherodev>
An equality function has to be intimately aware of the data it's comparing
<adamkowalski>
I disagree
<adamkowalski>
it can recursively equality check each field
<pixelherodev>
What if it contains nested pointers?
<Cucumbas>
traviss: i get this error 'error: container 'std.math' has no member called 'approxEqual''
<andrewrk>
automatic recursive quality checking is a footgun
<pixelherodev>
a contains a pointer to b contains a pointer to a
<andrewrk>
*equality
<Cucumbas>
traviss: is that bc maybe my version of zig is behind the current source code?
<pixelherodev>
I can probably think of other ways to cause such a comparison to fail
<andrewrk>
nothing in the language prevents you from using comptime reflection from implementing this though. I believe the hash map API even supports deep equality if you opt in to it
<pixelherodev>
If you have two u8 slices, should they be compared by memory? By pointer + length?
<adamkowalski>
I'm open to doing things in a different way
<adamkowalski>
I just want to know what the rational is before I get behind an idea
<pixelherodev>
On the topic of comptime reflection, how performant is it generally?
<pixelherodev>
Will over-relying on it bloat compile times the way e.g. templates do to C++?
<andrewrk>
sure, give me a real world application you are writing where you need this and I will explain why I automatic recursive equality checking is a potential footgun
chemist69 has quit [Ping timeout: 246 seconds]
<adamkowalski>
okay i'll tell you the current problem i'm working on
<adamkowalski>
it's a simple problem but maybe thats better
<mq32>
hey
<Cucumbas>
traviss: ah, thank you :) test passes now.
<adamkowalski>
I'm reading in a bunch of measurements
<andrewrk>
pixelherodev, if you're using it, then presumably you would have either had to type out all the code manually anyway, or you would have done some kind of code generation. in either case, having zig generate the code with comptime features, and properly cache it, will be as fast or faster
<adamkowalski>
I store those measurements in a dataset class
<andrewrk>
caveat being that stage1 does not do incremental compilation
<adamkowalski>
it just has two arrays the dates and the thickness readings
<pixelherodev>
It caches it now? Actually, how is comptime implemented in stage1?
<adamkowalski>
I want to write a unit test and check if the parsing is done correctly
<adamkowalski>
so I instantiate the dataset expliclity, this is my expected value. then I call my parsing code and generate a dataset
<adamkowalski>
I want to check if the actual is equal to the expected
<pixelherodev>
Or I can just look through the code if you don't have time to explain
<andrewrk>
pixelherodev, I think I did a live coding stream where I showed an overview of how that stuff works once
<andrewrk>
I should probably do another "how to contribute to the stage1 c++ compiler" tutorial video
Cucumbas has quit [Remote host closed the connection]
<mq32>
andrewrk: +1
<pixelherodev>
Thanks!
<pixelherodev>
I'm more interesting in contributing to stage2 though
<adamkowalski>
do we have anything for recursive equality comparison?
ky0ko_ has quit [Ping timeout: 245 seconds]
<mq32>
i'm still kinda scared of this, so i always just report bugs
<mq32>
adamkowalski: nope, and i don't think it's reasonable to have this in std
<mq32>
recursive comparison is a footgun as andrewrk said
<adamkowalski>
can you all elaborate on these so called footguns
<traviss>
+1 for any kind of contributions tutorial videos
<adamkowalski>
just bad aliasing
<andrewrk>
pixelherodev, the next step to that is going to be improving std lib's evented I/O support, because I plan to take full advantage of that for self-hosted
<adamkowalski>
what if we promise we don't have them
<mq32>
Node = struct { node: *Child };
<mq32>
var n : Node = undefined; n = .{ .node = &n; };
<mq32>
now compare n recursively
<adamkowalski>
okay well if you do that thats on you
<andrewrk>
even if you don't have aliasing, your data types may not fully describe the notion of equality that is correct for the application, and in fact is likely to be subtly wrong
<mq32>
you either run out of stack or you require an allocator for caching
<adamkowalski>
okay so what is the alternative that you all would do?
<andrewrk>
maybe you add a field which is an allocator, or a logging ID, or some other out-of-band data
<mq32>
write a equality function, that is sane?
<andrewrk>
yes alternative is to be explicit
<andrewrk>
you could even have a comptime assertion in there that the number of fields is X. to remind yourself with a compile error to check the equality function's correctness when adding or removing a field
<adamkowalski>
yeah I can do that, thanks
<andrewrk>
nothing is stopping you from implementing deep equality checking using zig's comptime features
<andrewrk>
but I'm just recommending to do the simple thing
<adamkowalski>
but so you think thats less error prone then implementing deep equality by default and then opting out of it when it's not safe?
<pixelherodev>
People tend not to realize when it's not safe.
<andrewrk>
idk, do whatever makes sense for the data you have
<mq32>
i know no language that has deep equality
<adamkowalski>
D language
<mq32>
looks like D has even more features than c++ :D
<pixelherodev>
The problem is this: any generic recursive equality algorithm *will* fail under certain loads. People *will* at some point give it those loads. Writing a specific recursive equality comparison is relatively trivial.
<adamkowalski>
andrewrk: yeah I love mike acton! thats a great talk
<andrewrk>
he would definitely say to just write your equality function rather than trying to solve it with meta programming
<adamkowalski>
that was actually one of the things that got me excited about your language, it seems like it embodies the spirit of that talk
Ichorio_ has quit [Ping timeout: 276 seconds]
<adamkowalski>
however, I also think people like Alexander Stephanov were briliant and his book elmements of programming is a masterpiece
<adamkowalski>
I don't think writing code which is performant, simple to reason about, and maintanable need to be disjoint from writing generic code
<pixelherodev>
I made a thingy which takes an enum and outputs output and input instructions :P
<pixelherodev>
That `expect_char` thing is one of many many tricks I needed to get the same code working identically natively and as a kernel :)
<adamkowalski>
anyway thanks for all the feedback! i'll implement the equality explicitly. I'm off for the night. have a good one everyone!
<pixelherodev>
Night!
<pixelherodev>
I enjoyed the debate and look forwards to the next one :)
<pixelherodev>
It's always good to hear other perspectives on things I don't generally think about
adamkowalski has quit [Quit: Lost terminal]
<mq32>
btw, pixelherodev: i have my x86 IO now in zig style *grin*
<pixelherodev>
?
<mq32>
IO.in(u8, port) and IO.out(u16, port, value)
<pixelherodev>
Ah
<pixelherodev>
Yeah, I've had that for a while now :)
<mq32>
which is MUCH MORE readable than inb, inl, inw and the latter
<pixelherodev>
Wait, you mean as opposed to using inline asm everywhere, or?
<pixelherodev>
Ohhhhh
<pixelherodev>
Neat!
<mq32>
yes
<mq32>
:D
<pixelherodev>
That's brilliant, I'm totally stealing that
<pixelherodev>
;)
<mq32>
GO! :D
<mq32>
i need to make some "intrinsincs" file though
<pixelherodev>
The fun part with that comptime/runtime hybrid function is I can probably now hijack it and use it to auto-implement, say, saving/loading, to interface to the basic inventory system I implemented earlier...
<mq32>
have too much inline assembly over the place
<pixelherodev>
That's a good idea
<mq32>
so something like
<mq32>
CPU.halt();
<mq32>
instead of inline assembly
<mq32>
also andrewrk: is it wanted that error return traces may be *very* long and circular? :D
LargeEpsilon has joined #zig
<mq32>
i discovered that a return trace may be weird if the error is handled with a retry loop
<andrewrk>
mq32, unless you're hitting an old bug, they should be capped at 32 items, and they include when you "catch" an error even if you don't return it
<bgiannan>
andrewrk, i definitely had some over 32 items
<pixelherodev>
Reminds me of my fun "panic within panic" errors :P
<andrewrk>
mq32, you're trying to link against your own DLL right?
<mq32>
no
<mq32>
i have "acknex.dll", with a documentation and headers
<mq32>
but no library fil
<mq32>
*file
<FireFox317>
andrewrk: what is the zasm you are working on? btw is your sleeping schedule a bit off? xd
<andrewrk>
is my sleep schedule is foobar'd
<andrewrk>
*yes
<andrewrk>
you might even say it is quuxed
<andrewrk>
up until recently zig would auto generate import .lib files for dlls when you use extern "acknex" fn (...) syntax
<andrewrk>
LemonBoy did some legitimate improvements in this regard, especially with regards to non-x86_64 windows targets. But I'm not sure where we're at anymore with that feature
<andrewrk>
mq32, my recommendation will be to try to do that, and let's get that feature working again if it broke
<mq32>
okay, i'll get my gamestudio installation later :D
<mq32>
it would be really funny to code games in acknex, from linux
<andrewrk>
in the meantime a workaround will be manually generating the .lib file from a hand coded .def file using LLD or link.exe
<mq32>
for a windows/lite-c based engine :D
<FireFox317>
trips always shrew up my sleeping schedule too hahah, but zasm is just a beginning of an assembler in zig?
<mq32>
yeah, would be lld then, i don't have a windows installation near me :D
<andrewrk>
FireFox317, yes, zasm is my "fun after hours" project right now, where I'm learing how to do direct-to-machine-code
<andrewrk>
*learning. I looked at the LLVM and NASM instruction database files but they were too hard for me to understand. So my plan is to start building my own instruction database up from first principles, and then once I understand the problem enough I can toss out my amateur hour database and port LLVM's
<FireFox317>
ah cool! I'm preparing a PR for clashos to get it working on hardware again, and will change the structure a bit, such that people can learn from it :)
<andrewrk>
but the main idea behind zasm is that it will enable a direct-to-machine-code backend in self-hosted eventually
<andrewrk>
as well as non-llvm backends in general
<mq32>
that would be really cool!
<andrewrk>
I'm tired of people asking if zig is as fast as jai, I decided I want the answer to this question to be "it's faster"
<mq32>
heh
<mq32>
+1
<mq32>
git commit -m "Adds FTL drive to zig"
<andrewrk>
it'll probably be more like "Merge pull request #6666 from kprotty, new event loop implementation"
<mq32>
yeah true, but i want to believe! :D
<FireFox317>
people really want fast compilation times for some reason, i really like that fact that zig has so many targets thanks to llvm :)
<mq32>
FireFox317: targets, compilation speed and code optimization are all valid targetss to optimize for
LargeEpsilon has quit [Ping timeout: 276 seconds]
return0e_ has joined #zig
frmdstryr has quit [Ping timeout: 245 seconds]
LargeEpsilon has joined #zig
return0__ has joined #zig
return0e has quit [Ping timeout: 240 seconds]
<FireFox317>
does someone know how i would reach LemonBoy?
<FireFox317>
nvm found a email address
casaca has quit [Ping timeout: 265 seconds]
FireFox317 has quit [Ping timeout: 245 seconds]
LargeEpsilon has quit [Ping timeout: 276 seconds]
traviss has quit [Read error: Connection reset by peer]
FireFox317 has joined #zig
LargeEpsilon has joined #zig
FireFox317 has quit [Ping timeout: 240 seconds]
<tgschultz>
jai has a lot of hype but who cares how fast it is if you can't even use it.
<scientes>
^^^
<scientes>
hype is overrated :)
<bgiannan>
is there an IDE where i can see compile errors on the code as i'm typing?
<scientes>
bgiannan, that requries language server
<adamkowalski>
this is one of the PyTorch devs discussing how their auto diff works and how they represent the computation graph
<adamkowalski>
Should I just use the same allocator for the entire forward pass as well as the computation graph then deallocate all at once?
tines9 has joined #zig
<fengb>
So... I'm not sure if that's the best solution, but arena_allocator helps you do that easily
daex has quit [Quit: /me 's znc kicks the bucket]
daex has joined #zig
<fengb>
Most of our parsers use an arena
<adamkowalski>
yeah that sounds like a good fit
<adamkowalski>
so each training loop you create the arena and defer to deinit it
<adamkowalski>
then you build up the computation graph and you know you can safely store references to other parts of it
<adamkowalski>
then just blow it all away at the end
<mq32>
yeah the arena allocator is really great of all kind of graph wor
<mq32>
*work
<adamkowalski>
perfect!
<adamkowalski>
Once it's ready we should choose a project that shows off why people should use Zig for machine learning rather than Python
<mq32>
heh
<adamkowalski>
One thing Intel was working on that we were going to help with was differentiable ray tracing
<mq32>
i think people should use less python anyways
<adamkowalski>
well the libraries are too damn good
<mq32>
yeah, i know
<mq32>
but the overhead
<adamkowalski>
it makes doing data science in anything but that a really hard sell
<adamkowalski>
but it struggles when the library support isnt there because the key to writing fast python is to shell all the work out to C++ haha
<mq32>
yeah, but a lot of software shouldn't be python. that costs so much energy :D
<adamkowalski>
yeah thats why I'm trying to convince my boss to switch to Zig
<adamkowalski>
but i'm tasked with showing alternatives to all the libraries we use in Python
<adamkowalski>
so it will be a while
<adamkowalski>
I'm working on a plotting library for now
<adamkowalski>
we also need a way to deal with large tabular data (they have data frames which are unified abstractions for dealing with excel, sql tables, etc)
return0__ has quit [Read error: Connection reset by peer]
<adamkowalski>
a tensor (nd array) library that supports auto diff
<adamkowalski>
and then I think we are done
daex has quit [Quit: /me 's znc kicks the bucket]
<adamkowalski>
well actually we also need probability distributions
return0e has joined #zig
<adamkowalski>
the auto diff one is what i'm thinking is gonna be hardest to implement haha. So I could use any help I can get
daex has joined #zig
<adamkowalski>
On an unrelated note. Do you all tend to keep tests in the same file as the code they are testing? Or in a seperate directory? Or whats the best practice
doublex has joined #zig
<Snektron>
I usually do them in the same file, since Zig's system makes that so east
<Snektron>
Easy
<adamkowalski>
okay cool, thats what I've been doing so far too
<Snektron>
Also gives you example usage on functions
<adamkowalski>
thats true
<Snektron>
I think theres no reason to not put them in there
<Snektron>
If your file grows too large its probably wiser to split out some functionality
<adamkowalski>
Would it be a valid strategy to use a series of arena alocators. Each section of your program uses an arena and then when that portion of the work is done then you deallocate the whole region
<adamkowalski>
then you go upwards deallocating regions until the whole program finishes
<adamkowalski>
Then you only pay for deallocation at predetermined times and you get something that almost feels like a garbage collected language since you know the lifetimes are always valid
<Snektron>
If the parent of an arena allocator is another arena allocator you might as well just use the one
<mq32>
i kinda remember that zig std has some kind of iterator for multiple slices
<mq32>
can somebody hint me the name?
kenaryn has joined #zig
<kenaryn>
Hello, please what does it mean the '&' character? It is not explained in the official documentation. Here is an example: `var buf: [100]u8 = undefined; const amt = try self.file.read(&buf);`
<mq32>
& is the "address operator"
<mq32>
it takes the address of a certain value
<mq32>
the `&buf` expression would return a pointer of type `*[100]u8`
return0e has quit [Read error: Connection reset by peer]
adamkowalski has quit [Quit: leaving]
return0e has joined #zig
<Snektron>
Interesting how there seem to be more people programming zig lately that dont have experience with C
<Snektron>
Seems like a small victory
<companion_cube>
if you want to replace C, requiring prior experience with C seems asking a bit much!
WilhelmVonWeiner has joined #zig
WilhelmVonWeiner has left #zig [#zig]
<kenaryn>
Thank you buddy!
<kenaryn>
Please what is the difference between the pointer and the address operator? Is there a discrepancy between (for example) *buf and &buf?
<kenaryn>
Andrew use both in this server.zig live stream example and I admit I'm lost.
<companion_cube>
they're inverse operations, & takes the address of something
<companion_cube>
and * follows the address back to the object
<kenaryn>
Thank you my dear french fellow.
<fengb>
That used to be the same syntax but it caused parser ambiguity
<companion_cube>
:D
<kenaryn>
I hope one day the Zig documentation will be written to allow people to learn it as a first programming language because currently it requires a lot of prerequisite concepts.
<kenaryn>
The entry barrier is quite high you know.
<companion_cube>
it's 0.5, so, very early days
<kenaryn>
I need a Zig book for Christmas :D
<fengb>
And documentation isn't the best. We have decent resources for C programmers, but probably need more for newbies
<kenaryn>
I read all 0.5.0 release notes and the official documentation, read some github examples and followed the live chat tcp server stream but it is cleary not enough, I'm still unable to code anything.
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
kenaryn has quit [Quit: WeeChat 2.3]
return0e_ has quit []
LargeEpsilon has quit [Ping timeout: 246 seconds]
<Snektron>
Ability to program doesnt come overnight, and Zig is not reallt the easiest place to start
<Snektron>
But sont let that demotivate you
<Snektron>
dont
doublex has quit [Ping timeout: 246 seconds]
WilhelmVonWeiner has joined #zig
reductum has joined #zig
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
Cucumbas has joined #zig
<Cucumbas>
If you want to write code that can be compiled to C, do you have to use a subset of zig? Because how could
<Cucumbas>
You express generic stuff in C
jua_ has joined #zig
FireFox317 has joined #zig
<fengb>
Yes, Zig only adheres to C ABI with data structures/functions marked extern
<fengb>
And Zig things like error unions and slices are not supported in extern
Cucumbas has quit [Ping timeout: 265 seconds]
Cucumbas has joined #zig
<gruebite>
how can i convert a c string to a zig string?
<gruebite>
and how do i build c strings without literal `c"string"` syntax?
<gruebite>
is it just u8 and add a 0 at the end and cast?
<andrewrk>
Cucumbas, generic functions are not compatible with the C ABI. if you want to create an ABI you have to use C ABI only types. You could call a generic function in your implementation of a function though
<mikdusan>
andrewrk: re: "unembeds ConstExprValue from IrInstruction",
<mikdusan>
i should have some time to re-engage with this PR. the current state is,
<Cucumbas>
andrewrk: ah, so it would be a matter of wrapping the code. would my code have to use C ABI types internally too?
<andrewrk>
Cucumbas, it's up to you how you organize this
<andrewrk>
generally, I would advise to create your C ABI as a "layer" on top of a Zig API. This way you could have a zig package and also export a C library
<andrewrk>
one nice trick is that you can have *pointers* to zig types in external functions. these show up as forward declarations
<andrewrk>
so you could have an API like `export fn createFoo() *Foo` and your Foo can be a zig struct with zig types in it
<mikdusan>
i'll merge with master/head again and take out "flagged" (conditional) implementation for interning and settle on const value interning only for 1-possible-value types,
<Cucumbas>
andrewrk: oh awesome! thanks for explanation, super helpful
<andrewrk>
mikdusan, I think this will be a big step in the right direction, for tackling the memory issues, looking forward to merging that
<mikdusan>
but friendly reminder this unembedding will pretty much hit any stage1 forked work out there with the need to merge (trivial) struct changes
<andrewrk>
yes that's unfortunate, but has to happen
<mikdusan>
is there a "time" you feel this kind of merge would be easier to do? i can try and hit that time for you if you want.
<andrewrk>
any time. this would have already made #3728 easier to do
<andrewrk>
since I need to intern the sentinel value
<mikdusan>
okie dokie
Ichorio has joined #zig
Pistahh has joined #zig
<fengb>
Seems like every "error as value" language reinvents stacktraces in the userland :(
<fengb>
I hope Zig error traces become more commonly adopted
<andrewrk>
we also need something to help with async function (non-error) traces
<andrewrk>
if you never used async/await and only made async calls, we actually could set up the frames so that the normal stack unwinding code would see no difference between async fns and normal fns
<andrewrk>
the problem is that the trace we care about flows through the async, not the await, and the calling frame might not exist at time of stack unwinding
<andrewrk>
there's also the problem of using a debugger. it would be nice if the debugger could find the async fn trace
<andrewrk>
languages that allow hidden memory allocations have such an advantage in ergonomics. you can do a lot with the assumption of infinite memory
<andrewrk>
there's absolutely no excuse for a garbage collected language that doesn't have python-style integers
<pixelherodev>
Does #3728 make it so that normal string literals are null-terminated?
<andrewrk>
pixelherodev, yes
<andrewrk>
with this, string literals can type coerce both to `[]const u8` as well as `[*:0]const u8` (C strings)
<fengb>
andrewrk: you mean automatic promotion to BigInt?
<pixelherodev>
Hmm, so that means that there's an extra byte for each string once that's merged? :(
<andrewrk>
fengb, yes but that's an implementation detail. I mean that in a garbage collected language, integers should have unlimited range of values
<andrewrk>
pixelherodev, yes. do you foresee a problem with this? larger binary size?
<pixelherodev>
Mostly joking, it should probably be negligible
<fengb>
Yeah that makes sense. Although a reasonable argument is that accidental promotion can non-obviously destroy performance
<andrewrk>
fengb, yes that's a reasonable argument. But my counter to that is you're already using a garbage collector (and probably a JIT). non-obvious performance is a given
<fengb>
Might be a Java centric argument since that's the only language I know that forces primitive boxing shenanigans
<fengb>
There's no perfect language, only tradeoffs
<pixelherodev>
Though I'm not sure I see the need for null termination, personally
<THFKA4>
wrong, zig will be perfect
<THFKA4>
begone heathen
<andrewrk>
pixelherodev, that's great, don't use it
<pixelherodev>
No, I mean I don't see the need for string literals to be null terminated in situations in which the null byte is never used
<pixelherodev>
One byte isn't a big deal, but it still seems wasteful when it's being coerced into a `[]const u8` anyways
<andrewrk>
in theory zig should be able to determine when the null byte could not possibly be observed and omit it. but I'm guessing this would be a lot of work for negligible gain
<andrewrk>
this is one of those things where if it was done from the start you wouldn't think twice about it, but since it's a change that's requiring effort, it's under scrutiny
<pixelherodev>
That's definitely true
<pixelherodev>
I think the biggest use case for doing that would be embedded targets
<pixelherodev>
e.g. AVR, where RAM is measured in KB, every byte counts for some real-world applications
<andrewrk>
in this use case, embedded targets might actually want null termination, since each string requires 1 null byte rather than a usize for the len
<pixelherodev>
String literals will store both after #3728?
<pixelherodev>
Proposal: add an explicit "non null-terminated string literal" syntax, and an explicit "only null-terminated (no usize for length) string literal" syntax
<andrewrk>
existing code will work the same, except the `c` from C string literals gets dropped, and string literals are pointers now, so if you want the array value, dereference it
<pixelherodev>
Wait, is the usize part of the literal itself? Or is that in-memory for the slice?
<andrewrk>
the type of "hello" is *const [5:0]u8`
<andrewrk>
the length is part of the type
<pixelherodev>
Right, I mean does it show up in the binary, or is it set aside in the stack when that value is used?
<pixelherodev>
And on a different note, is there a way to basically "jump" to another function? e.g. if function x wants to under certain conditions `return x(other_args)`, is there a way to avoid wasting stack?
<Pistahh>
andrewrk: what if a c library, when used with zig, decides to put a \0 in the middle of an existing string (as some kind of "chop" operation), screwing up the zig semantics with the length still referring to the full length?
<gruebite>
that would throw off existing stdlib strlen operations too
<andrewrk>
Pistahh, the semantics do not guarantee that the sentinel is not present before the length, only that it is present at the len index
<andrewrk>
the main use case for this type is a foot-shield, to make sure you don't forget to null-terminate stuff. the language doesn't really do much with this type information other than typecheck
<andrewrk>
I think this change is going to be a lot less disruptive than people fear
<Pistahh>
andrewrk: still, it can cause weird issues, when using such a "malformed" string with pure c functions would have different result than the "same" functions in zig. i.e. appending one char to it. C would find the first \0 and append there; zig would use the length
<andrewrk>
pixelherodev, optimized builds will already do this optimization
<pixelherodev>
Thanks!
<andrewrk>
Pistahh, I challenge you to provide a zig example code where a weird issue occurs
<pixelherodev>
C and Zig disagreeing on the string's length might be problematic, but it also might be useful
<fengb>
It already disagreed before this change. This isn't making it worse
Srekel has joined #zig
<Srekel>
Hi everyone, got a question that I asked on Discord but got conflicting answers, so wanted to check here. What would be the corresponding way to do C-style void* userdata? @OpaqueType seems to be the best option.
Akuli has joined #zig
<bgiannan>
weirdest bug i'm having: seems like any allocation crashes because of a std.debug.warn in an unrelated code...
<daurnimator>
andrewrk: stream today?
<bgiannan>
whats [c*] vs [*] ?
<bgiannan>
just updated zig and it complains of *.cimport:19:17.struct_SDL_Surface != [*c].cimport:19:17.struct_SDL_Surface
<daurnimator>
bgiannan: [c*] is a "c pointer" => which is a pointer that zig doesn't know if its to many or one.
<daurnimator>
it should coerce to both "many" and "one" pointer types
<daurnimator>
pixelherodev: indeed. it makes e.g. openC() and open() actually different
<bgiannan>
bmp[0..1] ?
<daurnimator>
bgiannan: try using @as()?
<bgiannan>
works thx
wootehfoot has joined #zig
lobsta has quit [Ping timeout: 265 seconds]
kristoff_it has joined #zig
kenaryn has joined #zig
<kenaryn>
Please does someone know where the @builtin functions have been exported from the official documentation? I cannot find them anymore and I'm looking for the meaning of @Frame because Andrew said it was very memory-efficient.
<daurnimator>
kenaryn: what do you mean exported?
<daurnimator>
kenaryn: builtins are.... builtin
<kenaryn>
Hello daurnimator, I mean 'moved', or 'migrated'
<jmiven>
oh sorry didn't see that the link was already posted :-)
<kenaryn>
Well done guys! I was deceived by the similar look of the home page.
<kenaryn>
Both begin by the same table of contents.
ur5us__ has joined #zig
<kenaryn>
It is very difficult to grasp the 'frame' concept without any explanation anyway. :/
<andrewrk>
I'll do a live stream in 1hr50min. coding on zasm, should be fun.
<andrewrk>
until then, gonna focus on #3728
<FireFox317>
kenaryn: you really don't need all these frame things when start to code in Zig or coding in general, is really for advanced stuff basically
<FireFox317>
I mean if you would like to dive into it, sure :)
<reductum>
Looking forward to the stream!
Akuli has quit [Quit: Leaving]
ur5us__ has quit [Ping timeout: 246 seconds]
<pixelherodev>
mq32, wait, your OS/FC works?!
LargeEpsilon has joined #zig
<kenaryn>
:)
<pixelherodev>
It can run games already?
<kenaryn>
Is it planned to include at least one example for each function into the documentation to help apprehend the concept or is it considered information pollution?
LargeEpsilon has quit [Ping timeout: 276 seconds]
<kenaryn>
off-topic: thank you pixelherodev for sharing your experience on your blog. I liked reading your feed-back about programming and zig's deviations from ambiant conformism (e.g. shadowing forbidden, etc.).
<kenaryn>
perhaps a follow-up in a few months would be interesting.
<daurnimator>
andrewrk: also: if you write your zasm as a library that works at both runtime and compile time, then we might just end up on the path to a JIT compiler... :)
<pixelherodev>
Ooh
wootehfoot has quit [Read error: Connection reset by peer]
<Snektron>
Whats the idea of zasm? Assembler with common language and different output languages? or just a library for generating binaries containing machine code?
<daurnimator>
Snektron: I think its a project for andrew to experiment with machine code generation
<Snektron>
I saw the repository with just an initial commit containing some tokenization code. Im not sure if that should be part of a library for code generation
<shachaf>
andrewrk: Oh man, I wrote a little amd64 assembler in C a few months ago.
<shachaf>
Good times.
<shachaf>
(I mostly wrote it to test my ELF emitting code, but then I started implementing a bunch of addressing modes and things.)
<pixelherodev>
On the topic of writing an assembler: if it's meant to be multi-target, I'd highly suggest having the actual ISA spec separate from the code
<pixelherodev>
Makes it nearly trivial to retarget
<pixelherodev>
Then again, if it's meant to go straight from IR, that's probably not really possible