On Saturday, March 23rd, 2024 at 20:41, Rob Landley <r...@landley.net> wrote: > On 3/21/24 23:59, Oliver Webb wrote: > > On Thursday, March 21st, 2024 at 22:45, Rob Landley r...@landley.net wrote: > > > On 3/17/24 14:52, Oliver Webb wrote: > > > > > > > Same here, I can remember the posix commands. > > > > > > Can you? I still have to check some from time to time, and the definition > > > of > > > whether "tar" is a posix command or not is outright eldrich bordering on > > > quantum. > > > > I can certainly remember them better then the LSB commands. Most of the > > time I can > > remember if a command is in posix, which is what matters when trying to > > find it usually. > > Congratulations?
Me (In response to enh): "Same here, I can remember the posix commands [...]" you: "Can You?" Me: [Response that boils down to "yes"] you: "Congratulations?" (With a "How is this relevant" question-mark because I answered a question you asked) ... > Bikeshedding is vaguely related to the Dunning-Kruger effect, in which the > question "how hard can it be?" requiring some expertise to actually answer > gets > people in trouble. [...] > I think we have a different definition of the term. I always thought it was "Technical discussion that gets in the way of more important things" > And partly that the effort put into writing up plans for external consumption > is > NOT effort put into implementing those plans. (Ala "here's how I could > simplify > the kconfig design so a rewrite is less work, although that still doesn't > entirely address depends/selects resolution with "SYMBOL && > (SYMBOL||SYMBOL)". I > blog, and go into quick stream of consciousness asides on the mailing list, > but that's not remotely complete coverage.) I've done some research on this too, we have no "select" statements in any of our config symbols, but we do have a fair amount of that ""SYMBOL && (SYMBOL||SYMBOL)"" expression processing that's annoying to deal with. Also a "choice" block and a few number ranges in the main Config.in we will need to deal with in some way, the depends/selects stuff seems easy but with that expr evaluating probably isn't I tried to write a kconfig parser (As a toy to make the codesharing easier) and got absolutely nowhere. The approach I took to it was storing the entire menu structure as a tree of linked lists, each having a "type" (Menu, comment, selection, etc), A parent item, and a pointer to the next and previous item. The entire tree being stored in one root item who's parent is itself. After parsing the Config.in and generating this. (This is the point where I gave up) The screen drawing routine navigates this and lets you go back/forward/up/down and change config symbols, storing the result in a hash table or array before generating a .config (Idea: Maybe we could generate a C header file as a option instead of a .config file that has to be parsed.) What approach do you plan to take with the data structures? they matter a _lot_ less on oldconfig from my knowledge, but menu navigation is convenient when you have 250 items to go through > Sigh, lemme hit the old damaged .flv file with ffmpeg to convert it to mp4, > upload that, and here's the outline I gave the talk from: > > https://landley.net/talks/prototypeandfanclub.mp4 > https://landley.net/talks/flourish-2010.txt Just wget'ed both things, will watch and read through when I find the time. Thanks [I cut the summary of your talk out, but I read it, interesting stuff even tho I don't have anything to respond to it with, thank you] _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
