| Time |
S |
Nick |
Message |
| 00:21 |
|
|
gbeshers joined #darcs |
| 01:17 |
|
|
Korusef joined #darcs |
| 01:20 |
|
|
twb joined #darcs |
| 01:50 |
|
|
alexsuraci joined #darcs |
| 02:30 |
|
|
Korusef joined #darcs |
| 02:48 |
|
|
Korusef joined #darcs |
| 03:08 |
|
|
Korusef joined #darcs |
| 03:29 |
|
|
Korusef joined #darcs |
| 03:53 |
|
|
trofi joined #darcs |
| 05:40 |
|
|
twb joined #darcs |
| 06:10 |
|
|
twb joined #darcs |
| 06:23 |
|
|
balor joined #darcs |
| 06:56 |
|
|
JaffaCake joined #darcs |
| 07:02 |
|
|
darcscommitbot joined #darcs |
| 07:03 |
|
|
darcswikibot joined #darcs |
| 07:20 |
|
|
sxs joined #darcs |
| 07:21 |
|
|
gal_bolle joined #darcs |
| 07:36 |
|
|
gh_ joined #darcs |
| 07:43 |
|
|
lelit joined #darcs |
| 08:14 |
|
|
alpounet joined #darcs |
| 10:33 |
|
|
JaffaCake joined #darcs |
| 12:18 |
|
|
JaffaCake1 joined #darcs |
| 12:46 |
|
|
tibbe joined #darcs |
| 12:47 |
|
tibbe |
Someone should really assign a mentor to the second Darcs SoC proposal |
| 12:47 |
|
tibbe |
Eric is currently listed as mentor for both |
| 12:50 |
|
mornfall |
Well, I am listed as possible mentor on one. |
| 12:50 |
|
mornfall |
But no idea how to reassign. |
| 12:58 |
|
mornfall |
tibbe: Any idea what needs to be done to change the mentor? |
| 13:01 |
|
tibbe |
mornfall: decide who's going to mentor, tell me (or Edward) |
| 13:19 |
|
dino- |
Is it still possible to make anew d1 repo? |
| 13:19 |
|
dino- |
s/anew/a new/ |
| 13:19 |
|
dino- |
Is this what --old-fashioned-inventory does? |
| 13:21 |
|
|
kpreid_ joined #darcs |
| 13:22 |
|
idnar |
dino-: you probably want --hashed, unless you need to work with quite an old darcs |
| 13:23 |
|
idnar |
but yeah, --old-fashioned-inventory is the old format |
| 13:28 |
|
dino- |
I need to work on the broken d1 -> d2 convert |
| 13:28 |
|
mornfall |
The GHC repo on darcs.haskell.org is now hashed. (Maybe this is old news, but woo.) |
| 13:28 |
|
mornfall |
dino-: What do you mean? |
| 13:29 |
|
mornfall |
dino-: About darcs convert? |
| 13:29 |
|
dino- |
http://bugs.darcs.net/issue1760 |
| 13:29 |
|
mornfall |
dino-: You don't need old-fashioned for that. With hashed, it should break the same. |
| 13:29 |
|
dino- |
This issue says not only does it take a long time, but the resulting d2 repos are damaged |
| 13:29 |
|
mornfall |
dino-: Corruption is unrelated to this, though. |
| 13:30 |
|
dino- |
ok |
| 13:30 |
|
mornfall |
It says that happens with 2.3.1. |
| 13:30 |
|
dino- |
ok. I had only tested with the HTab repo that was attached to 1232 (missing prefs after convert), and never let it complete myself. |
| 13:31 |
|
|
lisppaste2 joined #darcs |
| 13:32 |
|
dino- |
By the time it gets to patch 8 or 10 it's going away for minutes. |
| 13:32 |
|
dino- |
iirc |
| 13:56 |
|
|
Korusef joined #darcs |
| 13:58 |
|
|
kpreid_ joined #darcs |
| 14:12 |
|
dino- |
I created a new repo with --hashed and have 7 patches in it. I will add more patches to confirm, but I don't think I'm seeing the slow behavior that I do with a repo that reports as Format: darcs-1.0 |
| 14:14 |
|
mornfall |
Oh? Heffalump said he saw it with hashed, too, I think. |
| 14:14 |
|
dino- |
Maybe I need more patches, will triple them to 20 or so. |
| 14:15 |
|
dino- |
But with that HTab test repo from issue 1232 clearly slowing down by 6, 7, 8 |
| 14:29 |
|
|
tibbe left #darcs |
| 15:02 |
|
|
kpreid_ joined #darcs |
| 15:11 |
|
dino- |
I tried it the other way too, obl down a darcs-1.0 repo to a dozen patches, still bogs after patch 8. |
| 15:11 |
|
mornfall |
Can you write whatever you have found down on the issue tracker? |
| 15:12 |
|
dino- |
Will do. |
| 15:44 |
|
|
trofi joined #darcs |
| 15:53 |
|
|
FunctorSalad_ joined #darcs |
| 15:54 |
|
FunctorSalad_ |
am I doing something else wrong? Or does darcs consider a change to a giant multiline regex atomary? |
| 15:54 |
|
FunctorSalad_ |
s/regex/sexp/ |
| 15:55 |
|
FunctorSalad_ |
(I'd like it to treat the lines as normal lines) |
| 16:00 |
|
lispy |
FunctorSalad_: I don't understand the question |
| 16:01 |
|
lispy |
?dict atomary |
| 16:01 |
|
lambdabot |
Supported dictionary-lookup commands: |
| 16:01 |
|
lambdabot |
all-dicts devils easton elements foldoc gazetteer hitchcock jargon lojban vera web1913 wn world02 |
| 16:01 |
|
lambdabot |
Use "dict-help [cmd...]" for more. |
| 16:01 |
|
lispy |
?all-dicts atomary |
| 16:01 |
|
lambdabot |
No match for "atomary". |
| 16:02 |
|
lispy |
FunctorSalad_: I don't understand the question, but perhaps the diff algorithm does not work the way you expect? Finding a perfect diff is computationally expensive so diff algorithms focus on "good enough" diffs |
| 16:05 |
|
FunctorSalad_ |
lispy: maybe I said it badly... I mean that when I modify a few lines in the giant sexp, darcs gives me a hunk where the whole thing is deleted and one where the new version is added |
| 16:05 |
|
FunctorSalad_ |
with 'atomary' I meant that it doesn't seem to try to look into the parts of the sexp |
| 16:05 |
|
lispy |
FunctorSalad_: it's probably not computing a perfectly minimal diff. If you use GNU diff do you get the same results? |
| 16:06 |
|
lispy |
Or maybe you changed the line endings? |
| 16:06 |
|
|
kolmodin joined #darcs |
| 16:06 |
|
lispy |
It's hard to say without looking at it, I guess |
| 16:06 |
|
FunctorSalad_ |
(could the problem be not diff-related at all, and be emacs's backup-by-rename? i.e., rename the old file to a backup, and write the new version as a fresh file) |
| 16:06 |
|
FunctorSalad_ |
but I didn't think darcs monitored such things |
| 16:07 |
|
FunctorSalad_ |
lispy: I shall try with GNU diff (does darcs invoke that?) |
| 16:07 |
|
lispy |
darcs uses a built in LCS algo that I think was written by Igloo originally |
| 16:08 |
|
Igloo |
I think it's changed since then |
| 16:08 |
|
FunctorSalad_ |
FWIW, the sexp in question is emacs's "custom-set-faces" :) |
| 16:08 |
|
FunctorSalad_ |
which contains all the face definitions |
| 16:08 |
|
lispy |
FunctorSalad_: it's possible that lots of that changed in some small way |
| 16:09 |
|
FunctorSalad_ |
(btw, LCS?) |
| 16:09 |
|
FunctorSalad_ |
(don't know what it is :)) |
| 16:10 |
|
FunctorSalad_ |
but are you saying that it can't be darcs parsing the parentheses and considering the whole sexp as one "unit"? |
| 16:11 |
|
Igloo |
No, darcs is line-based |
| 16:11 |
|
FunctorSalad_ |
hmm ok, I'll try to get a GNU diff somehow |
| 16:11 |
|
|
iago joined #darcs |
| 16:12 |
|
FunctorSalad_ |
(I'm expecting that that will display just a few lines) |
| 16:12 |
|
FunctorSalad_ |
hmm so should I record the file and then rollback it to get my hands on both versions as files? |
| 16:14 |
|
lispy |
FunctorSalad_: you could copy the current one to a new name, and then revert |
| 16:15 |
|
FunctorSalad_ |
by the way, it *does* seem to work smoothly for the customize-set-variables sexp, just not -faces |
| 16:21 |
|
lispy |
FunctorSalad_: FWIW, I've found this to be a pretty good reference: http://en.wikipedia.org/wiki/Diff |
| 16:22 |
|
lispy |
FunctorSalad_: if you think our diffs are suboptimal, perhaps you should create a bug ticket |
| 16:22 |
|
lispy |
FunctorSalad_: bugs darcs.net or http://bugs.darcs.net |
| 16:23 |
|
FunctorSalad_ |
lispy: ok, here's a 'darcs record' transcript (sorry, took me so long to deansify it ;)) http://pastebin.org/151085 |
| 16:23 |
|
FunctorSalad_ |
hunk #2 exemplifies this fact that for customize-set-variables, it works fine |
| 16:24 |
|
FunctorSalad_ |
will try gnu diff now... |
| 16:24 |
|
FunctorSalad_ |
lispy: I'm not sure enough yet that it isn't some oversight on my part, to create a ticket ;) |
| 16:24 |
|
lispy |
FunctorSalad_: you might need to compare line endings / whitespace. They sure look similar to me |
| 16:25 |
|
FunctorSalad_ |
lispy: hmm everything that ever touched these files is linux :) |
| 16:25 |
|
FunctorSalad_ |
(if I'm understanding correctly that you mean CRLF vs CR) |
| 16:26 |
|
FunctorSalad_ |
(or LF, don't remember) |
| 16:27 |
|
FunctorSalad_ |
lispy: ah, I have an idea. maybe the set-variables (the first sexp in the file) works properly because the two versions align? whereas the second sexp (set-faces) is displaced by changing length of the first? |
| 16:28 |
|
lispy |
Maybe? |
| 16:28 |
|
FunctorSalad_ |
but I thought darcs usually handles that |
| 16:28 |
|
lispy |
yeah, diff usually deals okay with shifting of content |
| 16:33 |
|
FunctorSalad_ |
diff --minimal fails too :o |
| 16:33 |
|
FunctorSalad_ |
odd... |
| 16:37 |
|
FunctorSalad_ |
ok, I feel stupid now. emacs actually permuted the two toplevel sexps between the versions |
| 16:37 |
|
FunctorSalad_ |
(these two are not under my direct control, emacs writes them) |
| 16:37 |
|
FunctorSalad_ |
sorry, didn't consider that possibility |
| 16:38 |
|
FunctorSalad_ |
(wasn't visible from either the darcs or the gnu diff :)) |
| 16:38 |
|
FunctorSalad_ |
unless you read the line numbers |
| 16:40 |
|
|
kowey joined #darcs |
| 16:41 |
|
FunctorSalad_ |
sorry for the false alarm... |
| 16:42 |
|
kowey |
there's a ticket requesting patience diff on the tracker |
| 16:42 |
|
lambdabot |
kowey: You have 1 new message. '/msg lambdabot @messages' to read it. |
| 16:43 |
|
Igloo |
patience diff? |
| 16:44 |
|
* Igloo |
asks google |
| 16:44 |
|
lispy |
Dr. Darcs paging patient diff? |
| 16:45 |
|
kowey |
http://bramcohen.livejournal.com/73318.html may be a good one |
| 16:45 |
|
FunctorSalad_ |
kowey: are you implying that that notices transpositions? |
| 16:45 |
|
FunctorSalad_ |
(of large blocks) |
| 16:46 |
|
FunctorSalad_ |
that sounds hard ;) |
| 16:46 |
|
kowey |
oh no, I'm just being a superficial (skimming) idiot |
| 16:46 |
|
FunctorSalad_ |
can one in principle hook up a sexp-level diff to darcs? |
| 16:46 |
|
kowey |
sorry, bad habit :-) I saw diff-dissatisfaction and just automatically switchboarded to "patience diff" |
| 16:47 |
|
FunctorSalad_ |
(I'll never get around to that anyway, but ...) |
| 16:47 |
|
kowey |
perhaps if you expanded on that question (to what extent do you mean "hook up?") |
| 16:47 |
|
FunctorSalad_ |
kowey: heh I think everyone does that more or less |
| 16:48 |
|
FunctorSalad_ |
kowey: I mean whether darcs works on top of an arbitrary `diff' program |
| 16:49 |
|
FunctorSalad_ |
(so you could exchange the `diff' if you implement some interface) |
| 16:49 |
|
kowey |
not at the moment, but maybe with some refactoring? |
| 16:50 |
|
kowey |
although mornfall has suggested one day freezing the diff algorithm to make it possible to achieve equivalence with snapshot based VCS |
| 16:50 |
|
Igloo |
If you don't make line-based diffs then you'd also need to define commutation rules |
| 16:51 |
|
lispy |
FunctorSalad_: yeah you could do that. On a related note, Simon Thompson came to visit and we were investigating the idea of tree based diffs for darcs |
| 16:52 |
|
lispy |
kowey: I think it would be better to have the format specify the diff algo used and not just have OneTrueDiff. |
| 16:52 |
|
lispy |
kowey: and I think mornfall's suggestion can fit into that if the hunk has a record of which diff was used |
| 16:53 |
|
kowey |
I think the idea was to guarantee that if you did darcs get from a git repo in two places, you always get the same patches |
| 16:55 |
|
FunctorSalad_ |
I'm in over my head here, I know little about darcs in depth |
| 16:55 |
|
FunctorSalad_ |
lispy: but tree-based diffs sound awesome for any kind of source code |
| 16:56 |
|
kowey |
it's sort of the general dream of Darcs - not tree based diffs per se |
| 16:56 |
|
kowey |
but arbitrary patch types |
| 16:56 |
|
lispy |
Maybe I'm reading too deeply into the implications, but it sounds like you'd also be losing the ability to add more patch types in that case. It seems better to add support for knowing which diff was done. What you might lose is 1) extra maintenance 2) sometimes one darcs might default to different diffs so you'd end up with different patches |
| 16:57 |
|
FunctorSalad_ |
I once made a sort of "diff" for haskell values implementing Data.Data.Data, it's almost trivial ;) |
| 16:57 |
|
kowey |
the silly example I sometimes used being to have cherry picking in your Photoshop undo stack |
| 16:57 |
|
FunctorSalad_ |
(produces a tree where every node is "Same", "Mixed", or "HeadsDiffer: ...") |
| 16:58 |
|
FunctorSalad_ |
("Same" being a leaf and "Mixed" containing a constructor name of the type in question and some subdiffs) |
| 16:59 |
|
FunctorSalad_ |
(head=constructor there) |
| 17:00 |
|
FunctorSalad_ |
of course it gets less trivial with more sophisticated things like detecting relocation of a subtree |
| 17:02 |
|
mornfall |
It's not a suggestion. |
| 17:02 |
|
mornfall |
I was merely stating the requirements for snapshot v. patch equivalence. |
| 17:02 |
|
mornfall |
I never said it was a good idea to go that route. :) |
| 17:03 |
|
kowey |
I suppose the hypothetical git-plugin could have stable diff, with Darcs being able to evolve however it wants |
| 17:03 |
|
mornfall |
Yes. |
| 17:04 |
|
mornfall |
That's the only safe way to treat snapshot-based VCS-es. |
| 17:05 |
|
lispy |
If snapshot-by-default made darcs more efficient, and then we generate current patch objects to share patches, that seems like an interesting approach though. A possible hybrid between current darcs and current git. |
| 17:05 |
|
mornfall |
On the other hand, you could get around that limitation by bumping the darcs patch format number. |
| 17:05 |
|
mornfall |
lispy: Well, it doesn't necessarily make anything more efficient. |
| 17:06 |
|
lispy |
mornfall: our on disk representation seems to be a lot bigger than git's over time. |
| 17:06 |
|
mornfall |
lispy: Not for the loose format, just for the packed one. |
| 17:06 |
|
lispy |
And I think that might be because we're storing so many deltas |
| 17:06 |
|
kowey |
we could also have some sort of representation of the high-level patches to "explain" the diffs |
| 17:06 |
|
kowey |
much like how the pending patch works, but for each individual changeset |
| 17:07 |
|
kowey |
"you see -R foo +A bar; but with my high-level patch, you know that this -R foo +A bar was actually caused by mv foo bar" |
| 17:08 |
|
mornfall |
That's of course mandatory for all non-hunk patches. |
| 17:08 |
|
lispy |
kowey: that's probably how the tree based patches will work |
| 17:09 |
|
mornfall |
Well, all non-derivable patches I mean. |
| 17:09 |
|
lispy |
kowey: we were considering flatting them to hunks to apply them, but trying to keep them as trees as much as possible |
| 17:09 |
|
mornfall |
But anyway, I don't see much promise in snapshot-based storage for darcs. |
| 17:09 |
|
mornfall |
All snapshot-based systems eventually degenerate to some sort of delta compression anyway. |
| 17:10 |
|
kowey |
mornfall: yep.. by "high-level" I just mean "not diffs" |
| 17:10 |
|
mornfall |
And it's not *that* much better than diffs. |
| 17:10 |
|
mornfall |
Not enough to compromise our future flexibility for it. |
| 17:14 |
|
lispy |
kowey: oh, I think I see what you mean. It's like storing a reference or a function call to what the patch does. And later if you need the patch you can use that to actually compute it. |
| 17:17 |
|
kowey |
hmm, let me see if we agree on what we think I mean |
| 17:18 |
|
kowey |
you can infer a patch between two snapshots by computing a diff on them, right? |
| 17:18 |
|
kowey |
only the patch is not so nice because it's all hunks |
| 17:19 |
|
kowey |
most of the time actually, that's all you want, but sometimes you want to do "darcs replace" or "darcs mv" or something fancier |
| 17:19 |
|
lispy |
Right. So in pending we just store that the diff should happen? |
| 17:19 |
|
kowey |
so you store an "explanation" that says "mv foo bar" |
| 17:19 |
|
lispy |
Actually, in Pending, i guess we store things like AddFile/RemoveFile but not the hunk request |
| 17:20 |
|
lispy |
kowey: explanation for the user or does darcs evaluate them? |
| 17:20 |
|
kowey |
well, I'm not the expert here, but I think of pending (and also the explanation) as being the intermediary state between the two snapshots |
| 17:20 |
|
kowey |
old - pending - new |
| 17:21 |
|
kowey |
and I think sometimes through commutation you have to store a few hunks here and there in pending |
| 17:22 |
|
kowey |
so the idea behind this old-pending-new approach is that instead of computing the hunks between old-new directly, you just apply pending to some tmp state, and compute the diff between pending and new |
| 17:22 |
|
kowey |
a smaller set of hunk patches |
| 17:25 |
|
lispy |
I certainly would love to decouple the contents of hunks from the rest of the patch stuff |
| 17:25 |
|
lispy |
For pragmatic reasons if nothing else |
| 17:25 |
|
kowey |
my thinking is that if every git changeset contained this sort of "explanation patch" (eg. in its changelog as a silly example), then you could do darcs in git |
| 17:29 |
|
lispy |
glguy has told me that some things he would need from darcs to consider it a replacement for git are: 1) merges need to be in the log, 2) a way to enforce a distinction between the types of merges that can happen locally vs. remotely. (git has a notion of a fast-forward merge). |
| 17:30 |
|
kowey |
for #1 he wants issue891 - history tracking (which depends on the more general issue1613 - patch annotations) |
| 17:30 |
|
mornfall |
Well, that's totally orthogonal to snapshot-vs-patch based. |
| 17:31 |
|
kowey |
it's just that by coincidence, the snapshot-based ones currently lend themselves to history tracking |
| 17:31 |
|
kowey |
whereas darcs has totally neglected in in favour of patch management (my sloppy terminology) |
| 17:32 |
|
kowey |
hg, as I understand it, is even more fanatical by default than git about history tracking |
| 17:32 |
|
|
gal_bolle joined #darcs |
| 17:34 |
|
Igloo |
fast-forward merge? |
| 17:34 |
|
kowey |
concidentally recently discussed in my query to sjt about branching http://lists.osuosl.org/piperm[…]April/023645.html |
| 17:35 |
|
* kowey |
actually should not have started that discussion (due to time pressure), but was too darn curious |
| 17:35 |
|
lispy |
Igloo: yeah. Have you ever tried to push with git and it tells you it failed? It's usually because the remote end doesn't support non fast-forward merge. |
| 17:35 |
|
kowey |
err, http://marklodato.github.com/v[…]-git-guide/#merge may be a better guide |
| 17:36 |
|
kowey |
sjt's point was that Darcs could have a much more liberal notion of "fast forward" |
| 17:36 |
|
lispy |
Igloo: it's a way of ensuring that merges happen in local repos where people (in theory) verify that they have the repository state they expect before pushing the result of the merge |
| 17:38 |
|
mornfall |
kowey: You mean --skip-conflicts? :) |
| 17:38 |
|
mornfall |
kowey: But I think that a --fast-forward kind-of switch is ProbablyEasy. |
| 17:38 |
|
mornfall |
kowey: Just check that remote is subset of local. |
| 17:38 |
|
kowey |
why yes, come to think of it :-) [skip-conflicts] |
| 17:39 |
|
mornfall |
Well, for apply, check that given context is same as our context (modulo commutation). |
| 17:39 |
|
kowey |
I was just trying to understand what sjt meant when he said we needn't worry about what happens when people push to the wrong branch |
| 17:40 |
|
kowey |
as long as --skip-conflicts tells you it skipped conflicts, --fast-forward probably isn't necessary (?) |
| 17:41 |
|
mornfall |
kowey: The key difference is that sometimes clean merges lead to unindentend (and broken) results. |
| 17:42 |
|
mornfall |
kowey: And you may want to disallow such clean merges as well, encouraging people to first try the result locally. |
| 17:42 |
|
kowey |
ah! so you meant --fast-forward in the strict sense |
| 17:42 |
|
mornfall |
kowey: In a semi-strict sense. :) The completely strict one would require same repository order (but that doesn't make any difference as long as darcs is correct). |
| 17:42 |
|
kowey |
so --fast-forward would just say "nope! remote repo has patches you don't have, no-can-push" |
| 17:42 |
|
mornfall |
Yes. |
| 17:43 |
|
mornfall |
"Please pull first." |
| 17:43 |
|
kowey |
hmm, sounds nice... but it's raising my oh-noes-new-flag grumpiness |
| 17:43 |
|
mornfall |
Like when CVS cries "foo out of date". |
| 17:43 |
|
kowey |
but maybe worthwhile anyway |
| 17:44 |
|
kowey |
I'd better head back and cook me some dinner, see ya! |
| 17:48 |
|
* mornfall |
just microwaved what remained of his lunch. :) |
| 18:05 |
|
|
gh_ joined #darcs |
| 18:22 |
|
|
abuiles joined #darcs |
| 18:57 |
|
|
drk-sd joined #darcs |
| 18:57 |
|
drk-sd |
evening! |
| 19:00 |
|
mornfall |
Evening. |
| 19:35 |
|
|
sm joined #darcs |
| 20:21 |
|
|
alpounet joined #darcs |
| 20:57 |
|
|
alexsuraci_ joined #darcs |
| 22:50 |
|
|
zooko joined #darcs |
| 22:51 |
|
zooko |
Folks: when I run this "darcs query" command nothing happens until I hit C-c. |
| 22:51 |
|
zooko |
I left it running for 15 minutes. |
| 22:51 |
|
zooko |
Now I'd like to try again with some sort of verbose debugging output. |
| 22:52 |
|
zooko |
But it tells me that "-v", "--debug", and "--progress" are all invalid options. |
| 22:54 |
|
drk-sd |
zooko: what « darcs query » command ? what args do you try it with? |
| 22:57 |
|
zooko |
darcs query contents --quiet --match "hash 20080107232302-92b7f-34c300e2a0124fe689b74ed40068c9e9bb4f9e46.gz" "docs/running.html" |
| 23:00 |
|
|
kpreid_ joined #darcs |
| 23:01 |
|
drk-sd |
(i can't help you, sorry) |
| 23:03 |
|
idnar |
--help says that --debug / --debug-verbose / --verbose are valid options |
| 23:03 |
|
idnar |
so that's odd |
| 23:05 |
|
zooko |
idnar: zookolocalhost:~$ darcs --version |
| 23:05 |
|
zooko |
2.3.0 (release) |
| 23:05 |
|
zooko |
Maybe --debug was added in 2.4? |
| 23:05 |
|
idnar |
ah, possibly; I do have 2.4 here |
| 23:08 |
|
drk-sd |
(so do i) |
| 23:08 |
|
lispy |
I think --debug has been around for quite a while |
| 23:08 |
|
lispy |
But I could be mistaken |
| 23:08 |
|
lispy |
My memory for such things is terrible |
| 23:11 |
|
zooko |
It definitely has for pull. |
| 23:11 |
|
zooko |
Not sure about query nee show. |
