Emu48 Edit a CSV File

[rprosperi]

(01-09-2022 08:39 PM)MNH Wrote:  

(01-09-2022 02:34 PM)DavidM Wrote:  SL3: Source string
SL2: Target string to be replaced
SL1: Replacement text that takes the place of target

targ: the text which will end up being replaced in the source string
new: the replacement text for each target encountered
len: the length of the target text (not the length of the source text)

The stack arguments, SL1 through SL3, don't correspond with the local variables targ, new, and len.
I think my problem is that I don't know, or are confused by, what should be on the stack to make REPLS work. I executed REPLS, and the program didn't remove the line feed character from the first extracted string. Also, the program ended up in an infinite loop.

To expand a bit on David's comments:

SL1 means Stack Level 1 - this should be the new text to replace the target string

SL2 means Stack Level 2 - this should be the text which is to be replaced

SL3 means Stack Level 3 - this should be the original string

In order to replace a line feed in the original string, use 10 (the ASCII code for LF) for SL2.

[DavidM]

(01-09-2022 07:16 PM)Giuseppe Donnini Wrote:  Not true, the C$ $ method uses all of the remaining characters following "C$ $ ", including linefeeds, tabs, spaces, control characters, escape characters, whatever. If you happen to use it while entering a program, it will include everything from that point on, even the closing guillemet. It is therefore only useful for entering a single string object.

Thanks for the correction, Giuseppe! I'm not sure why I was under the wrong impression with that version of C$.

I've never had a reason to use the "C$ $ ..." form of the command. I'm sure I would have seen the error of my ways very quickly if I had. :-)

[DavidM]

(01-09-2022 08:39 PM)MNH Wrote:  

(01-09-2022 02:34 PM)DavidM Wrote:  SL3: Source string
SL2: Target string to be replaced
SL1: Replacement text that takes the place of target

targ: the text which will end up being replaced in the source string
new: the replacement text for each target encountered
len: the length of the target text (not the length of the source text)

The stack arguments, SL1 through SL3, don't correspond with the local variables targ, new, and len.

You are correct, and it is intentional. There's no reason the stack arguments for REPLS have to be the same as the local variables defined for use within the program.

(01-09-2022 08:39 PM)MNH Wrote:  I think my problem is that I don't know, or are confused by, what should be on the stack to make REPLS work. I executed REPLS, and the program didn't remove the line feed character from the first extracted string. Also, the program ended up in an infinite loop.

Rather than responding with a lengthy line-by-line breakdown of how REPLS works (which I started to do and subsequently closed the window by accident before posting :-) ), I'd recommend that you actually step through the code and watch how it operates. Two possible ways to do this:

1) Place some simple arguments on the stack (I'd suggest "ABCDE" "BCD" "X" as a first attempt)
2) Put 'REPLS' on the stack (single quotes required)
3) Execute DBUG by navigating to PRG -> NXT -> RUN -> DBUG and pressing "DBUG"
4) Step through the code with SST to watch how it loads the stack and proceeds

-or-

1) Place 41 MENU HALT at the beginning of REPLS.
2) Place some simple arguments on the stack (I'd suggest "ABCDE" "BCD" "X" as a first attempt)
3) Execute REPLS
4) Step through the code with SST to watch how it loads the stack and proceeds

Make sure that you are actually passing strings to REPLS, not variables which contain strings. That might be one issue you are running into.

If you have truly found a combination of string arguments passed to REPLS that results in an infinite loop, please post an example so that the code can be fixed to accommodate that situation.

[DavidM]

(01-08-2022 07:41 PM)MNH Wrote:  Please note that all substrings will not be of equal lengths, because some coordinate pairs will have point numbers containing 1 to 5 digits. Also, an actual coordinate file will be in the form of P,N,E,Z,D (e.g., 208,1531217.411,520676.455,98.393,IRC 1/2 LB 6300) where:

P is the point number
N is the northing
E is the easting
Z is the elevation
D is the description

Does your final list need to have all of the fields present? Or just some?

One possible way to do this would be to convert every field to a string in a first pass, then extract only the needed fields while converting to numeric objects. It would be easier to show with some real data.

Would you be able to post a complete example of the "FILE" string that contains real data for experimentation?

[MNH]

(01-14-2022 04:25 PM)DavidM Wrote:  Does your final list need to have all of the fields present? Or just some?

My immediate needs require only the first three fields. My future needs will require all five fields.

Quote:Would you be able to post a complete example of the "FILE" string that contains real data for experimentation?

Please see the attached file. It's a contiguous piece of a real CSV file from a project that we're doing. Our data collector, a Topcon FC-5000, stores spatial data as a CSV file. I've been busy, so I haven't kept up with this thread. Again, thank you for your help!

[MNH]

Knowing how many points (point strings, actually) there are in advance and using a definite loop structure eliminates the need to handle a missing line feed character at the end of the last point string. Please note that the PNTS variable is a list of point numbers. The local variable pnezd is called after the definite loop ends so the user can check the output. I renamed the program to CSVO. Kindly test it on your Emu48.

Program: CSVO
Checksum: # D830h
Size: 247 bytes
Purpose: Remove line feed characters from a CSV file.

Code:


\<< FILE DUP SIZE 10
 CHR 1 PNTS SIZE { }
 \-> file size lf
 start numpnts pnezd
  \<< 1 numpnts
    START file DUP
 DUP lf POS DUP 2 -
 ROT start ROT SUB
 pnezd SWAP +
 'pnezd' STO 1 +
 size SUB 'file' STO
    NEXT pnezd
  \>>
\>>

This is the contents of the PNTS variable.

{ 101 102 103 104
105 106 107 108 109
}

Please see the attached file so you can load it in your Emu48 and store it in a variable named FILE.