[Lldb-commits] [PATCH] D20193: test infra: catch bad decorators and import-time errors

[Zachary Turner via lldb-commits]

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.fiala at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160512/cb2098cc/attachment.html>