Hello Enrico, The new test has been failing on Ubuntu buildbot. But it's passing on some offline Ubuntu machines, I don't understand what caused the difference. Could you please help to take a look?
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10299 Thanks, Ying On Wed, Jan 13, 2016 at 11:32 AM, Enrico Granata via lldb-commits < lldb-commits@lists.llvm.org> wrote: > > On Jan 13, 2016, at 11:26 AM, Zachary Turner <ztur...@google.com> wrote: > > Thanks! btw would having the command write its output to a file instead > of stdout solve the pexpect problme as well? > > > That’s possible - but I would need to play with it a little bit to > convince myself that it really is a faithful reproduction of my original > issue > It’ll take me a little while to get to it - stay tuned. > > On Wed, Jan 13, 2016 at 11:22 AM Enrico Granata <egran...@apple.com> > wrote: > >> >> On Jan 13, 2016, at 10:34 AM, Zachary Turner <ztur...@google.com> wrote: >> >> >> >> On Wed, Jan 13, 2016 at 10:25 AM Enrico Granata <egran...@apple.com> >> wrote: >> >>> On Jan 13, 2016, at 10:21 AM, Zachary Turner <ztur...@google.com> wrote: >>> >>> >>> On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits < >>> lldb-commits@lists.llvm.org> wrote: >>> >>>> + >>>> +class CommandScriptImmediateOutputTestCase (PExpectTest): >>>> >>> Does the bug that you were trying to fix occur only when using the >>> command_script.py file from the lldb command line? If you load it from >>> within lldb via an LLDB command, does the problem still occur? If the >>> problem you are fixing is not specific to the LLDB command line, I would >>> prefer if you write this not as a pexpect test. >>> >>> >>> I would love to not touch pexpect :-) But in this case, I can’t see a >>> way around it. I am trying to detect whether some text is “physically” >>> printed to stdout. And pexpect seems the most obvious straightforward way >>> to get that to happen. Note that, in this bug, the result object is filled >>> in correctly even if nothing gets printed, so looking at the result won’t >>> quite cut it - it really needs to detect output to stdout. >>> >> You're calling result.SetImmediateOutputFile(sys.__stdout__). Wouldn't >> it work to use a file on the file system here, and then you open that file >> and look at it after running the commands? It wouldn't work in remote >> cases, but it already doesn't work on remote cases anyway (as you point out >> below) >> >> >>> >>> >>> >>>> + >>>> + mydir = TestBase.compute_mydir(__file__) >>>> + >>>> + def setUp(self): >>>> + # Call super's setUp(). >>>> + PExpectTest.setUp(self) >>>> + >>>> + @skipIfRemote # test not remote-ready llvm.org/pr24813 >>>> + @expectedFlakeyFreeBSD("llvm.org/pr25172 fails rarely on the >>>> buildbot") >>>> + @expectedFlakeyLinux("llvm.org/pr25172") >>>> >>> Are these necessary? The windows one is necessary (but not if you >>> change this to not being a pexpect test as I've requested above), but why >>> are the other ones necessary? >>> >>> >>> Do we support remote pexpect? As for FreeBSD and Linux, they might not >>> be necessary, but I’d rather much remove them (or let the relevant platform >>> owners) remove them in a separate commit >>> >>> No remote pexpect, so the @skipIfRemote probably needs to be there. But >> I think everyone should be checking in tests enabled by default in the >> widest set of environments possible that you aren't completely sure are >> broken. It should be up to the platform holders to disable broken tests, >> not to enable working tests. Because it's much easier to notice a broken >> test going in than it is to notice a working test went in disabled (because >> who's going to think to test it out?). >> >> >> This is a fair point. I’ll enable those platforms in a subsequent commit >> ASAP >> >> >> Thanks, >> *- Enrico* >> 📩 egranata@.com ☎️ 27683 >> >> > > Thanks, > *- Enrico* > 📩 egranata@.com ☎️ 27683 > > > _______________________________________________ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
