Martin Kersten wrote:
> Sjoerd Mullender wrote:
>> Wrong on (almost) all counts.  It's amazing.
> Most of it is a concurrency conflict for which I warned upfront in an
> email that checkins where pending.
> I only removed the conflict lines that result from your (too-quick)
> actions.

You did not check what my changes entailed.  You blindly removed my
changes and substituted your own.  This is not proper conflict
resolution.  If you had actually *looked* at what I did, you would have
realized my solution was better.
My actions were not too quick, they were just in time (i.e. before you
did a worse job).

I also replied to your announcement "But no, let me look into it".

> Moreover, it is more than just mclient code. It is proper handling
> at all levels in a situation where different readers emerged
> over time.
> In particular the overloaded '?' in the MAL context and debugging.

Now we have the situation that a bare ? and a \? both result in a list
of MAL modules.  I would say that is less than useful.  It would be
better if \? continued to give mclient help.  This help can then even
say that a bare ? will give help from the server.

> None of the check-ins proofed that testing was carried even close
> to this level.
> 
>> Martin Kersten wrote:
>>> Update of /cvsroot/monetdb/clients/src/mapiclient
>>> In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv10235
>>>
>>> Modified Files:
>>>     MapiClient.mx 
>>> Log Message:
>>> Move the mode change into one place. Set the default rendering of MAL to
>> This I had already done in the previous checkin, but better because more
>> complete
> Beginning of a debugging session can start any time, should be trapped
> and was not done at all places. So be defensive.
> 
>>> align with the console. Best option still is to make mclient part of
>> This is debatable.
>>
>>> the server too. 
>> This has *nothing* to do with this checkin (and is debatable anyway).
> It has to do with understanding of the implications of the functionality
> provided.
> 
>>> Index: MapiClient.mx
>>> ===================================================================
>>> RCS file: /cvsroot/monetdb/clients/src/mapiclient/MapiClient.mx,v
>>> retrieving revision 1.73
>>> retrieving revision 1.74
>>> diff -u -d -r1.73 -r1.74
>>> --- MapiClient.mx   28 Aug 2007 07:43:07 -0000      1.73
>>> +++ MapiClient.mx   28 Aug 2007 08:03:57 -0000      1.74
>>> @@ -243,6 +243,15 @@
>>>  }
>>>  
>>>  static void
>>> +modeChange(char *reply){
>>> +   if (strstr(reply, "mdb>#EOD")){
>>> +           setPrompt();
>>> +   } else
>>> +   if(strncmp(reply,"mdb>",4)==0)
>>> +           sprintf(promptbuf,"mdb>");
>>> +}
>>> +
>>> +static void
>>>  SQLsetSpecial(const char *command)
>>>  {
>>>     if (mode == SQL && command) {
>>> @@ -371,6 +380,7 @@
>>>     do {
>>>             if ((reply = fetch_line(hdl)) == NULL)
>>>                     return 0;
>>> +           modeChange(reply);
>>>     } while (*reply != '[' && *reply != '=');
>>>     return mapi_split_line(hdl);
>>>  }
>> Now the change is checked twice.
> modechange was there, because row-fetch-line as
> called in my version. This was not marked as a conflict.
>>> @@ -412,7 +422,8 @@
>>>  {
>>>     char *line;
>>>  
>>> -   while ((line = fetch_line(hdl)) != 0) {
>>> +   while ((line = mapi_fetch_line(hdl)) != 0) {
>>> +           modeChange(line);
>>>             if (*line == '=')
>>>                     line++;
>>>             fprintf(toConsole, "%s\n", line);
>> Why did you undo my change which did this already?
>>
>>> @@ -1310,7 +1321,7 @@
>>>                                     continue;
>>>                             }
>>>                             case '?':
>>> -                                   if (!isspace((int) line[2]) && mode == 
>>> MAL) {
>>> +                                   if (mode==MAL ||debugMode() ){
>>>                                             strcpy(line, line + 1);
>>>                                             break;
>>>                                     }
>> This is the only part of the checkin that has merit, except a comment
>> that the line with ? is sent to the server might be useful.
>>
>>> @@ -1756,7 +1767,8 @@
>>>  
>>>     /* default formatter depends on whether we're interactive */
>>>     if (formatter == NOformatter)
>>> -           formatter = interactive && interactive_stdin && mode != XQUERY 
>>> ? TABLEformatter : RAWformatter;
>>> +           formatter = interactive && interactive_stdin && mode != XQUERY ?
>>> +           (mode==MAL?RAWformatter: TABLEformatter) : RAWformatter;
>>>  
>>>     if (command) {
>>>             /* execute from command-line */
>>>
>>>
>> If you really insist that in MAL mode the default should be RAW, then
>> write it like this:
>>
>> formatter = interactive && interactive_stdin && mode != XQUERY && mode
>> != MAL ? TABLEformatter : RAWformatter;
>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems?  Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>> _______________________________________________
>>> Monetdb-checkins mailing list
>>> [EMAIL PROTECTED]
>>> https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Monetdb-checkins mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Monetdb-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/monetdb-developers


-- 
Sjoerd Mullender

Attachment: signature.asc
Description: OpenPGP digital signature

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Monetdb-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-developers

Reply via email to