ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<mjacob> andrewrk: ok, about the stack size thing:
<mjacob> you probably already know that determining an exact upper bound for the stack size is impossible in the general case
<mjacob> one possiblity is to restrict the set of analysable programs
<mjacob> the other is to (possibly) overapproximate the stack size
<mjacob> my first question would be which of these two you want to implement
<mjacob> can the user expect that the calculated stack size will be a tight upper bound?
<mjacob> (although it is unclear what a *tight* upper bound actually is)
<mjacob> this is a good paper about the topic: https://www.cs.utah.edu/~regehr/papers/p751-regehr.pdf
<mjacob> given that one of the authors of the paper is also an active llvm developer, he can probably say a thing or two about your plans
<mjacob> one thing for which i didn't find any research so far is how to tell the analysis that its assumed worst case can't actually happen
<mjacob> it would be interesting to combine static stack size analysis with a type system that can encode the resource usage of a function
<mjacob> i'll answer the llvm-specific part on the mailing list
arBmind1 has joined #zig
arBmind has quit [Ping timeout: 258 seconds]
<mjacob> ... which contains more useful information than my random brain dump in this channel :)
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 252 seconds]
hasen_judy has joined #zig
arBmind1 has quit [Quit: Leaving.]
_whitelogger has joined #zig
pupp has joined #zig
hasen_judy has quit [Remote host closed the connection]
hasen_judy has joined #zig
pupp has quit [Ping timeout: 248 seconds]
pupp has joined #zig
pupp has quit [Ping timeout: 258 seconds]
pupp has joined #zig
hasen_judy has quit [Remote host closed the connection]
pupp has quit [Read error: Connection reset by peer]
pupp has joined #zig
<pupp> programs that consist from only one function are the best kind of programs, don't need to worry about stack size
<pupp> a bunch of inline functions and not using recursion will work too
<pupp> can disable stack frame as well, always wanted to do that
<Elronnd> what about TCO?
pupp has quit [Ping timeout: 240 seconds]
pupp has joined #zig
<pupp> Total Cost of Ownership?
<pupp> Elronnd
hasen_judy has joined #zig
pupp has quit [Ping timeout: 255 seconds]
pupp has joined #zig
pupp has quit [Client Quit]
_dev_zero has quit [Remote host closed the connection]
_dev_zero has joined #zig
_whitelogger has joined #zig
tiehuis has quit [Quit: WeeChat 1.9.1]
hasen_judy has quit [Remote host closed the connection]
Max_ has joined #zig
Max_ is now known as Guest96346
Guest96346 has quit [Client Quit]
ofelas has joined #zig
pupp has joined #zig
<pupp> Hm, it looks like either my diff tool or my patch tool is broken.
<pupp> --- a/src/main.cpp
arBmind has joined #zig
<pupp> Can't find this file, have to manually retype "src/main.cpp" for some reason
<pupp> Everything is falling apart, as usual
<pupp> I guess the problem is in the "/" character, because file on top level gets patched without problems.
<ofelas> are you using patch? patch -i some.patch --dry-run -p1, -pN or --strip=N to strip N leading slashes from filenames
<pupp> "patch -i my.patch -p1
<pupp> " worked
<pupp> hmm, I'm creating a patch using "git diff > my.patch", it needs to patch files CMakeLists.txt and src/main.cpp
<pupp> I don't quite understand what "strip slashes" means
<ofelas> yes, that is typically a case for -p1, details are in "man patch", i guess pathname components may be a better term
<pupp> "patch -i my.patch -p1" worked for both files, thanks
<pupp> so it wasn't a bug
<ofelas> nope, there is also "git apply" and "git am", more details here, https://www.devroom.io/2009/10/26/how-to-create-and-apply-a-patch-with-git/ and possibly numerous other places
pupp has quit [Ping timeout: 248 seconds]
arBmind has quit [Quit: Leaving.]
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 260 seconds]
hasen_judy has joined #zig
pupp has joined #zig
hasen_judy has quit [Remote host closed the connection]
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 246 seconds]
<andrewrk> mjacob, I think there is value in obtaining an upper bound which is very close to exactly correct
<andrewrk> one reason that go can get away with a large number of goroutines is that it uses a segmented stack and so stack sizes are smaller
<Elronnd> pupp: Tail Call Optimization. Basically if the last call of a function is to recurse, then the compiler can optimize it down to a goto and not waste a stack frame
<pupp> ah, it's that lisp trick. Always thought that just using "for" is simplier.
<Elronnd> ?
<Elronnd> for is completely different
<Elronnd> and it's not just a lisp trick. Plenty of lisp implementations don't have TCO (and plenty of implementations for other languages do)
<Elronnd> pretty sure gcc and clang have TCO for c
<pupp> I first heard about Tail Call Optimization from a lisp book.
<pupp> I'm currently using recursion in one place, it iterates parsed http. Not really sure how to do it without recursion.
<pupp> Need to allocate memory on the side manually, indeed recursion is simplier here.
<pupp> By the way, how to do a function pointer in zig?
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 246 seconds]
cenomla has joined #zig
ofelas has quit [Quit: shutdown -h now]
dimenus has joined #zig
ryan_ has joined #zig
Mikayil has joined #zig
<Mikayil> Hello World !
<ryan_> hello
ryan_ has quit [Client Quit]
Mikayil has quit [Client Quit]
puppp has joined #zig
pupp has quit [Ping timeout: 248 seconds]
tiehuis has joined #zig
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 252 seconds]
ryan__ has joined #zig
ryan__ has quit [Client Quit]
<dimenus> andrewrk, does the stock 'build-exe' support @cImport/cInclude?
<dimenus> having issues with a basic hello world example on both current head and 0.1.1 release
cenomla has quit [Quit: cenomla]
afsd has joined #zig
afsd has quit [Client Quit]
_whitelogger has joined #zig