<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/17 Idan Kamara <span dir="ltr"><<a href="mailto:idankk86@gmail.com" target="_blank">idankk86@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><div class="h5">On Sun, Sep 15, 2013 at 11:45 AM, Giovanni Gherdovich <span dir="ltr"><<a href="mailto:g.gherdovich@gmail.com" target="_blank">g.gherdovich@gmail.com</a>></span> wrote:<br></div></div>
<div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello Idan and Iulian,<br>
<br>
2013/9/15 Idan Kamara <<a href="mailto:idankk86@gmail.com" target="_blank">idankk86@gmail.com</a>>:<br>
<div>> On Sat, Sep 14, 2013 at 3:34 PM, Iulian Stana <<a href="mailto:julian.stana@gmail.com" target="_blank">julian.stana@gmail.com</a>><br>
> wrote:<br>
>><br>
>><br>
>>>> + *<br>
>>>> + * \param handle The handle of the connection, wherewith I want to<br>
>>>> communicate<br>
>>>> + * \param callback A function that will handle error data.<br>
>>>> + *                 A NULL pointer will ignore error data.<br>
>>><br>
>>><br>
>>> What meaningful thing can a user do in this callback?<br>
>>><br>
>><br>
>><br>
>> What ever he wants to do with error data, print it do the stderr, store in<br>
>> some place<br>
>> or I don't know parse this data in his own way is his decision.<br>
><br>
><br>
> Parsing error data is a bit of a problem in Mercurial, since its output<br>
> isn't guaranteed to be stable between releases.<br>
> But more importantly, I don't think there's anything meaningful to do when<br>
> 'hg tip' fails..<br>
><br>
> You already have errno to check for command errors, does it also expose a<br>
> generic 'command failed' error code?<br>
> If so, you could use that and store the error string somewhere, and have<br>
> strerror (or similar), return it.<br>
<br>
</div>They idea behind a callback to handle error messages is to let the user<br>
decide if (1) print the err msg somewhere, like dialogue box or stderr or<br>
(2) ignore.<br>
Below I paste the IRC transcripts of the discussion we had with Matt<br>
at the time.<br>
<div><br>
<br>
>>>> + * \param argument The option list. Will contain all option that you<br>
>>>> wish.<br>
>>><br>
>>><br>
>>> If you let the user pass in more arguments, it has the potential of:<br>
>>><br>
>>> 1) breaking your changeset parser (user passed --template)<br>
>>> 2) leaving unparsed data after you successfully parsed the changeset (not<br>
>>> sure how you deal with that)<br>
>>><br>
>><br>
>> The last --template will overwrite all preview templates probably I must<br>
>> tell in<br>
>> documentation that is not allowed to use other template...<br>
>><br>
>><br>
>> hg tip --template '{rev}' --template '{node}' --template 'Template - {rev}<br>
>> - {node}\n'<br>
>><br>
>>> I'm not sure you really want that.<br>
>><br>
>><br>
>> I really don't want to leave unparse data.<br>
><br>
><br>
> Right, so I'm not sure if you agree there's an issue here..<br>
<br>
</div>I agree that there is an issue here.<br>
We don't just proxy commands trasparently to commandserver,<br>
we inject a template that must be respected.<br>
<br>
What does python-hglib and JavaHG do about that?</blockquote><div><br></div></div></div><div>The high level interface doesn't let you pass arbitrary flags, it is 'typed', so you</div><div>can only pass what each command expects (excluding --template/style or other</div>

<div>flags that might alter the output in an unexpected way).</div></div></div></div>
</blockquote></div><br>Hi, Idan, </div><div class="gmail_extra"><br></div><div class="gmail_extra">My high level commands signature can be found in the following forms:</div><div class="gmail_extra"><br></div><div class="gmail_extra">
<span style="font-family:arial,sans-serif;font-size:13px">1) hg_cset_entry *hg_tip(hg_handle *handle, int(*callback)(const char *msg, </span><span style="font-family:arial,sans-serif;font-size:13px">size_t len), char *argument[]);</span><br>
<div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">2) int hg_pull(hg_handle *handle, int(*callback)(const char *msg, </span><span style="font-size:13px;font-family:arial,sans-serif">size_t len), char *argument[]);</span><br>
</div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">3) hg_csetstream_buffer *hg_log(hg_handle *handle, int(*callback)(const char *msg, </span><span style="font-size:13px;font-family:arial,sans-serif">size_t len), char *argument[]);</span><br>
</div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div class="gmail_extra">For the first case I think that it will be better to pass the hg_cset_entry structure </div><div class="gmail_extra">
by a function argument, like you proposed, this means that those function will be </div><div class="gmail_extra">more like second form, will return the exitcode received from cmd-server.</div><div class="gmail_extra"><br>
</div><div class="gmail_extra">In the third form the function will return a yield-like mechanism, in this case I am </div><div class="gmail_extra">allocate the space, but I also free this space if you use the the hg_fetch_entry()</div>
<div class="gmail_extra">functions that I made available for users.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Probably you already see the pattern of those functions:</div><div class="gmail_extra"><br>
</div><div class="gmail_extra">The first argument is the handle of the connection.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The second argument is a callback function that will handle the error data </div>
<div class="gmail_extra">received from cmd-server. My first thought was to store this data in a pointer</div><div class="gmail_extra">and to let user to decide when he needs this data. Matt suggest that it would</div><div class="gmail_extra">
be better to use this callback function, in this way I don't need anymore to</div><div class="gmail_extra">store the error data. I just pass the received error data to this function.</div><div class="gmail_extra"><br>
</div><div class="gmail_extra">The third argument is a list of arguments (a null terminate list that will store</div><div class="gmail_extra">all options and all flags that users need). Why I choose this option? That </div>
<div class="gmail_extra">time when I started to think about possibilities of passing the flags I found </div><div class="gmail_extra">three options: </div><div class="gmail_extra">1) to lay the options in the signature, like you did in the python-hglib, </div>
<div class="gmail_extra">but in C you cannot call a function just with the needed argument, </div><div class="gmail_extra">so you must pass a value for each agument,</div><div class="gmail_extra">2) to pass a list with wished options, like I already did</div>
<div class="gmail_extra">3) to create a flag structure for each command like Martin suggest </div><div class="gmail_extra">in his mail....</div><div class="gmail_extra"><br></div><div class="gmail_extra">After some discussion we decided to use the second option, because</div>
<div class="gmail_extra">it's easier to implement, and will make the code more clear, I agree </div><div class="gmail_extra">with you that its not safe to let user pass what option he want, but in</div><div class="gmail_extra">
this way, some features flags can be used more easier...</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think that Martin option will be the best in my case, if you have other </div><div class="gmail_extra">
suggestion for how to implement this issue please tell me, in the meantime</div><div class="gmail_extra">I will start to prepare the ground for this change.</div><div class="gmail_extra"><br></div>-- <div dir="ltr"><div>Iulian</div>
</div>
</div></div>