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 Monetdb-checkins@lists.sourceforge.net 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 Monetdb-checkins@lists.sourceforge.net 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 Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
-- Sjoerd Mullender