<Snektron>
ed_t: You should probably separate parsing of the pipeline definition and running the pipeline. Integrating async into parsing seems like overengineering to me
brzg has joined #zig
layneson has joined #zig
blackpawn has quit [Ping timeout: 256 seconds]
blackpawn has joined #zig
brzg has quit [Quit: leaving]
<vent>
Is there a way to define an ad-hock slice over 3 seperate variables? I have 3 strings that I want to pass into std.mem.concat().
sundbp has quit [Ping timeout: 265 seconds]
<mipri>
slices are fat pointers, not iterators, so you couldn't do that unless the three separate variables happened to refer to contiguous memory in the order you wanted
<vent>
What about something like this? [_][]const u8{page_dirpath, page_basename, page_extension}
<vent>
If the pointers to each []u8 are contiguous then it should okay to index right?
layneson has quit [Quit: WeeChat 3.1]
notzmv has joined #zig
<vent>
Perhaps if I just declare it as an array first, then pass that in.
<vent>
mipri: Nice one, thanks for the code snippet. My code looked very similar already, but the type I was passing in was wrong. I was passing in []u8 when I should have been passing in u8.
osa1 has joined #zig
earnestly has quit [Ping timeout: 246 seconds]
osa1_ has quit [Ping timeout: 264 seconds]
aconbere has quit [Ping timeout: 265 seconds]
aconbere has joined #zig
powerofzero has quit [Ping timeout: 276 seconds]
aconbere has quit [Ping timeout: 264 seconds]
aconbere has joined #zig
tomku has quit [Ping timeout: 246 seconds]
tomku has joined #zig
v0idify has joined #zig
<v0idify>
what's a good way to have a Backend struct that can hold different things depending on the platform?
<v0idify>
essentially like an interface
<v0idify>
but without function pointers lol
<tdeo>
how much do you expect to share between the backends?
<v0idify>
basically nothing
<v0idify>
actually, it depends
<tdeo>
if they're not sharing much code, then you can have each struct separately and do `const Backend = if (cond) BackendA else BackendB;`
<v0idify>
opengl backends that share rendering functions but not initalizations that are os dependant
<v0idify>
but there might be other kinds of backends
dimenus|home has quit [Ping timeout: 265 seconds]
<v0idify>
oh maybe just make a single function that takes a union(enum) :/
LobbyLobster has quit [Quit: Leaving]
<v0idify>
is there a way to make a union(enum) and only allocate the memory required for the kind chosen?
<v0idify>
without having an extra pointer ofc
<v0idify>
it's for using on a SinglyLinkedList
<daurnimator>
v0idify: sounds like you want a SinglyLinkedList(void) and use `@fieldParentPtr`
Rum has joined #zig
<v0idify>
daurnimator, huh it seems like it but it confuses me? how do i know what type it is from void
<v0idify>
and what is field_name
<daurnimator>
v0idify: you don't: put the `SinglyLinkedList(void).Node` *in* your structure. instead of your structure in the node type
<v0idify>
oh that's crazy
<v0idify>
hmm i'd rather not though, it wouldn't make much sense for the data structure i'm doing, is there any other way?
<v0idify>
i mean, how can i figure out the type from a Node then
<v0idify>
use case: linked list of draw operations (think fill rectangle with color, draw text, etc)
<tdeo>
you can have a "base" struct with just an enum of which variant it is, and put that base struct in each of the variants
<tdeo>
then you can have a linked list of that
<v0idify>
and then call fieldParentPtr on that right?
<v0idify>
but the Node would need to be a pointer to the struct
<aconbere>
(imagine me adding many different consts to places in case that's it)
<aconbere>
this is the error I get `./src/mime.zig:62:51: error: expected type '[]u8', found '*const [4:0]u8'
<aconbere>
Which I read to say that the big difference is that [_][]u8{ "val1", "val2" } has pointers to the array?
<daurnimator>
aconbere: you probably want `[]const u8` as the first argument.
<daurnimator>
and then you'll need `&` before the `[_]`
<aconbere>
interstingly that changed nothing :-D
<daurnimator>
aconbere: you'll also need a `const` so you get: `&[_][]const u8{ "val1", "val2" }`
<aconbere>
phew that did it
<aconbere>
I had previously put in the consts because... that makes sense to me
<aconbere>
but the dereference surprised me
<daurnimator>
dereference?
<aconbere>
"&"
<aconbere>
maybe that's backwards :-|
<daurnimator>
that's getting a reference; not a dereference
<aconbere>
backwards
<daurnimator>
Might be easier for your brain to think of `&` as the "address-of" operator
<aconbere>
Thanks :)
<daurnimator>
aconbere: `[_][]const u8{ "val1", "val2" }` is an *array* of strings: in memory its two `[]const u8` in a row. with the `&` its a pointer-to-two `[]const u8`s
<daurnimator>
aconbere: and then "pointer to some number of `[]const u8`" can coerce to "slice of `[]const u8`", which is what your `expectEqualSlices` wants
<aconbere>
actually super helpful
<aconbere>
Your explanation makes perfect sense, and it seems obvious in retro spect that this was about the type of the array containing the strings
<aconbere>
feel like the error kinda sent me down the wrong route though :-/
<aconbere>
'[]u8', found '*const [4:0]u8'
<aconbere>
Why do you think the compiler was pointing to the inner strings as the issue?
<aconbere>
(sorry super interested in the response but I don't have a bouncer and I have to head to bed, I'll follow up tomorrow, thanks again)
cole-h_ has joined #zig
jumpnbrownweasel has quit [Quit: Connection closed]
aconbere has quit [Ping timeout: 265 seconds]
cole-h_ is now known as cole-h
jumpnbrownweasel has joined #zig
Rum has quit [Read error: Connection reset by peer]
waleee-cl has quit [Quit: Connection closed for inactivity]
sord937 has joined #zig
ed_t has quit [Ping timeout: 246 seconds]
ed_t has joined #zig
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
GreaseMonkey has quit [Remote host closed the connection]
GreaseMonkey has joined #zig
cole-h has quit [Ping timeout: 264 seconds]
riba has joined #zig
yyp has joined #zig
sundbp has joined #zig
ur5us has joined #zig
riba has quit [Ping timeout: 260 seconds]
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #zig
earnestly has joined #zig
yyp has quit [Quit: now it's safe to turn off your computer]
sundbp has quit [*.net *.split]
notzmv has quit [*.net *.split]
sundbp has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
qazo has joined #zig
TheLemonMan has joined #zig
Raito_Bezarius has quit [Ping timeout: 264 seconds]
Raito_Bezarius has joined #zig
notzmv has joined #zig
Rum has joined #zig
Rum has quit [Quit: Leaving]
TheLemonMan has quit [Ping timeout: 260 seconds]
sord937 has quit [Quit: sord937]
TheLemonMan has joined #zig
gazler has joined #zig
<TheLemonMan>
sundbp, don't give up! you were this close to the end!
<ikskuh>
This time, 100% self hosted and no restrictions on the number of markers!
<ikskuh>
Contribution via Github PRs
<TheLemonMan>
OSM looks pretty nice
<Nypsie>
\o/
<ikskuh>
TheLemonMan: yeah! and only a little bit of glue JS to Leaflet and Zig code to build the data :)
qazo has quit [Quit: ...]
nore has quit [Ping timeout: 245 seconds]
nore has joined #zig
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
fireglow has joined #zig
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
aconbere has joined #zig
gpanders has joined #zig
dyeplexer has joined #zig
cole-h has joined #zig
nvmd has joined #zig
teknico has joined #zig
teknico has quit [Client Quit]
notzmv has quit [Ping timeout: 264 seconds]
marler8997 has joined #zig
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
yyp has joined #zig
notzmv has joined #zig
yyp has quit [Quit: now it's safe to turn off your computer]
notzmv has quit [Ping timeout: 246 seconds]
yyp has joined #zig
delaney has joined #zig
delaney has quit [Client Quit]
<v0idify>
so the only way to make "interfaces" is with function pointers/
<v0idify>
?
<ikskuh>
yes, for runtime interfaces
<ikskuh>
comptime interfaces can be done with generics (anytype9
<v0idify>
thinking about how it would work memory-wise makes it make sense but i have thought about it with languages that hide those details for too long :)
<ifreund>
companion_cube: I'm no expert on lisps, but janet at least does let you evaluate things at compile time
<yyp>
AST -> AST feels like what Rust macros allow
<companion_cube>
ifreund: all of them always did, yes
<ifreund>
rust doesn't have quoting
<companion_cube>
that's what macros are about
<yyp>
What quoting?
<companion_cube>
ifreund: rust procedural macros take the AST, so why would they need quoting
<yyp>
^
<ifreund>
which means you need to learn a separate macro language, unlike with lisp
<companion_cube>
sure, it's a lot more work to write these, yes
<txdv>
wait, is zig the next lisp?
<companion_cube>
if that means zig gets the lisp curse, hopefully not
<ifreund>
zig's not a lisp, but some of its features correlate loosly to some nice things about lisps
<txdv>
if you allow people to do something in the language, they will do it
<companion_cube>
I think D's comptime is a lot closer to zig's
<yyp>
ifreund: yep, having to learn another language for macros is quite annoying
<txdv>
its a law, if it is expressible, they will do it
notzmv has joined #zig
<ifreund>
companion_cube: probably, but D looks way too kitchen sink for me to invest any more time looking at it
sawzall has quit [Read error: Connection reset by peer]
<yyp>
Checked some D examples, it has exceptions, not interested
<ifreund>
and GC
<yyp>
even worse
<ifreund>
and I think a borrow checker too now?
<ifreund>
and C++ ABI compat of some kind
<companion_cube>
it was designed as a C++ replacement, so yeah, it's big
<yyp>
C++ replacement doesn't need to have exceptions and GC
sawzall has joined #zig
<yyp>
¯\_(ツ)_/¯
<companion_cube>
it's from the late 90s/early 00s, exceptions were the least of evils
<ifreund>
zig is a fantastic C++ replacement because it makes different design descisions instead of repeating the same mistakes
<companion_cube>
the GC is because it helps with memory safety
<ifreund>
Rust is also quite a good C++ replacement in some cases
<companion_cube>
ifreund: I'm not sure zig is a good C++ replacement
<companion_cube>
if C++ programmers can dismiss it with "there's no RAII"
<companion_cube>
the same way Go was suppoesd to be a C++ replacement and was laughed out of the room
<companion_cube>
(with reason, tbh)
<yyp>
Go was supposed to be a C replacement
<ifreund>
not seriously, it has a GC
<companion_cube>
oh actually at the beginning they thought it'd attract the C++ crowd
<companion_cube>
you have talks where they say that
<yyp>
Blame Plan9 guys then
<companion_cube>
showing they didn't get what people use C++ for
<aconbere>
I just see Go as the C author's mulligan
<aconbere>
do overs!
<aconbere>
Like regardless of who they thought it would attact and what languages they thought it might replace. It just feels like ... they wrote it.
<ifreund>
companion_cube: compared to Go, Zig is a far better C++ replacement, having super powerful/flexible generics that can replace all that template metaprogramming as well as no runtime or GC overhead
<ifreund>
infact, I'm going to predict that C++ gets types as first class values in constexpr scopes sometime in the next 20 years
<companion_cube>
ifreund: I'd say it's halfway there
<ifreund>
indeed, though not 100%
<companion_cube>
no RAII will rebuke most C++ programmers
<ifreund>
oh you're talking about the first thing I said
notzmv has quit [Ping timeout: 276 seconds]
<yyp>
RAII seems like a bad idea anyway
<companion_cube>
seems like a good idea to me, it's even one of the few things rust salvaged from C++
<TheLemonMan>
lol
<aconbere>
Today seems to be the day in which I conqure Readers / Generics
<aconbere>
Wish me luck
Akuli has quit [*.net *.split]
<txdv>
isn't defer the equivalent of raii?
<companion_cube>
no
<companion_cube>
defer doesn't compose with generics in the same way
<txdv>
can you give me an example why not
<ifreund>
no, and thank god it isn't
<companion_cube>
let's say you have, in rust, a Vec<Foo> where Foo contains stuff with destructors (like a hashmap, a socket, etc.)
<ifreund>
raii needs move semantics and a whole bunch of other complexity
<companion_cube>
`Vec.clear the_vec` will automatically clear resources
sawzall has quit [Read error: Connection reset by peer]
<companion_cube>
defer is more explicit but only for scope allocated resources
<companion_cube>
ifreund: yeah, and RAII typically needs some sort of specialization for the (fast) case where there's no destructors
<companion_cube>
it can be done by hand of course, but the "clear a vector of Copy types" needs some kind of optimization to recognize it has nothing to do
sawzall has joined #zig
<yyp>
Maybe RAII is not actually that bad and I misunderstood what it does, but still I think that Zig does better since everything is explicit instead of hiding a free() with ~Object
<yyp>
Just that acronym is confusing
<companion_cube>
yyp: imho the value of RAII is that it composes well. Doing stuff manually means you need to pass `free` as parameters in many cases
<earnestly>
TheLemonMan: Have you rewritten lemonbar in zig yet? :p
<companion_cube>
(or do something else, but anyway)
<earnestly>
raii(composes(well)));
<TheLemonMan>
earnestly, it's pretty far in the todo list heh
<yyp>
companion_cube: no, at least not with Zig since allocated objects store an allocator within themselves and then you can just defer thing.deinit(); or something
<earnestly>
It's the first thing I remember you making
<TheLemonMan>
my very first linux program!
<TheLemonMan>
everything went downhill from there on
<yyp>
Now I want to make Wayland version of lemonbar..
Akuli has joined #zig
<TheLemonMan>
oh, I also contributed to companion_cube ocaml-containers
<TheLemonMan>
damn, the GH repo list is a trip down memory lane
notzmv has joined #zig
<txdv>
companion_cube: can you show off the composition of raii in an example in your favorite language?
waleee-cl has joined #zig
<companion_cube>
yyp: yeah if you allocate everything in allocator it's a different story
<companion_cube>
it does indeed require move semantics to work cleanly
<companion_cube>
you can also have interesting examples with Arc<T>, locks, etc. (refcounting is an area where it's also super useful)
daeluk has joined #zig
<txdv>
How would you implement this in zig (without the raii aspect)?
<companion_cube>
nested std.ArrayList I guess, but you need to defer either the destruction of v2, or to clear v's elements before destroying it
<companion_cube>
of course you can also shove everything into a local allocator :p
<ifreund>
do you mean a local arena?
<ifreund>
that's not great with the way growable arrays allocate
<ifreund>
to do this in Zig, I'd use ArrayListUnmanaged for the nested elements
<ifreund>
the deinit is just 2 lines: for (foo.items) |child_list| child.list.deinit(); foo.deinit();
<mikdusan>
andrewrk: can you eyeball #8265. I'd like to get this in, then adopt the same approach for llvm12 branch macos-arm64, and shift llvm12 macos-x86_64 to build x86_64 host using a xcode-based bootstrap tarball
<txdv>
I think that zig wants to tell you that there is a lot more going on, that there is something allocating memory
<mikdusan>
this way we're ready for llvm12. and if/when zig-bootstrap can build artifact, then we can switch. but I'd like a working thing now
<companion_cube>
txdv: yes, zig is more explicit, we all agree
<txdv>
{ let v2 = vec![1,2,3]; v.push(v2) } // this is just v2 = [1,2,3,4]// and since nobody uses this is optimized away
<mikdusan>
also what happens if llvm12 continuous integration succeeds? I don't see any logic to prevent tarball posting if branch != master
<txdv>
Most of the languages just overdo it with the "I will do this without you knowing it", zig tries to show it in the language what is happening
<mikdusan>
^^ scratch my last comment. I see condition now in pipelines.yml
<companion_cube>
txdv: I mean, in rust, you know it; but it's automatic like stack allocation or other things