spacepaste

  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
7:29 PM <iulians> ggherdov, now
7:30 PM <ggherdov> iulians: I'd like you, once more, to argument a design choice you made:
7:30 PM — ggherdov looking for links...
7:31 PM <ggherdov> here we go: why these lines https://bitbucket.org/istana/c-hglib/src/1d8f0f84e8a50b8f1fadd782fa3aff1ab7ff06aa/hglib/main.c?at=default#cl-95 look so different from mpm snippet at http://markmail.org/message/tc6hsvl7fofdjqcl ?
7:32 PM <ggherdov> my point: when do you read the return code of hg_rawread ? hint: you don't :)
7:33 PM <ggherdov> seriously, we didn't discuss much that part. I'd like to hear your comments
7:35 PM <iulians> The hg_rawread function is not seeking for the 'r' channel
7:36 PM <iulians> The functions will read data from std output of command server
7:37 PM <ggherdov> "The functions" <---- you mean "the function hg_rawread" ?
7:37 PM <iulians> yes
7:37 PM <iulians> and will return the length read data
7:37 PM <ggherdov> ok. the 'r' channel is written on the stdout of cmdsrv too.
7:37 PM <ggherdov> so, hg_rawread *could* read the 'r' channel too.
7:38 PM <iulians> the data send from command server for 'r' channel
7:39 PM <iulians> I could change a bit the implementation for hg_rawread
7:39 PM <ggherdov> " the data send from command server for 'r' channel" <---- is that a statement ? I don't understand it
7:40 PM <ggherdov> I am not asking to change, I want to discuss the motivations of your choice.
7:40 PM <iulians> let's take from the beginning
7:40 PM <ggherdov> go ahead
7:41 PM <iulians> The rawread function will read data from cmdserver and will put the read data on buff
7:41 PM <ggherdov> ok
7:41 PM <iulians> the return value is the length of buff
7:42 PM <ggherdov> ok
7:42 PM <iulians> before the return, the new channel will be read on the handle
7:42 PM <iulians> to prepare the next step
7:43 PM <iulians> if you will not make this verification
7:43 PM <iulians> to see if the channel it's still the output channel
7:43 PM <iulians> the rawread function could read the exitcode
7:44 PM <iulians> the data send for the 'r' channel
7:45 PM <ggherdov> I expect a "but..." coming
7:45 PM — ggherdov is there a "but..." coming ?
7:45 PM <iulians> not really
7:45 PM <iulians> ...
7:46 PM <ggherdov> ok
7:47 PM <ggherdov> Let me digress a little and ask you: why is hg_rawread that read next next "channel name" ?
7:47 PM — ggherdov it might actually be a good idea...
7:48 PM <iulians> I think that I can change the implementation for the rawread function but you don't always finish the while statement from a rawread call
7:48 PM <ggherdov> "you don't always finish the while statement from a rawread call" <---- can you elaborate on this ? I am not sure I get it
7:50 PM <iulians> sometimes you will have to send some data to cmdserver(before the commands ends, see the merge_with_conflicts)
7:50 PM <iulians> after you finish dealing with prompts the cmdserver will ends his work and will send the exitcode
7:51 PM — ggherdov looking at merge_with_conflicts
7:52 PM <ggherdov> iulians: anyway, the reason I am playing devil's advocate is the following:
7:52 PM <ggherdov> mpm asked the lib to behave in a very well specified way ---> http://markmail.org/message/tc6hsvl7fofdjqcl
7:52 PM <iulians> About reading the next channel name, is more a defense action. I am not letting the use call for a wrong channel.
7:53 PM <ggherdov> you are giving a slightly different usage paradigm ----> https://bitbucket.org/istana/c-hglib/src/1d8f0f84e8a50b8f1fadd782fa3aff1ab7ff06aa/hglib/main.c?at=default#cl-95
7:53 PM <ggherdov> there *have* to be good reason for that. That is my point. You might be right, but it *must* be an informed and deliberated choice.
7:54 PM <ggherdov> " I am not letting the use call for a wrong channel" <---- you mean "the user" ?
7:54 PM <iulians> user
7:54 PM <iulians> yes
7:54 PM <iulians> sorry :D
7:54 PM <ggherdov> no pb no pb
7:55 PM <ggherdov> I am still at understanding "you don't always finish the while statement from a rawread call". I am trying to get what you mean.
7:57 PM <ggherdov> iulians: I don't have any "merge_with_conflicts" function at https://bitbucket.org/istana/c-hglib/src/1d8f0f84e8a50b8f1fadd782fa3aff1ab7ff06aa/hglib/main.c
7:57 PM <hgbot> <http://ln-s.net/-ZFH> (at bitbucket.org)
7:57 PM <iulians> https://bitbucket.org/istana/c-hglib/src/1d8f0f84e8a50b8f1fadd782fa3aff1ab7ff06aa/hglib/main.c?at=default#cl-200
7:58 PM <iulians> first the cmdserver will send to the 'o' channel, your conflict
7:59 PM <iulians> then will wait for your answer
7:59 PM <ggherdov> ok
7:59 PM <iulians> in 'L' channel
7:59 PM <ggherdov> ok...
7:59 PM <iulians> and then will quit his action, will send the exitcode :D
8:00 PM <ggherdov> o ---> hg_rawread, L ---> hg_rawwrite, correct ?
8:01 PM <iulians> yes
8:01 PM <ggherdov> ok
8:01 PM <ggherdov> iulians: let me restate the original question: why "while(hg_rawread(...)) { ... } " would not work ? apart for the obvious reason that an error (exit -1) would be bool-eval'ed to true, with catastrophic consequences
8:02 PM <ggherdov> I see the "while(hg_rawread(...)) { ... }" paradigm as "read until there is data available"
8:02 PM <ggherdov> and you are saying: uhm... it is not that simple.
8:03 PM <ggherdov> I do understand that the conversation with cmdserver terminates when the 'r' channel is available.
8:03 PM <ggherdov> But I also think that the conversation with cmd server terminates when there is no more data to read .
8:03 PM — ggherdov or not?
8:03 PM <iulians> hmm, if you point in this way
8:04 PM <iulians> I think that you are right ...
8:04 PM <ggherdov> wait, now I think that *you* are right :)
8:04 PM <iulians> :)))
8:04 PM <ggherdov> let me say what I am understanding:
8:05 PM <ggherdov> "conversation with cmd server terminates when there is no more data to read" <----- false. As soon as we get an 'L' channel, there is *no more data* to read, but the conversation is far from being terminated...
8:06 PM <ggherdov> it's just... our turn to talk.
8:07 PM <ggherdov> wait iulians, why don't we have nested while loops ? outer one: "while channel different from 'r'
8:07 PM <ggherdov> inner one: (just in case of hr_rawread) "while no more data to read"
8:07 PM <iulians> probably I can assume that the conversation with cmd server terminates when I receive the 'r' channel in my read.
8:08 PM <ggherdov> this latter while loop is *only* dedicated to handling the 'o' channel
8:08 PM <ggherdov> (which is, a "read" channel)
8:08 PM <ggherdov> what do you think ?
8:08 PM <iulians> it's there necessary to use two while statements?
8:09 PM <iulians> I can do something else
8:09 PM <iulians> to return value 0 from rawread when the next channel will be
8:09 PM <ggherdov> is it necessary _not to_ use two while statement ? why the adversity ?
8:10 PM <iulians> 'r' or 'L'
8:10 PM <ggherdov> iulians: a library needs to be easy to understand.
8:10 PM <ggherdov> do simple things.
8:11 PM <ggherdov> iulians: do you know PLA ? http://en.wikipedia.org/wiki/Principle_of_least_astonishment
8:11 PM <ggherdov> seriously, people have other things to do instead of studying the intricacies of a convoluted library
8:12 PM <ggherdov> open/close/command/read
8:12 PM <ggherdov> as simple as that
8:13 PM <ggherdov> iulians: I vote for nested while loops. The advantage is that mpm will have what he asked for, and I trust very much his instinct for simplicity of things.
8:13 PM <ggherdov> iulians: gotta go, they'll lock me down in the building. see you in an hour or so, if you'll still be here
8:13 PM <ggherdov> bye bye
8:13 PM <iulians> ok I understand now, I will change it
8:13 PM <ggherdov> good boy :)
8:13 PM <ggherdov> talk to you later