Monday, 2023-05-29

*** rsc <rsc!~robert@fedora/rsc> has quit IRC07:00
*** rsc <rsc!> has joined #libre-soc07:00
*** rsc <rsc!> has quit IRC07:00
*** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc07:00
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC07:32
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc07:32
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC08:21
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc08:21
lkcl> <ghostmansd> lkcl, beware, we only have 1 bit in svp64_desc left.09:15
lkclwilldo. there *really* should not be more.09:15
lkcl> ghostmansd> Is it at least close to final revision?09:16
lkclimpossible to say. i really *want* changes to stop, but we are now getting "actual feedback"09:16
lkclplus remember if this is "wrong" and it's not noticed, that's it, we're done: there's no way back09:17
lkcl> <ghostmansd> class CROpFF5RM: RC1 = 109:18
lkclyep. it works.  i hacked that in so as to avoid a (significant) base-class shuffle09:18
lkclit "works" because there *is* no mode other than RC=1 in CROpFF5RM. why? because there is no Rc=1 for CRops, therefore there is no Rc=0 to override, therefore RC1 is "on by default"09:22
lkcls/other than RC=1/other than RC1=1/09:22
*** octavius <octavius!> has joined #libre-soc10:40
*** ghostmansd <ghostmansd!> has quit IRC11:44
*** octavius <octavius!> has quit IRC12:16
ghostmansd[m]I don't get why we need RC1=1. Why not always output as if it's set?13:25
ghostmansd[m]I also noticed that with recent changes we can have common fields like ffrc1/ffrc0 regardless of actual LD/ST type or even for normal. Only CR ops are outsiders (as usual).13:27
ghostmansd[m]Perhaps I'll add these for binutils. The code gets messy there, because now I have to add checks like `if (svp64->record->mode == SVP64_MODE_LDST_IMM)`, but the actual field name only changes from imm to idx.13:29
ghostmansd[m]This eventually will make the logic simpler, we'll only end up with the assertion that mode is not CROP.13:29
lkclyes i am trying to amortise the bits across functions14:41
lkclbecause apart from simplifying your job14:41
lkclit also drastically simplifies hardware, where it *really* matters14:41
lkclRC=1 is supposed to be for instructions that don't have Rc=1 in the main 32-bit instruction.14:46
lkclRc=1 creates "Co-results" associated with Arithmetic instructions (add, subtract, min/max)14:46
lkclso for example "add." if the result is zero, the *CO-RESULT* (CR0) is set to "0b0100"14:47
lkclbut some instructions like prtyd (parity double-word) just don't have Rc=1 (because it was deemed non-sensical)14:48
lkcland unfortunately, all those instructions - even though there is a bit free - *IGNORE* bit 31 (the space where Rc=1 *COULD* have been put)14:49
lkclwe have to use a bit in the SVP64 RM field for the job14:49
lkclthat's what RC1=1 is supposed to be for14:50
*** toshywoshy <toshywoshy!> has quit IRC15:13
lkclbut of course CROps don't *have* a Rc=1 option.15:14
*** toshywoshy <toshywoshy!> has joined #libre-soc15:15
*** ghostmansd <ghostmansd!> has joined #libre-soc15:44
ghostmansdFolks, I've dropped some of my obsolete branches in openpower-isa, feel free to do the same :-)16:19
ghostmansdFolks, has anything been changed with setvl recently?16:37
ghostmansdI see that gas test suite fails after regeneration on setvl tests...16:37
ghostmansdSo either the rebase was wrong, or the disassembly was changed.16:37
ghostmansdregexp "^.*:    (37 00 00 58|58 00 00 37)       setvl.  r0,r0,1,0,0,0$"16:38
ghostmansdline   "   0:   37 00 00 58     setvl.  r0,0,1,0,0,0"16:38
ghostmansdHm. It seems that one of the operands stopped being a register...16:41
ghostmansdOK checking this. Perhaps something with register operands went wrong.16:41
ghostmansdHm. It actually was broken for a while, after I changed its RA operand to RA0 (RA_OR_ZERO per our lingo).16:44
ghostmansd#define RA0 RA + 1 /* As above, but 0 in the RA field means zero, not r0.  */16:45
ghostmansdIt seems binutils are correct here and we're not.16:45
ghostmansd$(echo "setvl.  r0,r0,1,0,0,0" | SILENCELOG=true pysvp64asm | powerpc64le-linux-gnu-as - -o /tmp/elf.o && powerpc64le-linux-gnu-objcopy -Obinary /tmp/elf.o /tmp/bin.o && pysvp64dis < /tmp/bin.o)16:45
ghostmansd37 00 00 58    setvl. r0,r0,1,0,0,016:46
ghostmansdThat's wrong, should be 0 instead of second r0. I'll handle it in our code base.16:47
ghostmansdHm. It seems setvl also has RT_OR_ZERO.17:09
ghostmansdSo `setvl.  r0,r0,1,0,0,0` should instead be `setvl.  0,0,1,0,0,0`, if I'm not confused.17:10
ghostmansdYes, indeed.17:11
ghostmansdif ((operand->flags & PPC_OPERAND_GPR) != 0 || ((operand->flags & PPC_OPERAND_GPR_0) != 0 && value != 0))17:11
ghostmansd(*info->fprintf_styled_func) (info->stream, dis_style_register, "%sr%" PRId64, (vector ? "*" : ""), value);17:11
ghostmansdBTW setvl is the only instruction which has RT_OR_ZERO.17:14
ghostmansdTherefore binutils lack RT0 operand...17:15
ghostmansdYou know what? I'm raising the task, this becomes too big to handle it in comments here.17:15
ghostmansdlkcl, FYI:
ghostmansdNot a critical one, but I cannot tolerate broken binutils tests and incorrect disassembly in openpower-isa, I wasted too much time on it to keep it as is. :-)17:23
ghostmansdHeck, that's not trivial. Operands must know what exact selector is now in action.18:01
ghostmansdAnd guess what? The current code does not bother about it.18:01
ghostmansdThat said... Is there a slightest opportunity, if operand is present on both input and output... that operand ends up being GPR_OR_ZERO for one and a simple GPR for another? This seems to be impossible, right?18:03
*** yambo <yambo!> has quit IRC18:41
*** yambo <yambo!> has joined #libre-soc18:52
lkclghostmansd, ahhh you know why?19:11
lkclit's because the original version of sv/trans/ relied on binutils19:11
lkcland - ahh setvl is a 32-bit scalar instruction19:12
lkcli'm going to treat this as "review of setvl specification" because that's what it needs19:18
*** knar <knar!~knar@2405:201:d02a:7803:606d:603b:c79b:3f75> has joined #libre-soc19:50
ghostmansdlkcl, about selectors... they can't contradict to each other, can they?19:53
ghostmansdthat is, if input selector is GPR_OR_ZERO, output cannot be simply GPR, and vice versa, right?19:54
knarI was interested in this bug report
knarI have written a sort of toy transpiler which transpiles the RTL pseudo code to C code.20:10
knarI have also built Cavatools.20:10
knarLike Im wondering what exactly are we trying to do with the C code generated using Cavatools20:10
knarI apologies if this sounds too noobish20:10
knarif RA = 0 then b ← 020:12
knarelse b ← (RA)20:12
knarEA ← b + (RB)20:12
knarRT ← EXTS(MEM(EA, 2)20:12
knarthis would be simple to compile to C except handling the EXTS and MEM,(i need some guidance on that).20:12
knaralso how exactly should i represent the registers in C20:12
*** knar <knar!~knar@2405:201:d02a:7803:606d:603b:c79b:3f75> has quit IRC20:35
ghostmansdI'd say GPRs are fixed-size integers, FPRs are float/double/integers-with-sw-float depending on your needs21:21
ghostmansdMEM is a simple memory I think21:21
ghostmansdThat is, just plain bytes21:21
lkclghostmansd, no absolutely not - they're mutually-exclusive, definitely.21:34
programmerjakewhat is mutually-exclusive? there are several things that could refer to...21:36
lkclknar: use it! the current python-based simulator (ineptly-named ISACaller after the class name) is 2,500 instructions per second.   cavatools is over ten *THOUSAND* times faster than that, achieving around a 1:50 ratio of Host:Emulated speed21:36
lkclpeter hsu has requested a preference that all registers be held in uint64_t21:37
lkclMEM would translate to a macro - because of the "2" it would be: (uint16_t)(*EA)21:38
lkclcavatools "cheats" - it is not actually a "full guest emulator like qemu"21:38
lkclit is a *userspace-only* simulator that ACTUALLY runs in the ACTUAL host (userspace) memory21:39
programmerjakelkcl, no, that's technically UB, you need to use read/write through union or memcpy because C has type-based alias analysis21:39
lkclconsequently you can only execute ELF binaries.  you can *NOT* execute "the linux kernel" for example.21:39
lkclprogrammerjake, this is "speed and pragmatism over correctness" and it would be behind a macro and/or inline function over which there is direct control to change (without messing with the output of the compiler)21:41
programmerjakeso instead of *(uint16_t *)EA you need:21:42
programmerjakeuint16_t v;21:42
programmerjakememcpy(&v, &mem[EA], sizeof(uint16_t)); // gets optimized to unaligned load21:42
lkclthat would only be used in cavatools if that function (memcpy) is an inline function.21:43
lkclthe function overhead is too great and would severely damage performance21:43
ghostmansdAs for aliasing, this gets dumb over the years I'm looking at it. Over the years, I begin to understand why people disable strict aliasing.21:43
ghostmansdIt sort of became cargo cult, TBH.21:44
ghostmansdYes I know that's the letter of the standard.21:44
programmerjakememcpy is treated specially by every decent c compiler, it translates to whatever instruction sequence is fastest at copying for the given length, generally only actually calling memcpy if the length is dynamic or very big21:44
ghostmansdlkcl, didn't get about mutually exclusive21:44
lkclcavatools is designed very specifically for high-performance21:45
lkclghostmansd: XOR.21:45
programmerjakein the case i posted, it will literally be just a single load instruction21:45
ghostmansdNo I know what's mutually exclusive is in general21:45
ghostmansdI just cannot get what you mean applying it to CSVs21:45
ghostmansdEither one of these?21:46
lkclhang on...21:46
lkcl"if input selector is GPR_OR_ZERO, output cannot be simply GPR,"21:46
ghostmansd(I used GPR as placeholder for RA|RT)21:46
ghostmansdWe cannot have insn record which states cr_in=RA, cr_out=RA_OR_ZERO21:47
ghostmansdThat's what I asked21:47
lkclok.. thinksthinksthinks...21:47
lkclthere is no CR_OR_ZERO if that is what you mean21:47
ghostmansdBecause how'd it work?21:47
ghostmansdNo, that's not about CRs21:47
ghostmansdOK, let's take an example21:48
lkclahh no i got it21:48
lkclok so what "0" is doing here is it is simply changing the behaviour of the instruction21:48
lkclthere are 4 combinations:21:49
lkclRA=0, RT=021:49
lkclRA!=0, RT=021:49
lkclRA=0, RT!=021:49
lkclRA!=0, RT!=021:49
lkclall four permutations are permitted21:49
ghostmansdThat I get21:49
ghostmansdI'm talking about selectors21:49
lkclbut if we ever design an instruction that has in=RA_OR_ZERO,out=RA_OR_ZERO that would be catastrophically stupid of us21:50
programmerjakememcpy being a single load:
ghostmansdIf it can happen that the same operand is chosen for both in and out (say RA)21:50
ghostmansdCan we have record which contains in=RA,out=RA_OR_ZERO?21:50
ghostmansdonly selectors21:51
ghostmansddon't think about SRC/DST21:51
lkclprogrammerjake, okaay. somebody clearly thought about that.21:51
lkclghostmansd, again that would be catastrophically bad/stupid21:51
lkclor would it...21:51
ghostmansdYes that waas my intention too. Because that's basically the same operand.21:51
ghostmansdI'm asking because I need to track operands marked as OR_ZERO21:52
lkclok in=RA_OR_ZERO,out=RA would be okay, because it's actually a "Read-Modify-Write" where you are giving the instruction the opportunity to set GPR(RA) to zero21:52
ghostmansdbut my only option is tracking selectors21:52
ghostmansdI have nothing else to rely on21:52
lkclbut in=RA,out=RA_OR_ZERO would be pretty stupid.21:52
ghostmansdNah don't think about this hardware21:53
lkclwell let us cross that bridge when we come to it.  you have to be pretty desperate in terms of instruction design to do it21:53
ghostmansdRemember, I simply parse goddamn CSVs :-D21:53
programmerjakethat's because c compilers generally use their builtin memcpy for struct assignments, obviously they'd try to optimize that to just a bunch of load/stores, memcpy just gets directly translated to the builtin memcpy21:53
ghostmansdAnd I need some ground to make an assumption "is it a simple RA or RA0"21:54
ghostmansdthat's it, nothing else, no fancy stuff21:54
lkclprogrammerjake, thank you for testing that - can you put the source code into the bugreport because is "too modern" for debian releases of firefox and chrome?21:54 has a no-script variant...21:54
lkclghostmansd, mmmm.... that's making me nervous/twitchy for some reason21:54
ghostmansdlkcl, me too :-)21:55
lkclprogrammerjake, no it's about actually putting the actual source code into the bugreport21:55
programmerjakewhich bug?21:55
lkclas a non-external resource not controlled by us21:55
ghostmansditchy I'd say21:55
lkclghostmansd, is there any reason why you can't just pick up the insndb record and use that?21:57
lkclit _should_ have in1=RA_OR_ZERO and/or out=RT_OR_ZERO in it21:57
ghostmansdyes, that's exactly what I'm going to use21:58
ghostmansdbut the example you posted has different operands21:58
ghostmansdI'm asking whether some insns can have the same operand but differently "marked"21:59
lkclahh actually this is a general problem21:59
ghostmansdI just think whether I need to add some assertion or handle it specifically21:59
lkclno, and any instruction that has different s:RA from d:RA needs to be red-flagged and sorted21:59
ghostmansdYes, thanks21:59
lkclit means there's a bug in sv_analysis.py21:59
ghostmansdThat's what I wanted to hear22:00
ghostmansdSorry for not formulating it in an obvious way22:00
lkcli finally understood what you were driving at, and fortunately it's something i've been keeping an eye on for 8+ months22:00
lkclnono you raised it last week and i understood what you means22:01
lkclah i appreciate it's late, but i wanted to run an idea past you22:01
ghostmansdGo on :-)22:01
ghostmansdIs it a legal one?22:01
* lkcl *snorts*22:01
lkclare you familiar with python's HTML and XML parser?22:02
lkclit's more an "in-order node/tree walker"22:02
ghostmansdNot really, hated XML throughout the entire life :-D22:02
ghostmansdWell I used it a couple of times22:02
ghostmansddom tree or something like that22:02
lkclXML just won't die, sigh22:02
lkclDOM/SAX parsers, yes22:02
ghostmansdNope, not in this multiverse22:03
lkclone is in-memory, the other is stream-based22:03
lkclwell all that's bullshit, but it's along the right lines22:03
lkcli'd like to consider bringing in the "node/tree-walker" thing into insndb.22:03
ghostmansdwhat for? :-)22:03
lkclnot looking inwards22:04
lkclbut for looking outwards22:04
lkclwith a first view to being able to auto-generate the cavatools Decoder22:05
lkclbut *also* replace - ha ha - by outputting *nmigen* that does the exact same job22:05
lkcloutputting - replacing - the way that pysvp64dis works22:06
lkcland (the big one):22:06
lkcloutputting binutils source code.22:06
lkclconceptually it's a bit of a mind-bender, given that insndb is already hair-raising22:07
ghostmansd> given that insndb is already hair-raising22:08
ghostmansdthat's true :-)22:08
lkclbut ultimately they are all of the form "here's this database, let me call a function for you, on every aspect of it: you get to do something with that"22:08
ghostmansddo you have some example configuration in mind?22:08
ghostmansdI don't quite get the structure of XMLs22:09
lkclright now, there is a nested set of for-loops *explicitly* enumerating the database, inside insndb-binutils, right?22:09
ghostmansda total crap TBH22:09
ghostmansdbut we have so many different formats22:09
lkcl(HTML/XML itself is irrelevant, a red herring: it's the *walking* that's important)22:09
ghostmansdI've been thinking of putting it in one giant config22:09
ghostmansdbecause we actually deal with it as a whole22:10
lkclthat set of nested for-loops *is* the beginning of the "walking" thing i am talking about.22:10
lkclhave a look at this and have a think about how it works and why it is so useful:
ghostmansdOK so you want to lookup insn's data by tag22:10
ghostmansdor, well, rather element22:11
lkclat the moment you have:22:11
lkclfor each insn do22:11
lkcl    for each something in insn do22:11
programmerjakeso you want a insndb visitor?22:11
lkcl           action(insn, something)22:11
lkclprogrammerjake, yes!22:11
lkclha, thank you for using the right word i couldn't think of.22:12
lkclthat becomes:22:12
lkclfor each insn do22:12
lkcl      visitor->handle_insn(insn)22:12
lkcl      for each something in insn do22:12
lkcl            visitor->action(something)22:13
ghostmansdOK basically a walker22:13
lkclthat's basically what's in
ghostmansdwhere does "something" come from?22:13
ghostmansdAh wait22:13
ghostmansdIt's subelement22:13
lkcllkcl>       for each -->>>something<<<-- in insn do22:13
programmerjakee.g. insn operands or properties22:14
lkcland you can prooobbbably "morph" the existing binutils-for-loops *into* a "visitor" system22:14
ghostmansdWeeeeell I had some experience with parsing a huge file with x86 MSRs22:14
programmerjaketho imho it should call a different fn for each kind of insn thing22:14
ghostmansd(you can imagine how many MSRs today's Intel has)22:14
lkclprogrammerjake, yes exactly like
programmerjakee.g. there should be an operand fn, and a encoding field fn, and etc.22:15
lkclif you remember, i already ran into this problem, where i had to do a deep-dive into the insndb data structures22:15
ghostmansdfirst question: how about using lxml instead of builtin parser?22:15
lkcleek, 8 months ago now22:16
ghostmansdsigh :-)22:16
lkclthe absolute worst possible thing would be to "convert" to lxml and/or xml22:16
ghostmansdthat one was better TBH22:16
ghostmansdnono, I mean just lxml module22:16
ghostmansdfor parsing vanilla xmls22:16
ghostmansdbut OK, this doesn't matter that much22:16
lkclno, because that would mean converting everything *to* xml22:16
lkclwhich would be the absolute worst possible thing and, again, is a red-herring22:17
lkclforget XML22:17
programmerjakeif we were to use some format other than our existing format, i'd pick almost anything but xml22:17
ghostmansdshouldn't we rename the chat to "XML haters" already?22:17
lkclthe only reason i mentioned it was because it is where the visitor concept exists (and is well-known)22:17
lkcli am most definitely *not* saying "convert to a different database format"22:18
programmerjakebetter options would be json5 (json, but a bit more flexible around commas and includes comments)22:18
lkclit is the "visitor-walker" that i am advocating22:18
lkclprogrammerjake, no, please, no format-changing.22:18
lkclthat is completely off the table, as discussed several months ago22:18
programmerjakeyeah, i agree, was mentioning what i'd pick *if* we wanted to change22:19
ghostmansd“XML is a classic political compromise: it balances the needs of man and machine by being equally unreadable to both.” – Matthew Might22:19
lkclwhat is really badly needed - due to the amount of duplication that i can foresee and the complexity of using insndb - is visitor-walking22:19
* lkcl snorts22:19
lkclprogrammerjake, ah got it22:19
programmerjakeghostmansd: XD22:19
ghostmansdmore stuff here22:20
ghostmansdlike these pages22:20
lkcloh god i don't even want to go there, i will never come back out22:20
ghostmansdthat's just collection of quotes and notes on why XML is so fricking good :-)22:20
* lkcl goes to the site immediately22:21
ghostmansd“XML combines the efficiency of text files with the readability of binary files” – unknown22:21
ghostmansdyou know, perhaps the only reason XML got invented is for people to be jerks about it :-)22:22
lkclthe moment XSLT came out i knew it had gone too far22:23
lkcland that was... 24 years ago22:23
lkclSOAP: Shit lOAds of Poop22:24
ghostmansdthese guys come from plan922:26
lkclNode.js is one of the worst things to happen to the software industry in recent times,22:26
ghostmansdthey always troll about other techs22:26
ghostmansdthe only section filled is BUGS22:26
ghostmansdthe text is "Yes"22:26
lkclfrickin funny22:26
ghostmansdOS X is probably the worst *nix variant in use in the second decade of the 21sth century.22:27
ghostmansdOnly Apple could come up with something as fucked up as an Init system built on XML.22:27
ghostmansdtotally love'em22:27
ghostmansdabout _not_ format22:28
lkclOS/X is actually FreeBSD. they demo'd it at Imperial College back in 1990.22:28
ghostmansdthey sure diverged fricking a lot from FreeBSD22:28
lkclthey were so happy to have X11 "working", they hadn't had time to implement "window close" yet22:28
lkclokok one of the BSDs.22:28
ghostmansd4.4BSD I think22:29
lkclbut we are talking *really* at the start - 1988/198922:29
ghostmansdstill compared to BSDs this is a fricking nightmare22:29
ghostmansd(not that BSDs are pleasant per se)22:29
ghostmansdnothing is, though22:30
ghostmansdanyway, about this thing with visitors22:30
ghostmansdyou want to keep the format22:30
ghostmansdyou just want to replace bunch of methods related to iteration?22:30
lkclit's just... different, but for me i get frustrated using BSDs because i have memorised commands for linux22:30
ghostmansdso that each insn element is "walkable"?22:31
lkclabstract them to the "visitor" concept22:31
lkclit will evolve22:31
ghostmansd"and her walkman started to melt"22:31
lkclthe most obvious one will be "for insn in db: visitor->(insn)"22:31
ghostmansdthe visitor is fed by user, right?22:32
lkclbut any moment that the visitor function has an explicit for-loop "for something in insnrecord" that is a sign that the visitor should have a new function added to it22:32
ghostmansdI guess I begin to understand where you head22:32
lkclthe guiding principle of visitor-walkers is:22:33
ghostmansdyou want to feed different visitors depending on use case22:33
ghostmansde.g. some visitor for binutils22:33
ghostmansdsome for cavatools22:33
ghostmansdsome for other stuff22:33
lkcl*under no circumstances" should the visitor-function *itself* perform iteration on the database-object22:33
ghostmansdand different modules with their own visitors22:33
ghostmansdI rarely say it22:34
lkcl100% correct.22:34
ghostmansdbut I fucking love the idea22:34
ghostmansdactually I've been thinking about it for a while22:34
lkclit's one that keeps getting re-invented so is not a surprise22:34
ghostmansdbecause using insndb is way too complex as of now22:34
lkclit's a "kinda-obvious OO thing"22:34
lkcland all that "users" want to do is "just get on with it"22:35
ghostmansdkinda "gimme a big red button which makes stuff work"22:35
lkclbut for goodness sake do follow the pattern i suggest, which is to convert something that exists (like binutils-insndb)22:36
lkclone for-loop at a time22:36
ghostmansdI'd suggest "visit" method for db and "visit" method for record22:36
lkclthen those should be (following how it is done here:
lkclclass MyInsnDBParser:22:37
lkcl    def handle_db(self, ....):22:37
lkcl    def handle_record(self, .....)22:38
ghostmansdSo you think of checking whether there's a method to be called on visitor's instance22:38
ghostmansdnot an explicit "visit" but rather "feed me a visitor, I'll check which methods it has"22:39
lkclbut bear in mind: you *will* need "entry" and "exit" functions22:39
lkclyyeah there will be plenty of uses of "hasattr" here22:39
ghostmansdon entry and exit22:39
lkclif hasattr(visitor, "handle_db"): visitor->handle_db(db)22:39
programmerjakeyou should pass indexes into the visitor too, they're useful for e.g. figuring out which index to use for a generated c array22:39
ghostmansdwhat'd be those in insndb?22:40
lkclso it is more:22:40
lkclclass MyInsnDBParser:22:40
lkcl   def handle_db_start(self, ....)22:40
lkcl   def handle_db_end(self, ....)22:40
lkcl   def handle_record_start(self, ....)22:40
lkcl   def handle_record_end(self, ....)22:40
ghostmansdthese start and end, what do they map to?22:41
ghostmansdas for simple "handle_record", it's clear: on iteration22:41
ghostmansdah wait I see22:41
programmerjakeseems easier to just have a NoOpVisitor with all the methods, just derive from that and override what you need22:41
lkclwell for example handle_db_start would spew out "struct x {\n"22:42
ghostmansdyou want to handle iteration in insndb22:42
ghostmansdand call start on entry to iteration22:42
lkcland handle_db_end would spew out the corresponding "} // end struct x;\n"22:42
ghostmansdand call end after22:42
ghostmansdok, this totally makes sense22:42
lkclit's really detailed, but every "event" has to have a notification of some kind22:43
ghostmansdso folks just implement the methods they need22:43
ghostmansdOK, got it22:43
lkclbasically each and every for-loop has to have "start thing end"22:43
ghostmansdwill get to it once finally these damn OR_ZERO are done22:43
lkclso if you have nested for-loops that's six functions22:43
programmerjakerather than having to manually call a bunch of start/end pairs, it may be easier to use `with`22:44
lkclthat i suggest you output to a log file22:44
lkclprogrammerjake, i know it's late for ghostmansd now22:44
lkclso let's let him get some rest and continue tomorrow.22:45
programmerjakesounds good, ttyl. gn22:45
lkcli have a vague inkling of what "with" would look like with visitors22:45
lkcland also would like to go over it22:45
ghostmansdyeah 1 am :-)22:46
ghostmansdlet's continue this later22:46
programmerjakewith visitor.db(db):22:46
programmerjake    for insn in db:22:46
programmerjake        with visitor.insn(insn):22:46
programmerjake            for operand in insn:22:47
programmerjake                 ...22:47
lkcl22:46 here22:47
ghostmansdlkcl, could you, please, raise the task?22:47
ghostmansdor point me to one which already exists22:47
lkclghostmansd, willdo22:47
lkclit'll have to be cross-linked to a lot of other tasks22:47
ghostmansdI'm not sure about with thing22:48
ghostmansdI'd rather do visitor.visit(db)22:48
ghostmansdand that's it22:48
ghostmansdthen a bunch of hasattr(visitor, "whatever") calls22:48
ghostmansdinside insndb22:48
lkclprogrammerjake, ahh, the visitor has to then implement __entry__ and __exit__ on objects *in* the visitor22:48
programmerjake`with` basically auto-calls a start/end pair for you, makes it easy to not forget22:48
lkclprogrammerjake, but those start/end pairs *have* to be named "__entry__" and "__exit__".22:49
programmerjakejust use the whatever @contextmanager decorator, makes it really easy to implement22:49
ghostmansdbut we'll end up with users implementing separate objects for each substaff22:49
ghostmansdand with html-like parser they just need to implement methods in one class22:50
lkclyes. they'd need to create a visitor with an object visitor.db22:50
lkcland another object visitor.insn22:50
lkcleach with their own separate __entry__ and __exit___22:50
ghostmansdthis might become messy and too classy22:50
lkcli like it but it's not entirely intuitive22:50
ghostmansdbut I'll think about it too22:50
lkclif the database was flat it'd not be a problem at all22:50
ghostmansdthere are benefits here that it's, so to speak, modern and well-known22:51
ghostmansdbut perhaps way too classy22:51
programmerjakeignore that it internally uses __enter__/__exit___22:51
ghostmansdneeds to be thought22:51
ghostmansdno the naming is not an issue22:51
ghostmansdseparate classes are22:51
lkclyes it does.  ok i'll cross-ref it in the bugreport, let's pick it up another time22:51
ghostmansdbut perhaps not a critical one22:51
programmerjakebasically contextmanager puts the with body behind the yield in the method22:52
programmerjakeso you can easily do stuff before/after the with body22:52
ghostmansdah wait I see, it wraps __enter__/__exit__ for us22:52
ghostmansdthen it might be a good choice22:53
ghostmansdthe problem I worried about is that users will have to write these methods22:53
lkclthere's ways to make contextmanager a retro-fit22:53
programmerjakeimho writing the methods are easy with contextmanager22:54
lkclok leave it with me to write the bugreport folks22:54
programmerjakethx lkcl22:54
programmerjakei'll add a comment with contextmanager idea22:55
ghostmansdsee you later22:55
ghostmansdthanks for discussion22:56
*** ghostmansd <ghostmansd!> has quit IRC23:01

Generated by 2.17.1 by Marius Gedminas - find it at!