开云体育

In 2019 I changed functionLabels and soundlabels from fixed-length arrays to HashMaps to allow for planned expansions. But I forgot to update "locomotive-config.xsd" to reflect the changes.

As a result, direct XML validation of roster.xml will fail if any ESU Generation 5 decoders are in the current roster. But everything works fine.

It seemed to do so automatically I see no errors on the pages.

I have another BLI Heavy Pacific I used rolling thunder (prolly should of used steam) and all function names are blank on throttle. They do have the same functions is there a way to change the decoder type?

On 12 May 2020, at 9:00 AM, Dave Heap via groups.io <dgheap@...> wrote:

I'm not seeing this problem at all with HEAD of Master.

Sound Labels 33 and 34 are valid in the code, needed for the decoder definition and are loading fine for me. I can't see where the schema error is happening.

开云体育

I'm worried if I upgrade jmri with that error I would get a blank roster due to that error. Can't I just modify the XML file to remove that entry?

On Mon, May 11, 2020, 10:16 AM Bob Jacobsen <rgj1927@...> wrote:

Thanks.? It’s saying that the num field in the sound label description can only go to 28, and it found 33? (not a particularly clear message though).

That check happens as the file is read, before the rest of the code processes it.? If 33 is actually something that the rest of the code can handle, you can run the jython/TurnOffXmlValidation.py script in the JMRI startup options. That’ll turn off this check.

I don’t know whether that 33 value will cause downstream problems, though.

开云体育

Thank you Dan,

Certainly the wrong rabbit hole was what i followed.

My apologies.

Cliff

Variable length data records in CSV files are somewhat common, if not universally so. I am not a Java programmer but I have been involved with computers and software for longer than I would like to admit.

It is likely that the major changes involving the change to the JAVA CSV library now distributed with JMRI, effective with version 4.19.3 (as of 2020-01-28) has caused some problems in transition.

In a script that I wrote for Sam that use the previously available library, variable length data records were allowed. Non-trivial changes had to be made to accommodate the new library.

On Sun, May 10, 2020 at 02:38 PM, Dan Boudreau wrote:

The code has been modified by one of the other JMRI programmers, and is a bit broken.? I found that I could import his files if I added 10 extra commas to each line.? The original code accepted variable length input fields, but now the code is hardwired to search and expect 18 fields.

But it took me several hours to find and verify that any legacy data files with variable length data records, could still be read with the modified script.

In part, some of the original script looked like:

import com.csvreader        # Allow us to read CSV formatted text files
# http://javacsv.sourceforge.net/com/csvreader/CsvReader.html 
~ ~ ~
class ManageTurnoutListeners(jmri.jmrit.automat.AbstractAutomaton):
~ ~ ~
    def ReadTurnoutFile ( 
                self,
                turnoutFileName
            ) :
        # https://docs.oracle.com/javase/7/docs/api/java/io/File.html
        tempInputFile = java.io.File(turnoutFileName)
~ ~ ~
        # Check if file exists
        if tempInputFile.exists() :
            # It does, so load it
            tempCsvFileReader = com.csvreader.CsvReader( turnoutFileName )

            # Read the headers
            tempCsvFileReader.readHeaders()
~ ~ ~
            while (tempCsvFileReader.readRecord()):

                # Read the record details
                ColumnCount = tempCsvFileReader.getColumnCount()

But the similar snippet in the revised script indicates what eventuality passed for the no longer available getColumnCount() function.

import org.apache.commons.csv   # Read CSV formatted text files  Updated for 4.19.3ish
###!    http://commons.apache.org/proper/commons-csv/user-guide.html
~ ~ ~
class ManageTurnoutListeners(jmri.jmrit.automat.AbstractAutomaton):
~ ~ ~
    def ReadTurnoutFile ( 
                self,
                turnoutFileName
            ) :
        # https://docs.oracle.com/javase/7/docs/api/java/io/File.html
        tempInputFile = java.io.File(turnoutFileName)
~ ~ ~
        # Check if file exists
        if tempInputFile.exists() :
            # It does, so load it
            ###!   https://commons.apache.org/proper/commons-csv/apidocs/org/apache/commons/csv/CSVParser.html 
            tempCSVParser = org.apache.commons.csv.CSVParser.parse(
                        tempInputFile, 
                        java.nio.charset.StandardCharsets.UTF_8, 
                        org.apache.commons.csv.CSVFormat.DEFAULT.withFirstRecordAsHeader().withCommentMarker('#')
                    )
~ ~ ~
            ###! tempCsvFileReader.readHeaders()
            ###! https://commons.apache.org/proper/commons-csv/apidocs/org/apache/commons/csv/CSVRecord.html
            for record in tempCSVParser.getRecords():
                # Type ( record ) == List
~ ~ ~
                # Read the record details
                ###! ColumnCount = tempCsvFileReader.getColumnCount()
                ColumnCount = record.size()

As is evident, with the org.apache.commons.csv library, the script code that eventually did provide the record column count was a bit more convoluted than I would have preferred.

Perhaps some similar revision to the Java code that reads CSV files could also be considered.

Both versions of the script were uploaded to either the Files/ProblemsBeingWorkedOn or else the Files/Script Examples folder at one time but are not there now. If requested, a new copy could be uploaded. The revised script contains a lot of comments as to what was changed for the new library.

This note got too long.

Cliff in Baja SoCal