<andrewrk>
ok std.fmt fill character definitely regressed
<waleee-cl>
yeah I know it's companion_cube (sorry for the ping)
<andrewrk>
var char: u8 = 9; std.debug.print("\n\\x{X:02}\n", .{char})
<andrewrk>
ok {X:0>2} works
<andrewrk>
I think {X:02} should be a compile error telling you how to use the API
<fengb>
Sounds like you need a refresher course at ziglearn.org 🙃
ur5us has joined #zig
<andrewrk>
omg is that there?
<andrewrk>
amazing. I should have checked here
ccube has left #zig [#zig]
a_chou has quit [Ping timeout: 260 seconds]
<companion_cube>
ah, an impostor!!
<companion_cube>
oh they left :(
<fengb>
I’ve never seen the both of you in the same room 🤔
xd1le has quit [Ping timeout: 240 seconds]
a_chou has joined #zig
<andrewrk>
I could tell it wasn't you companion_cube, they were slightly more edgy
<andrewrk>
also more interested in zig :P
nephele_ has joined #zig
nephele has quit [Ping timeout: 240 seconds]
nephele_ is now known as nephele
xd1le has joined #zig
<leeward>
To be fair, it's hard to be edgy with hearts on your faces.
a_chou has quit [Ping timeout: 256 seconds]
<mkchan>
isn't the while (i < size) : (i += 1) {} syntax equivalent to while (i < size) {defer i += 1;} ? Why should there be 2 ways of doing it?
<leeward>
mkchan: It's subtly different. The defer happens if there's an error.
<mkchan>
that's errdefer
<leeward>
Yes, errdefer also happens if there's an error.
<leeward>
I'm not saying it's an important or useful difference, just that they're not equal.
<mkchan>
so if an error occurs there's 2 things that could happen: 1. you handle it within the scope => it won't actually do the defer statement because scope is still on. 2. it exits the scope and in this case, does the : (i += 1) execute? Because the defer variant will execute
<leeward>
I don't believe the : (i += 1) will execute, which isn't super important for counters scoped to the function, but can matter for more broadly scoped state.
<leeward>
Worth double checking...
<mkchan>
it feels like a footgun because the scope of the counter var is not the scope of the loop usually because zig doesn't have the for (init;condition;update) kind of formulation
<leeward>
It is true that the counter variable is not scoped to the loop. I don't think I would want it incremented in the event that the loop exits with an error.
<mkchan>
so then the defer i += 1 could lead to unexpected behavior
<mkchan>
ok thanks, i'll use the other syntax
<companion_cube>
andrewrk: I am interested in zig :p
<leeward>
Just confirmed it, i does not get incremented.
<mkchan>
though the lack of loop-scoped variables and the inclusion of loop-scoped updates seems kind of... half-baked
<mkchan>
i was thinking along the lines of: say you have a tcp session object and its lifetime is controlled by its scope, if you need to shut it (for example you need to allocate a new connection at the expense of a less valuable one), you would noerrdefer a close on it. because if you just normal defer it, and an error occurred, you trying to close the connection would presumably also give an error because
<mkchan>
it's already closed
<mkchan>
unless i'm wrong and zig says closing is a no-op if already closed
<leeward>
Why is it already closed in the normal case?
<torque>
you would set up the defer to close it after it had successfully opened, typically
<mkchan>
yes, but my point is if it fails because of a network issue, the connection would be implicitly closed right? then the deferred handler runs and tries to close it again
<torque>
that sounds more like imaginary bad api design than a practical problem
<mkchan>
boost asio works kind of like that
<leeward>
real world bad api design?
<leeward>
It does sound like a bad API though. You don't have to close the socket if the other side already closed it, and it's bad if you do?
<justin_smith>
a real problem with the same shape: double free
<torque>
yeah, if you give ownership of the socket to someone else, you shouldn't be doing things like implicitly closing it
<leeward>
Double free has a different shape, because remote code over which you have no control won't sometimes free your memory for you.
<leeward>
And if it does, then it's that code's fault if you have a memory leak and you shouldn't be freeing it ever.
<leeward>
andrewrk: I do what I can to push your time-in-merge-queue averages down.
<andrewrk>
:)
<mkchan>
if the other side closed the socket, your object would still go out of scope and the defer would run. now you could obviously wrap a call to close with isClosed() but that's a style choice whether you want noerrdefer or whether you want defer to be errdefer+noerrdefer
<andrewrk>
that might be the first CI commit that makes it all the way to the download page with Ave/Luna's newly provided freebsd CI testing service
<leeward>
Wooo
<leeward>
mkchan: I think you're making some OOP assumptions that look like RAII.
<andrewrk>
they are graciously giving us more RAM on freebsd builds so we can enable std lib testing. it already caught a regression (which is not yet fixed in master branch)
<mkchan>
i'm assuming the session manages its own lifetime based on scope and has a way of some other service telling it to shutdown. this is how boost-asio works
<mkchan>
but yeah it could very well not be the best way to do it in zig
<mkchan>
like you said it assumes RAII
<leeward>
Yeah, defer is how Zig does RAII, and they're not particularly compatible. Destructors are very implicit function calls, which is a no no in Zig.
a_chou has joined #zig
<mkchan>
while zig is still young lets try to call it scope-based-lifetime-management SBLM or SLM instead of a crappy name like RAII :)
<leeward>
RAII is really one of the worst names ever.
<justin_smith>
right, we aren't talking about I at all here
<mkchan>
that's the argument bjarne uses for not changing the name RAII to something else: "you should have been there 20 years ago"
<justin_smith>
on the posix level, double closing an fd is an error (hopefully) or closes someone else's socket that used the same numeric fd (oops)
<mkchan>
yes, which is why if you use defer to handle an error related to it you must check isClosed() before you close it
<justin_smith>
that can close someone else's file
<justin_smith>
it's just a number
<justin_smith>
I could be confused because you all are talking about an abstraction above sockets that manages the identity and state of objects holding sockets
<mkchan>
that was an example use case i borrowed from my experience with c++
<mkchan>
the core issue was the double close pretty much
<justin_smith>
sure, and given the implementation of files (numeric fd passed to syscall), checking if it's open isn't a fix, because it can be reallocated after closing
<justin_smith>
you need something dumber, or something smarter
<mkchan>
the open close stuff is per-process i think
<mkchan>
at least in c
<mkchan>
presumably if you wrote syscalls you *could* do whatever
<justin_smith>
so only one thread is allowed to open/close files, that helps
<justin_smith>
(maybe that's not a valid leap...)
<justin_smith>
sorry I'm used to programming at a much higher level abstraction so this stuff still confuses me sometimes
<mkchan>
i'm not sure if it's per process or per thread. i think per-process
<justin_smith>
mkchan: right, my steps were: if it's per process that it's managed, two threads can potentially get into a funky state, if the closes and opens happen in different threads, maybe that's not a realistic concern
<mkchan>
i mean it's realistic in the sense multiple threads could be reading the same file but if someone actually writes multithreaded writing code oof
<mkchan>
i haven't tried it so i really have no idea. it seems like an inane thing to do
klltkr has quit [Ping timeout: 244 seconds]
mokafolio has quit [Quit: Bye Bye!]
<justin_smith>
mkchan: but the root thing that made me anxious was the idea of some state that can be flipped by my code, or a connection between my machine and another, or the other machine, and needing to gracefully handle things using only a yes/no of open or closed, plus the fact the kernel is allowed to give you the same numeric fd between a close and another open. maybe that's not a real problem though
mokafolio has joined #zig
<justin_smith>
even if each fd was opened/closed by one thread, one thread could still close another's fd due to reuse of the descriptor which is just a number
<mkchan>
i don't really know all the specifics, sorry i can't help much
<mkchan>
my knowledge mostly ends at the memory/cache level. i'm a noob at storage
<andrewrk>
oh sorry never mind I think I figured it out already
a_chou has quit [Remote host closed the connection]
<justin_smith>
mkchan: upon refreshing my memory, network related errors don't close the fd, but they do raise a signal that an application can set a handler for to fix / cleanup. not setting a handler means your process is simply shut down.
traviss__ has joined #zig
<justin_smith>
so I think a socket does fit the defer pattern
<mkchan>
the problem is the OS can close a socket for you and then your read() function fails and you try to close it again
traviss_ has quit [Ping timeout: 260 seconds]
<justin_smith>
oh, I must be misreading the docs
<mkchan>
it is not analogous to double free because afaik OS won't partially free memory for you, they'll just completely shut you down
<justin_smith>
there's mention of a signal raised for broken sockets, that's not the same
<justin_smith>
the kernel promises to reuse the lowest available fd number, so clashes where a "double close" closes a resource being used are quite likely
<justin_smith>
combining that with silently / implicitly closing your fd from outside your process seems pathological, but I could be missing something important here
<mkchan>
though i suppose if close() can fail for whatever reason anyway (regardless of previously closed) and you have to check the close() return value in any case, it makes the entire point moot
<justin_smith>
I'm afraid I'm getting too hung up on this detail, I just don't see how the API for file descriptor allocation and closing could be sanely used if a something outside your control can close the fd, since fds are guaranteed to be reused after closing. but I don't think that detail was even the material point you were making
<mkchan>
i was assuming that if you're guaranteed that you're the one closing the fd that you own (which you don't. the OS owns the fd) then you don't need to check if its already closed
<mkchan>
the OS just does whatever it wants
<justin_smith>
the fd is a number unique to your process
<mkchan>
praise OSjesus
<justin_smith>
there's no other data process side
<justin_smith>
your process *does* own the fd, and it would be weird for any outside code to manipulate it
<mkchan>
imagine you're writing to a file x.txt on desktop, and while you're writing someone `sudo rm`s the file
<justin_smith>
your fd 1 is your fd 1, if you close it and open another file, that's your new fd 1
<justin_smith>
the OS doesn't care what your file name was etc. when you write, it just wants the fd, which is a number
<justin_smith>
mkchan: that rm doesn't close the file
<mkchan>
the OS cares exactly what inode that fd points to
<justin_smith>
it's easy to test, you still have an open fd for that file after rm
<mkchan>
if that inode disappears, the os closes your file
<justin_smith>
no, it does not, this is a trick that is deliberately exploited (in posix applications)
<mkchan>
wut!?
<justin_smith>
well - OK, the inode
<justin_smith>
the rm doesn't delete the inode
<justin_smith>
it just reduces the usage count
<justin_smith>
your fd being open is another usage
<justin_smith>
the inode isn't free until you close
<justin_smith>
many apps create a temp file, open it, then delete the file, and continue to use the inode via the fd
<mkchan>
that's so hacky and shared-ptr-esque
<justin_smith>
it's quite common, and a guranteed behavior
<justin_smith>
it's not a shared pointer, because the kernel doesn't close the fd on you
<justin_smith>
anyway, I think I've lost the topic of this irc channel here, and I need to retire for the night, apologies for the noise
<mkchan>
that's why it is a shared ptr to the inode isn't it. the process using it would be another reference
<mkchan>
oh yeah massively off topic, sorry
<justin_smith>
the process only has a number, starting from 0 and counting up, the kernel maps that to a resource
<justin_smith>
np, cheers
<andrewrk>
OS stuff is on topic here :)
<andrewrk>
we like to think about how computers work
jjsullivan1 has quit [Ping timeout: 258 seconds]
<andrewrk>
here's an idea I didn't consider before: `block` keyword which makes `break` apply to it (no label)
<andrewrk>
const x = block { ...; break y; };
<mkchan>
seems like a lambda?
<companion_cube>
without arguments
<mkchan>
yes
<companion_cube>
that's an interesting compromise andrewrk
<companion_cube>
removes the need for inventing a name
<andrewrk>
nah it's syntax sugar for label: {...; break :label y;}
<fengb>
Once we have anon functions, we can switch to IIFE instead of named blocks 🙃
<andrewrk>
joke's on you I don't even know what IIFE is
<mkchan>
x = [capture](param){code + return}(args);
<companion_cube>
my guess is is `(() -> …) ()`
<companion_cube>
the kind of stuff you see in JS and Go
<andrewrk>
is IIFE like UUPDG?
<mkchan>
and c++
<companion_cube>
😂
<companion_cube>
statement based languages…
<mkchan>
btw, can someone point me to an example where you sort of stack generic types. I have this: https://godbolt.org/z/feMo4h and i want to make a pub fn Network(layers: []Layer) but i'm not sure how to code that
<mkchan>
the c++ equivalent would be a variadic template
mwgkgk has quit [Quit: Connection closed for inactivity]
<mkchan>
i can think of a not-so-nice way of implementing it => taking all the layer parameters N times followed by the respective N layers which works i guess. You would do the same in c++ i believe but you don't have to because it deduces a lot implicitly hmm...
<andrewrk>
mkchan, are you trying to dispatch control flow at runtime?
<mkchan>
i'm not sure what you mean
<andrewrk>
oh I think I see your question. you'd use duck typing for this in zig
<mkchan>
but basically i know the exact structure of the network at compile time
<andrewrk>
pub fn Network(layers: anytype) type { ... }
<andrewrk>
if you want some safety rails you can add `comptime assert(..);` to give yourself compile errors
<mkchan>
so i can assert that layers is a list and once i pick out one with layers[0] i will still be able to call the self-method on it?
<mkchan>
so basically it's modeled correctly at compiletime but i just can't express it nicely in source code right?
<andrewrk>
right
<andrewrk>
rust is pretty good at that sort of thing, but zig is too simple so you have to use duck typing
<mkchan>
that's alright, i find rust syntax very... different and i actually did try doing this in rust and i'm not a fan of the style it boxes you into
<mkchan>
zig feels more like the kind of thing c++ should've been but c++ is more like c+++++++++++++++++++++ now
marnix has joined #zig
<mkchan>
so i'm leaning towards zig quite a bit for hobby projects
<nikki93>
hey there :)
<nikki93>
looked at zig on and off but really trying it out now. it's nice!
ur5us has quit [Ping timeout: 244 seconds]
xd1le has quit [Read error: Connection reset by peer]
xd1le has joined #zig
pangey__ has quit [Ping timeout: 244 seconds]
pangey has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
<3
cole-h has quit [Quit: Goodbye]
marnix has quit [Ping timeout: 260 seconds]
marnix has joined #zig
oxymoron93 has joined #zig
gpanders has quit [Read error: Connection reset by peer]
gpanders has joined #zig
gpanders has quit [Read error: Connection reset by peer]
gpanders has joined #zig
mokafolio has quit [Quit: Bye Bye!]
jjsullivan has joined #zig
mokafolio has joined #zig
<jjsullivan>
does the build API have helpers for compiling/linking static C libraries?
<jjsullivan>
even just something to get `zig cc` for the current target would probably be enough
<traviss__>
are you looking for exe.addCSourceFile(file: []const u8, args: []const []const u8)?
<jjsullivan>
traviss__, I was trying to compile something that already has a makefile, but I don't think there's really anything stopping me from doing that
<jjsullivan>
I'll give it a try
xd1le has quit [Read error: Connection reset by peer]
<traviss__>
if the makefile is simple enough, this may work. another idea, maybe run the make command from build.zig with b.addSystemCommand(argv: []const []const u8)
<jjsullivan>
yeah, the makefile isn't too complicated. There's a few options but I'm ignoring most of them anyway. If I have a `build.zig` next to it, it can probably compile without much effort.
<jjsullivan>
plus I get cross-compiling for free
<andrewrk>
jjsullivan, it's even better than that, it will build C and C++ libraries from source with zig instead of relying on external tools
<jjsullivan>
yeah, I think this library is mostly turning source files 'on/off' in the makefile. Probably wouldn't be too difficult to do everything in the main `build.zig`
xd1le has joined #zig
<jjsullivan>
thanks traviss__ andrewrk :^)
<andrewrk>
and now you probably made your project buildable by windows users
<jjsullivan>
ehh, wayland client actually
<andrewrk>
ahh fair enough :)
<jjsullivan>
although wsl could probably do it?
<jjsullivan>
I know they got xforwarding anyway
<andrewrk>
🤔
<andrewrk>
ooh do they? that's super interesting
<andrewrk>
I did not know you could do graphical stuff with WSL
<jjsullivan>
it's kind of a hack, but yeah you can peek into a running xserver from the 'outside'
<jjsullivan>
I forget if there's some special client or if the client is built-in now
<andrewrk>
it was on hacker news for a good part of the day
<andrewrk>
don't worry rain1 we're still going full steam ahead. I'm proud of our MIT license and not asking contributors to sign CLAs and it's going to stay that way 💪
<rain1>
:)
<jjsullivan>
wow, hard to believe people will try to grift like this. Hope any well-meaning people can benefit from the outreach
<ifreund>
everything on their site is pretty neat in fact :)
gonzus has joined #zig
<Cadey>
ifreund: 100 rabbits is great
gonzus has quit [Remote host closed the connection]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Ping timeout: 244 seconds]
marnix has joined #zig
<cren>
would be fun to see if you could write a program that was also a meaningful passage in some natural language like English
Akuli has joined #zig
<cren>
(in orca, not zig! you could try with zig but it would be quite difficult...)
oxymoron93 has quit [Quit: Connection closed]
jjsullivan1 has joined #zig
waleee-cl has joined #zig
yorickpeterse has left #zig ["User left"]
<pixelherodev>
andrewrk: I'm starting to think it might be worth integrating CBE with the normal backends a bit more thoroughly...;
<pixelherodev>
Instead of duplicating all of the core logic in a separate file (e.g. branches)
<pixelherodev>
Maybe instead of using cpu.Arch, we could switch on a Backend struct which is defined as, effectively, `Arch || enum { C }`?
marnix has quit [Remote host closed the connection]
marnix has joined #zig
vgmind has joined #zig
<marler8997>
Found around 10 instances of undefined behavior in the Dune source code by compiling it with Zig instead of GCC
<marler8997>
Sorry, "DOOM" source code (not Dune)
<fengb>
Is this one of the cleaned up repos?
<leeward>
That is not super shocking.
<marler8997>
not sure what LLVM options Zig is using to detect these instances of UB
<marler8997>
original repo
<marler8997>
from id-software
<leeward>
It's just using ubsan, right?
<marler8997>
I'm sure the cleaned up repos will have fixed these issues :)
<fengb>
I'm impressed with only 10 UB
<marler8997>
10 UB so far :)
<marler8997>
I can now go through menus and start the game...still hunting down more
<fengb>
lol
<marler8997>
ubsan though..thanks for the tip
<marler8997>
is there a way to disable ubsan? to check if that' it?
<fengb>
Hmm, do you think the ports were cross compiled? I'd expect SNES and before to be rewrites
<marler8997>
SNES was a rewrite in assembly as I understand (code was release recently actually)
<marler8997>
but the C code is pretty portable, I expect most would be modified and cross-compiled
<marler8997>
but my plan is to port to Zig...which will be super fun :)
<fengb>
Sure, I'm mostly curious if they had to cleanup UB :P
<ifreund>
you can disable with -fno-sanitize=undefined iirc
<marler8997>
I'll try that, off the top of your head do you know how to add LLVM options in build.zig? If not Ill figure it out
a_chou has joined #zig
<ifreund>
marler8997: you pass them to addCSource() iirc
<fengb>
I think Rust has a translate-c library that worked on DOOM. They're ahead of us :(
<marler8997>
fengb: thanks that worked! I can now play the game :)
<marler8997>
I mean, thanks ifruend :)
<fengb>
I'll take some credit too
<marler8997>
lol
<ifreund>
:D
blinghound has joined #zig
<justin_smith>
regarding IIFE mentioned above, I learned what they were while writing a lisp transpiled to a source language with "statements", in lisp everything is an expression (has a return value to use), to use expressions and also have a return value, you turn every expression usage into an Immediately Invoked Function Expression
blinghound has quit [Remote host closed the connection]
<justin_smith>
a function of no args (thunk, as scheme calls it), that exists so that your block of code will have a return value, and no other reason
<justin_smith>
err, I switched statement/expression a few times above - to be clear, statement=noreturn expression=return
blinghound has joined #zig
<justin_smith>
surely the more civilized adult approach is forth, where each word results in a variable reduction or increase of the depth of the stack
<blinghound>
is there an approach I can use to implement an event system - basically an array of bound fns I can call? Functions bound to a particular instance of a struct can't be used as a Fn pointer
<justin_smith>
blinghound: you can capture and bind the "frame" - the initialized stack data of a function, and revive it
<blinghound>
oh sweet! Are there any docs or pointers you can provide?
<justin_smith>
look at the stuff around binding @frame() / and resume - I think this fits your use case very nicely
<justin_smith>
eg. "Resuming from Suspend Blocks"
<blinghound>
That looks like exactly what I'm after, thanks. I assume I can store an array of frame pointers?
<justin_smith>
blinghound: it's data, I wouldn't save it to a file and read it back, but otherwise it's data :D
<justin_smith>
(because maybe you read it back from a version of the executable where the type no longer makes sense...)
<justin_smith>
blinghound: sounds like a nice way to make an event queue processing loop - keep a queue of stuff that's not done processing, hand it off to threads...
<blinghound>
I'm in the process of translating a cross-platform GUI toolkit I wrote in C++, and my initial approach in Zig was to write a huge switch statement with the corresponding function for every widget type
xackus has joined #zig
<blinghound>
which worked well with a small number of widget types, but ultimately doesn't scale
<blinghound>
with an event queue, it's also easier to implement a new widget type without having to modify the huge switches
<justin_smith>
blinghound: I think I understand, in a lisp I'd use functions closing over state, the @frame() technique lets you allocate that closure explicitly
<cren>
are zig strings utf-8?
<fengb>
Sorta. stdlib mostly expects UTF8 but they're just bytes at the language level
<cren>
this question may make no sense. My understanding of how programming languages handle strings is bad lol
<cren>
oh yeah uh
<cren>
course they are
<cren>
I had my python head on
<fengb>
If you ingest data that's known to be UTF8 and you do UTF8 logic, then it'll work
<fengb>
But there's mostly no validations atm
<justin_smith>
I have yet to see zig code that handles encoding
<cren>
so if I were to try to get the stdlib to process some utf-16 or cp1252 strings, it would probably break?
<justin_smith>
it's all u8 everywhere, so sufficiently naiive code handles all encodings equally well (badly)
<fengb>
There's a lot of encoding work for Windows interop
blinghound has quit [Remote host closed the connection]
a_chou has quit [Ping timeout: 240 seconds]
<justin_smith>
fengb: it's just bytes at the zig stdlib level, you need functions that care about characters to run into problems, do we even have any of that?
<justin_smith>
of course you could break things by splitting a codepoint across buffers
<justin_smith>
and not recombining before real string/character code sees the data
<fengb>
I'm not sure. But I do know this problem needs to be addressed for proper HTTP support >_>
<justin_smith>
right, your HTTP layer needs to know about encodings
<justin_smith>
fengb: quoting the comment under "using slices for strings" test in the master docs "Zig has no concept of Strings"
<companion_cube>
http doesn't know about encodings, does it?
<companion_cube>
only the content aware layout, like the browser, needs to
<justin_smith>
companion_cube: I hope that's true, because then zig would be at the same layer of abstraction as the HTTP layer (don't worry about the bytes, just convey them and don't scramble them, let the presentation layer worry about the nonsense)
zippoh has joined #zig
<companion_cube>
if I remember correctly, it is: headers are ascii
<justin_smith>
even if a multi-byte codepoint is split across data frames, you don't need to care as long as said frames are not mangled
<companion_cube>
bodies are binary (length is given in header)
<justin_smith>
right, images would be such a waste of bandwidth otherwise
* companion_cube
looks at json
<companion_cube>
but yes
<companion_cube>
for large content you also have chunked encodings :)
<companion_cube>
so you stream the data
<justin_smith>
right, and the chunking shouldn't care about object boundaries, whether it's codepoints or video frames or zip file entries
<companion_cube>
indeed not.
<companion_cube>
http 1.1 is a pretty neat protocol, in the end
<justin_smith>
almost worthy of the variety of insane use-cases it's been shoehorned into
<justin_smith>
nowadays the concept of "internet but not http" blows minds, or makes people think you're an evil hacker
<justin_smith>
or so it seems
<fengb>
HTTP is the new TCP
<justin_smith>
fengb: and block-chain is the new HTTP
<justin_smith>
the layers will never stop...
<companion_cube>
nah, blockchain is a fad
<pixelherodev>
^
<justin_smith>
companion_cube: math flavored beany babies, yeah, but I still see people trying to mis-apply it in so many places
<leeward>
blockchain has yet to provide a good solution to a problem. I'm not convinced it never will, but it's hard to convince me of a never.
<justin_smith>
leeward: there's that one "programming language in block chain" project, which turned the ability to learn a programming language quicker than others, or find and exploit bugs, into short term cash rewards
<leeward>
justin_smith: Did it need to be a block chain, or would a database have sufficed?
<justin_smith>
I don't think that's what they wanted to make, but they made it
<justin_smith>
leeward: with a database, an admin could have fixed an obvious error without forking the whole reality of the project
<justin_smith>
oh, etherium, that's the name I was thinking of
<justin_smith>
leeward: in other words, a database would be less exploitable by fast language learners / fast exploit finders
<leeward>
Not ethereum?
vgmind has quit [Remote host closed the connection]
<justin_smith>
leeward: no yeah, I was thinking of etherium, they forked their chain due to stupid bugs in apps that were effectively chain letters / pyramid schemes
<justin_smith>
"oh wait my code accidentally gives me all your cash on this corner case, easy mistake I guess"
<leeward>
Yeah, that's one of the problems with transactions that are not reversible. Easy to defraud.
<justin_smith>
I am being sardonic of course, cynically exploiting rubes is a use case, but not one that makes block chain look appealing to me
<leeward>
Oh, I get it.
<justin_smith>
leeward: the great thing is it didn't even look like fraud, it looked like an easy programming mistake that *just happened* to benefit the programmer
<leeward>
I thought you were talking about an actual project.
frett27 has joined #zig
<leeward>
Yeah, block chain has been found to be of great use to many kinds of criminals. The kind of useful I'm thinking of is for people whose business model is not primarily fraud.
<justin_smith>
similar things with bitcoin wallets that just happen to accidentally put a fraction of btc in a wallet whose id is determined by a weird but predictable side effect of the hashing
<justin_smith>
easy bug, just happens to benefit the people who figure out how to find and access the result sooner
<justin_smith>
leeward: right, the systems we have now have a lot of allowance for combatting fraud, which block chain impedes by design
<leeward>
Oh, someone stole your credit card? No problem. Someone stole your bitcoin wallet? You're SOL.
<justin_smith>
luckily block chain also impedes true obfuscation of said fraud, so there's one more monster at the bottom of pandora's box
<leeward>
Yeah, I love how so many people think transactions are anonymous.
a_chou has joined #zig
<justin_smith>
leeward: on the internet, the many meanings of "anonymous" approach absolute meaninglessness
<justin_smith>
I'm anonymous right now, "oh no that's his real name you've narrowed him down to one of hundreds of thousands of people with thatlegal name"
<leeward>
Even in the BTC dystopia where you never have to convert out to a real currency, it's basically impossible to hide your identity when every transaction you make is necessarily public.
<justin_smith>
brb swapping out my nick for a UUID
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<leeward>
Narrowed down to hundreds of thousands of people who connect to IRC through the netherlands with that name.
<leeward>
with IP addresses from Santa Clara (Hey, my mom used to live there)
<leeward>
Lunch time. I wonder if I should bounce my IRC sessions through digitalocean. Oh well.
cole-h has joined #zig
marnix has quit [Ping timeout: 240 seconds]
marnix has joined #zig
klltkr has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
<pixelherodev>
leeward: I'm in copmplete agreement with you
<pixelherodev>
I think blockchains are a fascination solution... to absolutely no problems.
<pixelherodev>
They're a solution looking for problems.
<pixelherodev>
ifreund: you're good with wayland, right?
<pixelherodev>
I had a small question :P
<ifreund>
you could say that
<pixelherodev>
How hard do you think it'd be to port a small application, which currently uses X11 + GLX, to Wayland?
<pixelherodev>
libwayland + EGL, rather
<pixelherodev>
(as the target)
<ifreund>
I know comparatively little about GLX and EGL, which is what that questions really about :P
<pixelherodev>
That's true, yeah
a_chou has quit [Ping timeout: 272 seconds]
<leeward>
pixelherodev: that's because you like being correct, and my position on blockchain is correct ;P
<pixelherodev>
lol
<nephele>
I'd think beeing completely anonymous would imply that your interactions have no chronological cohesion, so nobody remembers you
<nephele>
wouldn't be easy to acomplish, if you are that one guy that joins as a different UUID every day people quickly recognize you as the UUID guy :)
<leeward>
That sounds true, nephele. Also, you can't be a member of any communities.
a_chou has joined #zig
<justin_smith>
nephele: but anybody could easily spoof you by picking their own UUID
<justin_smith>
I watched the async chat server video demo this morning, and follow up with a few thoughts that I tagged onto an existing "issue" on gh https://github.com/ziglang/zig/issues/5962
<justin_smith>
I should check if concurrent queue / concurrent hash with lock-free reads are on the road map already
<justin_smith>
leeward: oh cool, maybe various data structure questions are consolidated somewhere (eg. arguments about which data structures are good enough / light weight enough / general enough to come with zig?) good data structures being available can make a big difference in language lib quality / usability
<justin_smith>
eg. if we all start using a data structure that doesn't fly on embedded, that doesn't seem like what zig was designed for
cole-h_ has joined #zig
<justin_smith>
OTOH if there's a light and powerful data structure that avoids re-implementing trees / lists everywhere, that's a bonus
<leeward>
I haven't seen that discussion, but it's probably happened. If you know of a data structure that's not supported in the standard library, it's pretty easy to get an implementation in.
<justin_smith>
TBH I should look at what data structures are already provided before speculating
<justin_smith>
leeward: yeah, sounds like a plan, and a way I could likely contribute something I'd be proud of :D
<leeward>
sweet
<leeward>
It's all under lib/std in the source. That's (unfortunately) the best place to look these days.
<leeward>
The standard library docs at ziglang.org/documentation/master/std are not up to date.
cole-h has quit [Ping timeout: 258 seconds]
<leeward>
Or maybe I'm wrong? It looks like they have been updated since I last looked.
<justin_smith>
leeward: thanks for the tip, yeah I don't find much about data structures in documentation/master and that's been my primary learning resource so far
<leeward>
The source is still a better place to go for now.
<justin_smith>
eg. I spent way too long trying to translate a library example from c, because translate-c isn't mentioned in documentation/master, I only noticed it because someone mentioned it here
<justin_smith>
great
<leeward>
Huh, that seems like an oversight.
<leeward>
documentation/master is also in the source, under doc/langref.html.in
a_chou has quit [Remote host closed the connection]
a_chou has joined #zig
<justin_smith>
oh, so it's like std/hash-map std/atomic/queue
<justin_smith>
it would be nice if they were at least aliased to std/data-structures/...
<leeward>
agreed
<leeward>
maybe std/data-structures/threadsafe/
<leeward>
or std/data-structures/threadunsafe/, if there's anything that belongs in there.
<leeward>
I'm not sure there should be. Since you can tell it to build single-threaded, it makes sense to have the implementations chosen at build time.
<andrewrk>
pixelherodev, that's something worth considering, certainly. are you running into situations where you have to copy+paste logic?
<pixelherodev>
andrewrk: not direct copy paste, but close enough
<pixelherodev>
The next big change on my radar is condbr
<andrewrk>
I'd like to see a couple instances of the logic being duplicated and then we'll have something to look at when figuring out how to re organize
<andrewrk>
let's let it get a little bit bad at first
<pixelherodev>
Heh, sure
wootehfoot has joined #zig
cole-h_ is now known as cole-h
traviss__ has quit [Quit: Leaving]
traviss has joined #zig
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
a_chou has quit [Ping timeout: 260 seconds]
reductum has joined #zig
dermetfan has quit [Quit: WeeChat 2.7.1]
dermetfan has joined #zig
<nikki93>
i've been working no an ecs-based game engine in c++ that runs natively but also in wasm and uses the dom for an editor ui in the web -- quick video here: https://imgur.com/a/X4djmaj -- the code for that particular game itself is just around 600 SLOC over the engine: https://gist.github.com/nikki93/003d19e263931edf28ff5d0ebb1ec585 (just a bunch of `struct`s with 'rules' for how to query and update them)
<nikki93>
anyways i've been interested in how zig could be cool for such a thing bc. you can reflect on the structs and do a bunch of comptime stuff for editor ui / serialization / scripting bindings etc.
<nikki93>
there's also this dom dsl (you can see in `Sprite_uiInspect` or `Feet_uiInspect` below for example, where i define custom inspection ui for the sprite and feet stuff you see in the vid) -- would be cool to try something like that in wasm zig (tho the c++ version relies on emscripten for js bindings and isn't much freestanding wasm)
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
a_chou has joined #zig
frett27_ has joined #zig
wootehfoot has quit [Quit: Leaving]
frett27 has quit [Ping timeout: 256 seconds]
marnix has quit [Ping timeout: 260 seconds]
<nikki93>
playing around w/ reflection in zig rn and it's nice :o a main thing that caught my eye is also a quick recursive fibonacci benchmark that i tend to do in any new language i'm trying out and it's faster in zig than see / neck n' neck lol
<pixelherodev>
I accidentally made an infinite loop in freaking color extraction code
<pixelherodev>
Haven't felt this dumb in a while
<fengb>
That’s a type of error I make every week >_>
marnix has joined #zig
ur5us has joined #zig
<nikki93>
@pixelherodev: maybe the zig compiler could detect if one's code is going to infinite loop ;o lolz
<leeward>
That sounds like a nice easy problem that could be solved in an afternoon.
<leeward>
Just write a little program that tells you if a loop is infinite.
<pixelherodev>
There's a few types that could be caught
<pixelherodev>
This isn't one of them
<leeward>
We actually discussed having an SDL I worked on detect certain types of infinite loops. It's not hard in some cases, and can be very handy.
<pixelherodev>
s/SDL/DSL ?
<nikki93>
but what if ur program does an infinite loop if zig says the program doesn't
<pixelherodev>
Some loops are definitely infinite, some are definitely finite
<pixelherodev>
Most, the compiler can't reasonably know
<nikki93>
fn f() { if (doesntInfiniteLoop(f) { while (true) {} }
marnix has quit [Ping timeout: 240 seconds]
<leeward>
heh, yes, a DSL
gpanders has joined #zig
frett27_ has quit [Read error: Connection reset by peer]
a_chou has quit [Quit: a_chou]
<jjsullivan1>
`@doesHalt()`
<jjsullivan1>
lol
<andrewrk>
welcome nikki93 - I'm looking forward to seeing how it works out for you
<fengb>
Until andrew takes away recursion ;)
<mkchan>
alright, i've been banging my head against this since yesterday: https://godbolt.org/z/bxhx3Y why is this complaining about me not providing the self parameter
<mkchan>
there's also other errors i suppose because i seem to be doing some really questionable stuff
ur5us has quit [Quit: Leaving]
ur5us has joined #zig
<mkchan>
nvm, i'm dumb. i returned the struct into network but never initialized it
<mkchan>
this channel is a good rubber duck it seems
<ifreund>
quack!
<mkchan>
rubber ducky debugging! :)
xackus has quit [Ping timeout: 256 seconds]
jjsullivan1 has quit [Ping timeout: 244 seconds]
<mkchan>
also the other error was i hadn't marked my loop variable as comptime so the array access complained. the code works now
Akuli has quit [Quit: Leaving]
jjsullivan has quit [Remote host closed the connection]
jjsullivan has joined #zig
reductum has quit [Quit: WeeChat 2.9]
nvmd has joined #zig
<nikki93>
andrewrk: thanks! i'm gonna keep doing this existing game project in c++ but gonna keep keeping an eye on zig and trying lil projects in it ^_^
<andrewrk>
oh nice all checks passing for #6250
<andrewrk>
let's see how the CI server likes it when I delete 5,000 lines of C++ code
<andrewrk>
nice, just got `zig cc -o hello hello.c` working entirely self-hosted (depends on clang of course)
<mkchan>
wait then what's the self hosted part?
<daurnimator>
mkchan: "what is `zig cc` written in"
<andrewrk>
providing all the objects needed to link and doing the linker driver
<andrewrk>
zig is doing quite a lot of handy work for you when you use zig cc
<mkchan>
yeah i remember that from your talk. so you mean zig is bootstrapped now?
<mkchan>
like initially you would compile zig with c++ but now you used that c++-compiled zig compiler itself to compile zig
<mkchan>
if i understand correctly
<andrewrk>
well there is https://github.com/ziglang/zig-bootstrap but it's not really fair to call it bootstrapped since it depends on C++, LLVM, Clang, and LLD
<andrewrk>
it will be a milestone when self-hosted (without llvm) can build itself
<mkchan>
alright nvm me then, i need to google some stuff
<andrewrk>
I think we're about 6 months away from that ;)
<andrewrk>
building hello.c into an executable: stage1 took 2.4s with cold cache, stage2 took 1.0s with cold cache
<fengb>
o_O
<andrewrk>
with a warm cache, stage1 took 0.04s, stage2 took 0.02s
<andrewrk>
I'll get some tracy screenshots going :D
<andrewrk>
oh those were debug builds of stage1/2 btw
<pixelherodev>
Warm cache is cheating...
<pixelherodev>
Ah wait, zig cache?
<pixelherodev>
Thought you meant cpu cache for a minute :P
<andrewrk>
yeah, that's the whole problem lol it's impossible to use it correctly
<pixelherodev>
i mean, I agree, but...
<mkchan>
use less templates
<mkchan>
and by that i mean the entire stdlib
<pixelherodev>
I thought C++ had runtime perf on par with C?
<pixelherodev>
(and atrocious comptime perf, and also just sucky as a lang :P)
<mkchan>
mostly does, but depends on the optimizations it can make if you use exotic features
<mkchan>
if i use --release-fast on godbolt, it no longer shows corresponding source and asm colors is that normal?
dermetfan has quit [Ping timeout: 240 seconds]
<mkchan>
https://godbolt.org/z/YE6Krs - here's some NN code if anyone's interested in looking at generated asm. i can't make out much but i see some vectorization going on