You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Generally, in-place update for formatted files does not make a lot of sense. Performing an update as opposed to re-write is a performance issue and using ascii instead of binary is not performant. However, currently the use may be mislead to think that update does work for formatted files and get a NotImplmentedError.
The current issue with updating an entry in a formatted file is getting the whitespace correct. The reader treats whitespace as a separator of tokens, and there can be any amount of space between tokens. In reality, the whitespace in ecl files have a fixed length, which is what enables us to do an update.
The way the reader handles whitespace makes our implementation flexible in case any file should ever be generated with a more looser definition of how many spaces are allowed. However, it means we cannot simply call ecl_data_io._formatted.write.py::write_entry.py from ecl_data_io._formatted.read.py::update as self.start might not be pointing at the position where we want to start writing whitespace. This may be resolved by changing the reader so that self.start points at position directly after the last non-whitespace character of the previous entry.
The text was updated successfully, but these errors were encountered:
Generally, in-place update for formatted files does not make a lot of sense. Performing an update as opposed to re-write is a performance issue and using ascii instead of binary is not performant. However, currently the use may be mislead to think that update does work for formatted files and get a
NotImplmentedError
.https://github.com/equinor/ecl-data-io/blob/e2465b4e7c9e39cf59a9342fb547e76b4117ba56/src/ecl_data_io/_formatted/read.py#L42
The current issue with updating an entry in a formatted file is getting the whitespace correct. The reader treats whitespace as a separator of tokens, and there can be any amount of space between tokens. In reality, the whitespace in ecl files have a fixed length, which is what enables us to do an update.
The way the reader handles whitespace makes our implementation flexible in case any file should ever be generated with a more looser definition of how many spaces are allowed. However, it means we cannot simply call
ecl_data_io._formatted.write.py::write_entry.py
fromecl_data_io._formatted.read.py::update
asself.start
might not be pointing at the position where we want to start writing whitespace. This may be resolved by changing the reader so thatself.start
points at position directly after the last non-whitespace character of the previous entry.The text was updated successfully, but these errors were encountered: