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

    hundreds-breakfast-49010

    03/13/2020, 7:11 PM
    or just no one's done it yet?
  • w

    witty-crayon-22786

    03/13/2020, 7:22 PM
    no one's done it yet
  • w

    witty-crayon-22786

    03/13/2020, 7:22 PM
    they're generally pretty easy
  • w

    witty-crayon-22786

    03/13/2020, 7:22 PM
  • h

    hundreds-breakfast-49010

    03/13/2020, 7:24 PM
    I don't think there's any particular need to rush a rust update, I've just been running into the issue with tracking down where an 
    .unwrap()
    on an Option or Result failed a lot lately
  • h

    hundreds-breakfast-49010

    03/13/2020, 7:24 PM
    so it's an ergonomic change I'm excited about
  • h

    hundreds-breakfast-49010

    03/13/2020, 7:25 PM
    although, it should hopefully just be a matter of bumping the version number in that one file, right?
  • h

    hundreds-breakfast-49010

    03/13/2020, 7:25 PM
    is there a reason we'd want to go to 1.41 before 1.42?
  • w

    witty-crayon-22786

    03/13/2020, 7:29 PM
    imo, it's always a good idea to bump version-at-a-time
    👍 1
  • w

    witty-crayon-22786

    03/13/2020, 7:30 PM
    although it's possible that doing it as two commits in one PR would be fine.
  • w

    witty-crayon-22786

    03/13/2020, 7:30 PM
    but i don't think that this would count as "rushing"... we're mostly just behind schedule, as you can see from those commits.
    👍 1
  • h

    hundreds-breakfast-49010

    03/13/2020, 7:30 PM
    what happens if you do try to bump two versions at a time?
  • w

    witty-crayon-22786

    03/13/2020, 7:31 PM
    version at a time is always the best tested thing, basically
    👍 1
  • w

    witty-crayon-22786

    03/13/2020, 7:31 PM
    for something as stable as rust, it's fairly low risk
  • w

    witty-crayon-22786

    03/13/2020, 7:31 PM
    for pants itself though, we always, always recommend version at a time, because you'll miss deprecations and etc otherwise
    💯 1
  • h

    hundreds-breakfast-49010

    03/13/2020, 8:03 PM
  • h

    happy-kitchen-89482

    03/13/2020, 10:04 PM
    Is there an easy way to get the fingerprint of an instance of an engine type in Python
  • h

    happy-kitchen-89482

    03/13/2020, 10:04 PM
    E.g., an ExecuteProcessRequest?
  • h

    hundreds-breakfast-49010

    03/13/2020, 10:07 PM
    many rust types, including 
    ExecuteProcessRequest
    , implement 
    Hash
    ( https://doc.rust-lang.org/std/hash/trait.Hash.html )
  • h

    hundreds-breakfast-49010

    03/13/2020, 10:08 PM
    uh, in python
  • h

    hundreds-breakfast-49010

    03/13/2020, 10:08 PM
    isn't that what 
    hash
    the python builtin is for?
  • w

    witty-crayon-22786

    03/13/2020, 11:20 PM
    @happy-kitchen-89482: what's the usecase?
  • h

    happy-kitchen-89482

    03/13/2020, 11:37 PM
    Debugging
  • w

    witty-crayon-22786

    03/13/2020, 11:37 PM
    so, there is the fingerprint within the 
    Graph
    in memory, and there is the fingerprint within the persistent cache
  • w

    witty-crayon-22786

    03/13/2020, 11:38 PM
    do you suspect one or the other?
  • w

    witty-crayon-22786

    03/13/2020, 11:40 PM
    for the 
    Graph
    , you'd want to use 
    Hash
    (as Greg mentioned), or the visualization of the graph rendered by 
    --native-engine-visualize-to
  • w

    witty-crayon-22786

    03/13/2020, 11:42 PM
  • h

    hundreds-father-404

    03/13/2020, 11:43 PM
    (He’s debugging that we found 
    ./v2 test
    to have fewer cache hits than we’d expect)
  • h

    hundreds-breakfast-49010

    03/13/2020, 11:43 PM
    it might be worth noting that my recent Platforms-related changes were touching code around the way the rust 
    Fingerprint
    type maps to data stored in lmdb
  • w

    witty-crayon-22786

    03/13/2020, 11:45 PM
1...214221432144...2420Latest