<op_4>
i did this earlier, but i've been waiting, oh, 6+ hours for a successful (?) build of zig so that i can submit a manifest with the PR!
<op_4>
i basically know what the output of `kiss manifest zig` will be, but i don't want to fake it
<op_4>
dilyn: also zig static is that big because it's literally llvm
<dilyn>
indeed indeed
<op_4>
for now the compiler has all sorts of warts and bugs, but it's 0.9 and just there to get the bootstrapping process started. The current efforrt is on writing zig in zig, and specifically compiling to a C backend. That way the project can ditch the C++ compiler and thin out all of this LLVM stuff
<dilyn>
well it builds for me and the manifest is an absolute unit lmfao. It would probably take the average PC about ten hours to build this...
* op_4
checks uptime
<dilyn>
yeah that would make it a very nice compiler i think
<op_4>
dilyn: hahahaha
<op_4>
TWENTY HOURS BABY
<dilyn>
lmfao
<op_4>
but to be fair that's like 1.3 builds
<dilyn>
I'm so glad I wasted all my money on this PC
* op_4
wishes someone would waste their money on my pc
<dilyn>
XD
<op_4>
why did Dylan target AMDGPU in llvm?
<dilyn>
for mesa
<op_4>
is it a hard dep for mesa?
<op_4>
aha
<dilyn>
only for the radeon graphics
<op_4>
... wait
* op_4
doesn't have radeon graphics
<dilyn>
so for instance if you only use intel, you don't need llvm for mesa
<op_4>
by the end of this week i will have pointlessly built llvm maybe a dozen times
<op_4>
and really it only needs to have been once
<op_4>
well, lesson learnt
<op_4>
upstream != smallest possible choice
<dilyn>
facts
Erus_Iluvatar_ has joined #kisslinux
<op_4>
do you know where in mesa/build it sets radeon? Or is this more a case of ``if llvm is there, build blah''
<op_4>
ah, i'll just read the docs
<dilyn>
mesa will build all targets if you don't specify specific drivers
<dilyn>
so for instance if you only want intel GPU support you just specify i915/i965/iris in the build
konimex1 has joined #kisslinux
<dilyn>
if you specify amd/radeonsi you'll need llvm
konimex has quit [Ping timeout: 240 seconds]
kqz has quit [Ping timeout: 240 seconds]
Erus_Iluvatar has quit [Ping timeout: 240 seconds]
vulpine has quit [Ping timeout: 240 seconds]
mla has quit [Ping timeout: 240 seconds]
<op_4>
dilyn: amazing, i would never have guessed this, thanks for pointing it out
<op_4>
-Dgallium_drivers=i915 here i come
vulpine has joined #kisslinux
dilyn has quit [Ping timeout: 256 seconds]
kqz has joined #kisslinux
ella-0_ has joined #kisslinux
ella-0 has quit [Ping timeout: 256 seconds]
midfavila-laptop has quit [Ping timeout: 256 seconds]
Erus_Iluvatar_ is now known as Erus_Iluvatar
<testuser[m]>
Hi
mahmutov has joined #kisslinux
<testuser[m]>
dilyn bruh the zig package is in root of community repo
bibliocar has joined #kisslinux
<bibliocar>
There's a common set of instructions implemented by all gpu venders, the opengl ARB
<bibliocar>
I wonder if it would be possible to build a "mesa-light" with drivers centered around those. Not something I can work on in the immediate future.
<bibliocar>
almost all, and there are bugs in places, of course.
<sad_plan>
dilyn: so if you have an intel gpu, you dont need llvm to build mesa at all? wasnt that the same with libelf aswell? I seem to recall you mentioned that, when sifting through some irc logs earlier
<sad_plan>
nvrmind, I just notied you said you dont need llvm for intel gpu.
<sad_plan>
what about libelf though?
Ralph1977 has joined #kisslinux
mahmutov has joined #kisslinux
bibliocar has quit [Remote host closed the connection]
Denshi has joined #kisslinux
Denshi has quit [Client Quit]
phinxy has quit [Quit: WeeChat 3.5-dev]
<op_4>
bibliocar: sorry, that's my fault
<op_4>
re zig
<op_4>
opened a pr to fix
<op_4>
sad_plan: i can confirm that crocus (gallium) or i956/i915/... (dri) mesa doesn't need llvm
<sad_plan>
nice
<sad_plan>
now I sortof regert choosing amd for my laptop :p but that pesky intel ME is there though..
<op_4>
sad_plan: you could always go ~2006 intel or so ;)
<op_4>
or for real ARM
<sad_plan>
well yes, Ive looked at those old thinkpads, but theyre getting ancient. hell even older than my desktop :p
<sad_plan>
ARM is indeed interesting
<sad_plan>
I have sortof been eyeing the M1 mac. even though I kinda hate apple. the M1 macs have good hardware
phinxy has joined #kisslinux
<sad_plan>
I do however wish there were more ARM hardware which has better hardware, or something similar to whatever I already have
bibliocar has joined #kisslinux
<bibliocar>
huh? I think you meant somebody else. Unless you were working at nvidia?
dilyn has joined #kisslinux
<dilyn>
sad_plan: same story with libelf. You can probably run entirely libelf free if you opt to use the worse unwinder in the kernel
<sad_plan>
Ive tried to use the others, but on amd, it doesnt seem to matter :p so Im considering switching to intel whenever, or ARM if I eventually get there. but nice to know anyway
<op_4>
sad_plan: i've been curious about the samsung chromebook plus k01us, it's a 64 bit relatively beefy ARM with mainline blobless GPU support
<op_4>
dilyn: lol sorry i suck at this somehow
<dilyn>
so do i lmao
mobinmob has quit [Quit: Connection closed for inactivity]
<op_4>
well we got there in the end
<op_4>
the real friends are the PRs we made along the way
<sad_plan>
nice, Ill check that out. maybe I end up switching out my acer laptop.
<op_4>
that would be cool, i'd love to hear about this if you undertake it. Having said that, we may have different standards about "relatively beefy", i hope i haven't mislead you
<sad_plan>
whats beefy and not is subjective, so I gotchu. Ive never had any highend pcs anyway, so having my 3700 ryzen 7 cpu is fine performance wise.
<sad_plan>
damn, I just stumbled upon the pelican case for rpi, theyre really cool. now I want one
<jslick>
Is zig supposed to have all those source files in the built (installed) package? The package has over 14 thousand files in it
<sad_plan>
correction, itss not for the pi, but people seem to use it for them
<op_4>
jslick: yeah, those are all the library headers for cross compilation
<jslick>
ok thanks
<op_4>
they should all be in /usr/lib/zig/ i hope
<jslick>
yeah I think so
<op_4>
jslick: the compiler is still in its infancy, but a nice thing right now is that it effortlessly cross-compiles c code too
<op_4>
well, `````effortlessly''''''
<jslick>
yeah, I saw a demo of it a while ago. Looked kinda neat
midfavila has joined #kisslinux
<midfavila>
afternoon #kisslinux
<sad_plan>
hi mid
<jslick>
op_4 does zig build have parallel build? It looks like it's keeping 1 core busy, and I can't find any documentation about specifying number of jobs
<op_4>
jslick i don't know the answer to that question, sorry
<op_4>
do you mean compiling the compiler, or using zig to compile zig code?
<jslick>
ah, I meant a program. e.g. the equivalent of -j9
<op_4>
jslick: yeah, not sure, sorry. #zig here on libera will know the answer however
* op_4
only has two cores :'(
<op_4>
i wouldn't be surprised if the answer was something like: the self-hosted compiler will, but everything about the C++ compiler sucks and we're not working on improving it
<op_4>
i.e., wait for 0.10.0
<jslick>
2 cores? jeez how long did it take you to build zig?
<op_4>
i think i'd prefer to answer questions in the presence of my lawyer
<op_4>
but yeah, i lost track, probably around ~20 hours? only because it has to build llvm twice!
<midfavila>
>20 hours to build a memelang compiler
<midfavila>
wtf
<op_4>
midfavila: hmm, i don't think we agree on the status of Zig
<op_4>
but also, as i've mentioned before, this is an old computer with an intel core 2 duo P8400
<midfavila>
okay, *that* makes more sense
bibliocar has quit [Remote host closed the connection]
<op_4>
i'm not sure whether the hard cap on my processing power is financial or limited by the great intel ME wall
<midfavila>
yas
<midfavila>
it's both
<op_4>
facts
<midfavila>
my next machine is unironically going to be an m68k
<midfavila>
getting real fucking sick of modern computers
<op_4>
haha
<midfavila>
i'm dead serious.
<op_4>
welcome to #kisslinux
<midfavila>
wait until I post my manifesto
<midfavila>
"revolt against the digital world"
<op_4>
yeah, i sympathise but i don't know that i have the volition to see it through
<op_4>
power to you midfavila
<midfavila>
love how even the "lightweight" textmode browsers are almost all upward of 100k lines of code
<sad_plan>
lightweight is subjective you know. lightwight compared to what? :p
<midfavila>
if you want to argue about the meaning of words, then yeah, you have a point. i'm just really frustrated with how huge even small browsers are because of all the excess features that they support
<sad_plan>
well that makes two of us
<midfavila>
it'd be *really cool* if there was a browser that was basically nothing but an HTTP parser
<testuser[m]>
Why u always complaining
<midfavila>
because i'm an extremely neurotic individual
<sad_plan>
lol
<sad_plan>
well, mid, just for comparison, if I did my wc -l correctly, surf for example, has 2377 LOC. which isnt a whole lot imo. Ill check couple of more for funzies
<midfavila>
surf is just a webkit frontend
<sad_plan>
I know
<midfavila>
so no, it drags in hundreds of thousands or even millions of lines of code
<sad_plan>
ye
<midfavila>
even edbrowse is around 50-60k sloc
<midfavila>
links2 is over 100k
<sad_plan>
huh
<midfavila>
same with w3m I think
<sad_plan>
thats quite alot
<sad_plan>
wonder how many ff has
<midfavila>
way too many
<sad_plan>
how bout lynx?
<midfavila>
lynx is almost certainly over 100k
<midfavila>
let me check
<sad_plan>
are you using cloc to check?
<midfavila>
yes
<sad_plan>
Ive never figured out how it works
<midfavila>
273k sloc
<sad_plan>
damn
<midfavila>
and you just point cloc at a directory
<midfavila>
it'll spit out relevant info a few minutes later
* midfavila
shrugs
<sad_plan>
aah
<midfavila>
anyway yeah, main reason this is a *problem* for me is that I want to tinker and play with my PC's programs
<midfavila>
but it's kind of hard to do that when said programs are tens or hundreds of thousands of lines of code
<op_4>
i don't know that loc is a useful metric. It feels a little arbitrary, because some languages are more verbose/make certain things more elaborate than others, right?
<testuser[m]>
Why not give it a shot urself
<sad_plan>
^ correct
<midfavila>
sure, but i'm specifically talking about C
<testuser[m]>
And for hacking u don't need the context of the whole codebase
<testuser[m]>
Just the thing ur working on
<midfavila>
i can't work like that
<midfavila>
personal flaw, but I don't feel comfortable working on something unless I can keep everything related to it in working memory at once
<midfavila>
also re: why not give it a shot myself, in the future I fully intend to
<testuser[m]>
Most non trivial programs are atleast like 10k loc so
<op_4>
midfavila: that helps for narrowing it down, but i still can't help but feel that if the subject matter is something that C is bad at (eg, unicode aware string handling) then all programmes exhibiting these features will be at least so large
* midfavila
coughs in ascii
* op_4
coughs in document encoding for HTTP
<midfavila>
HTTP4.01 and prior are fine with ascii
* testuser[m]
wears a mask
<midfavila>
it's only 5 that forces utf
<op_4>
midfavila: TIL
<midfavila>
yeah ISO 15445 "Hypertext Markup Language 4.01" specifies that you can use any arbitrary text encoding if you declare it in your header
<midfavila>
at least I think that was the number...
<op_4>
well then i agree with testuser[m], write an http parser :)
<op_4>
personally i'd love a nice line-mode http interface
<midfavila>
my eventual goal is to write a system using lisp based on the actor model and filesystem interfaces
<op_4>
that could pipe to whatever pager or renderer the user wanted
<midfavila>
mmh, that's what I'm thinking too
<op_4>
and could compose with external tools for protocol stuff (eg. openssl for TLS or whatever)
* midfavila
nods
<op_4>
cool, i look forward to seeing this ;)
<midfavila>
my ideal would be to use an embeddable dialect of scheme (probably based on T or PreScheme) to write all runtime code, and then the "programs" are basically nothing more than hyperspecialized lisp interpreters for given domains, effectively libraries
<midfavila>
they expose program internals via filesystem interfaces, and communicate with other programs by reading and writing those special pseudo-filesystems
<op_4>
this sounds great
<op_4>
like plan9 meets lisp machine
<midfavila>
that's the goal
<midfavila>
i shall call it a/OS
<op_4>
woo
<midfavila>
for autism or asynchronous, whichever picks your fancy
<op_4>
heh
<sad_plan>
firefox has 27851392 LOC
<midfavila>
but don't forget about all of its dependencies
<midfavila>
:^)
<sad_plan>
yeah that too
<sad_plan>
and firefox has ..some dependencies
<midfavila>
first thing I'm doing once I rework my LAN is hosting local copies of all necessary source over gopher
<midfavila>
gopher is at least sane
<sad_plan>
its unencrypted though
<midfavila>
it's on my LAN
<sad_plan>
well then I suppose its fine :P
<midfavila>
besides, gopher generally only serves static content
<sad_plan>
yeah, thats true. its only text anyway
<midfavila>
the worst that'd happen over the internet is that someone injects ASCII or something
<testuser[m]>
Gonna inject a nul termination at the start of ur file
<testuser[m]>
Terminator
<midfavila>
'm gonna refresh my page.
<midfavila>
besides, there's no reason to attack gopher traffic because it's all publically available data anyway
<sad_plan>
youre right. I was just pointing it out, that it only serves http, not https
<midfavila>
only thing I can think of is if you knew of a bug in the parser that would give RCE, but gopher is a simple enough protocol that eliminating such bugs should be easy
<midfavila>
and it doesn't serve http at all
<midfavila>
plus there *is* an SSL-encrypted gopher extension iirc
<op_4>
midfavila: are you someone who dislikes gemini?
<midfavila>
yes
<midfavila>
i think it's a poorly-designed solution to a problem that doesn't exist
<op_4>
in a way that's worse that gopher + ssl?
<midfavila>
no, because gemini is its own much more complex protocol+mandatory tls
<op_4>
right, there's CGI stuff
<midfavila>
CGI is w/e
<midfavila>
you can pull similar stuff off with gopher
<op_4>
so where in your opinion does the complexity lie?
<midfavila>
my main issue is that it (afaik, correct me if wrong) also handles data transfer, and that mandatory tls thing is kind of a huge problem
<midfavila>
gopher is nice because it's extraordinarily simple (the entire RFC is like 20-30 pages) and handles hierarchical plaintext
<midfavila>
that's it
<midfavila>
but on older machines modern cryptography absolutely demolishes performance
<op_4>
midfavila: i don't believe it handles data transfer, at least not in any specific way
<op_4>
but yes i can see that some might find mandatory tls displeasing
<midfavila>
then I misremembered something, fair enough
<op_4>
yeah, in fact i remembered being annoyed at the folks who asked for content-length headers because then we'd have to handle arb. data
<op_4>
anyway, not important
<op_4>
i can understand the tls thing
<midfavila>
i can at least say I'd rather be stuck using gemini than http
* op_4
nods
<midfavila>
man I should really get back to writing my gopher client...
<midfavila>
eventually I'd like to have a filesystem interface for it
<midfavila>
this thing will be to gopher as ii is to irc, basically
<midfavila>
huh
<midfavila>
cloc works on gzipped tarballs
<sad_plan>
thats nice, so you dont have to untar them to figure out loc
<sad_plan>
do you guys know of any good places to learn C? and what kind of C would be best? I mean, like C99, C89 etc. iirc those are standards or something
<sad_plan>
midfavila: cloc works on tar.xz aswell as tar.bz2. in case you didnt know. I got curious if it did so I checked :p
<sad_plan>
.tgz too
<midfavila>
sad_plan canonical reference is K&R second edition
<midfavila>
i've heard many people sing the praises of Gustedt's "Modern C" and King's "C Programming: A Modern Approach"
<midfavila>
those three combined will give you a firm grasp on C89, C99, and C11
<midfavila>
i'm learning from them atm
<midfavila>
i also intend to work through "Learn C the Hard Way" which is supposedly there to teach best practices and how to write safer programs
<midfavila>
"Hacking: The Art of Exploitation", whilst not a book specifically about C, includes extensive sections on C, assembler, and the use of debuggers and other development tools, as well as a lot of useful information wrt: security, as you might expect
<midfavila>
fair warning though, if you look at King's, you need the second edition, not the first
<midfavila>
...oh! You should also look at "The UNIX Programming Environment", too. Talks about C somewhat, but about UNIX tools and design in general
<midfavila>
it's a little obsolete, but very informative
<midfavila>
mandatory reading for all KISS users, change my mind uwu