Skip to content

syntax errors on linux system #196

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

Closed
jerryneedell opened this issue Aug 20, 2017 · 10 comments
Closed

syntax errors on linux system #196

jerryneedell opened this issue Aug 20, 2017 · 10 comments
Assignees
Milestone

Comments

@jerryneedell
Copy link
Collaborator

jerryneedell commented Aug 20, 2017

I have been seeing the same issue discussed in Issue #111

on a linux (Ubuntu 16.04 on a Mac Mini box) system. Since #111 focused on the Windows platform, it was recommended that a new issue be opened for linux.

What I have found is the when editing and saving a file on the circuitPython device, I often get a "syntax error" the first time I try to execute the saved script.

With guidance from @dhalbert here are a few consistent observations:
The problem only occurs if sufficient time is not allowed after saving the file and executing it.
It also depends on the editor used to save the file.
Using "gedit" I found that I had to wait ~30 seconds after saving the file before rebooting and executing it to reliably avoid the syntax error. I tried several delay times and found anything less than 30 seconds to be unreliable.
Using "nano" to edit the file, I was unable to cause the error no mater how quickly I rebooted.

One other note is that the problem did not occur at all with a very short (~300 byte) script. This is consistent with the discussion in #111

These tests were executed with CirCuitPython 2.0.0-beta-1.4 on a Metro_M0_Express - with a Jewel(7 Neopixel) connected to D2

Here is an example of the syntax error and the script.

Press any key to enter the REPL. Use CTRL-D to reload.

Adafruit CircuitPython 2.0.0-beta.1-4-gf6a7025 on 2017-08-11; Adafruit Metro M0 Express with samd21g18

import jewel_rainbow
Traceback (most recent call last):
File "", line 1, in
File "jewel_rainbow.py", line 45
SyntaxError: invalid syntax

# Gemma IO demo - NeoPixel
 
from digitalio import *
from board import *
import neopixel
import time
 
pixpin = D2
numpix = 7
 
#led = DigitalInOut(D13)
#led.direction = Direction.OUTPUT
 
strip = neopixel.NeoPixel(pixpin, numpix, brightness=0.3,auto_write=False)
 
 
def wheel(pos):
    # Input a value 0 to 255 to get a color value.
    # The colours are a transition r - g - b - back to r.
    if (pos < 0):
        return (0, 0, 0)
    if (pos > 255):
        return (0, 0, 0)
    if (pos < 85):
        return (int(pos * 3), int(255 - (pos*3)), 0)
    elif (pos < 170):
        pos -= 85
        return (int(255 - pos*3), 0, int(pos*3))
    else:
        pos -= 170
        return (0, int(pos*3), int(255 - pos*3))
 
def rainbow_cycle(wait):
    for j in range(255):
        for i in range(len(strip)):
            idx = int ((i * 256 / len(strip)) + j)
            strip[i] = wheel(idx & 255)
        strip.show()
        time.sleep(wait)
 
try:
    while True:        
        rainbow_cycle(0.001)

except:
    pass

finally:
    for i in range(len(strip)):
        strip[i] = (0,0,0)
    strip.show()
@kwagyeman
Copy link

kwagyeman commented Aug 27, 2017

Hi, if you use the sync command on linux/mac you can get around this issue. However, unless CircuitPython gets a proper IDE it's going to be a problem in general. I have the following code in OpenMV IDE for the OpenMV Cam to fix this:

LINUX

                    bool ok = false;

                    DIR *dirp = opendir(m_portPath.toUtf8().constData());

                    if(dirp)
                    {
                        if(syncfs(dirfd(dirp)) >= 0)
                        {
                            ok = true;
                        }

                        if(closedir(dirp) < 0)
                        {
                            ok = false;
                        }
                    }

                    if(!ok)
                    {
                        QMessageBox::critical(Core::ICore::dialogParent(),
                            tr("Disconnect"),
                            tr("Failed to eject \"%L1\"!").arg(m_portPath));
                    }

MAC

                    if(sync_volume_np(m_portPath.toUtf8().constData(), SYNC_VOLUME_FULLSYNC | SYNC_VOLUME_WAIT) < 0)
                    {
                        QMessageBox::critical(Core::ICore::dialogParent(),
                            tr("Disconnect"),
                            tr("Failed to eject \"%L1\"!").arg(m_portPath));
                    }

@tannewt
Copy link
Member

tannewt commented Sep 6, 2017

I think this problem is plaguing Rosie CI as well. I added something that should monitor the flush through the kernel block device stat but its still having issues.

@jerryneedell do you feel that is new post-1.0?

@tannewt tannewt added this to the 3.0 milestone Sep 6, 2017
@jerryneedell
Copy link
Collaborator Author

jerryneedell commented Sep 6, 2017

@tannewt I had not experienced this under 1.0.0 but that is not conclusive, since it also depends on whether I used gedit or nano and I can't be sure I exercised it on 1.0.0. I'll try reverting to 1.0.0 and see if it is reproducible there. Hopefully later today.

@jerryneedell
Copy link
Collaborator Author

@tannewt I just reverted to 1.0.0 and I am not able to reduce the problem. I can cause it to occur reliably under 2.0.0 - looks like it is post-1.0.0.

@tannewt
Copy link
Member

tannewt commented Sep 11, 2017

I believe I fixed Rosie by watching for outstanding IO requests. I want to validate that its not using the SPI flash scratch space all the time. That would slow down the IO and perhaps cause trouble. Otherwise, I think its ok CircuitPython-side.

@tannewt
Copy link
Member

tannewt commented Sep 12, 2017

Ok, I checked the SPI flash bus traffic and it looks as I expect. I'm not going to block 2.0 on this.

@tannewt
Copy link
Member

tannewt commented May 14, 2018

Once I revive Rosie I can see if its still an issue there.

@dhalbert dhalbert self-assigned this May 24, 2018
@dhalbert
Copy link
Collaborator

@tannewt does Rosie now working well mean this can be closed? I can't remember why I assigned this to myself.

@tannewt
Copy link
Member

tannewt commented Jun 12, 2018

Yup, sounds good to me.

@dhalbert
Copy link
Collaborator

@jerryneedell Closing for now. I believe this is a general Linux delayed-write problem.

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

No branches or pull requests

4 participants