This site requires JavaScript, please enable it in your browser!
Greenfoot back
MrBradley
MrBradley wrote ...

2017/6/28

Greenfoor 3.1 (possible) parsing error in (BlueJ) editor

MrBradley MrBradley

2017/6/28

#
Davin, This is the follow up from the old post where I received a project error when loading a project that contained syntax errors. (https://www.greenfoot.org/topics/58201) I have been using the generic version of the install. The error may be related to the delay I see when creating a new class from the GF UI, where the class stays "grey" for quite some time. Here is some sample code to assist with debugging:
/**
 * Intersection represents the intersection of a street and avenue.
 * It can also be referred to as a corner, as in the corner of 3rd street and 2nd avenue.
 * 
 * @author Mr Bradley 
 * @version 2017-06-28
 * 
 * This is a good example class for students to create.
 */
public class Intersection  
{
    public int street;
    public int avenue;
    
    public Intersection()
    {
        street = 1;
        avenue = 1;
    }
    
    public Intersection( int aStreet, int anAvenue )
    {
        street = aStreet;
        avenue = anAvenue;
    }
    
    public boolean isInWorld()
    {
        
    }
    
    public static final Intersection ORIGIN = new Intersection( 1, 1 );
    
    /**
     * calculates the "move" distance between two locations 
     *              street1, avenue1  & street2, avenue2 
     */
    public static int distance( int street1, int avenue1, int street2, int avenue 2 )
    {
        int streetDiff = Math.abs( street1 - street2 );
        int avenueDiff = Math.abs( avenue1 - avenue2 );
        int moveDistance = streetDiff + avenueDiff;
        return moveDistance;
    }
}
The error occurred when typing in the code by hand, when sometimes the BlueJ parser may not be able to keep up with the typer. You will note the following syntax errors in the file: Line 29 ( the parser does not catch this as the an error ); and Line 38 where the identifier (avenue 2) has a space. Also note that just following line 37, the editor starts renumbering the lines at 28. (This is may be actual java code line 28 omitting comments). This version was cut&pasted into the editor. When originally creating the file by hand no errors were detected by the parser, including Line 38. I have attempted to include an image of the file in the GF editor below: Editor Image I hope this helps narrow down the issue for you. Sorry for the delay in getting an example source to you. Please inform me if you can duplicate (and resolve) the issue. ADDENDUM: I have also noticed that the BlueJ can get confused when changing method signatures (say adding a parameter), where the state of the code in not consistent until both Server and Client updates are made. Yet once this is completed the source files remain greyed and further editing does not trigger a compile. The only work around is to close GF and reload the project. I would consider this fairly important as many beginner students can get frustrated with tracking down their "error". Is there a way to force a recompile without having to close GF? Mr. Bradley
davmac davmac

2017/6/29

#
Hi Richard, I think by syntax error on line 29 you mean that there is no return statement in the method? This is actually a semantic error, not a syntax error, and that's why it's not shown: the compiler reports the syntax errors (occurring later in the file, eg lines 38) and does not perform a semantic analysis, so it does not find the semantic errors. (These errors are reported by the Java compiler from the JDK, not actually the parser in Greenfoot). The line renumbering after line 37 is actually a visual illusion resulting from the red error background. If you look very closely you'll see that what looks like 28 is actually 38 and so on. So, I think the numbering is correct. (We are changing the font for the next Greenfoot version which will hopefully make the line numbering easier to read). If I type the class in by hand starting from an empty editor window, it does appear to show the errors as I type (even the missing return which it flags on line 30, though that is removed when the later syntax error is introduced). So it seems I'm not able to reproduce this. In general to reproduce this kind of problem we really need some step-by-step instructions - along the lines of paste the following into an editor, put the cursor on line 53 and type "public int x = 4;", you will then see the following problem: (etc) - the chances are if you can't reliably reproduce a problem, then I won't be able to either. (If you still happen to have the code you referred to in the previous post which reliably generated an error in the debug log, for instance, that would be extremely useful for us!) Thanks, Davin
MrBradley MrBradley

2017/6/29

#
Davin, Yes your response makes sense. It seems to me that many of the odd behaviours I see in GF3.1 present themselves in very difficult to reproduce manners. I work with students to resolve their "errors" in class and 99% of the time restarting GF resolves the issue. This seems to indicate some internal state error is occurring. My concern is for the the students: the time spent unable to determine why their code/GF is broken, and the increasing level of frustration they can experience trying to resolve it. (Some of our younger students are in grades 6/7.) The original code base resulting in the project error is fairly large and I have updated it significantly. My approach to posts is to create small isolated examples that highlight the issue, independent of the original work. I do this to avoid long discussions (education) on my code base. I am teaching a summer java course and am "biting the bullet" with using GF3.1. It is a large class and should be a good indicator of whether or not we should use GF3.1 in the regular school year. Also, and this is just a hunch, when there are co-dependencies across source files (the server/client addendum mentioned above) how goes GF/BlueJ determine it needs to recompile the other file? Current file compiles are triggered by moving off of the line. If there is a semantic error that prevents that file from compiling, the co-dependent file will also remain uncompiled and out of synch. I will continue to keep an eye out for these issues and look for a chance to more consistently reproduce the issues. Thanks for your support.
davmac davmac

2017/6/29

#
My concern is for the the students: the time spent unable to determine why their code/GF is broken, and the increasing level of frustration they can experience trying to resolve it.
Understood. We have some fixes scheduled for the next release of Greenfoot, but that won't be available for some time I'm afraid. I'm sure there are some glitches and restarting Greenfoot is usually the best solution. However, to actually fix problems we need to be able to reproduce them (and this is often difficult).
Also, and this is just a hunch, when there are co-dependencies across source files (the server/client addendum mentioned above) how goes GF/BlueJ determine it needs to recompile the other file?
The parser detects dependencies, so if one file is changed (becomes uncompiled) its dependents are also marked as uncompiled. It won't be possible to compile a file with a dependency which contains an error (even though no error may be shown in the dependent file) - that's a natural result of the dependency and is a case of Greenfoot "working as intended" though I can see how it might cause confusion for users (I'll file a note in our task tracker to see if we can improve the user feedback in this case). Certainly let us know if you find an issue that you can reproduce. Finding a way to reproduce a bug is really invaluable to us. Thanks.
MrBradley MrBradley

2017/6/29

#
You bet. Is there a way to turn off auto-compile? The reason I ask is because toggling it off/on should have the same effect as restarting GF.
MrBradley MrBradley

2017/6/29

#
By the way, I wanted to let you know that we get a tremendous amount of value from using GF. We use it to teach beginner though to advanced programming concepts (including AP Computer Science). I have recently been successful in introducing concurrency topics into our classes and GF Scenarios. It is extremely valuable to be able to visualize concepts to our students. Many thanks to you and the rest of the GF team!
davmac davmac

2017/6/29

#
You bet. Is there a way to turn off auto-compile? The reason I ask is because toggling it off/on should have the same effect as restarting GF.
There's no way to turn off auto-compile. But there must be a misunderstanding here (I may have explained badly) - toggling compilation on/off should in no way be the same as restarting Greenfoot. Thanks for your words. It's great to know that Greenfoot is being used effectively (although I wish we could clear up these issues you/your students seem to be having).
You need to login to post a reply.