IRC channel logs
2025-02-05.log
back to list of logs
<fossy>stikonas: Oh, interesting, didn't even consider that.... <fossy>stikonas: huh, no idea how CI passed then.... <stikonas>fossy: what is the version of python there? <snuik>stikonas, you have 1 message <snuik>stikonas, janneke says: oh that's great news! <fossy>oh, yeah, we updated to 24.04 <stikonas>yeah, that's old news from janneke, I saw that... <stikonas>so on my Gentoo system I tested, it starts working from 3.12 <stikonas>and they indeed have changes to f-string in changelong <stikonas>in particular now you can have arbitrary nesting of f-strings <stikonas>before 3.12 this was the deepest possible nesting f"""{f'''{f'{f"{1+1}"}'}'''}""" (limited by the number of different quotes) <fossy>didn't even know that limitation existed, when i was writing the code i just thought this should work... right... <stikonas>fossy: oh you had to completely rewrite some generators for gcc pregen files... <stikonas>and at this stage I would probably trust your problematic-source more than myself looking at pregen-files... <fossy>me too, i think i overestimated my ability to find pregen files lol, heuristics work better than i expected <fossy>yeah, just one generator needed rewriting <fossy>has a very obtuse history, was published in a research paper with a singular implementation <fossy>clearly someone ran it, checked it into version control, and left it since <stikonas>not sure whether they care about pregen files though <stikonas>as we saw, some maintainers don't really understand the concept <fossy>yeah.... often i see that they will have the generators in-tree, but they also distribute the generated file <fossy>this is one of the few cases where the generator just.. isn't maintained or existing <ztrawhcse>fossy, stikonas: before python 3.12, f-strings were strings with specially parsed contents. After 3.12, f-strings enter a new lexer context every time you transition across quote characters, and determining the end-of-string position requires a PEG parser running the cpython grammar so that it can evaluate whether a quote character is part of an embedded expression or is the string <ztrawhcse>(yes, it changes the lexer rules, not the parser rules) <oriansj>aggi: spot on again. I was referring to runtime memory usage as reported by the kernel. <oriansj>lanodan: mksh shows up on guix with a 3.4MB runtime memory usage <oriansj>which interestingly enough is less than the 4MB memory usage reported for kaem <lanodan>Ah, memory usage, not executable size <fossy>byacc has this awk script skel2c <fossy>so we have some pregened .c files made using awk, but we don't have awk when we build byacc <lanodan>Which is sometimes weird to measure, like res column of ps/top lies (like static executables showing at 0 due to not doing any mmap/brk) and I haven't really found one that really seems to work well <fossy>Hmmmmmm, thanks lanodan, looks promising <matrix_bridge><Andrius Štikonas> It is only needed for one .y file to build bash... <matrix_bridge><Andrius Štikonas> I guess gash would be another fallback option <matrix_bridge><Andrius Štikonas> But who knows how to properly configure it... <fossy>yes, gash looked even worse than even mescc to run last time i examined it <oriansj>well interpreted languages with dynamic typing tend to easily hit weird portability problems. <oriansj>and running your scheme program on multiple different scheme platforms to ensure portability seems always to be a skipped step in development. <fossy>hmmm, might be time for a CI rework soonish <fossy>appears KVM is now supported on GH actions <fossy>and per-job time limit is now 6 hrs <fossy>coreutils 6.10 was released in Jan 2008 <fossy>however the gnulib import in it includes a module "mgetgroups" which was added to gnulib proper, the commit message says "taken from coreutils", in Nov 2009 <fossy>where was this magic module before that?! <fossy>Answer: in a special directory not included in the tarball, only in version control -.- <aggi>well, digged into TeX implementations available; after patching configure.ac for some hours... tetex-3.0 (year 2006) introduced a dependency against c++ with libxpdf already <aggi>i'll give some tetex-1.x from year 1999 a try next... that's round about the same time of ghostscript-7.07 that i salvaged already for tinycc support <aggi>the maintainer of tetex gave up almost 20years ago already; and some recent texlive is a nogo (cmake, icu,... c++, and a heavy dependency graph) <aggi>i don't know if any compatibility or standard exists, for basic TeX authoring, in any case at best there seems not TeX implementation any later than some tetex-1.x version that could pass acceptence criteria with tinycc <aggi>tetex-1.0 got xpdf as dependency on board too, and with it c++ <aggi>not sure yet, if this can be disected, and tex format be rendered to ps/pdf without xpdf <aggi>ok, some old GNU texinfo-4.8 seems to have compiled/linked with tinycc