1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111
9:22 PM <iulians> mpm, If you have some time could we talk about my project? 9:22 PM <mpm> iulians: Don't ask to ask, please, just ask. 9:26 PM <iulians> mpm, you said that you would like to see a API propose , I'm a bit lost and I don't know from were to start. Last week I've make a proposal for the commands signatures ... 9:27 PM <iulians> I know that some of the commands are a bit special. 9:29 PM <mpm> iulians: Send me a .h file ONLY. Why is this confusing? 9:30 PM <mpm> Do not write a .c file. Do not attempt to compile anything. 9:30 PM <iulians> .h that will contain all the API commands? 9:31 PM <iulians> mpm, It will be there a problem if there will be two different approaches? 9:33 PM <mpm> iulians: Two different approaches? 9:36 PM <iulians> mpm, Sorry because I am a bit confuse, but last week when I stated to make a header file for the API, I send a mail where I asked about opinions on how the mercurial commands must look, with some pro and contra examples. 9:36 PM <iulians> and you told me to stat with the level 0 9:37 PM <mpm> How about you proceed by answering the questions in my latest response in the form of an improved header file. 9:39 PM <ggherdov> iulians: I understand that sketching out an implementation is helpful to clarify your mind. I also wouldn't have the experience to come out with a meaningful .h file w/o at least trying to see what the functions look like. But mpm will review only the .h part, which makes a lot of sense. He knows this game enough to understand how a function will be written 9:39 PM <ggherdov> just looking at the header. 9:39 PM <ggherdov> s/header/signature/ 9:40 PM <ggherdov> iulians: you should focus on mpm last mail. Some of mpm comments aren't obvious to me, for instance. 9:41 PM <ggherdov> ah sorry iulians didn't see your last mail. reading. 9:44 PM <ggherdov> for instance, mpm comments on "int hg_close(hg_handle *handle);" . iulians and me discussed and to us it looked a good idea to have this return 0 if no error and, say, 1 if the operation is not successfull for whatever reason. mpm, does this make sense? do you think it's ok? 9:45 PM <ggherdov> (mpm asks "What does this return?") 9:46 PM <iulians> mpm, My best idea right now it's to force users to create a specific structure with all their needs. For the example if they would like to use the 'add' command, they will create a structure 'my_options' where all there options will be find. 9:47 PM <mpm> Ok, are we having this discussion on IRC or email? 9:47 PM <iulians> and the 'add' function signature will be of the form "return_something add(handle *hdl, struct cmd_opt my_options)" 9:48 PM <mpm> That is not level 0. 9:48 PM <ggherdov> mpm let's go for irc. 9:48 PM <mpm> And I am not interested in it yet. 9:48 PM <mpm> Let's talk about exit codes. 9:49 PM <ggherdov> yes please 9:49 PM <mpm> You cannot return an exit code from hg_rawcommand. 9:49 PM <ggherdov> iulians: is this obvious to you ? 9:49 PM <mpm> Consider a command like log. It may return many many megabytes of data. 9:49 PM <mpm> The command server won't hand back an exit code until its done spooling out data. 9:50 PM <mpm> The client library cannot/should not internally buffer unknown huge masses of data. 9:50 PM <ggherdov> ok 9:51 PM <mpm> Therefore, we need a separate way to get the exit code. 9:51 PM <mpm> ..after we're done reading all the data. 9:52 PM <mpm> Also, we don't want to use hg_close for this.. because we might want to run more than one command per connection. 9:52 PM <ggherdov> "this" being the return status ? 9:53 PM <mpm> ggherdov: You are over-helping. 9:53 PM <ggherdov> ok I step back. 9:53 PM <iulians> mpm, so, you want to stop somehow the 'log' command ? 9:54 PM <iulians> or the server to sent the data ? 9:55 PM <mpm> iulians: Let's look at http://mercurial.selenic.com/wiki/CommandServer#runcommand-1 9:55 PM <mpm> See how r: happens after some arbitrary number of o:s 9:55 PM <iulians> yes 9:58 PM <mpm> iulians: See how r: happens after some arbitrary number of o:s 9:59 PM <mpm> iulians: That suggests an API where we do a bunch of reads followed by a get_exit_code when those run out. 10:00 PM <iulians> That r:s is the exit code for all the commands 10:01 PM <mpm> In the example, it's the exit code (0) of the summary command. 10:01 PM <iulians> When the rawcommand will reach to the r: will return 0. 10:02 PM <mpm> iulians: Ok, let's say I do hg_rawcommand("this command will run for four days and output 500G of data").. when does this API call return? 10:03 PM <mpm> Can I convince you that the answer should not be "four days from now after trying to buffer 500G of data"? 10:04 PM <iulians> yes 10:04 PM <mpm> The answer should be "immediately after sending the command to the server, without reading any output, regardless of what the command is". 10:05 PM <mpm> Then it's the user's responsibility to read all the output, and then fetch the result code. 10:06 PM <mpm> ..with separate calls. 10:07 PM <TheMystic> mpm: we're doing this in a blocking way? 10:07 PM <mpm> Yes? 10:08 PM <brendan> selectable hg_fd()? :) 10:08 PM <mpm> ..more or less the same as the shell. 10:09 PM <TheMystic> hah, yeah, event-driven via polling is probably more complicated than needed. 10:09 PM <mpm> http://mercurial.selenic.com/wiki/CommandServer#Protocol <- might want to read this if you're dropping in on this discussion. 10:10 PM <iulians> wait but the hg_rawcommand will give an immediately answer. In the hg_rawread will be a big process to get data from server. 10:10 PM <TheMystic> yeah, I've forgotten what we've done about deadlock here 10:11 PM <mpm> iulians: In my 4 day example, the C client -will not have access to the exit code- until a) 4 days have passed and b) it has first read 500G of data from hg. 10:12 PM <iulians> mpm, You concern maybe is when I will create the log command . And user will wait to much for the 'log' ? 10:12 PM <marmoute> iulians: It's not hard to imagine long commands 10:13 PM <marmoute> log can be "not so fast" but clone can be uber slow 10:13 PM <mpm> Or convert or whatever. 10:13 PM <mpm> Focus on this: b) it has first read 500G of data from hg. 10:14 PM <mpm> Where are you going to stick that 500G of data while you're trying to fetch the exit code? 10:14 PM <TheMystic> iulians: consider e.g. a GUI tool that keeps a cmdserver open. It will want to show output while a slow command is in progress. 10:15 PM <iulians> I think that you cannot keep 500G in memory for a single output. 10:15 PM <mpm> Correct. 10:15 PM <mpm> Which means _it is impossible to return the exit code of the command from hg_rawcommand_. 10:16 PM <iulians> So you try to avoid this, 10:16 PM <TheMystic> ...and the same goes for hg_rawread. 10:16 PM <mpm> Try to avoid what? Running commands that might have non-tiny output? 10:16 PM <iulians> but hg_rawcommand will return 0 if the command was send to the server and 1 if there was a problem 10:17 PM <iulians> and hg_rawread will return just chunks of data 10:18 PM <mpm> It's impossible to know if you've understood me yet. 10:19 PM <mpm> Say something like "yes, I see, we'll need an exit code function." 10:20 PM <iulians> I understand that it's impossible to return a message of 500G, in a single call. But I don't know how to do that exit code, and where this exit code will come. 10:21 PM <mpm> http://markmail.org/message/tc6hsvl7fofdjqcl <- see example here 10:21 PM <TheMystic> iulians: The exit code is always returned after the output is done. 10:22 PM <TheMystic> that is, it's output on the r: channel after all the o: lines. 10:23 PM <iulians> hg_exitcode(handle) ? 10:24 PM <mpm> Yes. 10:24 PM — ggherdov wow I totally overlooked that function in mpm's mail. 10:25 PM <iulians> in the http://mercurial.selenic.com/wiki/CommandServer#runcommand-1 example the exit code is 0 10:25 PM <mpm> Yes. 10:28 PM <mpm> (Btw, hg log -vp on the Mercurial repo itself takes 4 minutes and produces 193M of output.. just imagine what it does on a repo with half a million files and changesets.) 10:30 PM <mpm> iulians: In figuring out what needs to be in the level 0 API, here are the commands you should probably figure out a story for: 10:30 PM <mpm> a) hg init <- doesn't start with a repo 10:30 PM <mpm> b) hg log <- can produce huge output 10:31 PM <mpm> c) hg import - <- wants a patch fed to it from client 10:31 PM <mpm> d) hg merge <- has prompts 10:32 PM <mpm> e) hg verify <- might give warnings intermixed with output 10:33 PM <mpm> This doesn't mean "figure out how to wrap these commands" in C code, instead it means "figure out how to expose enough of the protocol to the user so that they can run these sorts commands" 10:35 PM <mpm> Hint: we'll almost certainly want to have an hg_rawchunk function exposed so that we can get the next chunk regardless of what typie it is. 10:39 PM <iulians> mpm, That hg log must return that huge output? in this time the user can do anything 10:39 PM <ggherdov> iulians: "must" is not the same as "can" 10:40 PM <ggherdov> since there are situation where it *can* return a huge output, your lib must be able to handle that too. 10:47 PM <iulians> mpm, In my API the users will have the possibility to make individual calls for hg_rawread or related commands or they will use the specific commands : hg_log, hg_init etc, and wait for the output ? 10:48 PM <mpm> You have left level 0. <zap> 10:48 PM <iulians> an other question. How could you stop the server sending data... 10:49 PM <mpm> Hint: if you can't build level 1 from your public level 0 APIs, your level 0 is not complete. 10:53 PM <mpm> And no, you can't stop the command server sending data. 10:53 PM <mpm> You can disconnect though. 11:04 PM <iulians> mpm, To do a recap, for the level 0, I must see how to treat some different input/output according to what channel I'm receiving. channels('o','e','r','L','I'), And to come with a good answer for the last 4 question from your mail. 11:05 PM <iulians> And to come with a .h file for the functions that will cover this things . 11:05 PM <mpm> iulians: Yes.
This paste never expires. View raw. Pasted through import.