<noocsharp>
im unironically beginning to believe that templeos' command line is better than unix
midfavila-laptop has quit [Client Quit]
midfavila-laptop has joined #kisslinux
hhheccks has quit [Quit: nyaa~]
<acheam>
illiliti: oops I thought I removed all of the '[['s thanks!
<acheam>
noocsharp: how so?
hhheccks has joined #kisslinux
hhheccks has quit [Quit: nyaa~]
<noocsharp>
acheam: "commands" are just function calls
<noocsharp>
you get the flexibility and power of a real programming language
m3g has quit [Ping timeout: 264 seconds]
<acheam>
hmm interesting
<noocsharp>
it would be like using python as a shell, except closer to the metal
<acheam>
xon.sh
<acheam>
I'd use it if it weren't so damn slow to launcy
<acheam>
and just slow in general
<noocsharp>
i shouldn't have said python: it would be more like using c with a repl
<noocsharp>
but interpreted like python
<noocsharp>
and substantially faster, because it's c
<acheam>
thats cool
<acheam>
not exactly the same thing, but you light like picoc
<noocsharp>
so the entire system uses the same language for everything
<acheam>
thats hot
<noocsharp>
if you haven't seen templeos in action, you should check out some videos of terry davis
<noocsharp>
it's pretty amazing
<acheam>
ive seen bits here and thete
<acheam>
just never dove under the hood
<noocsharp>
the templeos kernel code seems like a good educational resource because of how simple it is
<noocsharp>
it is far more kiss than kiss
<acheam>
how's nvidia support tho
<acheam>
and I gots to have my ac wireless
<testuser[m]_>
hi
eyepatchOwl has quit [Ping timeout: 264 seconds]
illiliti has quit [Quit: leaving]
<acheam>
hello testuser[m]_
gtms has joined #kisslinux
No`_ has joined #kisslinux
No`_ has quit [Client Quit]
smartin has joined #kisslinux
_whitelogger has joined #kisslinux
_whitelogger has joined #kisslinux
aman has joined #kisslinux
aman has quit [Quit: aman]
nerditup- has quit [Quit: Bye]
nerditup has joined #kisslinux
<nerditup>
o/
<omanom>
\o
illiliti has joined #kisslinux
sad_plan has joined #kisslinux
<sad_plan>
shiet, this LTO stuff is going to take forever. gcc alone been compiling for roughly around 1.5hrs already :p compiling the rest of the system aswell is going to take foreveeer
<acheam>
nerditup: were you able to get sr.ht up?
<testuser[m]_>
sad_plan: only pgo stuff takes longer
<testuser[m]_>
thats lkike 5 packages
<testuser[m]_>
3* excluding gcc
<sad_plan>
aah ok. I was worried there for a sec, thinking about rust and firefox, which already takes really long time already.
<sad_plan>
what is this pgo stuff anyway?
<testuser[m]_>
ff is with pgo so it takes 2x time, but you can disable it and just go for LTO
<testuser[m]_>
you build a program to generate profile data into a directory, then compiler uses it to optimize hot code paths better
<testuser[m]_>
basically
<testuser[m]_>
its a noticeable difference on large programs like gcc
<sad_plan>
great
humky_ has joined #kisslinux
humky has quit [Read error: Connection reset by peer]
acheam has quit [Quit: connection reset by purr]
kqz has joined #kisslinux
acheam has joined #kisslinux
strajder has joined #kisslinux
midfavila-laptop has quit [Ping timeout: 244 seconds]
_whitelogger has joined #kisslinux
acheam has quit [Quit: connection reset by purr]
psydroid has joined #kisslinux
<midfavila>
noocsharp of course templeOS' command interface is superior
<midfavila>
it's far more flexible and just *capable*
claudia has joined #kisslinux
<omanom>
KISS Temple when?
<noocsharp>
acheam: templeos supports neither graphical accelerate nor wifi
sad_plan has quit [Read error: Connection reset by peer]
<noocsharp>
nor internet for that matter
<testuser[m]_>
nice
claudia has quit [Quit: zzz]
<june>
noocsharp: are those bad things?
claudia has joined #kisslinux
<june>
what has graphics acceleration and internet ever done for us
<claudia>
good point
claudia has quit [Read error: Connection reset by peer]
<illiliti>
guys, how do you concat strings in C? would like to hear your opinions
strajder has quit [Quit: leaving]
<soliwilos>
I'm a noob, but there's the strcat() function.
<illiliti>
unfortunately, strcat() is unsafe
<testuser[m]_>
strlcat from *bsd?
<testuser[m]_>
just put it in a .h file instead of adding dep on libbsd
claudia has joined #kisslinux
<illiliti>
yeah, i considered strlcat
<illiliti>
until i saw memccpy
<illiliti>
which is defined by XSI(POSIX)
<june>
ime there is rarely a good use of str*cat
<june>
for example if it's called in any kind of loop, it's accidentally quadratic
<illiliti>
probably i'll have to roll my own concat func with variadic params, bell and whistles
<midfavila>
hmm. i'll have to read more about that, june. thanks
<june>
basically if you're calling strlcat in a loop, it gets slower and slower the more you do it
<illiliti>
same thing with snprintf
<illiliti>
snprintf is even slower than str*
<june>
snprintf doesn't inherently get any slower if you use it properly
fwze has joined #kisslinux
<june>
the problem with strlcat is that it contains an implicit strlen call
<testuser[m]_>
is there some smaller function than strlcat/snprintf if you just need to add a single char to a char array ?
<june>
sure, arr[i++] = c;
<testuser[m]_>
thanks
<testuser[m]_>
howndid i forget that
claudia has quit [Quit: zzz]
<illiliti>
june: i don't think that using it "properly" will help. if you have a lot of strings that you need to concat, snprintf is slower than anything
<june>
based on what?
<noocsharp>
june: i never said they were bad, but acheam asked about it
<omanom>
with the noted caveat that i am probably the worst when it comes to optimizing... at what threshold of "slower" does it actually matter? is it just purely a best-performance-possible thing, or is the use case driving the need for speed?
<illiliti>
june: snprintf(buf, sizeof(buf), "%s/%s", "/sys/", class); << this is used in lots of threads and definitely slower than chainsaws like memcpy
<illiliti>
i agree that snprintf gives best safety with average performance
<noocsharp>
snprintf is what i always use in that scenario
<noocsharp>
it's fast enough :>
fwze has quit [Quit: WeeChat 3.1]
<illiliti>
but i need excellent performance with excellent safety
<illiliti>
snprintf is slow in my case
<noocsharp>
probably best to roll your own then, i don't know of anything like what you want in libc
<june>
lol you really need to be concatenating /sys/ onto the beginning of a string a trillion times per second?
<june>
seems unlikely that's ever going to be the performance bottleneck
<midfavila>
algorithms are funky...
<omanom>
is there a way to ensure calls to strcat() are done safely? like a safety blanket?
<june>
sure, if you check your own bounds beforehand
<illiliti>
june: lol yes
<illiliti>
memccpy is almost what i'm looking for
kayw has quit [*.net *.split]
rio6 has quit [*.net *.split]
clemens3 has quit [*.net *.split]
kernelc has quit [*.net *.split]
vulpine has quit [*.net *.split]
rio6 has joined #kisslinux
vulpine has joined #kisslinux
kayw has joined #kisslinux
clemens3 has joined #kisslinux
kernelc has joined #kisslinux
<zr>
illiliti: You probably shouldn't be using ASCIZ strings for non-trivial applications
acheam has joined #kisslinux
<zr>
That kind of performance is hard to avoid with those kinds of data types
<zr>
I'd use something like `struct { char *data; int sz; };` for strings
vulpine has quit [Quit: Connection reset by purr]
<illiliti>
yeah
vulpine has joined #kisslinux
<june>
s/int/size_t/
<zr>
antirez has a good lib for this http://www.google.com/url?q=https://github.com/antirez/sds&sa=U&ved=2ahUKEwiN2o7m-_bwAhVFElkFHeBYBLcQFjAAegQIAhAB&usg=AOvVaw0X8zEfkjcIqzWFAssZmQgJ