Web REPL frozen by single token expressions.

[pygy]

On OS X 10.6.8, 32-bi CPU.

After launching launch-server, the web UI works fine and you get the julia> prompt. However, if you try to evaluate an expression, you don't get any answer. If you reload the page, or try to open another one, it takes ages to get past the <initializing> stage. You can still change the color theme.

The activity of julia-server shoots even higher than reportred in #300 (~ one full core).

I get the following error at the console:

2012-02-20 15:37:20: (network_writev.c.115) writev failed: Socket is not connected 6

[ViralBShah]

@boyers would you be able to look into this?

[ViralBShah]

Would this have anything to do with the firewall on OS X, in case it is enabled?

[BinarySplit]

I'm running the latest Git source(3c3e0ae) on a Kubuntu machine.
Expressions and function calls work correctly for me; but, if I hit enter after only typing a single word, number, etc. then it freezes.
Examples:

julia> 1+2         #works correctly
julia> 1           #freezes
julia> +1          #works correctly
julia> 2b          #works correctly(assuming b is defined)
julia> b           #freezes(regardless of whether b is defined)
julia> Array     #freezes

It appears that if there is only a single "token", the web interface will freeze. Reloading the page fixes it(after about 5 seconds of ).

[ViralBShah]

Yes, just putting the single token makes it freeze for me too.

[pygy]

That's what I'm experiencing too, actually.

Since the most simple test didn't work, I didn't investigate more complex ones.

[ViralBShah]

The more complex stuff works. Sigh.

-viral

On 21-Feb-2012, at 5:14 PM, pygy wrote:

That's what I'm experiencing too, actually.

Since the most simple test didn't work, I didn't investigate more complex ones.

---

Reply to this email directly or view it on GitHub:
#416 (comment)

[6e441f9c]

Hm, the bug seems to be quite obvious after a few debugging statements added... Single-token expr gets parsed to this token, not to a full Expr structure, so 1.head leads to an error.

[6e441f9c]

--- ui/webserver/julia_web_base.jl      2012-04-11 13:49:40.840746107 +0400
+++ ui/webserver/julia_web_base.jl      2012-04-11 13:49:41.840746107 +0400
@@ -127,13 +127,15 @@
             end
             __all_nothing = false

+            __expr_multitoken = isa(__expr, Expr)
+            
             # stop now if there was a parsing error
-            if __expr.head == :error
+            if __expr_multitoken && __expr.head == :error
                 return __write_message(__Message(__MSG_OUTPUT_PARSE_ERROR, {__expr.args[1]}))
             end

             # if the expression was incomplete, just keep going
-            if __expr.head == :continue
+            if __expr_multitoken && __expr.head == :continue
                 continue
             end

[StefanKarpinski]

Ah, nice catch. Can you make a pull request?

[6e441f9c]

I know Git exactly enough to hate it... Isn't it quicker to just apply the patch in this case? Looks like a trivial typo-fix, not worth a review or pull request or attribution or anything.

[StefanKarpinski]

I guess, but in general that makes me do more work so that you can do less work, which doesn't scale very well since there are more contributors to open source projects than there are maintainers.

[StefanKarpinski]

Also, this isn't even a valid patch fragment because the first line of the diff is missing, meaning that git and patch won't accept it. This makes it even more work for me: I either have to try to reconstruct the missing diff line in such a manner that git/patch will accept it, or I have to make the edit by hand, which although not terribly difficult in this case is tedious and error-prone.

[6e441f9c]

It was a correct "patch" patch, just not a "git patch" patch.

Created a fork, I guess I will do a few things where creating pull request is less work than the code itself sooner or later.

[StefanKarpinski]

Git's not so bad, even after just a little experience using it. And having a powerful distributed version control system completely changes the way you work after you get used to it. Your patch is much appreciated in any case.

[6e441f9c]

I have used Bazaar, Mercurial, Monotone, Subversion and Git. I am keeping an eye on Veracity (just in case) and Fossil. Of all those, I hate only Git.

[StefanKarpinski]

Ah, well, in that case, I'm sure you have your reasons. I've tried all of those too — and Git is by far my favorite.

[stepchowfun]

Nice! This bug randomly cropped up a few months ago -- I'm guessing that parse_input_line used to return an expression or nothing, and it was modified to also return single tokens.