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.