ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
return0e has quit [Ping timeout: 244 seconds]
return0e has joined #zig
<daurnimator>
wow that's long
IntoxicatedHippo has joined #zig
<benjikun>
he livestreamed making it
davr0s has joined #zig
<IntoxicatedHippo>
Should the functions in std.math be made to support comptime_int and comptime_float arguments when possible?
<benjikun>
That's the plan (I believe)
<benjikun>
there are a few issues open for things not accepting comptime values and evaluating at compile-time
<daurnimator>
IntoxicatedHippo: which function do you need that doesn't work right now?
<IntoxicatedHippo>
daurnimator: right now the only one I need is floor.
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<benjikun>
How do I use the ANSI clear escape code? (\033[2J)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag>
andrewrk, forgive my lack of git understanding, which is still on the level of "I'd better google how to branch again", what does it mean to re-organize my commits (I don't think I have a problem with this)? More importantly, is there anything I can do in the future to make this easier for you?
<andrewrk>
MajorLag, well first let me maybe help you with something that could save you some trouble
<andrewrk>
It looks like when you want to synchronize your branch with master, you've been making a github pull request through the UI yeah?
<MajorLag>
yeah
<andrewrk>
that's fine - but here's how to do that from the command line
<andrewrk>
this is equivalent to what you've been doing
<andrewrk>
there is another thing you can do which is a little more advanced - and I recommend it only when your branch is only a little bit behind
<andrewrk>
which is: git fetch upstream && git rebase upstream/master
<andrewrk>
this is kinda the same thing, except instead of two branches merging together, it just undoes all your commits, merges upstream/master, and then re-applies your commits on top of that. it makes all the "merge branch ..." commits go away
<andrewrk>
it also rewrites your history. so you have to force push if you do it.
<andrewrk>
and if there are conflicts, then git becomes in an in between state, and you should look at the instructions that `git status` prints to see what your options are
<andrewrk>
(which are, fix the conflicts and then `git rebase --continue`, or give up by doing `git rebase --abort`)
<andrewrk>
does that all make sense?
<MajorLag>
I think so.
<andrewrk>
in answer to your question, the thing you could do is the rebasing thing, before making a pull request - that's the reorganization I'm asking permission to do on your behalf
<MajorLag>
I don't have a problem with that, and I'll make a note to do that in the future. Why is that not recommended if I'm more than a little behind master?
<andrewrk>
for example in my copy elision branch, a rebase would not make sense. it's 75 commits ahead of master, and I've resolved merge conflicts a dozen times
<andrewrk>
a rebase would mean solving these conflicts over and over again
<MajorLag>
Ah, I see.
<MajorLag>
My process has been to get whatever I'm working on in a state I'm more or less happy with before I even touch git. Then I would merge master into my fork, add my stuff, make sure I didn't break anything as best I can, the push it and make a pull request. I'm wondering if there isn't a better way?
<andrewrk>
to be clear, I don't think you need to change your workflow, if you're happy with it, and you don't mind me massaging the commits as I merge them into upstream
<MajorLag>
I have no attachment to the commits.
<andrewrk>
cool :)
<andrewrk>
to help you understand the rebasing thing - it's equivalent to, if you did your workflow, but instead of merging master into your work, you made a fresh git clone, and then overwrote all the files with your modifications
<andrewrk>
that's what rebase does, except with your git commits
<andrewrk>
rather than with files
<MajorLag>
Which is more what I actually want in my workflow anyway, so that'll work out I think.
<MajorLag>
An exception might be if I decide to tackle a std.fmt rewrite or something else with breaking implications throughout the codebase.
<MajorLag>
well, the stdlib codebase
<andrewrk>
in other news, I'm close to having "hello world" build in copy elision branch
<andrewrk>
which is harder than you'd think, if you consider that it involves std.fmt.format, and the default panic handler which supports stack traces
<andrewrk>
then it's time for test case whack a mole
<andrewrk>
and then we're going to have a fresh set of bugs to look forward to...
<MajorLag>
I'm excited for copy elision. It'll be worth it in the end.
suirad has quit [Ping timeout: 256 seconds]
IntoxicatedHippo has quit [Remote host closed the connection]
IntoxicatedHippo has joined #zig
<benjikun>
andrewrk: That's nice to hear
suirad has joined #zig
<daurnimator>
Is it possible to get zig to *not* use in-built functionality and instead make use of libc?
_whitelogger has joined #zig
<presiden>
daurnimator: could you give an example?
<daurnimator>
presiden: e.g. if you want to use pthread_mutex_init to back std.Mutex.....
<hryx>
If you don't import std anywhere, I believe none of it will get used. As long as you link to libc, I don't see why not
<hryx>
or pthread in the case above
<daurnimator>
So I'm thinking about using zig where C is currently assumed
<daurnimator>
And what might break
<hryx>
daurnimator: that might make a neat demo or blog post, making a zig executable with no std. it's probably easier than doing it in rust
<daurnimator>
There's a few classes of "changes" I can see:
<daurnimator>
1. internal calls that people are used to catching via LD_PRELOAD. malloc comes to mind.
<daurnimator>
2. libc plugin architectures, e.g. NSS
<daurnimator>
3. "special" kernel interfaces, e.g. set_robust_list
<daurnimator>
4. other plugin architectures where loaded libraries assume libc pthreads are used for all threading
<daurnimator>
That's my list for now....
<hryx>
Really interesting list of gotchas
<daurnimator>
oh, 5. things that assume libc stdio. -> e.g. zig stdin has it's own buffer in zig-land rather than the one out of C.
<daurnimator>
So I was thinking these things; and thought of one "simple" solution: favour libc over zig stdlib.
<daurnimator>
which might not be a bad thing ..... libc has had a *lot* of optimization effort go into it over the years. By not using e.g. C's stdio, which is sometimes written in optimised assembly, then we may be throwing away performance....
<presiden>
is it like, writing your own alternative std, e.g. const std = @import("mystd");
<presiden>
and everything on mystd use libc
forgot-password has joined #zig
forgot-password has quit [Quit: leaving]
forgot-password has joined #zig
Zaab1t has joined #zig
<suirad>
whats everyone working on?
<forgot-password>
I'm still playing around with OpenGL, you? :)
<suirad>
just finished touching up my pull request
<forgot-password>
Nice, for what?
davr0s has joined #zig
mht has joined #zig
<suirad>
changing some the remaining A functions from the std for winapi
suirad has quit [Quit: Page closed]
suirad has joined #zig
<forgot-password>
Is it possible to generate structs on compile time? I want to make a little helper for interfacing with shaders on a type-checked basis
Zaab1t has quit [Quit: bye bye friends]
<daurnimator>
forgot-password: yes. just return them from a function.