--- In [email protected], "Sheri" <sheri...@...> wrote: > > Works! But I don't think local one can work as I wanted, as it doesn't work > as a user arg for the cbx(...). Static or global version should be ok, since > the callback routine itself can access it.
Yeah, sorry, I lied. locals no good, gotta be static or global. > We still have an issue of reinitializing regex_mark. Possibly just not > picking up on when "mark" option is set and the extra block has NULL in it > after an exec. Because regex_mark is retaining the mark set for a previous > pattern/execution even when a new pattern/execution has the "mark" plugin > option set. Okay, probably eay fix. > > callout: seems to work now. It was indeed calling convention (ta, Bruce: > > every function but this one is WINAPI, this one seems to be STDCALL). > > > > Accepts cbx(@entry). > > Bravo. AFAICT the original tests in the plugin test script work again. Good. Never would have believed different calling conventions for entry points in same dll, but so it goes. > > Looks from code as anything in form !xxxx is interpreted as a something > > that can be executed with run.xxxx. > > Do not understand. I vaguely remember some discussion about being able to invoke a script embedded in a pcf command list. call(..) won;t work for that, I believe run.command_list will? ...can;t find anything in help on that. Help....oh there it is, under "expressions"...run.cmdlist(args) "!" I guess was meant to go in front of a command list name. Ring a bell (I'm sure it was your fault...) > > Appends address of pcre_callout_block as argument, need dll plugin to > > decode (looks like you already got scripts in place in > > regexPluginTest.powerpro to do that, haven't tested, may have a go later, > > see if appears to be working. See regexCallout.powerpro > > I don't remember much about it and those tests don't look particularly > meaningful. So whatever other demo you can come up with would be helpful. The other thing I could do is strip out the struct fields and send them into script as arguments. OTOH if callouts hardly ever gonna be used, can just provide the dll plugin recipe to use the incoming struct. > > Not yet done those tests for options valid only using, or only using dfa > > > > What of the other optimization something you said previously, i.e., to > eliminate sending a PCRE extra block except when called for? I think I did that. Nuit that was day before yesterday, so I forget. Will look. resultPostNoMatchAnchored: dealing with this situation (quote from you, made it into comment in my code cause so outlandishly convoluted)... /If the previous match WAS for an empty string, we can't do that, as it would lead to an //infinite loop. Instead, a special call of pcre_exec() is made with // the PCRE_NOTEMPTY and PCRE_ANCHORED flags set. The first of these tells PCRE that an empty string is not a valid match; //other possibilities must be tried. The second flag restricts PCRE to one match attempt at the //initial string position. If this match succeeds, an alternative to the empty string match has been //found, and we can proceed round the loop; So resultPostNoMatchAnchored is what I send back from here to there when (match with PCRE_NOTEMPTY and PCRE_ANCHORED set) fails. Return mark name result or not in that situation?
