<scientes>
zig supposedly exports those, but i haven't needed them yet
marijnfs_ has joined #zig
nikki93 has left #zig [#zig]
* daurnimator
is getting excited for interfaces.. tgschultz :)
marijnfs has quit [Ping timeout: 258 seconds]
<tgschultz>
daurnimator: I wouldn't get too excited, there's a good chance all my work gets thrown out because all it accomplishes its proving that userland solutions are insufficient. But we'll see.
<daurnimator>
tgschultz: yeah it does get a big ugly
<daurnimator>
tgschultz: but maybe it proves that just a little sugar is needed?
<tgschultz>
well that's what we're trying to work out
<daurnimator>
tgschultz: your most recent PR makes me think it could be related to variable length structs?
<daurnimator>
tgschultz: in the current PR, you have a *impl member. What if the implementation was instead a variable size trailing bit of the struct?
<andrewrk>
don't worry, it's only +11,248 −11,270 lines
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
<daurnimator>
tgschultz: so what is the issue with e.g. struct { const Self = @This(); var interface = FooInterface{.foo = Self.foo}; data: i32, fn foo(interface: *FooInterface) i32 { const self = @fieldParentPointer(Self, "interface", interface); return self.data; } };
<tgschultz>
we started down this path for three reasons: 1) the footgun of copying an inerface struct instead of taking a pointer to it, 2) the additional complication of error sets (see Sterams), and 3) @fieldParentPtr doesn't optimize well for some reason.
<tgschultz>
your exampe wouldn't work because .foo is just a pointer to a function, the function is static, not part of an instance of the struct
<tgschultz>
oh wait, nevermind, it's late
<tgschultz>
this is just status quo
<daurnimator>
tgschultz: 1) that footgun should be fixed soon with 'fixed'/'nocopy'... right? 2) FooInterface() could be parametized by e.g. error set?. 3) oh? that's news to me... do we have an open issue for that?
<tgschultz>
no.. I was right the first time, because interface is also static
<daurnimator>
tgschultz: oh right. it would have to be `var interface: FooInterface`, and then in e.g. an .init function you would have to initialise it.
<tgschultz>
1) yep, that's probably a good idea. 2) that's status quo with streams and it gets painful. Even andrew just gave up in dwarf.zig and uses an SeekableStream(anyerror, anyerror). 3) yeah, there is. It's referenced by the big "redo std lib with different interfaces pattern" issue
<tgschultz>
3) is also something we could probably just fix
<tgschultz>
1) and 3) are also solved by my latest PR, and my next one will attempt to handle 2), but like my first 2 PRs it may bring more cons than pros and waiting for new language features might be better.
<tgschultz>
but I'll sleep better knowing that all the options were explored.
<daurnimator>
tgschultz: so I've been thinking about how I might need it for e.g. std.LinkedList
<daurnimator>
tgschultz: e.g. I need to std.LinkedList to really be an interface... and then sometimes I need to implement it with atomic operations; other times with locks; etc...
<tgschultz>
isn't there already a linked list that's intrusive? That's basically what status-quo interfaces are, intrusive pointers with a vtable attached.
<daurnimator>
tgschultz: you can create an intrusive linked list today with std.LinkedList(void) and then embedding .Node in your struct.
<daurnimator>
tgschultz: I meant that sometimes for my linked list `.next` needs to be an @atomicLoad
<tgschultz>
I see, so you need the Node to be an interface so the operation of getting the next node can have differing behavior
<daurnimator>
yep. likewise .first in the main 'linkedlist' structure itself
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 258 seconds]
<redj>
\\
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 268 seconds]
<daurnimator>
andrewrk: indeed it's a lot to review... concentration ran out after reading 3 or 4 files; will try and do another round later
<andrewrk>
daurnimator, thanks for the review
<daurnimator>
time for tea :)
<daurnimator>
andrewrk: also it's hard to know what code is fresh/changed vs what is just moved from another location and should be fixed in another PR
<andrewrk>
yeah. I have no solution to that, sorry
<andrewrk>
I've been working really hard on this for a week, and it's taken a lot of time, it makes sense it would be hard to review
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 258 seconds]
<shritesh>
Guess the number example works on WASI with the PR.
<andrewrk>
great
<shritesh>
The new organization will make it easier to implement libpreopen-style capability-based file/socket operations on WASI. It was really difficult to shoehorn on top of existing interfaces before.
fengb has quit [Ping timeout: 256 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 248 seconds]
marmotini_ has joined #zig
_whitelogger has joined #zig
Aransentin has quit []
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
scientes has quit [Ping timeout: 248 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
<andrewrk>
thanks everybody for the review comments, I'm going to go to sleep and then respond to everything / wrap things up in the morning
<emekankurumeh[m]>
gn
<andrewrk>
and then spend some time on these 40 (!!) open pull requests
return0e has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
<daurnimator>
I'm sure many of the PRs will need to be rebased after this breaking PR
return0e has quit [Ping timeout: 244 seconds]
marmotini_ has quit [Quit: Leaving]
marmotini_ has joined #zig
reductum has joined #zig
return0e has joined #zig
rom1504 has quit [Ping timeout: 258 seconds]
rom1504 has joined #zig
marmotini_ has quit [Quit: Leaving]
marmotini_ has joined #zig
rom1504 has quit [Excess Flood]
rom1504 has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 244 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 248 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 246 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 248 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 246 seconds]
marijnfs has joined #zig
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 244 seconds]
marijnfs has quit [Remote host closed the connection]
marijnfs has joined #zig
marijnfs has quit [Remote host closed the connection]
marijnfs has joined #zig
marijnfs_ has joined #zig
marijnfs__ has quit [Ping timeout: 246 seconds]
hio has joined #zig
marijnfs__ has joined #zig
return0e has quit [Ping timeout: 272 seconds]
marijnfs_ has quit [Ping timeout: 258 seconds]
gamester has quit [Quit: Leaving]
return0e has joined #zig
marijnfs__ has quit [Ping timeout: 245 seconds]
marijnfs_ has joined #zig
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
reductum has quit [Quit: WeeChat 2.4]
marmotini_ has quit [Ping timeout: 250 seconds]
marijnfs_ has joined #zig
marijnfs__ has quit [Ping timeout: 272 seconds]
WilhelmVonWeiner has quit [Remote host closed the connection]
WilhelmVonWeiner has joined #zig
marijnfs_ has quit [Ping timeout: 246 seconds]
marijnfs__ has joined #zig
marijnfs_ has joined #zig
marijnfs__ has quit [Ping timeout: 259 seconds]
marijnfs_ has quit [Ping timeout: 244 seconds]
marijnfs__ has joined #zig
marijnfs_ has joined #zig
marijnfs__ has quit [Ping timeout: 272 seconds]
marijnfs_ has quit [Ping timeout: 244 seconds]
marijnfs_ has joined #zig
marijnfs_ has quit [Ping timeout: 248 seconds]
marijnfs__ has joined #zig
rivten has joined #zig
marijnfs_ has joined #zig
marijnfs__ has quit [Ping timeout: 245 seconds]
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
_whitelogger has joined #zig
tralamazza has joined #zig
marijnfs_ has joined #zig
marijnfs__ has quit [Ping timeout: 258 seconds]
rivten has quit [Ping timeout: 256 seconds]
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 246 seconds]
return0e_ has joined #zig
return0e has quit [Ping timeout: 252 seconds]
Aransentin has joined #zig
marijnfs_ has joined #zig
marijnfs__ has quit [Ping timeout: 246 seconds]
hio has quit [Quit: Connection closed for inactivity]
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
marijnfs has quit [Quit: WeeChat 2.4]
marijnfs has joined #zig
marijnfs__ has quit [Ping timeout: 258 seconds]
<shritesh>
What’s the recommended way to do regex right now?
<andrewrk>
I think tiehuis has a library
<andrewrk>
runtime compilation only afaik
<andrewrk>
we're going to need quite a few bug fixes & improvements to comptime before comptime regex compilation becomes practical, but it'll happen
marijnfs has quit [Ping timeout: 246 seconds]
marijnfs_ has joined #zig
<shritesh>
Thanks. I’ll try it out.
<scientes>
andrewrk, I have wanted that for years in GCC but I don't think it will ever happen
<scientes>
andrewrk, both compilation and execution
<andrewrk>
zig's design allows it. just need to improve zig a lot
<scientes>
it also makes a clearer language, from a theoretical standpoint
<scientes>
as long as they do not support backtracking
Aransentin_ has joined #zig
Aransentin_ has quit [Client Quit]
<emekankurumeh[m]>
why not? there is a rust project that supports compile time regex compilation.
<scientes>
emekankurumeh[m], with what engine?
<mikdusan>
i get real oddball branch:posix_layer build error genearting userland.o. some duplicates, but the weirdest one is "linux.zig" showing up everywhere and I'm building on macos
<andrewrk>
mikdusan, I haven't tested on macos yet
<andrewrk>
shritesh, it's about to not compile on master even harder when I merge this branch
<mikdusan>
heh
<andrewrk>
I'm sure the upgrade path is straightforward. zig hasn't lost abilities
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 244 seconds]
<shritesh>
Haha. In this case it’s the allocator.create function. It used to take a value and now it takes the type and you have to write to the returned memory address now.
<shritesh>
271 non trivial changes (and probably more). I’ll just write a state machine.
<scientes>
allows state machines to be more readable in some cases
marijnfs has quit [Ping timeout: 248 seconds]
marijnfs_ has joined #zig
<Aransentin>
Some C libraries have functions that take a lot of variable-length parameters; e.g. to connect with libpq there's a ton of options you can set.
<Aransentin>
libs also tend to solve this in many different ways. Vulkan has you passing large struct pointers as arguments,
<Aransentin>
in libpq you can either pass a "foo=bar blah=bloo" string or two null-terminated arrays of strings with the keys/values in each.
<Aransentin>
Is there any way you folks would prefer? Anything Zig-specific?
<andrewrk>
there are also plans for an anonymous struct literal which would make such a function call look very similar to passing keyword args
<andrewrk>
unrelated, I think I need to do a blog post about undefined behavior
<Aransentin>
Like vulkan, then? Would it be okay to arbitrarily add more options in later releases?
<Aransentin>
(insted of doing it like Vulkan, and having an extra void pointer for extensions)
<andrewrk>
if you added struct fields and gave them default init values then it would avoid breaking the API of callsites
<Aransentin>
You'd presumably break dynamic linking, if that's even a thing in Zig :)
<andrewrk>
I respect whitequark a lot, and she's the one who wrote the IRC logger for this channel, but even she thinks zig's approach to undefined behavior is "ridiculous" and "fundamentally wrong" https://twitter.com/whitequark/status/1132327234935631872
<andrewrk>
if someone like that misunderstands the situation, I think I need to write an article to clarify
<scientes>
andrewrk, I agree
<scientes>
doesn't get that zig makes undefined behavior more managable than C
<scientes>
less scary
<andrewrk>
if and when it comes time that people use zig for web servers of businesses, I think the preferred build mode for production will be release-safe
<andrewrk>
release-fast is more for game devs and for perf bottlenecks
marijnfs has quit [Remote host closed the connection]
<mikdusan>
i wonder why anyone would place value on C unsigned integer wraparound. frankly i've never once relied on that behavior. if it is useful, it smells like special case useful.
<rain1>
i always wanted carry bits to be exposed
<rain1>
I suppose i can just code in assembly if i want that though
<andrewrk>
rain1, if you're writing zig you can simply use the wraparound operators
<mikdusan>
so in fact looking at zig's features; if you want wraparound you explicitly use it. if not, you get undefined. seems ok to me.
<scientes>
mikdusan, the advantage is the determinism
wilsonk has quit [Ping timeout: 272 seconds]
<scientes>
undefined behavior is def. woorse than determinism
<scientes>
and until zig, no language "got" undefined behavior
<shritesh>
“Write in Rust” or “write C and provide proofs of your code” is not feasible for everyone. I have done the former professionally and I’m too dumb for the later. With Zig (and release-safe), I’m as confident as writing python and ruby and actually enjoying it.
<scientes>
but they didn't solve it the way zig finially does
<scientes>
actually, there would probably be a desire for the same thing in C---it is implemented for the string formatting function now because of a long history of security problems
<scientes>
and go uses -fwrapv just because they are so scared of the UB
<scientes>
so does java
<andrewrk>
I had to look that up: "This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. This flag enables some optimizations and disables others. This option is enabled by default for the Java front-end, as required by the Java language specification. "
<scientes>
andrewrk, it just turns off UB
<andrewrk>
yeah makes sense. the `v` made me incorrectly think it had to do with vectors
<scientes>
<andrewrk> I had to look that up:
<scientes>
this is like -fPIC
<scientes>
its best to have consistancy where possible
wilsonk has joined #zig
voldyman has joined #zig
hio has joined #zig
<Aransentin>
Can you conditionally add a function to a generic struct depending on some comptime value?
<scientes>
Aransentin, you are not being clear, however you can check for comptime values in the fucntion
<andrewrk>
Aransentin, yes you can. the strict answer to your question would utilize the `use` keyword but there may be an even simpler way to do what you're trying to do
<Aransentin>
I have a server that can be connected to with a unix socket and regular TCP, and figured I'd make a generic connection struct that didn't contain any host info if you were to only use the unix socket
<Aransentin>
So you'd have two init() functions in the struct, differing with each other depending on the enum you fed the function that returned the type
jjido has joined #zig
<Aransentin>
dunno if I'm making myself clear or not
<andrewrk>
Aransentin, one approach would be to simply put both init functions in the struct, and don't try to make one of them missing
<andrewrk>
the one that isn't called won't be analyzed
<Aransentin>
Oh, that's true
<andrewrk>
this is the pattern used by the standard library in many places
<shritesh>
How do I pass build options to my code?
<andrewrk>
that use case needs some improvements, but here's an example (just a sec, digging around)
<andrewrk>
mq32, you can do that. you may run into a few compiler bugs
<mq32>
would be good, so i can make you work! :D
<mq32>
*create you work
<mq32>
and make the compiler better
<andrewrk>
yeah. unfortunately at this point we have lots of people willing to do work but not enough funding to hire somebody besides me to work full time
<emekankurumeh[m]>
zig supports linker scripts just fine
<andrewrk>
oops. I meant that we have lots of contributors doing pull requests, which creates work
<andrewrk>
and keep in mind that anything that isn't Tier 1, you're probably going to have to get involved in the zig project development in some way for your project to be practical
<mq32>
arm cortex-m3, so arm 32bit
<mq32>
i'm fully aware of that
<mq32>
i'm going back to reading the manual, already half way through with some peeks forward
gamester has joined #zig
Ichorio has joined #zig
gamester has left #zig ["Leaving"]
<mq32>
andrewrk, do you plan to make it possible to have a kind of "type builder"?
<mq32>
so i could fully meta-program my own types?
<shritesh>
Isn’t that what comptime does?
l1x has quit [Read error: Connection reset by peer]
<mq32>
comptime is a requirement for "type builder"
<emekankurumeh[m]>
i remeber a post about comp-time psuedo structs a while back
<mq32>
what i mean is doing unions of types, adding fields to a struct type and so on
<mq32>
yes something like @reify *and* what tgschultz did
<mq32>
because you can also bake functions with comptime, you could create API generators
<mq32>
ultimate goal would be something like:
<mq32>
const ClockAPI = RestAPI("clock-api.xml");
<mq32>
var clock = ClockAPI.create("my-server.org");
strmpnk has joined #zig
<mq32>
const time = clock.get_time();
<mq32>
where RestAPI would create a struct type with member functions which provide a wrapper around a REST api
<hryx>
sort of reminds me of gRPC+protobuf but without the intermediate code generation step
<hryx>
neato
<mq32>
exactly that
<mq32>
zig could have it's comptime protobuf support :D
<hryx>
I'm into it
<mq32>
"yeah just protobuf me that multiline stringliteral, okaaay?"
dch has joined #zig
<hoppetosse>
I'm trying out tgschultz's pseudostruct to build shader structs with attributes and uniforms as fields
<hoppetosse>
typesafe shaders, w00t XD
<mq32>
hoppetosse, neat!
<hoppetosse>
do people still say 'w00t'?
<mq32>
wØØt?
<mq32>
but yeah, that's also an application
<hoppetosse>
i guess it's the same as leet -> 1337, but an exclamation of happiness instead of skill
dch has quit [Ping timeout: 252 seconds]
strmpnk has quit [Max SendQ exceeded]
Frank-Lesser has joined #zig
strmpnk has joined #zig
dch has joined #zig
l1x has joined #zig
<Frank-Lesser>
Hi all, first thanks to Andrew Kelley and all contributors for creating ZIG
marmotini_ has quit [Ping timeout: 272 seconds]
<Frank-Lesser>
just to mention since a few commits the example/hello_world/hello_windows.zig can't be build
<scientes>
I don't think anything works on Windows right now
<scientes>
big change, it will be fixed
<andrewrk>
scientes, careful saying stuff like that plz. do you have any cause to believe master branch is broken on Windows?
<andrewrk>
welcome Frank-Lesser
<andrewrk>
I'll take a peek at hello_windows.zig after these tests finish running
<Frank-Lesser>
Hi Andrew, hi Shawn , thx for the fast answer, just to introduce my self a little - I am maintainging a Smalltalk Virtual Machine since long time ( C / ASM )
<Frank-Lesser>
and I am lurking for porting it to ZIG
Aransentin_ has joined #zig
Aransentin_ has quit [Client Quit]
Aransentin has quit [Ping timeout: 256 seconds]
<Frank-Lesser>
as a small exercise my son ( who is studying computer science nearby Berlin ) have ported a small Path-Tracer to ZIG, hope to publish it soon
<hryx>
welcome Frank-Lesser. those sound like cool projects
<shritesh>
Is there another way to extract the value from a tagged union? My code is full of single case switch and empty else.
<andrewrk>
shritesh, you can access the union field directly just like in C - but in zig it's safety-checked
<shritesh>
Oooh. Nice.
<mikdusan>
fyi, branch:master builds examples ok for me on windows -> `zig build test -Dskip-release -Dskip-non-native` (0.4.0+df7aa9a4)
<scientes>
andrewrk, yeah i'm sorry. I was thinking #2527 landed
<mq32>
Frank-Lesser, thank's for the inspiration! wanted to write some pathtracer anyways, so why not do it in zig?
nilshi has left #zig ["WeeChat 0.4.3"]
<mq32>
andrewrk, scientes: is there already some kind of "package"/"library" list for zig?
<Frank-Lesser>
mike, thx I shall have a look, I shall ask my son ( he did the most work ) to publish it SAP - he is very busy now so hope it wil be soon
Frank-Lesser has quit [Quit: Page closed]
<hryx>
mq32: there's no comprehensive list yet, but one of the next release cycles (not the current one) will be focused on creating a package manager and package ecosystem
<hryx>
If you create something usable in zig that you want others to know about, you can announce it here or on the mailing list
<hryx>
or maybe it doesn't even need to be "usable", I dunno :>
<andrewrk>
anything "demoable" is eligible for that list :)
<andrewrk>
mq32, even when the package manager is fully complete it will be decentralized. so there is need of third party services to do package discovery
<mq32>
cool thing @ package manager
<shritesh>
Will it use the blockchain?
* shritesh
apologizes
<mq32>
so everyone *must* install all packages
<mq32>
what's the essential idea of packages? precompiled binaries or "include everything as source"?
<mikdusan>
the more pure zig (source) the better imo
<andrewrk>
mq32, source
<hryx>
ooooh shritesh now you dunnit! :D
<mq32>
i preferred binaries in my old days, but nowadays source is better ♥
<mq32>
has way better optimization potential
<andrewrk>
source lets us achieve out-of-the-box cross compilation
<mq32>
i think i read about zig doing "Link time optimization"?
<mq32>
and that, yes
<andrewrk>
you don't need LTO if you only create 1 .o file *taps forehead with index finger*
<mq32>
aaaah!
<andrewrk>
I got your LTO right here
<mikdusan>
zig already does a really good job at build-dependencies; think ccache for .zig files
<mikdusan>
whoa. posix-layer branch just passed `zig build test -Dskip-release -Dskip-non-native` for me on macos,linux,windows. i smell a merge coming.
<shritesh>
I hope we do *whatever rust does*. Using the Vulkano crate without having to install anything in Win/Mac/Linux was mind blowing when I first used it.
<andrewrk>
yeah zig is all about that, even moreso than rust
<mikdusan>
yeah unless you have RAM to comfortably spare, it's not worth risking crashing your host desktop.
<mikdusan>
ahhhh. i just noticed if i ssh into msys2-ssh-server on windows, run `zig build test` and ctrl-c ... it doesn't really ctrl-c. it keeps running.
<andrewrk>
there's no code that is intentionally blocking this
<andrewrk>
are you sure it's zig specific?
<mikdusan>
i'll poke around a bit after some merges. it might just be my choice of ssh/shell/env . i don't know yet.
<shritesh>
It could be one of ssh’s issues that the mosh project digs so much about.
<shritesh>
(You should totally try out mosh if you haven’t)
<mikdusan>
the behavior i'm seeing is: zig test runs.... output lines are coming... then ctrl-C and i get back to shell prompt... output keeps coming :)
<andrewrk>
maybe it's only killing the child process?
<hryx>
andrewrk: in zig_clang.cpp, I'm seeing alternating uses of reinterpret_cast<> and bitcast(). Do I understand correctly that reinterpret_cast is _only_ used to convert pointer types?
<hryx>
e.g. between the ZigClangXxx struct poitners and clang::Xxx class pointers?
<andrewrk>
hryx, that's correct. bitcast is used to safely convert the types that can't be pointers (some clang types are like this, such as QualType)
<hryx>
dope, thanks
<andrewrk>
we could provide bitcast overloads for the pointers too but I think that would be overkill
<hryx>
I see. I'm learning a lot about C++ features on this translate-c project :P
<hryx>
mq32 I'll take q peek
<andrewrk>
hryx, yeah, unfortunately the C API of libclang is completely nerfed
<mq32>
hryx, nevermind
<mq32>
i'm used to anything autoconverts :D
<andrewrk>
mq32, it was the u8 -> u4 - has the possibility of losing information
<mq32>
yep
<mq32>
@truncate(u4, ...)
<andrewrk>
that will chop off the upper 4 bits. another option is @intCast which will assert that the value is in the correct range
<mq32>
(my code snippet contains another bug, but that is fixed as well)
<mq32>
it'S really funny that in one project, i did an ascii to number conversion by "c & 0xF"
<mq32>
the "test" feature is cool :)
<mikdusan>
so i wrote a tiny loop in zig. sleep 1 second. print line. built executable, ran it. ctrl-c. runs in background and output keeps coming. had to powershell kill PID to stop it.
<andrewrk>
mq32, your function looks suspiciously like std.fmt.charToDigit
Ichorio has quit [Ping timeout: 252 seconds]
<mq32>
nice to know :D
<scientes>
why can't i divide by a comptime_int?
<scientes>
ome/shawn/git/zig/std/math/exp.zig:53:19: error: float value 6755399441055744.000000 cannot be implicitly casted to type 'comptime_int'
<andrewrk>
mq32, this is one of the difficult to explain but very intentional ways zig is designed. you, a brand new zig user, wrote basically an identical function as what's in the standard library, written by me & others
<mq32>
yeah, it's the obvious way
<andrewrk>
scientes, that looks like it should work. maybe there are hidden decimals after the zeroes that are getting rounded?
<andrewrk>
or maybe it's a bug
<scientes>
>
<scientes>
<mq32> it'S really funny that in one project, i did an ascii to number conversion by "c & 0xF"
<scientes>
but that won't truncate
<mq32>
scientes, yeah, but that was on a PDP-8 in PAL assembler
<scientes>
andrewrk, .shift_scaled = 0x1.8p+52 / N,
<mq32>
when you only have ~100 cycles to process all data from serial port, you scrape everything
<scientes>
its because the comptime_int is bound
<scientes>
rather than a literal
<andrewrk>
scientes, I doubt it's that. the compiler doesn't distinguish
<scientes>
mq32, they produce the same code, the truncate gets gets you better optimizations
<mq32>
yeah i know :)
<mq32>
and as i know that i have my range secured, i can safely truncate
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mq32>
question: i have a function that returns error{NoHash}!Color
<scientes>
mq32, zig has two, @intCast() where if it doesn't fit is undefined, and @truncate() that is always well defined
<scientes>
these come directly from LLVM-IR
<mq32>
i did some LLVM stuff myself :)
<mq32>
and i do a "try std.fmt.charToDigit()" in my function
<mq32>
my assumption was that this would not compile as my error union does not contain InvalidCharacter
<scientes>
yeah it wont
<mq32>
huh
<andrewrk>
you'll get an error message explaining that you'll need to address the InvalidCharacter error - try it out
<mq32>
oh, it only won't compile if the function is actually used
<scientes>
^^^ zig doesn't even look at code that isn't used
<andrewrk>
right - zig has lazy analysis. this is a core design premise that is relied on for many things
<mq32>
oh well, didn't think of that
<scientes>
just like with similar C optimizations you can generally work around it with volatile and extern
<scientes>
except that zig doesn't even *parse* it
<scientes>
only tokenizes it
<andrewrk>
it does parse it
<scientes>
i thought it could just get the top-level declaration
<mq32>
but no semantic evaluation?
<andrewrk>
mq32, right
<scientes>
i guess you have to because it is infinitely recursive
<scientes>
but you could add that to the tokenizer
<mq32>
okay, next thing: can i trivially compare two structs beeing equal?
<mq32>
or do i have to memcmp?
<scientes>
mq32, mem.compare
<scientes>
which is quite similar to memcmp, but allows arbitrary length types instead of just bytes
<hryx>
andrewrk: I'm trying to track down a crash I've caused in translate_c.zig. Is my assumption correct that it is safe to cast back and forth between ZigClangStmt * and ZigClangExpr * using @ptrCast()?
<andrewrk>
hryx, yes I believe that is correct & safe
<andrewrk>
I think Expr is a subclass of Stmt in clang API
<hryx>
k, great. I'll push what I've got in a sec and think some more
<andrewrk>
you can assert that it's safe by having an unused function in zig_clang.cpp which implicit casts one to the other
<andrewrk>
do yo usee what I mean? take advantage of c++ semantics to make it be a compile error if the class hierarchy disagrees with you
<hryx>
oh cool, ok!
<andrewrk>
I don't remember what the syntax for that would be in C++ offhand but in theory it should be possible
<mq32>
scientes, mem.compare is for slices, not single objects
<mq32>
i want something like "RGB(…) == Color { … }"
<scientes>
mq32, use @bytesToSlice
<hryx>
this question also arises partially because I'm wondering if I need to create e.g. `ZigClangImplicitCastExpr_getBeginLoc` when `ZigClangExpr_getBeginLoc` already exists, of I can just cast willy-nilly
<hryx>
not that I mind the extra typing
<andrewrk>
mq32, only some types in zig do not provide well defined memory layout. it would give you undefined results (not undefined behavior) to use memcmp with them
<andrewrk>
*only some types in zig provide well defined memory layout
<scientes>
but you could just have RGB return Color, and then you can just use ==
<mq32>
RGB returns error{…}!Color
<scientes>
then unwrap it
<mq32>
and i assumed that try either fails or returns Color
<scientes>
errors are values
<scientes>
this isn't c++
<mq32>
yeah, i know
<mq32>
but my assumption was "try x" == "if(x) |v| v else |err| return err"
<gamester>
Can someone explain to me what whitequark's issue with zig is? Clearly being explicit about whether overflow is intended or not is strictly superior, without it you won't even realize when your code is behaving bad! Is the issue about the "undefined behavior" label and not knowing what behavior the software will exhibit IF unintended overflow were to occur in release-fast mode?
<mikdusan>
gamester: unfortunately i cannot. that gripe is beyond my understanding
<mq32>
scientes: the error i'm getting is
<mq32>
error: operator not allowed for type 'Color'
<mq32>
where operator is ==
<andrewrk>
gamester, I believe the argument is that people will choose ReleaseFast in practice, and there will be bugs in practice, and so in practice zig will cause the existence of undefined behavior security exploits
<andrewrk>
it's a reasonable concern
<mikdusan>
mq32: inside Color define fn eql. then do (try RGB(...)).eql( Color { .R = 0x12... } )
<jjido>
will there actually be bugs? that's only if the codepath wasn't tested in normal mode right?
<mq32>
jjido, you cannot possibly test all cases where an addition of two i64 *could* overflow
<mq32>
but some people want *perfect* software security in every way
<scientes>
mq32, but there are often bugs whether it is UB or not
<scientes>
when they overflow or underflow
<mq32>
yeah, but with ReleaseSafe it isn't UB, isn't it? :P
<scientes>
so it isn't
<scientes>
its defined to crash
<mq32>
i like that, btw!
<mq32>
i can decide between performance and security
<jjido>
performance isn't exactly bad with ReleaseSafe
<scientes>
especially if key parts have the safety turned off
<jjido>
but yeah, people will go for ReleaseFast
<shritesh>
Rename release-fast to release-unsafe and release-safe to release. Then, Zig becomes Rust.
<gamester>
andrewrk: Ah okay, so the compiler 'knows' that a variable will never overflow and will optimize based on that, and it's this optimization that makes code more brittle/dangerous in the face of bugs?
<scientes>
rofl shritesh
<andrewrk>
one disconnect here is that I consider unintentional integer overflow to be a bug on par with undefined behavior
<scientes>
^^^
<scientes>
it is
<gamester>
andrewrk: compiler meaning llvm
<scientes>
I use SaturatingAdd and SaturatingMultiply defensively when coding LLVM
<scientes>
and I had some patches to add those to zig....
<hryx>
educating people through the official docs may be important ReleaseSafe should become the norm. Especially if you emphasize that non-security-critical hot loops can have checks disabled with a builtin fn call
<hryx>
*if it should become the norm
<andrewrk>
shritesh, there's an important distinction - Rust's release-fast mode still benefits from the safety features
<andrewrk>
...except for integers
<andrewrk>
scientes, btw you are of course welcome to resubmit any patches from closed PRs - just make it easier to merge them
<mq32>
i would appreciate not kicking out a "release fast" or "release unsafe" or whatever because sometimes even that teeny tiny bit performances matters
<scientes>
yes, I am just doing so much right now
<shritesh>
andrewrk: but that comes at a perf penalty, right?
<scientes>
shritesh, but rust has a goal to have the code be secure from itsself
<scientes>
which isn't really a goal for zig
<andrewrk>
shritesh, rust's borrow checker runs at compile time only. its release mode has defined integer overflow to be twos complement wraparound in release; trap in debug
<andrewrk>
zig is a general purpose programming language. that makes release-fast appropriate for plenty of use cases
<mq32>
if i want to have a member function with mutable self, do i have to "pointer" the self?
<andrewrk>
mq32, quick poll question: are you using an editor with zig fmt on save?
<mq32>
using visual studio code, but zig fmt currently failes because of syntax error
<mq32>
not having any "auto" stuff enabled
<hryx>
If anyone has a moment and the desire to help me debug something, I would greatly appreciate some eyes. Can't quite identify what is causing this to crash: https://github.com/ziglang/zig/pull/2569
<andrewrk>
hryx, I'll try to get to it today
<andrewrk>
I have a lot of PRs to look at
<hryx>
thanks a ton. I know you have a bunch on yer plate
<scientes>
why can't volatile be used on values, only pointers?
<hryx>
isn't it because volatile describes guarantees of a load/store?
<scientes>
C allows it on values
<hryx>
oh yeah
<scientes>
and i'm doing some float stuff where i need to force a calculation
<andrewrk>
you can always cast your value pointer to a volatile one
<scientes>
its just annoying to have to use a pointer
<scientes>
because float calculations can have side-effects in setting cpu status bits
<andrewrk>
if you're using volatile for something other than memory mapped I/O it's a code smell
Arghblarg has joined #zig
<andrewrk>
zig currently has no way to accomplish those side-effects except through inline assembly
<scientes>
volatile does it
<scientes>
oh I C
<scientes>
yeah you need volatile on values
<andrewrk>
I'm not sure that's correct
<andrewrk>
well maybe that's needed, but it would introduce semantics
<andrewrk>
what are these status bits?
<scientes>
overflow, underflow and nan
<andrewrk>
can you type up a use case / proposal?
<scientes>
yeah
<mq32>
are arrays packed by default?
<scientes>
no
<scientes>
oh array
<scientes>
i was thinking structs
<scientes>
mq32, @sizeOf
<mq32>
?
<scientes>
mq32, that gives you the packing of the array
<andrewrk>
shritesh, so the main feature of rust is that the safety is at compile time, which means you get it in both debug and release mode
<andrewrk>
in exchange, rust rejects some perfectly fine code that it cannot prove is safe
<mikdusan>
doesn't rust have -ffast-math option too?
<shritesh>
Yeah. My only concern was with the overflow issue.
<andrewrk>
assuming that zig manages to solve use-after-free etc in release-safe mode, there will not be a difference in safety between zig release-safe & rust release modes. however the rust release build will be much faster
<andrewrk>
oh if you're only talking about integer overflow, rust and zig are basically identical, except release-safe of zig has integer overflow checks enabled
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gamester has joined #zig
<gamester>
andrewrk: Identical? Isn't integer overflow defined in rust, meaning that x + 1 > x can't be assumed to be true? Whereas in Zig it can, and this is what whitequark is complaining about?
<andrewrk>
gamester, oops, correct - I misspoke above
<mq32>
have you ever heard the story of PGM image the gray? :P
<mikdusan>
hryx: where is 2569 crashing?
<mq32>
now that my basics are standing, let's do some colors! :)
<mq32>
is there an option to do a range-based loop like for(1...100) ?
<mikdusan>
hryx: i just cloned branch:translate-c-userland (3bbee1ba2e758d4bb5ea7d03b27133ffd6e4e9e2) built and ran a skip-non-native, skip release `zig build test` on macos and linux. no crash.
gamester has left #zig ["Leaving"]
<andrewrk>
hryx, have you tried using valgrind?
<hryx>
mikdusan: can you run this: `bin/zig translate-c-2 <some C file>`
<hryx>
good idea, I'll try valgrind
<hryx>
mikdusan: I just updated the gist with the C code that triggers the crash for translate-c-2
<mikdusan>
ah yes that triggers.
<mikdusan>
which os are you on
<shritesh>
mq32: no. Range-like syntax is only used in slices.
<hryx>
linux mint kernel 4.15.0
<mq32>
so a c-style for loop is more work?
<Arghblarg>
Hi, a follow-up to my questions from yesterday -- don't know if this sheds any new light but I was able to somewhat mitigate my issue using @inlineCall() - https://pastebin.com/mg8vB37U
fengb has joined #zig
<hryx>
mikdusan: that fault address looks suspiciously like a stack addy maybe?
<andrewrk>
this is an example of use-after-free that we've been discussing today
<Arghblarg>
OK, I had been told this might be the case, just wanted to be sure & post a simplified example. Thanks!
<Arghblarg>
Amazing stuff BTW, really excited at the prospect of being able to use zig in future projects. Thanks.
<hryx>
mikdusan: The `it.*` on line 352 is suspect to me. I'll step debug through this. thanks for your eyes BTW
<shritesh>
mq32: my understanding is that for is used for iteration over existing items. While is better here and has some neat capabilities compared to C
<mq32>
shritesh, my point was more "how can i count from 0 to n-1 in the least amount of characters"?
<shritesh>
mq32: while is probably the only way to do it.
<mq32>
i see one problem with the code: you spill the loop variable (only semantically useful in the loop) in the outer scope of the loop
<mq32>
so i have a variable i of type usize i can't reuse in a loop behind if i want to change the type (or reuse the variable in another subscope)
<scientes>
yeah its a minor nuisance, but it is fine
<mq32>
{ var i : usize = a; while(i < b) : (i += 1) { … } } would be semantically preferrable
<andrewrk>
mq32, every variable in zig is spilled if you don't use braces
<hryx>
mikdusan: I am so confused. I stepped through, and as soon as it calls ZigClangImplicitCastExpr_getCastKind(expr) it crashes -- it doesn't even step into that function. The arg `expr` looks like a totally normal address.
<shritesh>
I had a TA who bragged about knowing how to implement C++ iterators correctly.
<mq32>
andrewrk, yeah but i like to have my variables in the closest scope possible
<andrewrk>
hryx, that's a sign that the ABI is incorrect
<scientes>
shritesh, rofl
<mq32>
that's why i love the C++17 feature of "initializer if":
<mikdusan>
hryx: for me i'm getting what looks to be infinite recursion
<andrewrk>
hryx, e.g. check zig_clang.h file against clang.zig
<hryx>
andrewrk: would that mean an incorrect cast somewhere maybe?
<mq32>
if(auto it = vector.find(…); it != vector.end()) { /* do stuff with it */ }
<hryx>
ok. I've double checked a few times but it's gotta be somewhere in there
<scientes>
mq32, that is horrible, you don't even know the type of it
<andrewrk>
hryx, ah, sorry it was just a guess
<hryx>
mikdusan: I get that recursion when it doesn't crash (another problem to solve afterwards)
<scientes>
mq32, these are not real problems
<mq32>
scientes, zig does the same thing ;)
<shritesh>
mq32: not use, implement the STL iterator “interface”
<hryx>
hm, this is the first function to return a `ZigClangCK` enum
<mq32>
shritesh, nah, i'd rather built my own :D
<andrewrk>
hryx, you can try testing it in translate_c.cpp first
<mq32>
have enough c++ experience to know that iterators are broken beyond repair
<andrewrk>
and make sure the tests still pass
<hryx>
roger, I'll check that
<mq32>
scientes: yeah, but my inner semantic fetishist tells me to "not use the same variable for a different job again"
<andrewrk>
(that's still a worthwile change too, to make translate_c.cpp closer to using the C API)
<andrewrk>
mq32, if we wanted to actually solve that problem we'd need something like `deletevar` to end the scope of a variable without braces
<scientes>
mq32, its safe in zig, unlike C, because you can't reuse the same name in a nested scope
<mq32>
i have a problem with the "inverse" thing
<hryx>
BTW `ZigClangCK` is supposed to be `clang::CastKind` right? that's the only instance of the name not matching up exactly
<andrewrk>
but I think `deletevar` would be Too Complicated
<mq32>
nah, no deletevar
<mq32>
use the same variable (actual instance) for different semantic task (like iterating in another loop)
<hryx>
all tests pass for translate-c
<scientes>
you just use braces {}
<mq32>
yeah, probably
<scientes>
i've had reviewers complain about them, but they work
<mq32>
damn, i need to get some sleep. it's 0:37 already
<mq32>
i'll be back and built my raytracer!
<mq32>
*build
<andrewrk>
hryx, so that eliminates zig_clang.h and zig_clang.cpp as culprits
<hryx>
oh, sorry, I understand your suggestion now -- use that new function in the C++ code
<hryx>
I'll try now
<andrewrk>
ahh yes
<emekankurumeh[m]>
mq32 see std.meta.eql
Arghblarg has left #zig [#zig]
<emekankurumeh[m]>
mikdusan that's a problem with mingw itself I think. zig build has the same error
<hryx>
ok, replaced the `stmt->getCastKind()` with `ZigClangImplicitCastExpr_getCastKind()` everywhere. All translate-c tests pass still, no crash
<andrewrk>
that looks fine - but I realized I'm not reproducing your issue - I'm seeing something different
<hryx>
oh boy, dang. Yeah I think you and I are getting different errors in valgrind. Mine only has stack overflow, no jump on uninitialized
<andrewrk>
i'm also getting something different from gdb
<andrewrk>
did you push everything to hryx/translate-c-userland ?
<hryx>
I have one more small change I think - I'll push
<hryx>
latest is there now. I did also have changes where I was using ZigClangImplicitCastExpr_getCastKind instead of expr->getCastKind(), but I'm testing again with what's on GitHub just in case
<hryx>
same results
<hryx>
(my local working tree is what you see now)
<hryx>
FWIW `root_node.eof_token` does not seem to get set ever