Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scenes with `#` in description don't load properly #104

Open
scanner-darkly opened this issue Sep 24, 2017 · 8 comments
Open

scenes with `#` in description don't load properly #104

scanner-darkly opened this issue Sep 24, 2017 · 8 comments

Comments

@scanner-darkly
Copy link
Member

@scanner-darkly scanner-darkly commented Sep 24, 2017

if a scene has a # character in the description when such scene is loaded everything after the # will not be read, including all of the scripts.

@burnsauce
Copy link
Contributor

@burnsauce burnsauce commented Sep 28, 2017

Given that # is reserved in the teletype scene file syntax, I presume that the fix should be to disallow # in the scene description?

@samdoshi
Copy link
Collaborator

@samdoshi samdoshi commented Sep 28, 2017

Sounds like that's what we need to do until we rewrite the USB code.

It should be as simple as adding a branch to match # in process_preset_w_keys.

@scanner-darkly
Copy link
Member Author

@scanner-darkly scanner-darkly commented Sep 28, 2017

perhaps a better option would be to allow entering it but replace it with something else at that point (a space?), not just ignore it - otherwise it might look like keyboard is not working, and there is no messaging provided to the user to clarify what's going on.

@cmcavoy
Copy link
Contributor

@cmcavoy cmcavoy commented Oct 1, 2017

I looked for existing C serializer libraries we could leverage. I couldn't find any that seemed usable, but did see mention of using /* */ for comments in this implementation. Could we use an alternate comment format in TT scripts?

It's going to take me a while to understand the constraints around embedded development, but my first idea reading this thread was to leverage an existing serializer, doesn't sound like it's possible here - the embedded world is fun to learn.

@samdoshi
Copy link
Collaborator

@samdoshi samdoshi commented Oct 1, 2017

I think discussions here are being overtaken by discussions at:

https://llllllll.co/t/teletype-firmware-usb-disk-mode-interface/9442

We are currently contemplating switching from a text file format to a binary format.

@jlmitch5
Copy link
Contributor

@jlmitch5 jlmitch5 commented Oct 9, 2017

perhaps a better option would be to allow entering it but replace it with something else at that point (a space?), not just ignore it - otherwise it might look like keyboard is not working, and there is no messaging provided to the user to clarify what's going on.

My guess would be someone would be typing the # key because they are trying to document the script. i.e.:

#1:
foo

#2:
bar

#3:
baz

In that situation I don't really think replacing # with anything would really make sense to the user. My gut is that just not responding to the character press is probably the least invasive action to take pre-changing all the big, serializer changes.

@cmcavoy
Copy link
Contributor

@cmcavoy cmcavoy commented Oct 10, 2017

Can someone point to the serialization / deserialization code? Just curious to see it but have had trouble finding it in the source.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants