I will look at this in more detail later, but hold off on committing until
i have a chance to run it on Windows
On Thu, May 12, 2016 at 8:05 AM Todd Fiala <todd.fi...@gmail.com> wrote:
> tfiala added inline comments.
>
> ================
> Comment at: packages/Python/lldbsuite/test_event/formatter/pickled.py:57
> @@ +56,3 @@
> + # end.
> + if self.use_send:
> + # Send it as
> {serialized_length_of_serialized_bytes}{serialized_bytes}
> ----------------
> tfiala wrote:
> > labath wrote:
> > > Why do we need the format to be different based on the kind of object
> we are writing to? The added magic (introspection) seems like a bad
> tradeoff, if all it does is avoid a couple of lines in `event_collector.py`
> > When we're using sockets, we have to be able to know the size of the
> full info when reconstructing on the receiving side. This is the normal
> mode in which this is used. However, that also complicates the parsing of
> the data for the simple test driver.
> >
> > The code later on in the test_event unit tests:
> >
> > ```
> > if os.path.exists(pickled_events_filename()):
> > with open(pickled_events_filename(), "rb") as events_file:
> > while True:
> > try:
> > # print("reading event")
> > event = cPickle.load(events_file)
> > # print("read event: {}".format(event))
> > if event:
> > events.append(event)
> > except EOFError:
> > # This is okay.
> > Break
> > ```
> >
> > Would get considerably more complicated to deal with the same format
> that is only required for going over a network-style protocol. I prefer
> this tradeoff. In the unit tests, I just send the event output to a file,
> and then read it with the simple loop I included above.
> >
> > However, to verify that I really prefer it, I will try writing it the
> other way.
> > However, to verify that I really prefer it, I will try writing it the
> other way.
>
> The flip side is I can try to factor out the listener side logic that
> reconstructs these. However, that is currently rather tightly coupled to
> the network listening transport. And most of the work it does has purely
> to do with needing to receive the whole message before it can try to
> un-pickle it. So I'm not really seeing that as a big win. (Except for
> testability. So maybe it's okay to break that out.) I'll see what that
> looks like since that is probably the better high-level way to handle this
> if we didn't want the change I made to the sender side.
>
>
> http://reviews.llvm.org/D20193
>
>
>
>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
