KRL_FGETS

So... has anyone been able to get "krl_fgets" to work, reading strings from text files? At the moment, I'm stumped.

(it doesn't help that the manual is blatantly incorrect in several places, either...)

So, I've tried multiple different things. My original text file lacked any special separator, and I kept getting an error that my buffer string (chFileLine[]) had an invalid character 'H0D'. The original version of my text file was DOS-style, with Carriage Return ('H0D') and Line Feed ('H0A') terminating each line. Since the krl_fgets is based on the classic Unix fgets, I took this to mean that the CR was causing my troubles, and I changed my text file to Unix-type line termination, with only LF at the end of each line.

But, I still kept getting the invalid-character errors. So I added the ';' characters as separators, and changed my Separator value to match the ASCII value of ';'. Still no dice.

Then, I tried doing away with the separator and line-end characters entirely -- I reformatted the entire ASCII file so that each line would be identical length (using leading 0s), and set the character limit to end one character before the fgets would reach either the ';' or the LF. The "invalid character" message changed to complaining that the invalid character was 'H00' (or 0x0, but that's the same thing).

Still no good.

So then, I tried changing the character limit to 10, which is much smaller than the line length. And I still get the "Invalid character 0x0" message, but the message says that the location of the invalid character is chFileLine[10]. Then I tried changing the limit value, and basically found that whatever I set the character limit to, I will get an "invalid character 0x0" error for that character in the chFileLine string.

Along the way, I also tried things like clearing the chFileLine string, not clearing it, deliberately setting it in advance to various ASCII strings... I can definitely say that there are no Null (0x0) characters in that string when that message comes up, and the CWRITE is emphatically not making any changes to the string (which I've tried as both a static and runtime variable).

At the moment, I'm just... stumped. The file is definitely opening successfully (I have a separate subroutine for that) and I'm getting a good handle for it (and the Close works properly on that handle), and I've had lots of success opening text files and writing to them. The text file is located in /KRC/ROBOTER/USERFILES, just as it should be. I'm not even getting to the SWRITE parsing yet. I simply cannot figure out what this thing is complaining about.

As for errors in the manual:
1. The Separator argument is listed as being "optional" -- it's not. Leaving it off generates a STATE.MSG_NO of -10 (incorrect number of arguments passed) without fail
2. The Separator argument is shown as being type CHAR. It's not. Unless it's declared as INT (and it must be a variable, not an explicit value), MSG_NO -12 results (wrong data type). And my best guess is that it has to be set to the ASCII value of the separator character, but there's no way to be certain as yet.
3. Maybe not an error? No mention is made of how fgets handles Unix line terminators vs DOS line terminators. My original suspicion was that the DOS-type terminators were causing issues, but I can't test that theory yet.

Trying that...

Ow, what a chore. And now SWREAD is being buggy about parsing the bloody strings.

And, it looks like "krl_feof" doesn't actually detect the end of the file -- another thing that directly contradicts the manual. In fact, "krl_feof" sets the Boolean False invariably, regardless of whether the end of the file has been hit or not.

The silver lining is, I can check STATE.MSG_NO after "krl_fgetc" and get what appears to be a reliable, non-stopping check of whether I've hit the end of the file. So there's that much, at least.

Thanks, Panic, I'll give that a shot.

(edit)

Hey, how did you get fgets to work with your separator shown as an explicit ";" character? When I tried that, I got a "not a variable" error first from CWRITE, then once I changed it to a CHAR in the DAT file and tried to use it, I got a "wrong variable type" error. The only thing I found that got me past those errors was making it an Integer ASCII equivalent.

Okay, for a while there, I thought I was losing my marbles.

I put your program into my robot, changed the FOPEN to point at my test file, and it ran perfectly. I changed my test program to use FGETS again, and it failed utterly. And, as I said before, I could not put anything in as my Separator except an Integer variable. It was nuts.

Until I put your CWRITE and my CWRITE up against the wall... I mean, against each other:

cwrite ($FCT_CALL, s, m, "krl_fgets", h ,Buff[] ,87 ,Read, ";")
CWRITE ($FCT_CALL, State, _Mode, "krl_fgets", nFileHandle, chFileLine[],100, nSeparator)

Your CWRITE has one more argument than mine does. Where does that '87' come from? Your CWRITE has 9 arguments, where mine (and the manual) only show 8.
Anyway, this should get me past the FGETS issue. Now I just have to get past the SREAD parsing issue....

(edit)

So, of course it turns out that my copy of the CWRITE manual was outdated. Anyway, thanks, Panic, you saved my bacon.

(note to self, tell Werner this forum needs a bacon emoji....)

Yeah, I downloaded your newer version of the manual, which showed what I was doing wrong. But there's still some odd stuff happening.

So, if my Buff[] string is declared in the DAT file, CWRITE always fails with a "invalid character" error, pointing at the first EOL character of the line in the text file. Changing the Buff[] variable to a runtime variable fixed that, but only insofar as CWRITE failed "silently", without crashing the program, but still gave me a STATE.MSG_NO of -11: "At least one function parameter has an invalid value."

At this point, this is what my CWRITE and yours look like:
cwrite ($FCT_CALL, s, m, "krl_fgets", h, Buff[], 87, Read, ";")
CWRITE ($FCT_CALL, State, _Mode, "krl_fgets", nFileHandle, _chFileLine[], 100, nLineLength, ";")

The only differences left between your code and mine (aside from the variable names) is that my nLineLength and State are declared in the .DAT file with initial values, so I can monitor them in the VarCor. I'll try changing that next. But seriously, if this function is going to treat runtime and retentive variables differently... WTF?

Nope. No go. I have officially hit the end of my rope. There is literally no functional difference between your code and mine that I can see, but the CWRITE gives me nothing but "At least one function parameter has an invalid value." I dunno, maybe I've just gone pie-eyed from staring at this code all day.

&ACCESS RVP
&REL 86
&PARAM DISKPATH = KRC:\R1\Program\Test Programs
DEF ReadLineTest ( )

  DECL INT      _nLineIndex, _nOffset, _nStringLimit, _nLineLength, _nColumnIndex, _nASCII, _nFileHandle
  DECL MODUS_T _Mode
  DECL CHAR    _chFileChar, _chFileLine[100]
  DECL STATE_T _State

  bEOF = FALSE
  _nLineLength = 1

  _nStringLimit = STRDECLLEN (_chFileLine[])
  WAIT FOR STRCLEAR (_chFileLine[])

  _nFileHandle = 0
  FileOpen("ArrayRead.txt", "r", _nFileHandle)

  IF (_nFileHandle <> 0) THEN

    _nLineIndex = 1
    _nColumnIndex = 1
    FOR _nColumnIndex = 1 TO STRDECLLEN (_chFileLine[])
      _chFileLine[_nColumnIndex] = " "
    ENDFOR

    WHILE NOT bEOF

     CWRITE ($FCT_CALL, _State, _Mode, "krl_fgets", _nFileHandle, _chFileLine[], 100, _nLineLength, ";")
     MsgNotify ("FGETS STATE.MSG_NO %1", "ReadLineTest", _State.MSG_NO)

      SWITCH _State.MSG_NO
      CASE 0


         _nASCII = _chFileChar

         SWITCH _nASCII
         CASE nSeparator
          ;Parse line into array
          _nOffset = 0
          ;SREAD (_chFileLine[], _State,_nOffset, "%g", ArrayVal[1,_nLineIndex].X)
          Increment (_nLineIndex)
          _nColumnIndex = 1


        CASE nLineFeed, nCarriageReturn
          ; Do nothing, keep reading
          ;until next valid char


        DEFAULT
          ; Get next character and append to line
          _chFileLine[_nColumnIndex] = _chFileChar
          Increment (_nColumnIndex)

        ENDSWITCH

      CASE -4
        bEOF = TRUE
        halt


      DEFAULT

        CWRITE ($FCT_CALL, _State, _Mode, "krl_fclose", _nFileHandle)
        bEOF = TRUE

      ENDSWITCH 
beof = true      

    ENDWHILE

    CWRITE ($FCT_CALL, _State, _Mode, "krl_fclose", _nFileHandle)

  ELSE

    HALT

  ENDIF

END

Well, the FileOpen and FileClose subroutines are stuff I've got in my standard library of support functions, and they've been in production use for a year+ without any issues. And the STATE.MSG_NO I get from CWRITE (note the MsgNotify) isn't -3 (no file open), but -11 (at least one function parameter has an invalid value). Back when I had STATE decl'd as a retentive in the DAT file, I kept it open in the VarCor while I single-stepped through. On those occasions when the file didn't open, the error-handling caught it and skipped past the FGETS cleanly.

Also, when I brute-forced it by replacing the FGETS with FGETC and concatenating, everything worked almost perfectly. I'm just trying to avoid the extra time cost -- I've got some huge arrays to load, so huge that I can't keep them all in KRC RAM simultaneously.

Yeah, the CWRITEs (at least using $FCT_CALL) seem to be really fussy about the variables. The buffer string can't be empty, you need to put something in it -- if you empty it with an STRCLEAR, the CWRITE appears to reject it (note: I haven't tested this exhaustively).

I've also seen what appears to be issues with using static .DAT file variables as compared to identically-declared runtime variables. But again, I haven't tested this exhaustively.

Also, avoid the mistake I made upthread and avoid the KSS 8.2 CWRITE/CREAD manual -- it's wrong for 8.3+.

We've been sharing some working test code over in the CWRITE thread this week that you may find handy.