4900+ entries in 0.008s
mod6: Ah, ok. Thanks for the info asciilifeform.
mod6: Ooh, I see some are double stacked.
mod6 goes to find the picture
mod6: I suppose that one could be connected directly to the board, right asciilifeform? But would it physically have to be placed, i.e. underneath, the riser bolts/pegs?
mod6: This is an interesting question.
mod6: <+mircea_popescu> mod6, that's actually... exactly the opposite of what i said! << I've got ya. I'm just gonna stay on this rawtx stuffs, I'm making ok progress atm.
mod6: Anyway, food for thought.
mod6: Or work up to that point, anyway.
mod6: One other thing about ada-vtron, at the time, I was using system commands to execute `gnupg'. Where as now, perhaps we can use ffa/peh.
mod6: mircea_popescu: thanks too for prodding me about Ada-vtron. I'll poke at it as I can, for sure.
mod6: Thanks asciilifeform
mod6: sign and send are gonna be a tough ones, so we'll see how it goes. I've got a new test machine on the way, so I gotta stand that up, etc for all of this too.
mod6: which, requires a lot more changes, so we'll see.
mod6: But listunspent I already had working long ago, but not with the way you wanted it.
mod6: Yeah, I've got 'getrawtransaction', 'decoderawtransaction' working and minimally tested. createrawtransaction is built and untestd entirely (was working on recent bug report instead). that leaves signrawtransaction, and sendrawtransaction... and maybe listunspent too.
mod6: oh, hmm. I'll have to remind myself.
mod6: I need to go and look at that, I might be able to use that outright, or borrow from it.
mod6: see, I did think that alf had produced something of this kind that was connected to ffa.
mod6: Exactly, 0, 1, inf. I was worried about this. MOre pairs of eyes are good here.
mod6: fwiw, I did look for other appearences of the same bug in all of the trb source files, however, I didn't see one. Doesn't mean that they don't exist. I invite all to examine the source.
mod6: mircea_popescu: oh, betting against us or prb?
mod6: Where I did get to last year, had some of this working, not all, but some; and it was SLOOOOW. Too much string processing.
mod6: And I'll certainly need to write something (or work with someone) to produce a ~fast~ parser. It's a giant ass-pain with the fixed-length strings.
mod6: The problem with the Ada version is the string parsing.
mod6: <+mircea_popescu> hey mod6 how's your ada v coming along ? << Still stuck in the drawer. I haevn't even touched it since Q3 of 17. I'm distinctly intersted in rawtx tools getting into trb, currently.
mod6: well, sure not "urgent", but I shouldn't say "didn't work" either.
mod6: I'll maybe start fresh on it and see how it goes.
mod6: Which is why I don't think I ever posted about it. My attention probably turned to other things, and I haven't circled back yet.
mod6: (re: crystals) re-reading the email, it is jogging my memory that I didn't use the included trb files specifically. I recall screwing around and wiring in my vtron, as opposed to your vtron, then who knows. I probably did something dumb.
mod6: You may just have to disrgard what I was saying above, asciilifeform.
mod6: Otherwise we have a lot of extra complexity and mental gymnatics.
mod6: If there are 3 leaves, A, B, and C. And for some reason, I shouldn't have B and C, then I should just be a man, and remove them from my 'patches' dir.
mod6: I personally find this obnoxious.
mod6: And yea, V 99993K removed that, and now can only press to one leaf.
mod6: I'll have to get you the info. Probably later today.
mod6: asciilifeform: yeah, crystals is neato. Just tried to press (iirc) out the big thing and hit some sort of issues.
mod6: well, fwiw, i'm trying to not get sucked back into all of this. as far as I'm concerned V works.
mod6: It's very possible i just misused this tool.
mod6: I'll pull out my notes later today if you actuall want.
mod6: I'd have to go back an look, but I seem to recall trying to use it to create the trb patches, then inflate from those. and when I did, lotsa hunks/fuzz etc.
mod6: Did nasty things when I tried this with TRB.
☟︎☟︎ mod6: this just made it "tidy".
mod6: not at that time. at that time, we just pressed all leaves anyway.
mod6: I dunno, nevermind. Maybe will just have to leave this complicated work up to those whom understand it better.
mod6: This is something where you have two totally different trees, merged into one.
mod6: I feel like that is two different cases maybe. That was the case of tying up the leaves.
mod6: and just because it has been stated several times in the logs, does't mean it makes sense to me.
mod6: why are they unrelated ? are they not a part of the same project?
mod6: If there were vpatches in your flow that went down two different paths, you simply removed those vpatches from your 'patches' directory. Press path A. You want bath B? Then you just add in what ever path B consists.
mod6: Back in the old days, there was one tree. I'm still not sure what problem we are trying to solve with all of this.
mod6: Strictly speaking, that's a very nice rack of tits, but the clothes-pins add some nice aesthetic.
mod6: I kinda dig the clothes-pins.
mod6: BingoBoingo: Cheers!
mod6: Of course! Happy to do it. :]
mod6: Once I fed it this string "ab6o78", that sprung the trap (see the GDB debugging portion near the bottom).
mod6: And now it makes sense because the initial test case I was using was all values in the normal hexadecimal range.
mod6: The thing that really threw me off during the analysis is that before and after test drivers were both yielding the same, correct, result. So I had to dig way in and debug to see exactly where to spring the trap.
mod6: And it turns out, perhaps by luck alone, that they missed a comma on one value that is outside the normal character values for hexadecimal. If they had missed a comma somewhere in there, whoa. Could mean all kinds of bad things - OR perhaps they would have just caught it earlier as nothing would have worked right lol.
mod6: The reason that I did the analysis so in depth, I wanted to absolutely get to the bottom of how bad this could be.
mod6: So it's really a two headed ugly bug.
mod6: You would hit index 111 if one passed an 'o' to ParseHex, triggering the landmine. What is supposed to happen, is; the loop is supposed to break if it ever hits -1 (0xff). However, if we hit [111] (0xfe) -2, we continue on.
mod6: In the array, there is a missing ',', which causes gcc/g++ not to puke, and simply ADDS(!) the two values together... in this case we had ,-1 -1, giving us -2. This does 2 things, shortens the filled depth of the array by 1, and changing the value from -1 (at index 111) to -2 (0xfe).
mod6: So this one is rather ugly; however, after analysis it appears that to step on the landmine one would have to pass a lower case 'o' to the ParseHex function. Which is outside the Hexadecimal range 0-9A-F. Not that someone couldn't do it, just that my guess is that the probability of hitting it is lower.
mod6: jurov: Ah, alright, thanks for checking. It's weird because I did check the clearsigned file before sending, verified fine. Mail Client / ML must have magled it.
mod6: !~later tell jurov Please check the ML pipes, I think I got one stuck.
mod6: The foundation's is nearly caught up as well, adding another to the list.
mod6: Cool, trinque: thank's for the notice.
mod6: Ugh! Hopefully you can get some extra rest this weekend then.
mod6: Right on, I'm just reading your post here. :]
mod6: wow, this is quite the accounting of these beasts