IRC channel logs

2021-01-08.log

back to list of logs

<OriansJ>deesix: I love your idea for standardizing the clean up.
<OriansJ>I wonder if we standardize a few other things we could have generic tests that need only an architecture parameter to generate the correct results instead of having a seperate test for each architecture.
<fossy>from #reproducible-builds:
<fossy>15:46 <pabs> LWN predictions for 2021 mentions software supply chain attacks https://lwn.net/SubscriberLink/840632/fb4e404dbe82c65e/
<OriansJ>pder: well there is one part of the C preprocessor that I absolutely don't want in M2-Planet #include (because I can't do that on bare metal)
<OriansJ>amirouche: technically you probably are in the first 20 people on the planet to read it
<OriansJ>hell there are 10,000 people learning what rick rolling is for the first time in their lives today.
<xentrac>never gonna link you up, never gonna desugar you down; never gonna parse around and compile ou
<OriansJ>xentrac: :D
<OriansJ>deesix: that is some impressive work
<OriansJ>great job
<deesix>Thanks.
<deesix>OriansJ, yes... that's my next goal but I saw some details that need some thinking.
<OriansJ>deesix: I trust that you'll bring a brilliant solution as always ^_^
<fossy>is anyone doing anything at fosdem this year?
<OriansJ>I proposed a stage0 talk but it got rejected -_-
<fossy>:|
<OriansJ>janneke: might have had better luck than I
<xentrac>oh, that's too bad
<OriansJ>I guess I probably should come up with a better proposal than: https://github.com/oriansj/talk-notes/blob/master/librePlanet-2018/proposal.org
<OriansJ>because it clearly isn't working
<OriansJ>(so glad I don't have to work in sales)
<plasma41>oriansj, janneke: Could I get some more experienced eyes on this. In the package definition for the Free Pascal compiler (packagename fpc) it look to me like it's being compiled with a prebuilt fpc downloaded from upstream, thus breaking the chain to the Guix bootstrap binaries. Can y'all confirm?
<plasma41>The Free Pascal compiler is itself written in (Object?) Pascal. The only other free software Pascal compiler I am aware of is GNU Pascal, written in C. GNU Pascal appears to have not been maintained since 2005.
<OriansJ>well it is downloading mirror://sourceforge/freepascal/Linux/3.0.4/fpc-3.0.4.i386-linux.tar
<OriansJ>per gnu/packages/pascal.scm
<plasma41>oriansj: AFAICT, this looks to be the same kind of bootstrapping issue as the one affecting the Glasgow Haskell Compiler.
<stikonas>yeah, I think I've seen it before that free pascal compiler is not bootstrappable
<OriansJ>yep its a big binary blob
<plasma41>That's what I was afraid of
<stikonas>is it still widely used?
<stikonas>(we did have to learn it at school...)
<xentrac>no, because it compiles Pascal
<xentrac>I wonder how hard it would be to get fpc to compile with GNU Pascal
<plasma41>stikonas: Anything built with the Lazarus IDE uses it. I'm pretty sure ddrescueview falls into that category.
<OriansJ>probably not that hard compared to the GHC problem
<plasma41>I stumbled upon this because I wanted to compile the PortableApps.com Platform from source. Prior to yesterday I didn't even know that platform was written in Pascal.
<xentrac>hmm, I thought that at some point Borland had freed some version of their Pascal compiler, but I think I was wrong about that. I think I was misremembering Kylix
<fossy>> Originally, the compiler [Free Pascal] was a 16-bit DOS executable compiled by Turbo Pascal. After two years, the compiler was able to compile itself and became a 32-bit executable.
<fossy> https://en.wikipedia.org/wiki/Free_Pascal#Early_years
<fossy>HM.
<fossy>no going back in time for this one!
<OriansJ>probably only needs someone to create guix packages for all previous versions until it is able to be built by GNU Pascal again.
<fossy>proabbly
<plasma41>I've never written a line of Pascal in my life, I'm kinda stumbling in the dark here.
<OriansJ>plasma41: well good news is you only need to run a build tool
<OriansJ>eg download a source tar and using GNU Pascal see if it builds. If not go older
<fossy>i'll give this a go
<fossy>aw shite
<OriansJ>then find the latest version that can compile; repeat until done bootstrapping pascal
<fossy>it's a gcc backend
<fossy>this is less than simple
<xentrac>GNU Pascal may not have ever supported all the Pascal extensions used by any version of FPC
<OriansJ>xentrac: then it becomes just another one of our problems to solve
<xentrac>unlike C, standard Pascal was never powerful enough to use for practical programs, so every practical program written in Pascal was either written in a particular vendor's dialect of Pascal, or written in a higher-level language compiled into Pascal (things tha took this approach were Software Tools in Pascal, and TeX)
<OriansJ>then we throw a developer at it until we beat it into a proper bootstrap
<xentrac>but it wouldn't be surprising if some version of GNU Pascal *was* able to build some version of FPC
<OriansJ>Only so many combinations to check
<xentrac>plasma41 or someone (me?) would have to try it, along the lines you suggest
<fossy>well step 1 is compiling gcc 3.4.3
<OriansJ>I'm leaving it to anyone who wants to do the work
<fossy>and going backwards is less-than-trivial
<fossy>sdo we can go forwards from gcc 2 :)
<plasma41>The website for GNU Pascal hasn't been touched in so long, it still makes a point about not using GIF due to software patents. :P https://www.gnu-pascal.de/gpc/h-resources.html
<OriansJ>plasma41: maybe hunt down one of the previous Devs and see if they are willing to help us solve the bootstrap problem (or the FreePascal devs)
<OriansJ>you can even give them the guix promise, we will keep it working forever
<stikonas>fossy: you don't have gcc 2 yet :D
<plasma41>I'll see what I can do.
<OriansJ>thank you plasma41
<xentrac><3
<fossy>stikonas: when we do i mean :)
<fossy>well guix does at least
<vagrantc>hah! GIF patents!
<stikonas>well, you still shouldn't use GIF but due to different reasons
<fossy>whys that
<xentrac>GIF is a reasonable thing to use now, and supports animation, but PNG compresses better and supports truecolor
<vagrantc>if nothing else, the patent issue lead to the creation of better image formats :)
<stikonas>well, only for animation, for everything else PNG is better
<xentrac>and MPEG-4 or H.264 compresses better, supports sound, and also supports animation
<stikonas>but I guess even for animations something based on webm, etc would have better quality
<xentrac>yeah, though webm isn't as widely supported and is pretty CPU-intensive to decode
<xentrac>Fractint saves its fractal parameters in a GIF89a block, which allows you to load the image into Fractint and zoom out, or in, or tweak the parameters
<xentrac>or recompute it at a higher resolution
<xentrac>you could do that with PNG too but as far as I know nobody has added PNG support to Fractint
<xentrac>but this is pretty offtopic
<plasma41>The last two Debian packages of gpc are https://snapshot.debian.org/package/gcc-defaults/1.97/#gpc_5:3a:2.1-4.1.2-47 and https://snapshot.debian.org/package/gcc-defaults/1.97exp1/#gpc_5:3a:2.1-4.1.2-47exp1
<plasma41>It looks like gpc has received at least some maintenance since 2005 on some of the BSDs https://repology.org/project/gpc/versions
<stikonas>fossy: by the way, which files failed to compiled for you when building tcc?
<stikonas>maybe be the same problem I was facing with mes? i.e. kaem's quote escaping doesn't work
<fossy>stikonas: it's some weird preprocessing bug in mes
<fossy>bye
<fossy>or else yah a bug in kaem
<fossy>but i dont think so because sometimes the -D's work but other times they don't
<fossy>anyway i got everything compiled, now i just need to do the recompilations whihc are more straightforward
<stikonas[m]>I briefly tried -D with strings often failed
<stikonas[m]>E.g. in tccelf.c
<stikonas[m]>That's why I suspect quote escaping problem...
<stikonas[m]>But OK, if you got it compiled, it should be quick now...
<xentrac>plasma41: oh, that's great news, it probably means it still works :)
<OriansJ>stikonas[m]: well you can test what kaem does using echo can compare it against bash to spot any strings kaem escapes wrong
<fossy>hmmm
<fossy>stikonas[m]: !!! I think i know why kaem isn't handling escaping properly
<fossy>\ wasn't originally made for escaping and as such isn't handled correctly
<fossy>because we use it at the end of lines to concat newlines, it should only be eating the next character if it is a newline..
<fossy>yeah, that'll fix that issue
<siraben>pder: re: C pre-processor in Haskell, that would be possible, I'm looking at the source code https://hackage.haskell.org/package/cpphs-1.20.9.1/docs/src/Language.Preprocessor.Cpphs.RunCpphs.html#runCpphsPass1
<siraben>hm might be easier to write our own naïve one
<rain1> https://github.com/rain-1/s you can probably use this for scripts, after kaem and mes before bash if you need a simple shell
<rain1>dont know if that's needed, it is not posix compatable and we do have scheme at that point
<gforce_d11977>rain1: really like your table shell vs. codelines. please use 'sloccount' for that and add https://git.kernel.org/pub/scm/utils/dash/dash.git which has 13805 lines
<rain1>thanks! glad you liked it
<gforce_d11977>rain1: an 's' has according to sloccount ~1195 lines of code 8-)
<gforce_d11977>rain1: and 2639 lines including 'linenoise', but still much more slim than.....bash 8-)
<rain1>yes, linenoise can be removed too
<stikonas>I wonder what is the simplest C compiler that can build s...
<stikonas>tcc?
<rain1>i imagine it can be built by tcc and mescc, i don't know if the M2 c compiler could do it
<stikonas>if mescc can build it it might be worth building it then
<gforce_d11977>stikonas: interesting, but irrelevant: for bootstrapping you need a simple shell (e.g. kaem), so this is still an a task for a binary blobbed 'kaem'
<stikonas>yes, of course you need kaem
<stikonas>but the sooner we have better shell the better
<stikonas>kaem is a bit too simple :)
<stikonas>maybe I'll try to use mescc to build it this evening...
<rain1>kaem is wonderful
<gforce_d11977>stikonas: you are right, at least we can write better readable shell-script, but 's' is still very limiting
<gforce_d11977>you made my day with "kaem is wonderful" 8-)
<stikonas>well, yes, kaem is nice at the beginning
<stikonas>especially when build commands are simple (e.g. building hex2, M1, M2-Planet)...
<gforce_d11977>what is still missing for the early boot is 'chmod +x', but i have an idea for that
<gforce_d11977>idea1: introduce an filesystem/tmpfs where every file is executable 8-)
<gforce_d11977>idea2: prefill the filesystem with a '0-byte' and 'chmod +x' modded 'bin/hex.bin'
<gforce_d11977>idea3: ???
<stikonas>we have chmod +x quite early
<stikonas>definitely have it once we have M2-Planet
<rain1> https://gist.github.com/rain-1/f24216a0c75946b8a46984cd31d6f304 made s into a single file, with no linenoise (just commented out the interactive mode)
<gforce_d11977>stikonas: yes, but how will you start all the compiles hex-binaries without +x ??? 8-)
<gforce_d11977>rain1: nice! but s_packed.bin is still 35k stripped 8-)
<rain1>yikes why is that
<gforce_d11977>rain1: it's ok IMHO, i'am not wondering
<gforce_d11977>rain1: it's 21k built with O2 and stripped on x86_64
<stikonas>gforce_d11977: I think hex binaries call chmod syscall
<gforce_d11977>rain1: compared with a full blown POSIX shell (dash): 121k
<gforce_d11977>stikonas: will check that, thank you
<stikonas>gforce_d11977: or maybe kaem ignores it and can run non-executable files
<malina>stikonas, apart from this, other projects were isnpired by edmund's 'notes' . including .e.g. https://github.com/rui314/8cc
<malina>now works at google I think so, it obviously was interestin stuff. He did/does continue the whole thing of a self compiling compiler which I would think is even more basic than tcc. I forget now but it might be of interest to you as you asked about other simple c compilers.
<malina>(I haven't looked at it myself for a good while so not quite sure if it will be relevant to your question)
<rain1>rui had a promising 9cc project but stopped it
<malina>8cc? ye it says he has a new WIP, chibbi or os
<malina> https://github.com/rui314/chibicc
<malina>anyway, I sse in noted he does NOT refeence eddie's (sorry i never recall the surname :p) notes, my bad, was firly certain I thought it came from that as well. nvm then
<gforce_d11977>stikonas: you are right, the first HEX0 binary set +x on HEX1 and so on.....THANKS for the hint
<stikonas>yeah, it runs LOADI32_EDX %448
<stikonas>these alternative C compilers are probably harder to build then M2-Planet...
<stikonas>or cc_x86...
<malina>by all means, but your question was so broad "s..." I just had in mind, there could still be some 'reference material' which might have satsified your curiousity or so.
<stikonas>s is a shell, not a compiler
<malina>oh. I read s... as s...omething
<malina>got ya
<stikonas>it's this one https://github.com/rain-1/s
<malina>OH :D
<malina>I see TempleOs.. just doing a wc -l on its sources must have been brave
<OriansJ>gforce_d11977: originally mescc-tools had exec_enable to solve the need for chmod +x problem. Then I realized that one can make a file executable with the open command (ECX %577 [O_WRONLY|O_CREAT|O_TRUNC], EDX %448 [700 in octal], EAX %5) and only the hex* series need to make executable files as M0/M1, cc_*/M2-Planet just output for another program to process and 0600 (rw- --- ---) is sufficient.
<OriansJ>fossy: if you would like, I can try to find time later today to fix kaem's string tokenization to support C style escapes
<fossy>OriansJ: I was planning to do that today but if you want to do that thats fine
<pder>fossy: I have updated blynn-compiler so you can build to the final stage (precisely) without using shell redirection. So basically the go.sh can be changed to a kaem script with little change
<pder>does it make sense to add mkdir as a builtin in kaem?
<fossy>pder: no it does not
<fossy>pder: I am going to PR a cp and chmod command to mescc tools
<fossy>eventually I will need to add rm and mkdir too
<fossy>But not as a builtin
<pder>ok, so with blynn-compiler, go.sh does a mkdir for the bin and generated directories, so for live-bootstrap, they will need to already exist
<stikonas>rain1: so "s" will not be usable early in bootstrap
<stikonas>I tried building it with mescc and it didn't work
<rain1>ok
<stikonas>and I think even tcc would struggle, since we only have access to mescc libc
<stikonas>e.g. termios.h wouldn't be available...
<rain1>which file includes that?
<stikonas>linenoise.c
<rain1>oh there is a verson with linenoise reomved
<stikonas>well, mescc struggles with more files...
<rain1> https://gist.github.com/rain-1/f24216a0c75946b8a46984cd31d6f304
<stikonas>maybe tcc would do better...
<stikonas>let's see
<stikonas>no, mescc is too simple...
<fossy>pder: that is fine
<yt_>OriansJ: the next bit of the C preprocessor I promised: https://github.com/oriansj/M2-Planet/pull/11