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. <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>deesix: that is some impressive work <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 -_- <OriansJ>janneke: might have had better luck than I <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 <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 <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>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. <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 <OriansJ>then find the latest version that can compile; repeat until done bootstrapping pascal <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 <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 :) <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 <fossy>stikonas: when we do i mean :) <stikonas>well, you still shouldn't use GIF but due to different reasons <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 <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>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]>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>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>hm might be easier to write our own naïve one <rain1>dont know if that's needed, it is not posix compatable and we do have scheme at that point <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... <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>but the sooner we have better shell the better <stikonas>maybe I'll try to use mescc to build it this evening... <gforce_d11977>stikonas: you are right, at least we can write better readable shell-script, but 's' is still very limiting <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' <stikonas>definitely have it once we have M2-Planet <gforce_d11977>stikonas: yes, but how will you start all the compiles hex-binaries without +x ??? 8-) <stikonas>gforce_d11977: I think hex binaries call chmod syscall <stikonas>gforce_d11977: or maybe kaem ignores it and can run non-executable files <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>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>these alternative C compilers are probably harder to build then M2-Planet... <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. <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: I am going to PR a cp and chmod command to mescc tools <fossy>eventually I will need to add rm and mkdir too <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 <stikonas>and I think even tcc would struggle, since we only have access to mescc libc <rain1>oh there is a verson with linenoise reomved <stikonas>well, mescc struggles with more files...