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
People report all kinds of issues with not being able to send certain kinds of files. The reported problems seem to fall into three categories:
The file picker does not allow the user to select the file, because there's a check on file extension (currently limited to .8xp,.8xg,.8xv,.83p,.83g,.82p,.82g)
ticalc.link does not allow sending the file, with the message "The file you have selected does not seem to be a valid calculator file" (tifiles.isValid(file) returns false)
The file seems to send, but gives an error or doesn't show up on the device
Category 1 and 2 exist to prevent category 3. So the ones in category 3 are bugs, the ones in category 1 and 2 are technically "by design" because the library doesn't support each and every file. But I understand that both are pretty annoying.
Please note that Texas Instruments' file types are not really documented anywhere, so much of this is a dark art. The current file parser code is largely a port of tilibs (https://github.com/debrouxl/tilibs). Fixing exotic parsing issues or adding new file types is therefore not as easy as I'd want it to be.
This issue is here to at least document the different types of problems, collect ideas to solve them and maybe inspire someone (or myself) to fix them 😉
Some file extensions are supported by the parser, but not allowed by the file picker. These can easily be fixed. I do however feel like we need to test each type before we allow them. If you can run ticalc.link locally, you can easily change the list of allowed file types here, and test to see if the file then sends correctly:
I suspect we can probably parse these files (but need to test):
.8xs
.8ca
Other file extensions are not supported by the file parser, so those are basically category 2 problems that are caught in an earlier stage. For those we need additional work on the file parsing (see below).
I suspect these files can't currently be parsed:
.8ek
.b84
.8xk
Solution to category 2 problems
Here's the check that says files are valid or not:
If there are program (.8?p), group (.8?g) or variable (.8?v) files that ticalc-usb says are invalid, but are really valid files for supported calculators, then we probably have a bug in this or related code.
The code that parses files currently (probably) doesn't support files other than program, group or variable files. So the fix for being able to send other files is adding parsing support for additional file types. This would need to be written by someone, and I'm open to contributions 🙂
Solution to category 3 problems
These are almost always bugs. A file should not be loaded and parsed correctly, but not sent properly. I'm not entirely sure how people manage to end up in these states 😄 If people have example files or steps to reproduce the issue, please share them below.
One of these weird issues may be with sending .8xv files (#26). This could be a good place to start work on this category.
The text was updated successfully, but these errors were encountered:
lots of parsers for vartypes are available here: https://github.com/adriweb/tivars_lib_cpp (but then again I'm not sure why you'd want/need to parse the content, just transfer the file if the checksum matches - otherwise warn and offer to fix the checksum then transfer?). This lib can be compiled to wasm.
.b84/.b83 files are just zip files so there are wasm libs to extract them just fine.
The issue
People report all kinds of issues with not being able to send certain kinds of files. The reported problems seem to fall into three categories:
.8xp,.8xg,.8xv,.83p,.83g,.82p,.82g
)tifiles.isValid(file)
returnsfalse
)Category 1 and 2 exist to prevent category 3. So the ones in category 3 are bugs, the ones in category 1 and 2 are technically "by design" because the library doesn't support each and every file. But I understand that both are pretty annoying.
Please note that Texas Instruments' file types are not really documented anywhere, so much of this is a dark art. The current file parser code is largely a port of tilibs (https://github.com/debrouxl/tilibs). Fixing exotic parsing issues or adding new file types is therefore not as easy as I'd want it to be.
This issue is here to at least document the different types of problems, collect ideas to solve them and maybe inspire someone (or myself) to fix them 😉
Related issues
Thank you all for sending these in!
Solution to category 1 problems
Some file extensions are supported by the parser, but not allowed by the file picker. These can easily be fixed. I do however feel like we need to test each type before we allow them. If you can run ticalc.link locally, you can easily change the list of allowed file types here, and test to see if the file then sends correctly:
ticalc.link/src/index.js
Line 103 in eb56999
I suspect we can probably parse these files (but need to test):
.8xs
.8ca
Other file extensions are not supported by the file parser, so those are basically category 2 problems that are caught in an earlier stage. For those we need additional work on the file parsing (see below).
I suspect these files can't currently be parsed:
.8ek
.b84
.8xk
Solution to category 2 problems
Here's the check that says files are valid or not:
https://github.com/Timendus/ticalc-usb/blob/2a0f5e4bae433f5e411faacdd8d6c31d964fb864/src/tifiles.js#L36
If there are program (
.8?p
), group (.8?g
) or variable (.8?v
) files thatticalc-usb
says are invalid, but are really valid files for supported calculators, then we probably have a bug in this or related code.The code that parses files currently (probably) doesn't support files other than program, group or variable files. So the fix for being able to send other files is adding parsing support for additional file types. This would need to be written by someone, and I'm open to contributions 🙂
Solution to category 3 problems
These are almost always bugs. A file should not be loaded and parsed correctly, but not sent properly. I'm not entirely sure how people manage to end up in these states 😄 If people have example files or steps to reproduce the issue, please share them below.
One of these weird issues may be with sending
.8xv
files (#26). This could be a good place to start work on this category.The text was updated successfully, but these errors were encountered: