unison

unison copied to clipboard

I think this should work, but doesn't:

.ns1> find
.ns1> alias.many 1-28 .ns1_nohistory

Reason this doesn't work - find produces hash qualified numbered args and alias.many doesn't accept hash qualified arguments.

@aryairani I had thought this was a major use case for the command, copying a namespace without its history. I remember we'd considered a merge.nohistory command and went with this instead after thinking they had equivalent power.

Seems like alias.many could just be made to work with hash qualified names and that would address the problem?

Same problem with ls, which produces absolute names in numbered args.

Bummer, that was an oversight. Intended to work the way you expected.

The problem imo is that numberedArgs needs different contents depending on what you plan to do with them. In this case (and probably only this case!) you want it to contain relative names, as alias.many is only well defined over relative names.

A case when you don’t want relative names IMO is find followed by cd followed by view — you could end up viewing something other than what you’d found.

One solution I see would be to include multiple forms in the numberedArgs, and have the consumer pick the one that makes sense for it? But that would be a bit of work.

Seems like alias.many could just be made to work with hash qualified names and that would address the problem?

Say more?

Oh, I just re-read your comment. If alias.many does not accept hash-qualified args, that could indeed be changed. But the problem imo is absolute vs relative. The numberedArgs iirc are absolute hash qualified.

Another fix could be the “represent all paths as absolute, and apply an optional currentpath in some cases for parsing, printing, resolving” thing. ref #1298

Then you can alias.many any previous find results that happen to be in or below your currentPath, regardless of where you were when you found them.

@aryairani FYI find produces relative hash qualified names for numberedArgs. Maybe it shouldn't, but that's what it does currrently:

.origin_base.Bytes> find

  1. ++ : Bytes -> Bytes -> Bytes
  2. at : Nat -> Bytes -> Optional Nat
  3. drop : Nat -> Bytes -> Bytes
  4. empty : Bytes
  5. flatten : Bytes -> Bytes
  6. fromList : [Nat] -> Bytes
  7. size : Bytes -> Nat
  8. take : Nat -> Bytes -> Bytes
  9. toList : Bytes -> [Nat]
  

.origin_base.Bytes> debug.
debug.history       debug.numberedArgs
.origin_base.Bytes> debug.numberedArgs

  1. ++##Bytes.++
  2. at##Bytes.at
  3. drop##Bytes.drop
  4. empty##Bytes.empty
  5. flatten##Bytes.flatten
  6. fromList##Bytes.fromList
  7. size##Bytes.size
  8. take##Bytes.take
  9. toList##Bytes.toList

What do you think best next step is here? I was trying to create base3 to have all the stuff we merged into base2 but without the busted history and was blocked by this. We could manually recreate stuff or use existing copy (going to be pretty tedious), or if we had a fix for this ASAP I'd much rather just do that.

@pchiusano Sorry, okay — the absolute name thing must've been something I adopted later than find.

I think alias.many should be updated to accept hash-qualified source definitions, but I recommend that if they are hash-qualified, it be an error (or ignored with a warning) if the hash is ambiguous. Note, it shouldn't accept hash-only, since alias needs a name.

I can work on it or pair on it if you want; I have 2 open tasks on my stack currently though.

Update: it seems to be something screwy when copying symboly ids:

.origin_base> copy 1-28 .origin_base_nohistory

  InvalidSymbolyId ""

If you constrain your copying to just non-symbolic ids, it works okay.

Reminiscent of #763; recommend killing the ucm indentifier parsers with fire, per our conversation.

@pchiusano I haven't yet been able to replicate the parsing issue at the repl.

When you have a chance, could you post the debug.numberedArgs output for a failing case (e.g. your 1–28)?

.origin_base> copy 1-100 .blargh

  InvalidSymbolyId ""

.origin_base> debug.
debug.history       debug.numberedArgs
.origin_base> debug.numberedArgs

  1.   .#0hoa6tis7604fo17o91lfjflsvd843uvm7sueu5rfqqn5nbneajoh9fldfbmmjnhh1h2690ktfflrbb96q9lksesuh3t5amcc1ph92g
  2.   <|#oujnf8a703ha04c80ktnmub0rqg53mrrrvoreaacpu2ar9af43qq6r59d3rgm0j3jfogcih1u0c6k8ddqkfbr6mkf5vkrgdviiv3628
  3.   Boolean##Boolean
  4.   Boolean.not##Boolean.not
  5.   Bytes##Bytes
  6.   Bytes.++##Bytes.++
  7.   Bytes.at##Bytes.at
  8.   Bytes.drop##Bytes.drop
  9.   Bytes.empty##Bytes.empty
  10.  Bytes.flatten##Bytes.flatten
  11.  Bytes.fromList##Bytes.fromList
  12.  Bytes.size##Bytes.size
  13.  Bytes.take##Bytes.take
  14.  Bytes.toList##Bytes.toList
  15.  Char##Char
  16.  Char.fromNat##Char.fromNat
  17.  Char.toNat##Char.toNat
  18.  Debug.watch##Debug.watch
  19.  Either#kc92tha5f12vamultsbq93aqnphg9pnhuq3sodqvhes6st2a3h5sd2rksuptds94ptvvpg0tj0jp1rehlb73rkn0kj2r6elkdqndhjo
  20.  Either.Left#kc92tha5f12vamultsbq93aqnphg9pnhuq3sodqvhes6st2a3h5sd2rksuptds94ptvvpg0tj0jp1rehlb73rkn0kj2r6elkdqndhjo#0
  21.  Either.Right#kc92tha5f12vamultsbq93aqnphg9pnhuq3sodqvhes6st2a3h5sd2rksuptds94ptvvpg0tj0jp1rehlb73rkn0kj2r6elkdqndhjo#1
  22.  Float##Float
  23.  Float.*##Float.*
  24.  Float.+##Float.+
  25.  Float.-##Float.-
  26.  Float./##Float./
  27.  Float.abs##Float.abs
  28.  Float.acos##Float.acos
  29.  Float.acosh##Float.acosh
  30.  Float.asin##Float.asin
  31.  Float.asinh##Float.asinh
  32.  Float.atan##Float.atan
  33.  Float.atan2##Float.atan2
  34.  Float.atanh##Float.atanh
  35.  Float.ceiling##Float.ceiling
  36.  Float.cos##Float.cos
  37.  Float.cosh##Float.cosh
  38.  Float.eq##Float.==
  39.  Float.exp##Float.exp
  40.  Float.floor##Float.floor
  41.  Float.fromText##Float.fromText
  42.  Float.gt##Float.>
  43.  Float.gteq##Float.>=
  44.  Float.log##Float.log
  45.  Float.logBase##Float.logBase
  46.  Float.lt##Float.<
  47.  Float.lteq##Float.<=
  48.  Float.max##Float.max
  49.  Float.min##Float.min
  50.  Float.pow##Float.pow
  51.  Float.round##Float.round
  52.  Float.sin##Float.sin
  53.  Float.sinh##Float.sinh
  54.  Float.sqrt##Float.sqrt
  55.  Float.tan##Float.tan
  56.  Float.tanh##Float.tanh
  57.  Float.toText##Float.toText
  58.  Float.truncate##Float.truncate
  59.  Heap#kq8poq07dvel6qilj7nrngolm466l34bbfj5eifeb3lfoge17t9e91pp4u3c8978vofa0vqbrp9p4fn051h6fr0v6g5b0l981au0bi0
  60.  Heap.Heap#kq8poq07dvel6qilj7nrngolm466l34bbfj5eifeb3lfoge17t9e91pp4u3c8978vofa0vqbrp9p4fn051h6fr0v6g5b0l981au0bi0#0
  61.  Heap.children#f2nrun519d7srn5r3n7vlkbto9fuil89n4n773mss9dlu0493hlv2uc3j696oree0cr5lkt3eho42b0u2fgfuoitmciatfpke6oc1t0
  62.  Heap.fromKeys#rbs27vvm1n2js6upgitn4qdrfvilnms68tbfde82uea4uh55on6kd1aouv5lcbont6djmrsrrdff1p76druhdt98rd7ugedfraib6f8
  63.  Heap.fromList#et7vgc96hcqhnobco8n36eoitulc0n8ag6n103b6f9hg5bb34seua0gceqvkrg70rlk1cron9uq43scft9pcabpdj1ckotvar0qddt0
  64.  Heap.max#21erbbb2lhrsgk1nq6f1roejl1qtrimv7adod3h59u1ejm34ig8lc1kn4tb1luggef8chrk6c9dvdur0099b9otn82vmh38ddpplg0o
  65.  Heap.maxKey#mlma495f9ho6iuf9j00dcvif8fqgjlvsmjnhuebjnrknbh4jfaccbm4f7gpi5vnc68vsu599te2uqicd3r423oki6hmvc1r1tj8pmko
  66.  Heap.pop#ar5grl7qe86g2oiii3647he0mg6ropgnab17t06r5cm6a53opeoou98cclrjtou33grg2uqq619r813fhf6hd6lb4mjtf26rdse1kmg
  67.  Heap.singleton#00tac3luv05e0tqqsef1t5lt7ih8vppek8tqgembt9fsrjapc0rti50n24l76mvq6fsafl8l8a0laoaa91q29bjd08p2dq0e7r69prg
  68.  Heap.size#odvevnnmlp27b01rpfn5so4gbs9g0jd4nvm6cudalqbuq36hcrqgav6m340kcjq0biosfi2dps5jg2ilfq1vto35qsl0r4tsshfn99o
  69.  Heap.sort#75nrf25gjdp9cbc2qe61qkk0lqp5lql2c0h40tvn9ec8obnc3q130ome38fpb5bppurp54inrlbljokt91m1b6hk06ha5rcjnsf13u0
  70.  Heap.sortDescending#usuniqo5iebgg3iu8htlclup6mkfmf9f5h22508hr707h1odcvgp894sg0b5gkbmhqs2oj9vvkvlp4u8ko3ic3jv3nmdl4uemo9tb6o
  71.  Heap.union#8g9kgrmgh9pb4ckm1lca74ossdvpf6sck2ams5p93v1cedlfiqbmbs2r603fovf28qmh9v3tmv8jr6j195p55fone9psoeogjqbf2mo
  72.  Int##Int
  73.  Int.*##Int.*
  74.  Int.+##Int.+
  75.  Int.-##Int.-
  76.  Int./##Int./
  77.  Int.eq##Int.==
  78.  Int.fromText##Int.fromText
  79.  Int.gt##Int.>
  80.  Int.gteq##Int.>=
  81.  Int.increment##Int.increment
  82.  Int.isEven##Int.isEven
  83.  Int.isOdd##Int.isOdd
  84.  Int.lt##Int.<
  85.  Int.lteq##Int.<=
  86.  Int.maxInt#d75vubeoep5o8ph72v0v9qdm36n17up0d7bsbdckjapcs7k9g1kv5mnbpp3444u8fmvo2h3benmk7o3sd09g1lkrrvk4q93vv8u2n3g
  87.  Int.minInt#p9og3s2h41natoslfjoi1do0omp82s4jiethebfd4j5p99ltbdmcua2egbiehs9tq9k65744cvugibiqdkgip21t7se4e8faktnl3k0
  88.  Int.mod##Int.mod
  89.  Int.negate##Int.negate
  90.  Int.signum##Int.signum
  91.  Int.toFloat##Int.toFloat
  92.  Int.toText##Int.toText
  93.  Int.truncate0##Int.truncate0
  94.  IsTest#udk022hst8njtllajhq0g3spcpii7igeo9si0rq68i13vq9q1npf1vjp7mhqughcvoiskk387jrhnlvn9m1498aal85iubq49q398s0
  95.  IsTest.IsTest#udk022hst8njtllajhq0g3spcpii7igeo9si0rq68i13vq9q1npf1vjp7mhqughcvoiskk387jrhnlvn9m1498aal85iubq49q398s0#0
  96.  List##Sequence
  97.  List.++##List.++
  98.  List.+:##List.cons
  99.  List.:+##List.snoc
  100. List.at##List.at
  101. List.cons##List.cons

@pchiusano Sorry for not noticing that you had included the debug.numberedArgs output a few messages back.

Okay, so this looks like exactly #763: the bug prevents us from operating on unqualified symboly names.

In your first example, it would break on the unqualified ++.

In the second example, it would break on the unqualified . and <|.

A workaround for the first case would be to issue the find command from one level higher. The second case is harder to work around, you'd have to skip over . and <| (and any other symboly ids that appear at the root level of the library) and fix them up manually.

That said, this is a super annoying bug that we should fix. I'm going to take it off the top of my stack for now until we get another chance to chat and/or pair.

Now that #763 is fixed, ++ and <| will work, but . still won't, due to . vs .(.) ambiguity. (Related to #1476.) So I would say that find is mostly okay now.

ls is producing absolute numbered args, which can't easily work with alias.many. I think we need to overhaul how ucm internally references names, rather than just switch ls to producing relative results. (The absolute results let you move around and still use them, related to #1364.)

Reading through the thread, I think the only remaining problem (not covered by another issue) is that ls produces absolute paths, but alias.many wants relative ones.

Another fix could be the “represent all paths as absolute, and apply an optional currentpath in some cases for parsing, printing, resolving” thing. ref #1298

I wholeheartedly support this approach. It‘s the same thing I did in my path library, after being frustrated with never being sure where relative paths were going to resolve.

ls is producing absolute numbered args, which can't easily work with alias.many. I think we need to overhaul how ucm internally references names, rather than just switch ls to producing relative results.

I suppose it’s implied by my above statement, but I agree that ls shouldn’t produce relative results.[^1]

[^1]: Internally, I think the function backing ls should produce relative results, because searchPath </> relResult is total, while removePrefix searchPath absResult is partial. I.e, you can get back the absolute path when you need it (as you would for the ls command), but going from the absolute path to the relative path (e.g., for displaying a short form for the user) isn’t always possible.

What I don’t understand is why absolute numbered args can't easily work with alias.many. Is it just because of the tendency to use relative paths internally? Or is there something about the semantics of alias.many in particular?

wow TIL footnotes