Same old 0x63

[lootch]

Is there any way one can skip GLOBAL tags on unpickling? Crashing whenever these are encountered is not much of an option.

Alternatively, can one instead tag a field as "GLOBAL" and let the unpickle process try to match GLOBAL entries to it, returning success or failure (and the ability to ignore failure) back to the invoker?

Happy to help code the process, whichever way, but I'll need some guidance.

Lucio.

[hydrogen18]

My original thoughts on this was to try and define an interface like GlobalHandler that the library would call (if provided) to allow it to handle the GLOBAL opcode. It might work for what you are suggesting.

Can you provide me with some examples of pickled data that containts GLOBAL that you think the library can usefully handle?

[lootch]

I've attached a smallish "mailman" configuration that contains at least one 0x63 object. The contents could be sensitive, please do not publish it or release it where it could cause harm (including letting on that I released sensitive information :-)).

I investigated github.com/kisielk/og-rek as an alternative. It is fiendishly clever, but has its own shortcomings. Use of "reflect" is a bit alien to me, even after reading Rob Pike's paper, so I won't make any pronouncements, but I believe that your package could incorporate some of kisielk's tricks.

I don't think I will ever have the savvy to merge enough of the two approaches to satisfy the requirements that are facing me. But I will help as far as possible.

Lucio.

PS: I found that "Password" as a field name overrules the tag in the same field (wrong precedence), even when another field has "password" as its own tag. There was also a more peculiar error report involving a map[interface{}]interface{} type, I think some parsing failed. This is harder to explain, but I'll send you an example if you need one.

In all respects, I like both packages, but your competitor has a bit of an edge in simplicity, which then falls short when one wants a less blunt tool. I do thank you for your help.

On 4/9/16, Eric Urban [email protected] wrote:

My original thoughts on this was to try and define an interface like GlobalHandler that the library would call (if provided) to allow it to handle the GLOBAL opcode. It might work for what you are suggesting.

Can you provide me with some examples of pickled data that containts GLOBAL that you think the library can usefully handle?

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/hydrogen18/stalecucumber/issues/6#issuecomment-207651948

[hydrogen18]

I believe you replied to me via GitHub, which I think scrubbed your attachments. You can email me directly [email protected]

[hydrogen18]

I received your file directly via email, although I probably won't have time to investigate it until this weekend. Can you open a separate issue about the field name over writing? It sounds like it is probably a valid complaint, but a separate bug entirely.

[hydrogen18]

So the pickle you sent me will basically create a Mailman.Bouncer _BounceInfo object and set it up using __setstate__ on the object. I am thinking that maybe a specific type declared in my package that is really just a map[string]interface{} can emulate this adequately.

[lootch]

Hi, Eric. I'm sorry I did not get back to you before the weekend, I thought I would, then found myself swamped. I'll see what I can manage today. Thank you for continuing to look into this.

Lucio.

On 4/17/16, Eric Urban [email protected] wrote:

So the pickle you sent me will basically create a Mailman.Bouncer _BounceInfo object and set it up using __setstate__ on the object. I am thinking that maybe a specific type declared in my package that is really just a map[string]interface{} can emulate this adequately.

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/hydrogen18/stalecucumber/issues/6#issuecomment-210934457

[hydrogen18]

Support for this has been added. Please review the documentation and reopen if you can't get it to work

[lootch]

On 2/26/18, Eric Urban [email protected] wrote:

Closed #6.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/hydrogen18/stalecucumber/issues/6#event-1491067406

Hello, Eric. I seem to have neglected to respond to this, I confess to having been too scattered to have paid it any attention until today. Please accept my apologies.

Having now stumbled (I never liked Mailman, really!) against object code 0x6F, I was wondering whether it is at all possible for the parser you implemented could be persuaded to skip past any items in that long list you provide in the documentation as not implemented.

I have no idea what the internal representation of pickle elements looks like, I am hoping that when one encounters an unimplemented code, one is also supplied the distance in the stream to the next code. In a sense that is of course always the case, but is it simple enough to embed in your code, perhaps as a global flag?

I appreciate that this is a hack, but once the option is present in the code, one will hopefully discover a few sensible possibilities regarding the appropriate recovery operation.

I'll take a peek at your code, see if I can figure something out, but I'd far rather follow your advice regarding any actual recovery procedure.

Thank you once again for the useful facilities.

-- Lucio De Re 2 Piet Retief St Kestell (Eastern Free State) 9860 South Africa

Ph.: +27 58 653 1433 Cell: +27 83 251 5824 FAX: +27 58 653 1435

[hydrogen18]

I looked at this an 0x6F is some op-code I missed in implementation & testing. It's added as part of protocol 1. It's some shorthand for 0x63 so it should be easy to implement once I find time.

[lootch]

Your help is deeply appreciated, Eric.

I have a little running battle trying to establish Go as a viable alternative in a conservative context and every small victory (in this case accessing the Mailman membership list directly instead of through the Mailman toolset) helps in this direction.

I do wish I could contribute more to your efforts, I am very grateful that you find the time to deal with issues as they arise. Sadly, my desire to grasp pythonesque intricacies does not match my gratitude, so I guess we'll soldier on, one small victory at the time :-).

Thanks once more.

Lucio.

On 5/3/18, Eric Urban [email protected] wrote:

I looked at this an 0x6F is some op-code I missed in implementation & testing. It's added as part of protocol 1. It's some shorthand for 0x63 so it should be easy to implement once I find time.