waleee-cl has quit [Quit: Connection closed for inactivity]
nephele_ has joined #zig
nephele has quit [Ping timeout: 246 seconds]
nephele_ is now known as nephele
marijnfs has joined #zig
factormystic has joined #zig
marijnfs_ has quit [Ping timeout: 246 seconds]
factormystic has quit [Client Quit]
factormystic has joined #zig
RoguePointer has joined #zig
RoguePointer has quit [Quit: <>]
RoguePointer has joined #zig
reductum has quit [Quit: WeeChat 2.8]
Kingsquee has joined #zig
<daurnimator>
ikskuh: that's intentional: otherwise its impossible to e.g. open a file called "COM"
benjif has quit [Ping timeout: 260 seconds]
<daurnimator>
https://lwn.net/Articles/816085/ > A call to alloca() is made with a random value. This has the effect of "allocating" a random amount of memory on the stack, which is really just a matter of moving the stack pointer down by that amount.
<daurnimator>
^ interesting! I wonder if this would be a useful thing to do in zig
<foobles>
like having an alloca exposed as a function?
<shakesoda>
i've used alloca a couple times in c code but it is incredibly difficult to use both safely and such that it's actually a reasonable tool for the job (versus _anything_ else)
<shakesoda>
doesn't it also break zig's ability to know at compile time how big the stack is?
<shakesoda>
i could see complications arising
<yrashk>
Curiosity-wise, is ZIG_STATIC=ON supposed to work on master or is it currently broken?
joey152 has quit [Remote host closed the connection]
<fengb>
I had to manually convert it into a more intelligent copy (and hope the alignment is correct)
<shakesoda>
the fact that you had to aligncast is probably why
<fengb>
I tried alignCast without the manual slice conversion and still no good
<fengb>
Zig isn't recognizing it as a memcpy :(
marler8997 has joined #zig
<marler8997>
I've put together a patch for a qemu issue. I've built it and tried it out. Where can I find the configuration to build qemu for ziglang.org/deps/qemu...? And then how would I upload it?
<marler8997>
you've given access to the entire repo to the docker build, was that on purpose?
<marler8997>
I don't think the docker build needs access to README.md and LICENSE for example right?
<mikdusan>
are you speaking to .dockerignore ? we can odd those. not terribly important imo
<marler8997>
docker is weird, when you perform a build, it recursively copies all files and directories in the Dockerfile's containing directory to the virtual build image
<marler8997>
so typically I put the Dockerfile in a subdirectory, so I can limit what files it copies to the build image
<mikdusan>
it recursively copies files, but files not used are not a dep of the image. however, there is the overhead of the copy to consider.
<daurnimator>
:( child process needs to love
<marler8997>
true
<daurnimator>
too many things I want to work on right now
<marler8997>
they are copied for the build, but not copied to the image unless you explicitly copy them
<mikdusan>
docker has shortcomings in that way and imo they _really_ missed an opportunity to be able to set a docker ARG via RUN command
<mikdusan>
or at least build up an env as RUN commands are issued
<marler8997>
yeah, it doesn't bug me too much because I can't really get behind docker anyway. The "layer" approach doesn't seem right to me. I'd rather having something like Nix where you just pull in all the packages you need into your container, you could even share the memory with the host because they are all named from hashing their contents
<marler8997>
IMO you shouldn't have to rebuild all the things in your image just because you made a change in the middle. I understand why you have to, because linux packages can be installed anywhere, which is why a nix-container would solve that problem
<mikdusan>
docker could use a .dockerinclude file; really what I need here is include 2 dirs and that's it. but I guess the docker-way would be make 1 subdir, and change the instructions to build with that subdir
<marler8997>
yeah, that's what I end up doing
<marler8997>
the real reason is to prevent other people from accidently adding files to the docker build
<mikdusan>
oh yeah for publishing images ; this particular image is a bit... off the norm. the image is never published and we only need a containter to fetch the file.
<marler8997>
actually we do the same, we just use docker to create a stable dev environment
<marler8997>
we mount a host directoy and build directly in the host-mounted volume
<marler8997>
but I find nix does just as well :)
<Kingsquee>
so I've been playing around a bit with how well struct state changes are optimized
<marler8997>
goodness the qemu-static build takes a while
<andrewrk>
Kingsquee, I'm curious but I haven't been following the chat. what are you experimenting with?
<Kingsquee>
andrewrk: well, for context, in Rust I wrote a macro that essentially generates a renderer based on declarative render passes, with the idea that it would remove the unnecessary branches at compiletime and do more-optimal codegen than a traditional do-everything-at-runtime library
<Kingsquee>
but then I thought wait a minute, I should actually check that the optimizer is as intelligent as I think it is
<shakesoda>
that sounds horrifying
<mikdusan>
marler8997: did your build finish and patch does what is needed?
<Kingsquee>
shakesoda: it's actually really comfy to use :)
<marler8997>
build finished, let me check it real quick
<shakesoda>
it sounds like a design where by the time you've made it you've already lost :(
<shakesoda>
to hellish complexity
<Kingsquee>
I already made it so ¯\_(ツ)_/¯
<Kingsquee>
andrewrk: I'm testing to see if, with a struct with arbitrary fields, if the language can tell if some fields are not changed within the cacophany of branches and loops
<Kingsquee>
and therefore remove the branches that are conditional on them
<Kingsquee>
I'm trying to test that by inspecting the labels generated from the associated printfs
<marler8997>
looks like it fixed my issue
<marler8997>
but I haven't done any substantial testing with my patch
<mikdusan>
marler8997: 👍
<marler8997>
is there a way we could run zig's CI without first before we integrate it?
<andrewrk>
ahh yes. llvm is not good at this. zig the language should be since zig is allowed to re-order fields and remove unused fields
<mikdusan>
yup
<andrewrk>
I don't think llvm is allowed to remove unused fields from structs
<Kingsquee>
there should be two 'A' strings, since 'foo.a' can be modified at runtime, but only one 'B' string, since it's never changed
<mikdusan>
marler8997: yup I alway PR the qemu bumps to zig ci
<Kingsquee>
andrewrk: I'm not interested in removing the fields, just removing code that is conditional on the unchanged fields
<marler8997>
perfect
<mikdusan>
marler8997: I think I'll experiment with pushing those dirs to a subdir. might as well.
<Kingsquee>
like if 'b' is false and never changes, anything that requires 'if b == true' should be stripped
<andrewrk>
Kingsquee, ahh interesting
<Kingsquee>
what we're seeing here is that when allocated on the stack in Rust, the stripping occurs
<Kingsquee>
when allocated on the heap, it's not
<Kingsquee>
in C++, it seems to be stripped with both stack and heap
<Kingsquee>
in Zig, it's only stripped on stack if std.debug.warn isn't used
<marler8997>
at my job we usually have a "docker" directory and I build the Dockerfile in a subdirectory called "build"
<marler8997>
so: docker/build/Dockerfile
<mikdusan>
hmm... reading the dockerfile reference... "context". I might just use that
<marler8997>
but this repo is for the docker
<marler8997>
context sounds good
<andrewrk>
Kingsquee, interesting. I wonder what's different
<Kingsquee>
I mean, the data for storing gl state changes is pretty tiny, so storing it on the stack is trivial from a practical point of view
<Kingsquee>
but it's a little unsettling to see the optimizer undulate so eldrichly
<shakesoda>
trust no one
<Kingsquee>
not even zig
<andrewrk>
Kingsquee, oh you're using a page allocator and we don't have annotations for noting a syscall has not being a memory fence
<andrewrk>
every time you call allocator.create() you're doing an mmap which invokes a syscall and the compiler understands that any memory could have changed in between syscalls
<Kingsquee>
andrewrk: is there anything we can do about it?
<Kingsquee>
andrewrk: scroll to bottom of source code
<Kingsquee>
er, assembly code
<Kingsquee>
the four strings are still there
<andrewrk>
what are you expecting to see?
<Kingsquee>
should only be "1 A True", "1 A False", 1 B False"
<Kingsquee>
as foo.b is never true
<Kingsquee>
see: the C++ version
<Kingsquee>
(brb)
<andrewrk>
hmm I see
<andrewrk>
well it would be pretty straightforward to continue narrowing this down and also produce the equivalent C code and once the test case is small enough we can see how the IR is different
<Kingsquee>
not sure I follow
<Kingsquee>
how could I narrow it down more than two bools in a struct :V
<Kingsquee>
you mean call c.malloc?
<Kingsquee>
mm, I think I see
<mikdusan>
I need to add a "serial" number for versioning qemu tarball that bumps even when qemu upstream version doesn't bump. does this look too silly?:
<mikdusan>
qemu-linux-x86_64-5.0.0-z0.tar.xz ; I was thinking `-zN` for zig. rather than `-rN` which is used by alpine APK
<Kingsquee>
sorry, how do I convert a ?*c_void to a ?*Foo?
<mikdusan>
let's say I'm making a 3rd-party package in zig and one comptime setting is a choice of crypto hasher; the idiom `@hasDecl(root, "foo_Hasher")` doesn't quite work because someone else's package could use the same root decl. I can gen a UUID and use that for root.@"<UUID_GOES_HERE>" but it's not very friendly. any ideas?
<daurnimator>
mikdusan: name it after your package? `@hasDecl(root, "mypackage_options")` ?
<daurnimator>
and then look for a field in that struct: `root.mypackage_options.Hasher`
<mikdusan>
doesn't quite work when there won't be global package naming
<marler8997>
mikdusan: when will the new qemu be uploaded and available in the CI tester?
<daurnimator>
IMO we need a central registry of package names. not having one was a huge problem in the lua community
<daurnimator>
we ended up with e.g. 10 packages all named "md5", all with different APIs, and no idea which one was compatible with what
<mikdusan>
marler8997: see comment in #5245 . i think you need a conditional to handle both cases
<marler8997>
ah I just saw that, will take a look
<mikdusan>
daurnimator: yes exactly why I think the @hasDecl idiom only works for `std`
<mikdusan>
note; I'm not suggesting one way or another if we need a central registry; just wondering if I overlooked something obvious with @hasDecl(root,...)
bluesunground has quit [Ping timeout: 260 seconds]
<marler8997>
that's what I suggested to LemonBoy but he said it wasn't necessary in the next comment
ifreund has joined #zig
<marler8997>
ok I've replied on #5245, I think I understand what's going on now. I think LemonBoy's original patch was correct. It was counterintuitive, which is probably why the bug happened in the first place
<marler8997>
It is calling memory_reserve, on the memory that was just freed
<andrewrk>
daurnimator, this might just be a missing coercion from *@Frame to E!anyframe
<andrewrk>
yeah, that's supposed to coerce
foobles has quit [Ping timeout: 245 seconds]
<mikdusan>
marler8997: makes sense; can you make a PR to qemu-static
<marler8997>
yeah building it now
<marler8997>
probably take another 20 to 30 minutes to build/test
<marler8997>
Ordered the new ryzen 3900x pc though :)
<mikdusan>
for real? nice
<marler8997>
yeah I've been overdue for a new linux PC, took forever to find a good motherboard for it though
<marler8997>
spent $435 on the CPU, and around $400 for the rest (memory, motherboard, SSD, power supply), but it's completely headless, no gpu, just raw cpu power to build things :)
<mikdusan>
btw I think there's something of a race-condition in qemu's build. I'm seeing large variances during build.. sometimes 270s, sometimes 400s where the latter doesn't seem to run all my cores as much
<mikdusan>
how much RAM?
<marler8997>
32 GB
<marler8997>
I just upgraded my old linux PC from 4 to 8...building LLVM/Clang/ZIG with only 4 GB is not fun
<mikdusan>
especially with gcc.
<marler8997>
ah
<andrewrk>
after #5246 it should be reasonable to bootstrap zig with 4 GiB (without the optional LLVM features enabled)
<mikdusan>
during optimizing builds gcc9 got noticably hungrier building llvm/clang
<marler8997>
oh weird, I manually edited the diff file with emacs and it automatically modified the line counts for me
<marler8997>
kinda cool
<marler8997>
looking at a diff of a diff file is pretty weird by the way
<mikdusan>
andrewrk: reading between the lines... so #5246, a ci-build would _not do unit tests for zig0.exe, zig1.exe, zig2.exe; in other words only zig.exe ?
_whitelogger has joined #zig
<andrewrk>
mikdusan, if bootstrapping only took a couple minutes then probably the CI would do the entire process every time. why not? if bootstrapping ends up taking longer than, say, 10 minutes, then probably it will be 1 CI's job to do bootstrapping to make sure it works, and another's to simultaneously use a cached zig binary for the main test suite
ur5us has joined #zig
<marler8997>
build/test finished, appears to be working
fcambus has joined #zig
dddddd has joined #zig
<mikdusan>
marler8997: building now
<marler8997>
k, well I'm off to bed, will have to come back to this tomorrow
<andrewrk>
night
niftynei has quit [Ping timeout: 265 seconds]
niftynei has joined #zig
Nypsie has joined #zig
Chris660 has joined #zig
dddddd has quit [Ping timeout: 256 seconds]
aurele has joined #zig
aurele has left #zig [#zig]
kenaryn has joined #zig
kenaryn has quit [Client Quit]
kenaryn has joined #zig
return0e has joined #zig
drasko has joined #zig
pystub has joined #zig
st4ll1 has quit [Quit: WeeChat 2.8]
<daurnimator>
andrewrk: okay awesome; should I open an issue for that coercion in particular?
waleee-cl has joined #zig
kenaryn has quit [Quit: leaving]
kenaryn has joined #zig
<kenaryn>
damn you it works!
<kenaryn>
wrong channel, my apologies :)
ur5us has quit [Ping timeout: 260 seconds]
Kingsquee has quit [Quit: Konversation terminated!]
metaleap has quit [Quit: Leaving]
kenaryn has quit [Quit: leaving]
kenaryn has joined #zig
metaleap has joined #zig
klltkr_ has joined #zig
gazler has quit [Remote host closed the connection]
kenaryn has quit [Quit: leaving]
kenaryn has joined #zig
kenaryn has quit [Quit: leaving]
kenaryn has joined #zig
drasko has quit [Ping timeout: 240 seconds]
via has quit [Ping timeout: 265 seconds]
via has joined #zig
<ikskuh>
daurnimator: preparing some response for the openFile thingy
<daurnimator>
ikskuh: take out the check in windows.sliceToblahblahblah that the BadPathName is coming from
* ikskuh
always feels so dirty when hacking around in his std lib :D
<ikskuh>
reaches the same unreachable
<ikskuh>
yes, both on windows 10 and win64
<daurnimator>
ikskuh: that was when trying `\Global??\COM3`?
<daurnimator>
ikskuh: also can you share e.g. a screenshot of object manager?
<daurnimator>
I forget what this stuff looks like
<ikskuh>
oh wait
<ikskuh>
\Global??\COM3 gives me filenotfound
<ikskuh>
\\global??\com3 reaches unreachable
<daurnimator>
ikskuh: so follow up on the FileNotFound..... you *do* have COM3 right?
<daurnimator>
ikskuh: show me object manager contents :)
<ikskuh>
how do i open object manager?
<ikskuh>
i have device manager and it shows me COM1 and COM3
<mikdusan>
so return is triple-purposed... return { payload or error or error-union }; maybe we should make this explicit - return payload type of fn only. and `fail error.ThisIsReal;`
<ikskuh>
"throw"
<mikdusan>
`raise`
metaleap has joined #zig
kenaryn_ has joined #zig
kenaryn_ has quit [Client Quit]
kenaryn has quit [Quit: leaving]
kenaryn has joined #zig
dddddd has joined #zig
pystub has quit [Ping timeout: 256 seconds]
jonathon_ is now known as jonathon
kenaryn has quit [Quit: leaving]
chapl has joined #zig
pystub has joined #zig
chapl has quit [Quit: Leaving]
chapl has joined #zig
chapl has quit [Client Quit]
chapl has joined #zig
drasko has joined #zig
cole-h has joined #zig
<chapl>
Man, I've been using Discord for a while and I just realized how great IRC is. Dude, should have checked out IRC way earlier lol
Xavi92 has joined #zig
chapl has quit [Remote host closed the connection]
chapl has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<oats>
is there an idiomatic way to read a full line of input from stdin?
<tdeo>
i think there's a function that gets the return value actually
st4ll1 has joined #zig
<tdeo>
yeah, std.os.linux.getErrno
drasko has quit [Ping timeout: 246 seconds]
wozeparrot has joined #zig
<andrewrk>
pmwhite, there's a missing abstraction layer in std.os as a wrapper API for this to give it zig types and errors
<andrewrk>
it would be std.os.timerfd_create (even though it only compiles on linux) and it would have e.g. an error union as the return value
<andrewrk>
you can think of `std.os` as "if there was a POSIX API for this and it used zig types"
foobles has joined #zig
<Flaminator>
andrewrk are there any plans to add a defer that only runs when no error is returned? We have defer for every possible return and errdefer for when an error is returned but nothing for when a non error is returned.
<andrewrk>
Flaminator, no plan for that
<Flaminator>
That's fine, it's not as useful as the other 2.
r4pr0n has joined #zig
joey152 has quit [Remote host closed the connection]
joepie91 has joined #zig
<andrewrk>
if anyone wants a fun contribution of deleting code, look for "TODO: Remove nakedcc/stdcallcc once zig 0.6.0 is released. See https://github.com/ziglang/zig/pull/3977"
chapl has quit [Ping timeout: 272 seconds]
<joepie91>
I'm working on an experimental programming thing that targets embedded devices like microcontrollers (a bit like https://xod.io/ in concept, but also different enough to warrant a separate project), and because I don't really want to be writing compilers for every possible target architecture, I'm trying to decide on an IR - one of the options is the LLVM IR, another is nabbing XOD's C++ codegen, but I'm also considering using
<joepie91>
Zig as the IR
frett27 has joined #zig
<joepie91>
would Zig be a usable option for this? considering that my main goals are to catch code/IR gen errors early, and it being relatively easy to get something working going
<joepie91>
(and what would some caveats be that I might run into? aside from the language syntax occasionally changing as someone else already told me about)
<joepie91>
andrewrk: sorry, one sec, unexpected phonecall :P
r4pr0n has quit [Remote host closed the connection]
r4pr0n has joined #zig
chapl has joined #zig
chapl has quit [Remote host closed the connection]
<foobles>
andrewrk I got ?T == T to work! :D
<foobles>
it doesn't work on vectors though
<foobles>
but yeah! :)
chapl has joined #zig
<constptr>
andrewrk: are you planning to add gcc backend too for zig?
<andrewrk>
nice work foobles
<andrewrk>
constptr, that's a good use case but I don't think the "reference compiler" will do it. I would weclome a third party to take on that project (and it will be helped by having a language spec)
<constptr>
Ok, thanks
chapl has quit [Remote host closed the connection]
<tdeo>
it feels too inconsistent with generic structs so i don't like it
chapl has joined #zig
<ifreund>
I like how it saves on indentation
<tdeo>
> I'll open a separate proposal to remove support for async fn in favor of callconv(.Async) for uniformity.
<tdeo>
andrewrk: can't find this, was it forgotten?
<tdeo>
wait async fn is gone now right
<tdeo>
no, still seems like the syntax exists
<fengb>
It's only a type definition now
reductum has joined #zig
chaplchapl has joined #zig
chaplchapl has quit [Client Quit]
<andrewrk>
it's a calling convention which can be inferred
<chapl>
These join messages are so weird to see lol
<andrewrk>
I think most IRC veterans disable join/part messages
<chapl>
Using HexChat. Can this be done client-wise?
<tdeo>
so `async fn` does still exist in the language, is it redundant and can be removed now?
<andrewrk>
chapl, yes - that's what I use too
<andrewrk>
settings -> preferences -> chatting -> general -> miscellaneous -> hide join and part messages
<andrewrk>
tdeo, yes it should be removed in favor of callconv(.Async)
<chapl>
You are a treat. Thank you andrewrk!
<chapl>
(Oh and is HexChat gonna highlight every message for me if the message contains my name?)
<andrewrk>
yes and that is also configurable
<andrewrk>
chapl, ^
<chapl>
That's neat. Gonna leave it unconfigured though
<andrewrk>
your settings now match mine. default + disable join/part messages
<waleee-cl>
ifreund: river looks intresting, I don't think I have seen a tiling wm where you can use a different mod-key in each keybinding
<chapl>
So, I'm using the vim plugin/extension for Zig and I was wondering whether the used color scheme is the default color scheme of Vim. I like it a lot and I'd like to use it in VS Code too.
<andrewrk>
the vim plugin only communicates to vim things like "this is a keyword", "this represents storage", "this is a string" and vim maps that to its color scheme
<chapl>
Ah. So it must be the default color scheme then. Gotcha.
<andrewrk>
can't wait to ditch vim for a zig IDE
<andrewrk>
I'd do it in a heart beat
<Nypsie>
I'd do it if it comes with a good visual debugger :p
<fengb>
wat
<fengb>
Traitor!
<andrewrk>
I'd stab anyone in the back for editor type awareness and advanced refactoring capabilities
<chapl>
You'd switch Vim with an IDE? Really? Wowzers. Not in the sense of "Wow you dirty stinking rat. Traitor.". Actually kinda surprised because: Vim, Dvorak, actually typing real fast etc..
<tdeo>
nobody's made a language server based on the dump-analyis output yet :(
<alexnask>
The IDE could have a vim mode ;)
<ifreund>
waleee-cl: i think you can in most tiling wms I know of, but glad you find it interesting!
<chapl>
Like VS Code has a Vim mode too. Right.
<chapl>
(Achievable with extension)
<fengb>
It's terrible but it exists yes
<chapl>
I think I'm watching Andrew's presentation "The Road to Zig 1.0" for the fifth time. Something's pulling me back every single time.
<waleee-cl>
ifreund: mod1 is usually limited to one key, in the ones I have tried you cant have eg 'logo key'+q = kill window, alt+space = run dmenu
kenaryn has joined #zig
<joepie91>
andrewrk: well, that took a little longer than I expected, sorry for that. my immediate goal is to ideally target the typical cheap microcontrollers (Arduino, STM32, ESP8266/ESP32), though I realize that the LLVM backends for two of those are experimental at best. I'm not too concerned about having to update codegen to deal with syntax changes and such, so long as it doesn't mean any serious structural rewrites, because this is
<joepie91>
just a hobby project and not something that needs to run in prod any time soon :P
kenaryn has quit [Client Quit]
<joepie91>
more important is that I have something that can work Right Now, basically
<ifreund>
waleee-cl: well my knowlege of wms is far from complete, i see no reason to impose artificial restrictions on my users though :D
<andrewrk>
joepie91, I want zig to support this use case but the reality is that to make this work Right Now you are probably better off targeting C and using the arduino compiler
<andrewrk>
check back in a year or two :)
<joepie91>
andrewrk: any particular reasons that make it unsuitable?
<chapl>
andrewrk: You need to do more livestreams ma boi. :D
<andrewrk>
joepie91, the llvm backends being experimental as you noted
<andrewrk>
joepie91, oh, stm32 is ARM? that actually is pretty well supported already
decentpenguin has quit [Quit: decentpenguin]
<andrewrk>
ESP8266: "Processor: L106 32-bit RISC microprocessor core based on the Tensilica Xtensa Diamond Standard 106Micro running at 80 MHz" - is this a bespoke ISA?
Nypsie has quit [Quit: WeeChat 2.8]
<andrewrk>
anyway, I want to make it easy to contribute support for a huge range of target architectures in the self-hosted backend but we're just not quite there yet
<joepie91>
andrewrk: ESPs are Xtensa
<joepie91>
andrewrk: which is kinda sorta like a lego block architecture, you feed the instruction set you want into a tool and then it craps out a custom Xtensa derivation with toolchain, chip design, etc.
<joepie91>
but Espressif, the company behind the ESPs, is contributing to LLVM now
<andrewrk>
interesting
<joepie91>
so support for that will be improving over time
<tdeo>
does `async functionInferredNotToBeAsync();` make that function async? rewriting the tests
<andrewrk>
tdeo, yes, it forces the calling convention to be async
<joepie91>
(it's unfortunate that Xtensa is proprietary because the premise behind it is really cool)
<andrewrk>
yeah that is really cool. It would be interesting to try to support that in a real way
<chapl>
I'm wondering too what `async` actually does. I'm having a hard time understanding async/await/suspend/resume.
<andrewrk>
chapl, good timing, because today I am working on a redisconf2020 talk titled "Modeling Data Concurrency with Asynchronous I/O in Zig"
<joepie91>
andrewrk: anyhow, on the more practical side of things, AFAIK Xtensa and AVR both *work* in LLVM, they are just not particularly performant - but that's not very important for my usecase at the moment :P so is your recommendation against Zig just based on the LLVM support concern, or are there reasons within Zig itself as well?
<joepie91>
(I really really really do not want to codegen C, can you tell :P)
<andrewrk>
chapl, it will be available on may 12
<chapl>
Boy am I excited to see that talk. :D
<andrewrk>
joepie91, mainly based on LLVM support concern, and lack of a zig backend alternative. one more thing: zig source code is designed to be source, not generated code, so it's not the exact correct abstraction level for your project. however it would be easy to switch your codegen from zig to ZIR (Zig Intermediate Representation) once that is stable
<joepie91>
andrewrk: so all in all, when comparing the options of 1) LLVM IR, 2) Zig, 3) ZIR, which would you expect to be the optimal solution in my case?
<andrewrk>
this would then have the ability to be rendered directly into binaries, to C, or through LLVM to any of those backends
<waleee-cl>
is the "do not allow interleaved field declarations in structs"-proposal merged?
<oats>
I'm getting a weird build error with a string:
<oats>
./src/lexer.zig:52:42: error: expected type '[]u8', found '*const [21:0]u8'
<joepie91>
while LLVM IR would be the abstraction level I'm looking for in principle, AFAIK it would also include less correctness/safety checks
<joepie91>
and I don't know enough about these options to make an informed choice :P
<joepie91>
(yet)
<andrewrk>
joepie91, if you want to place your bets on zig for the future, then (2) for Right Now, with a plan to switch to (3) in 1-2 years
<joepie91>
so it's difficult to weigh for me whether the extra checks provided by going through Zig would make up for it being the wrong abstraction level, for example
<andrewrk>
I'm guessing a lot about your project but probably LLVM IR is the most correct abstraction level that is available to you right now, and I don't think the safety checks issue is what you think it is
<oats>
I've never had an issue giving a string literal to something that took a []u8 yet
<joepie91>
andrewrk: I'm listening :P
<andrewrk>
LLVM IR is well documented and the undefined behavior that you have to avoid makes complete sense
<andrewrk>
e.g. you have the option to specify "non null" on a parameter. if that parameter is null, it's UB. so make sure you don't use that attribute unless it's correct
<andrewrk>
all UB in LLVM IR is like this
<andrewrk>
there is a common misconception that it has the same UB problems as C, where a missing trailing newline technically means your entire program is UB
<joepie91>
(what.)
<andrewrk>
oats, const / mutable mismatch
<andrewrk>
string literals are immutable
<andrewrk>
waleee-cl, yes
<oats>
ahh, I gotta mark the recepient as const
<chapl>
I'm so thrilled. Actually want to help a lot with Zig and everything around it, but I just don't know where to start. Originally coming from Go and Java. Had a look at the issues in the Zig repository and I figured that I can't contribute to a single issue. Maybe it's because of my little to no knowledge about memory etc. - That being said, I do plan on doing documentation work. Improving the documentation generator and documentation
<chapl>
design itself. It's time to kick C crud to the curb (please don't be offended by that lol)
<joepie91>
andrewrk: and how would the two non-C options available today (Zig vs. LLVM IR) compare in terms of memory safety? in my usecase
<andrewrk>
chapl, have you read CONTRIBUTING.md and looked for the label "Contributor Friendly" ?
<chapl>
I indeed did. What you might call "Contributor Friendly" might not be contributor friendly to people that don't have done a lot of stuff with C or C++ in the past.
wozeparrot has quit [Quit: Connection closed for inactivity]
<andrewrk>
chapl, some issues are as simple as, "submit a bug report to this other project"
<andrewrk>
that might help get started
<andrewrk>
joepie91, essentially the same. you will be doing manual memory management either way
<ifreund>
if you want something mindless to do, migrating parts of the std to take advantange of top level fields might be desireable :D
<chapl>
andrewrk: Aight, gonna have a second look then. ^^
<andrewrk>
joepie91, there are some things in the works to provide use-after-free protections for heap allocations in zig but I don't see how that would apply to using zig as a code generation target
<chapl>
ifreund: Mind elaborating on that a bit more? :)
<joepie91>
andrewrk: I see, thanks for the answers. I think my conclusion from this is to target LLVM for now, and keep an eye on Zig from afar for potential future use :P
<andrewrk>
that seems quite reasonable
<andrewrk>
you could write your application in zig that generates the LLVM IR tho :)
<joepie91>
heh, for the actual application stuff I'm sticking with the tools I have and know for now :P
<andrewrk>
fair :)
<chapl>
ifreund: Discovered your comment on the issue. I see what you did there. ;)
<andrewrk>
ifreund, I was thinking about starting to capitalize the file names in that case since it ends up being the type name. e.g. Decoration.zig
<chapl>
Please don't. I like the consistency. D:
<ifreund>
andrewrk: yeah i was considering that, I think it's the right way to go
<chapl>
yikes
<oats>
ooh, that's cool
<ifreund>
since the files are the objects now, not namespaces containing the objects
<andrewrk>
chapl, I think you misunderstand the situation, this is making things more consistent
<chapl>
I don't know how to feel about this. I'm scared thinking about Zig becoming a victim to convoluted OOP. "ObjectFactoryCreatingFactoryBean.zig" hell yeah
<chapl>
This might be a bit extreme as an example
<andrewrk>
the only thing happening here is reducing one unused namespace level
<ifreund>
^
<chapl>
so that x.decoration.Decoration becomes x.Decoration?
<andrewrk>
precisely
<chapl>
I see.
<andrewrk>
I don't think you have to worry about these OOP things, since zig doesn't and won't have constructors or destructors
<andrewrk>
we don't even have language-supported vtables, although that's an open issue
<chapl>
I know. I was about to chatter about this today but stopped thinking about this.
<ifreund>
i'm starting to bring polymorphism into my codebase as well, though I've decided to keep it simple and just use a tagged union of impls + switch statements
<ifreund>
well it's already implemented, but there's currently only one impl
<chapl>
I wanted to express that I think concepts/contracts are a way better solution to polymorphism than interfaces/traits. Now, one might ask what's the difference. Well concepts/contracts are the idea of expressing behavior and/or the ability to do something while interfaces (runtime-based) and traits (compile-time) are only specifying behavior. Oh and I'm actually talking about traits in terms of Rust traits. I don't like them. They just
<chapl>
hide stuff. It's magic for me.
<oats>
but they don't "hide" anything :o
<oats>
they're just descriptions of behavior
<chapl>
So
<chapl>
Hold on right there :D
<oats>
trait-based polymorphism is best polymorphism
<fengb>
We already have traits. They’re just adhoc and not we’ll defined
<fengb>
`fn format` is a trait that you just need to know
<joepie91>
hopefully this doesn't end in classes/inheritance :P
<chapl>
All I know it's hard to track down which function comes from which trait in Rust. All this prelude import bullshit. Idk
<chapl>
Pardon for my foul language
<oats>
s'all good :)
<andrewrk>
I think that's an inherent property of polymorphism
<joepie91>
chapl: the concept of a pipeline operator may be interesting here
<joepie91>
where you sorta kinda do method calls except the methods are identifiers declared in scope
<joepie91>
so they are always traceable
<ifreund>
andrewrk: one other thing I thought about while doing this was that we could have different file extensions for toplevel enums and unions (e.g. thing.enum.zig)
<chapl>
Rust actually could have been really wonderful if people hadn't started abstracting the hell out of it.
<ifreund>
isn't that just a terrible idea?
<andrewrk>
it means looking at code and only knowing at runtime(!) where in your codebase a function call will go to
drasko has joined #zig
<andrewrk>
ifreund, that's a natural direction for this to go, but I think if we take a step back, it is clear that we should not do something weird like that
<oats>
chapl: haha, some folks (myself included) wouldn't mind if rust's type system took some shrooms and abstracted a bit more :P
<oats>
I don't think rust was ever meant to be a simple language
<andrewrk>
making all files structs instead of a bespoke "import" type was a simplification. making different "kinds" of source files is a complication
reductum has quit [Quit: WeeChat 2.8]
<foobles>
how do you get a vector type? I see @Vector no longer exists and I don't know how to use @Type
<ifreund>
yeah that totally makes sense, to be clear I don't actually support that as a proposal just wanted to bring it up
<andrewrk>
foobles, there is std.meta.Vector and the implementation shows you how to use @Type
<chapl>
foobles: They do exist in 0.6.0?
<andrewrk>
foobles, it's also on the table to add vector type syntax, if we can come up with something good
<foobles>
oh cool, alright
<foobles>
thanks
<andrewrk>
also the builtin still exists
<chapl>
oats: What type of abstraction are we talking about here?
<chapl>
If I think about this, I originally came from Java, where everything gets abstracted in some way. Kinda funny to think about this, me now ranting about too much abstraction lol
<oats>
chapl: rust's type system enables the kind of polymorphism it uses. I wish it had even more powerful polymorphism, but it would require a more powerful type system
<oats>
ahhh, I'm talking about like higher-kinded types and such
drasko has quit [Ping timeout: 272 seconds]
<oats>
most OOP woes IMO are caused by multiple inheritance
<oats>
I very much doubt zig (or rust for that matter) will get anything like that
<chapl>
If Zig becomes C++2, I'm outie. I'm gone faster than you can blink. (That should not happen as andrewrk states he won't let that happen in one of his presentations)
<ifreund>
yeah not a chance
<chapl>
andrewrk: Is the async/await threadpool always being initialized with the available cores? Like, if I had 8 cores and 16 threads avail, would it use all 16 threads?
<tdeo>
i still really like both rust and zig, though
<tdeo>
i feel like rust is really good at a lot of things but some problems just give you a lot of friction in it
<chapl>
I don't say Rust is shit. I'm actually very glad having Rust around because people can build safe and robust software with it. I'm just saying me as a developer I'm not happy with it. It doesn't bring to me, as a developer, programming in Zig.
<chapl>
doesn't bring me joy*
<oats>
*spark joy :P
<chapl>
Ok, I'm having troubles writing rn, because it's late and I'm typing too fast
<tdeo>
rust is fun until i have to pull out Weak<RefCell<T>>
<chapl>
All that sexy lifetime and generics syntax noise... mmmhhhhhh
<chapl>
Love it
<ifreund>
rust has it's place, but suffers from complexity
<chapl>
Really excited about Go's new contract feature
<ifreund>
still take it any day over c++/java though
<ifreund>
for real systems level stuff simlicity is king which means C or now Zig
<tdeo>
i like how go made a simple language popular, but i don't enjoy writing it at all
<chapl>
I'm actually kinda surprised that Zig is being sold as 'general purpose programming language', not as 'systems level programming language'.
<ifreund>
chapl: it is general purpose
<chapl>
One might say it's systems level :D
<foobles>
I actually quite like Rust's complexity, since it feels complex in the right places
<foobles>
like lifetimes and such are really complicated issues, im glad the compiler is picky
<chapl>
Rust is good in solving complex problems but I don't if it self has to be that complex. But sure, complex problems might need an expressive and complex language.
<chapl>
I don't know
<chapl>
Somebody else using HexChat? What do these gray-colored names mean? Some of them are black, some of them are gray.
<pmwhite>
Possibly. Some people here are on Matrix as well, and we are able to identify each other.
<chapl>
I think it means they're away/afk. Just had a look into the settings.
<joepie91>
pmwhite: bet you couldn't identify me as a matrix user :P
<chapl>
The red pill or the blue pill?
<ifreund>
i'm both
<pmwhite>
I guess, not if you aren't using the matrix client to connect.
<joepie91>
I am! I'm just using a different bridge :P
<pmwhite>
oh, nice.
<chapl>
Gonna try connecting via IRSSI :D
chapl has quit [Quit: Leaving]
chapl has joined #zig
<chapl>
interesting
<ifreund>
andrewrk: another thought on toplevel stuff, one other (dumb) alternative would be replacing @import with @struct, @enum, and @union
<ifreund>
it doesn't really seem like it would work well though
<ifreund>
cause like tagged unions are a thing, but the status quo doesn't allow for toplevel generic structs either since they are functions
<chapl>
Hm, I don't know. See the thing with @struct, @enum, @union is that you have to know what the file contains/exposes. With @import you don't. imho it adds more developer friction.
<ifreund>
yeah i think it's a bad idea too
<chapl>
Starting to love irssi already. Always have been and will be a terminal user. :D
<ifreund>
the status quo is quite good in practice as almost all my files were a single toplevel struct
<ifreund>
enums/unions generally don't get their own file
<chapl>
I like how often "status quo" is being used by the Zig folks. :D
<chapl>
I wonder what happens if somebody pings me when using irssi
<ifreund>
chapl: idk i use weechat
<chapl>
Ah, the name's getting colored yellow. nice
<ifreund>
never did find a way to make irssi look pretty enough
Akuli has quit [Quit: Leaving]
<ifreund>
though i'll admit I didn't spend too long trying
<chapl>
I find the simple look of IRSSI quite awesome. I do like it more than HexChat
drasko has joined #zig
<alexnask>
On the runtime dispatch topic, this: https://github.com/ziglang/zig/pull/4567/files is an implementation of 'interfaces', I will make a separate repo for it tomorrow and add some docs
<oats>
is there no "force unwrap" operator for an error value?
<oats>
*error union
<ikskuh>
what should that do?
<ikskuh>
crash on error?
<ikskuh>
`foo() catch unreachable`
<oats>
what does .? do?
<oats>
oh, catch unreadable
<oats>
perfect
<ikskuh>
`foo orelse unreachable`
<alexnask>
.? unwraps an optional
<ikskuh>
is `foo.?`
Chris660 has joined #zig
Xavi92 has joined #zig
demizer has quit [Remote host closed the connection]
<foobles>
`foo.?` = `foo orelse unreachable`
<foobles>
there is no equivalent for errors
<foobles>
just do `foo catch unreachable`
<oats>
:thumbs-up:
<ikskuh>
foo.bles?
<tdeo>
i wish it either worked on error unions or didn't exist at all, not just for one of them
wozeparrot has joined #zig
<ifreund>
idk, i feel like it's not uncommon for there to be a valid reason to unwrap an optional while unwrapping an error shouldn't be taken lightly
<tdeo>
that's true
st4ll1 has quit [Read error: Connection reset by peer]
frett27 has quit [Ping timeout: 256 seconds]
<fengb>
Yeah it was deliberated and decided that unwrapping errors should look like the nuclear option