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

    fancy-queen-20734

    09/12/2016, 10:15 PM
    well, sort of. Select(Collection.of(blah)) goes from O(1) to O(n) perhaps
  • w

    witty-crayon-22786

    09/12/2016, 10:15 PM
    i don't see why anything about 
    Select(Collection.of(blah))
    needs to change
  • w

    witty-crayon-22786

    09/12/2016, 10:16 PM
    ...oh
  • w

    witty-crayon-22786

    09/12/2016, 10:16 PM
    i think checking of members would be a creation-time thing
  • f

    fancy-queen-20734

    09/12/2016, 10:16 PM
    if Collection.of(Blah) goes from being a concrete product type, then some dict lookup things in the product graph would be trickier
  • f

    fancy-queen-20734

    09/12/2016, 10:16 PM
    The product graph could retain the type info on the entries though… I think that could work
  • w

    witty-crayon-22786

    09/12/2016, 10:17 PM
    no: because datatype just delegates equality/hashing to members
  • w

    witty-crayon-22786

    09/12/2016, 10:17 PM
    ...oh. i see.
  • w

    witty-crayon-22786

    09/12/2016, 10:17 PM
    after the type check.
  • w

    witty-crayon-22786

    09/12/2016, 10:18 PM
    mm. blargh.
  • f

    fancy-queen-20734

    09/12/2016, 10:19 PM
    we could make Collection not visible to tasks though and instead pass the unwrapped list/tuple. At that point whether it really exists or not is an implementation detail
  • w

    witty-crayon-22786

    09/12/2016, 10:19 PM
    yea, that seems like a good middle ground. and the constructor could validate the member types.
  • f

    fancy-queen-20734

    09/12/2016, 10:21 PM
    I think that’s a good idea
  • w

    witty-crayon-22786

    09/12/2016, 10:22 PM
    @fancy-queen-20734 : ok, so the 'Collection as "hidden" type' thing seems settled.
  • w

    witty-crayon-22786

    09/12/2016, 10:23 PM
    @fancy-queen-20734 : part of the reason i want to do it is to support native concat/flatten though. any other thoughts there?
  • f

    fancy-queen-20734

    09/12/2016, 10:26 PM
    I feel like this is a place where we could introduce a new type of declaration, either on the collection type, or as a rule that statically defines the ways a product can be merged
  • f

    fancy-queen-20734

    09/12/2016, 10:27 PM
    I think there’s 3 basic cases 1. products of different subjects of the same rule 2. products of different subjects of the different rules 3. products of the same subject of different rules 1 and 2 are possible results of SelectDependencies, and 3 is currently the ConflictingProducers case for Select
  • f

    fancy-queen-20734

    09/12/2016, 10:28 PM
    an example for 3 would be something like a classpath entries that come from different task sets.
  • w

    witty-crayon-22786

    09/12/2016, 10:28 PM
    hm... not sure i understand the relevance of those cases though. why does it matter which rules produced the value for 1/2
  • w

    witty-crayon-22786

    09/12/2016, 10:29 PM
    i explained 
    SelectDependencies
    to dan as 
    [Select(product) for subject in dep_product.dependencies]
    ... or perhaps 
    [SelectNode(subject, product) for subject in dep_product.dependencies]
  • f

    fancy-queen-20734

    09/12/2016, 10:30 PM
    well products are keyed by 
    (subject, variants, rule)
    where rule is the task and contains the product type.
  • w

    witty-crayon-22786

    09/12/2016, 10:31 PM
    ...currently they are not. currently they're keyed by Node
  • f

    fancy-queen-20734

    09/12/2016, 10:31 PM
    yeah, but nodes are 
    (subject, variants, rule info)
  • w

    witty-crayon-22786

    09/12/2016, 10:31 PM
    and a Node type
  • f

    fancy-queen-20734

    09/12/2016, 10:32 PM
    ah, I’m mostly thinking of comparing TaskNodes
  • f

    fancy-queen-20734

    09/12/2016, 10:32 PM
    I see
  • w

    witty-crayon-22786

    09/12/2016, 10:32 PM
    i mean, i'd absolutely like to be able to reduce this.
  • w

    witty-crayon-22786

    09/12/2016, 10:33 PM
    in particular, i think it will make staging multiple tasks to run independently massively simpler.
  • w

    witty-crayon-22786

    09/12/2016, 10:33 PM
    but i think whether 
    SelectDependencies
    supports concatenation is potentially orthogonal
  • w

    witty-crayon-22786

    09/12/2016, 10:34 PM
    i think that you are right that the graph should be TaskNode centric
1...167168169...906Latest