acheam changed the topic of #kisslinux to: Unnofficial KISS Linux community channel | https://kisscommunity.bvnf.space | post logs or else | song of the day https://vid.puffyan.us/1tQKW9aquT0
_whitelogger has joined #kisslinux
<iceman[m]> Hi
<iceman[m]> <sad_plan> "could use palemoon for now..." <- I used palemoon on fossapup (puppy linux)
<iceman[m]> it was decent enough
<iceman[m]> But it's still nice to keep going with upstream
mako2 has quit [Remote host closed the connection]
<sewn> hi
<xdream8[m]> i am thinking of introducing threading to kiss-rs
<sewn> if it's easy, yes that is a great benefit
<sewn> but if it requires great rewrite of the code it's not reallyw orth it
<xdream8[m]> it is pretty easy, i just need to look at the code and change parts that uses for loops and add threading
mako2 has joined #kisslinux
<xdream8[m]> i will also add a flag, which it will force kiss-rs to use only 1 thread.
<sewn> it is july 30
geekthattweaks has joined #kisslinux
mako2 has quit [Remote host closed the connection]
sad_plan has joined #kisslinux
<sad_plan> hi
<sad_plan> iceman[m]: sure. upstream is always best initially. atleast from a security perspective
<iceman[m]> <xdream8[m]> "it is pretty easy, i just need..." <- is it really beneficial?
<iceman[m]> the time taken for context switch for threads, time taken for setting up other stuff for the threads
<iceman[m]> all taken to consideration
<xdream8[m]> it is very useful. for example when kiss-rs creates a manifest file, it searches pkg directory and takes found files as a vector of paths(you can think of vectors like arrays) and removes prefix($XDG_CACHE_HOME/kiss/proc/<pid>/pkg/<pkg_name>) from all items in the vector. adding threading would shorten the time we spend on this. this is mostly beneficial for big packages as you might have thought.
mako2 has joined #kisslinux
<xdream8[m]> ^ this is single-threaded
<xdream8[m]> ^ this is multi-threaded
<sewn> i dont get how literally listing files and getting information from two files in them in a loop could be so much faster wth
<sewn> xdream8[m]: such a small difference
<sewn> your multi-thread will make difference when checking for conflicts
<sewn> a big one.
<xdream8[m]> i had to wait total 6-8 minutes for 'kiss list' test
<sewn> you set --min-runs to 1000 thats why
<xdream8[m]> yeah i want accurate tests
<sewn> :v
mako2 has quit [Remote host closed the connection]
geekthattweaks has quit [Quit: Connection closed for inactivity]
schillingklaus has joined #kisslinux
<xdream8[m]> should i parallelize source downloads and git checkouts?
<sewn> how
<sewn> btw i would reccomend you try out looking at a git library instead of executing git commands
<xdream8[m]> since they are functions that i wrote myself its pretty easy
<xdream8[m]> sewn: i already use git2 rust lib
<sad_plan> if you can, I would. but make it use a variable, so users can choose how many
<sad_plan> sabotage does this. really neat if you have a good connection
<xdream8[m]> sewn: kiss-rs does not depend on any system commands(except strip)
<xdream8[m]> sad_plan: it will have --jobs flag
<sad_plan> nice
qwinci[m] has joined #kisslinux
schillingklaus has quit [Remote host closed the connection]
schillingklaus has joined #kisslinux
<sewn> oh no
schillingklaus has quit [Remote host closed the connection]
schillingklaus has joined #kisslinux
<xdream8[m]> print order gets messed up
<xdream8[m]> maybe i should not print Reading sources
<sewn> there is NO way that is fast
<sewn> how on earth is that 1.5 seconds
<xdream8[m]> it did not download anything because they are already in cache
<sewn> yeah ik
<xdream8[m]> it only tried to fetch latest git commits
<xdream8[m]> so how should i handle printed output as it gets messed up?
<xdream8[m]> i should make it only print Reading sources... when debug is set
<sewn> is it multi threaded too
<xdream8[m]> yeah
<sewn> you're kidding me
<xdream8[m]> that is why print order gets messed up .d
<sewn> imo it should be one by one, this isnt a binary package manager
<xdream8[m]> this is better. i just need to improve my code
<xdream8[m]> does it look good enough?
<sewn> whats wrong with -> pkg
<xdream8[m]> i think i removed them when illiliti was suggesting me design ideas
<sewn> looks about right
<xdream8[m]> i found a better way to do this. instead of creating threads for packages, we check/download sources in threads
sad_plan has quit [Quit: nyaa~]
mako2 has joined #kisslinux
schillingklaus has quit [Quit: schillingklaus]
solaare has quit [Ping timeout: 246 seconds]
solaare has joined #kisslinux
<xdream8[m]> i am thinking of making some of the compression/decompression libraries in kiss-rs optional at compile-time as its just a lot of dependency
<xdream8[m]> ^ another test
<sewn> where can i see this kiss-rs thing
<xdream8[m]> its in codeberg but i havent pushed in a while
<sewn> maybe one day someone will write kiss-ha
<xdream8[m]> ^ ccache was used for precise results
<sewn> did you
<sewn> did you finish building
<sewn> how is it faster...
<sewn> shell sisters...
<xdream8[m]> pkg_conflicts has lots of bugs and is incomplete other than that i almost finished
<xdream8[m]> sewn: i feel like single-threaded version was faster
<sewn> statistics > feelings
<sewn> :^)
<sewn> whats so multi-threaded about generating checksums
<sewn> looks like you will be using multi-threaded when its needed yay
<xdream8[m]> should i set number of jobs to 1 by default?
<sewn> you should hard-set it automatically when needed
<sewn> for example in big downloads, 4 jobs, and with small ones one job
<sewn> same goes for checksums, etc
<sewn> like if its small disable multi-threading
<xdream8[m]> i can directly number of jobs to 1 by default, so it will be disabled by default
<xdream8[m]> * can directly set number of
<sewn> sure
mobinmob_ has joined #kisslinux
rio6 has quit [Quit: WeeChat 3.0.1]
mako2 has quit [Remote host closed the connection]
schillingklaus has joined #kisslinux
schillingklaus has quit [Remote host closed the connection]
<sewn> i wonder why the irc bridge hasnt gone down yet
schillingklaus has joined #kisslinux
mako2 has joined #kisslinux
_ctb has quit [Ping timeout: 260 seconds]
<mako2> chromium -> build failed https://termbin.com/7odu
_ctb has joined #kisslinux
<mako2> :/
<illiliti> log is truncated
<sewn> ^
mako3 has joined #kisslinux
mako2 has quit [Read error: Connection reset by peer]
<mako3> can i just shorten the log
<mako3> just from the beginning and in the end? i can't upload the file with the full log
<illiliti> use better pastebin
<illiliti> pastes.sh, envs.sh, 0x0.st
<illiliti> gcc/clang is up-to-date?
<mako3> I updated gcc along with nss yesterday
<mako3> I don't think I've heard an update with clang
schillingklaus has quit [Quit: schillingklaus]
<illiliti> weird
<illiliti> not sure why this fix is still not included
<illiliti> you can apply it and check if it works
<illiliti> or you can build chromium with clang
<mako3> does clang work most of the time?
<illiliti> yeah it should bacause google devs use it to build chromium
<mako3> i'll just build it with clang this time, will switch back to gcc if something happens
<illiliti> btw are you sure your computer is capable of building chromium?
<mako3> well, my pc is a r5 5600 and rx 6600 with 32gb
<illiliti> still not enough
<illiliti> get ready for OOM
<mako3> :/
<illiliti> yeah linking step will kill your computer
<mako3> my temps go from 56 to 60's when compiling chromium
<mako3> i just cat /sys/class/hwmon/hwmon0/temp1_input and a sed command to check my temps
<mako3> since there isnt a gotop package in any of the kiss repos
<illiliti> if you live in a cold climate that's probably advantage
<mako3> i wish
<mako3> i live where the sun makes me uncomfortable and itchy, typhoons are frequent
<illiliti> that sucks
<mako3> btw, can i compile the linux kernel without using gcc?
mobinmob_ has quit [Quit: Connection closed for inactivity]
<illiliti> i believe you can
<illiliti> with clang
<mako3> ah i see
mako3 has quit [Remote host closed the connection]
an3223 has joined #kisslinux
sujo has joined #kisslinux