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

    witty-crayon-22786

    10/07/2015, 10:19 PM
    ...was what made me think of it.
  • w

    witty-crayon-22786

    10/07/2015, 10:19 PM
    anywho
  • w

    witty-crayon-22786

    10/07/2015, 10:21 PM
    another way to think about it might be an immutable, copy-on-write ancestry
  • m

    most-cricket-96651

    10/07/2015, 10:46 PM
    Ah. Great.
  • m

    most-cricket-96651

    10/07/2015, 10:46 PM
    Reasoning about mutation is difficult. It's hard in git, it's hard in pants, it's hard for Shredder.
  • w

    witty-crayon-22786

    10/07/2015, 10:49 PM
    hahaha
  • w

    witty-crayon-22786

    10/07/2015, 10:57 PM
    @enough-analyst-54434: having 
    custom_types
    depend on Address would be a new dep from 
    option
    to 
    base:address
    ... it already depends on 
    base:build_environment
    , so maybe that's fine?
  • e

    enough-analyst-54434

    10/07/2015, 10:59 PM
    Is there any need to stuff this in custom_types?
  • e

    enough-analyst-54434

    10/07/2015, 10:59 PM
    Its custom custom
  • e

    enough-analyst-54434

    10/07/2015, 10:59 PM
    put it where its used?
  • w

    witty-crayon-22786

    10/07/2015, 10:59 PM
    the options_fingerprinter is aware of it currently
  • w

    witty-crayon-22786

    10/07/2015, 11:00 PM
    since the types are not themselves proper types
  • e

    enough-analyst-54434

    10/07/2015, 11:00 PM
    But that it sucstom
  • e

    enough-analyst-54434

    10/07/2015, 11:00 PM
    IE: lots of stuff in the wrong place
  • w

    witty-crayon-22786

    10/07/2015, 11:01 PM
    agreed. but i'd prefer not to tackle adding a first class 
    OptionType
    interface here.
  • e

    enough-analyst-54434

    10/07/2015, 11:01 PM
    But - yes, base and util is a fine dep for ~anything
  • w

    witty-crayon-22786

    10/07/2015, 11:01 PM
    ok
  • w

    witty-crayon-22786

    10/07/2015, 11:02 PM
    for one thing, i think this should all be unified with payloads =(
  • w

    witty-crayon-22786

    10/07/2015, 11:02 PM
    bummed out that i missed when that was refactored away
  • e

    enough-analyst-54434

    10/07/2015, 11:04 PM
    not following
  • e

    enough-analyst-54434

    10/07/2015, 11:04 PM
    I refactored that way?
  • w

    witty-crayon-22786

    10/07/2015, 11:05 PM
    oh, no... the options fingerprinting was initially implemented in terms of payloads, but benjy and patrick had cody separate it out
  • e

    enough-analyst-54434

    10/07/2015, 11:05 PM
    the fact that payload is built into target is probelmatic
  • w

    witty-crayon-22786

    10/07/2015, 11:06 PM
    yea... but in terms of it being the input to the cache key for a target, it was kind of perfect for this usecase
  • e

    enough-analyst-54434

    10/07/2015, 11:06 PM
    since fingerprints are task specific
  • e

    enough-analyst-54434

    10/07/2015, 11:06 PM
    and option fingerprints moreso
  • w

    witty-crayon-22786

    10/07/2015, 11:06 PM
    well, task+target == action graph, right?
  • w

    witty-crayon-22786

    10/07/2015, 11:06 PM
    so each node has a payload
  • e

    enough-analyst-54434

    10/07/2015, 11:06 PM
    each node is a tuple that hashes as itself
  • w

    witty-crayon-22786

    10/07/2015, 11:07 PM
    er, has a fingerprint computed by hashing portions of the payload i guess.
1...514515516...2420Latest