https://pantsbuild.org/ logo
Powered by
#general
  • w

    witty-crayon-22786

    09/28/2015, 11:45 PM
    or how long it is safe to allocate to each portion of the run
  • w

    witty-crayon-22786

    09/28/2015, 11:45 PM
    if we dial down overall timeouts, do we risk affecting compiles rather than tests?
  • w

    witty-crayon-22786

    09/28/2015, 11:45 PM
    etc
  • w

    witty-crayon-22786

    09/28/2015, 11:59 PM
    @bored-art-40741: since your release, have you guys tried out https://rbcommons.com/s/twitter/r/2851/ ?
  • w

    witty-crayon-22786

    09/29/2015, 12:01 AM
    running it on a few of our medium sized targets spotlighted some fun dumb stuff happening
  • s

    stocky-salesmen-83101

    09/29/2015, 12:12 AM
    @witty-crayon-22786: i would also be happy to know what timed out - build (hopefully never) or an actual test run.
  • b

    bored-art-40741

    09/29/2015, 12:15 AM
    Haven't had a chance to yet @witty-crayon-22786
  • b

    bored-art-40741

    09/29/2015, 12:15 AM
    Maybe later this week or next
  • b

    bright-dinner-81701

    09/29/2015, 12:18 AM
    @enough-analyst-54434: why are we bothering to resolve the npm_remote_modules individually right now if we still ultimately install them under each npm_module from the remote source anyway?
  • b

    bright-dinner-81701

    09/29/2015, 12:31 AM
    seems like:
    Copy code
    def _resolve(self, target, node_path, node_paths):
    if self.is_node_remote_module(target):
      self._resolve_remote_module(node_path, target)
    else:
      self._resolve_local_module(node_path, node_paths, target)
    could just be 
    self._resolve_local_module(node_path, node_paths, target)
    for speed purposes as long as we arent using those individual resolved node_remote_modules
  • b

    bright-dinner-81701

    09/29/2015, 12:31 AM
    nothing would work differently
  • h

    happy-kitchen-89482

    09/29/2015, 12:37 AM
    qq re DeprecationWarning. According to the python docs it's suppressed by default. So how are we showing deprecation warnings on the console?
  • r

    rough-minister-58256

    09/29/2015, 12:39 AM
  • r

    rough-minister-58256

    09/29/2015, 12:45 AM
    "The warnings that are ignored by default may be enabled by passing -Wd to the interpreter. This enables default handling for all warnings, including those that are normally ignored by default. This is particular useful for enabling ImportWarning when debugging problems importing a developed package.” -> that line is equivalent to passing 
    -Wd
  • b

    bright-dinner-81701

    09/29/2015, 1:48 AM
    @witty-crayon-22786: @enough-analyst-54434 added a README.md for Node contrib to https://rbcommons.com/s/twitter/r/2900/ and corresponding PR
  • b

    bright-dinner-81701

    09/29/2015, 1:48 AM
    will look at addressing the rest of stu’s comment tomorrow
  • w

    witty-crayon-22786

    09/29/2015, 1:49 AM
    thanks chris
  • l

    limited-country-20626

    09/29/2015, 2:27 PM
    @fancy-queen-20734: I have a patch that solves the problem. I am going to look into how hard it will be to add a test and then I will send a RB for you to take a look at.
  • l

    limited-country-20626

    09/29/2015, 2:39 PM
    FWIW, I still suspect a larger issue, perhaps elsewhere in the execution_graph queueing. There is a test in the test_execution_graph that is supposedly guarding against cycles and pants itself should detect them. My patch just guards against the pathological behavior of unboundedly filling the data structure.
  • l

    limited-terabyte-34878

    09/29/2015, 3:42 PM
    @happy-kitchen-89482: per stu, creating a generic test task superclass makes sense independent of timeouts. the primary point would be to allow us to implement test-specific functionality without having to implement it multiple times, once for every language.
  • l

    limited-terabyte-34878

    09/29/2015, 3:42 PM
    timeouts is just one of those, and specifically on timeouts, the functionality that we don’t get from putting the timeout in the test itself is the ability to enforce a default timeout if one is not already set.
  • h

    happy-kitchen-89482

    09/29/2015, 3:48 PM
    @rough-minister-58256: thanks!
  • h

    happy-kitchen-89482

    09/29/2015, 3:49 PM
    @limited-terabyte-34878 @witty-crayon-22786 I'm definitely in favor of a generic test superclass, with as much shared functionality as possible. If implementing timeouts turns out to be straightforward in that world, I'm not opposed.
  • b

    bored-art-40741

    09/29/2015, 3:50 PM
    Is a superclass required for that? As opposed to just a decorator?
  • f

    freezing-motorcycle-14222

    09/29/2015, 3:52 PM
    One thing I noticed in the course of adding benchmarking for my Haskell plugin is that some JVM tasks (like 
    Benchmark
    ) assume that the 
    ./pants bench
    goal is only for JVM targets
  • f

    freezing-motorcycle-14222

    09/29/2015, 3:53 PM
    There are two immediate issues I know of:
  • f

    freezing-motorcycle-14222

    09/29/2015, 3:53 PM
    The 
    Benchmark
    task expects certain JVM-specific flags to be set (like 
    --target
    ) even if you are running 
    ./pants bench
    on a non-JVM target
  • f

    freezing-motorcycle-14222

    09/29/2015, 3:54 PM
    The 
    Benchmark
    goal also fails if there are any non-JVM targets in the target graph when runnin 
    ./pants bench
    , which means that you can't add 
    bench
    support for other language targets
  • f

    freezing-motorcycle-14222

    09/29/2015, 3:55 PM
    The latter one is not due to a programming bug: there's an explicit added assertion to this effect
  • f

    freezing-motorcycle-14222

    09/29/2015, 3:55 PM
    So I was thinking of guarding behavior like that behind 
    isinstance
    check like in other tasks to make sure that we can add 
    bench
    support to other languages
1...476477478...2420Latest