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

    witty-crayon-22786

    10/18/2016, 4:55 PM
    that's correct
  • w

    witty-crayon-22786

    10/18/2016, 4:55 PM
    looking
  • r

    rough-minister-58256

    10/18/2016, 4:56 PM
    yeah - like I said, would expect a 
    _specs_to_targets
    to be much faster in an already constructed build graph
  • r

    rough-minister-58256

    10/18/2016, 4:56 PM
    but it seems like we’re double instantiating things most likely
  • w

    witty-crayon-22786

    10/18/2016, 4:57 PM
    iirc, one of the recent changes was to not create the Target objects in the daemon
  • r

    rough-minister-58256

    10/18/2016, 4:57 PM
    yes
  • w

    witty-crayon-22786

    10/18/2016, 4:57 PM
    so i'm pretty sure that codepath isn't "cached"
  • r

    rough-minister-58256

    10/18/2016, 4:57 PM
    it doesn’t need to be - both happen in the same process context
  • w

    witty-crayon-22786

    10/18/2016, 4:57 PM
    ... if it's running twice in the same process, then yea... just unnecessary probably
  • r

    rough-minister-58256

    10/18/2016, 4:57 PM
    so _specs_to_targets should be able to reuse whatever happens in _init_build_graph
  • w

    witty-crayon-22786

    10/18/2016, 4:58 PM
    ah. yea, that's redundant then.
  • w

    witty-crayon-22786

    10/18/2016, 4:58 PM
    interesting that it's not cheaper though... it's supposed to short circuit if something exists
  • r

    rough-minister-58256

    10/18/2016, 4:59 PM
    thats what I thought as well
  • b

    billowy-beach-68498

    10/18/2016, 5:46 PM
    I think it’s because specs are not saved? like for inject_address_closure, we can easily check if an address is already in build graph and return immediately
  • b

    billowy-beach-68498

    10/18/2016, 5:47 PM
    but for spec, we have to go into PG for that every time
  • w

    witty-crayon-22786

    10/18/2016, 5:51 PM
    hm, yea.
  • w

    witty-crayon-22786

    10/18/2016, 8:19 PM
    @fancy-queen-20734 : so, is there any position in a Selector where a type constraint can't be used? or is it constraints all the way down
  • w

    witty-crayon-22786

    10/18/2016, 8:22 PM
    introducing type checks when going from python to rust is... fun, heh.
  • f

    fancy-queen-20734

    10/18/2016, 10:54 PM
    I think it ought to be type constraints all the way down
  • w

    witty-crayon-22786

    10/18/2016, 10:55 PM
    k. i think i see one case where it isn't: SelectProjection needs a concrete type, because if the value isn't already the right type, we construct one
  • f

    fancy-queen-20734

    10/18/2016, 10:55 PM
    oh, right
  • f

    fancy-queen-20734

    10/18/2016, 10:56 PM
    There’s also field types, though that could probably be a constraint
  • w

    witty-crayon-22786

    10/18/2016, 10:56 PM
    yea
  • w

    witty-crayon-22786

    10/18/2016, 10:56 PM
    should be, probably.
  • w

    witty-crayon-22786

    10/18/2016, 10:57 PM
    but this merge is interesting enough already.
  • w

    witty-crayon-22786

    10/18/2016, 11:47 PM
    @fancy-queen-20734 : also, tasks vs intrinsics in NodeBuilder... both are hash lookups, but in some cases the product is a type constraint, and in other cases its a type
  • w

    witty-crayon-22786

    10/18/2016, 11:47 PM
    right?
  • f

    fancy-queen-20734

    10/18/2016, 11:48 PM
    yeah. The index has both the product and constraint registered, but its a little messy
  • w

    witty-crayon-22786

    10/18/2016, 11:48 PM
    gotcha. so heterogenous types in there.
  • w

    witty-crayon-22786

    10/18/2016, 11:50 PM
    ...blargh. would love to nuke constraint and just have unions everywhere.
1...184185186...906Latest