Do not require new line or ";" at the end of import expression

[yuyichao]

This is the first time I write scheme so it's very likely I've got sth wrong.

julia> :(using A)
:(using A)

julia> :(using A.b, B.c)
:($(Expr(:toplevel, :(using A.b), :(using B.c))))

julia> :(using A: b, c.d)
:($(Expr(:toplevel, :(using A.b), :(using A.c.d))))

julia> :(importall A)
:(importall A)

julia> :(import A.b, C)
:($(Expr(:toplevel, :(import A.b), :(import C))))

Fix #10910
@mlubin
@JeffBezanson

[yuyichao]

Also possible now.

julia> begin using Base end

julia> (using Base)

[yuyichao]

The 64bit windows CI hang on linalg1 again???.......

[tkelman]

The 64bit windows CI hang on linalg1 again???.......

Yeah, it does that occasionally. Suggestions for what to do about that very welcome. Probably related to #7942.

[yuyichao]

@tkelman
It might be helpful to figure out when it is happening and cut down the script to reproduce. That's what I usually do to isolate those gc/crashing issues (which turns out to be pretty efficient, not sure how much that apply to a not so reproducible hanging issue though)....

It might also be good to do a few finish after attaching gdb to figure out which function is hanging. I've got lucky when debuging similar issues (on other projects) before to isolate it to a single function that I can examine it's internal state to figure out why it gets into an infinite loop.

[JeffBezanson]

I'm not sure this really counts as a test of the parser; it only tests that the parse function does the same thing as the parser used to read source files. You have to examine the parsed expression in some other way.

[yuyichao]

On May 22, 2015 12:00 PM, "Jeff Bezanson" notifications@github.com wrote:

In test/parser.jl:

@@ -83,3 +83,14 @@ macro test999_str(args...); args; end

issue #10994

@test parse("1 + #= \0 =# 2") == :(1 + 2)
+
+# issue #10910
+@test parse(":(using A)") == :(:(using A))

I'm not sure this really counts as a test of the parser; it only tests
that the parse function does the same thing as the parser used to read
source files. You have to examine the parsed expression in some other way.

I see your point . The original goal is to just make sure it doesn't raise
an error. I guess making the @test actually test sth is better.

—
Reply to this email directly or view it on GitHub.

[yuyichao]

Rebased and updated the test.

[JeffBezanson]

This still doesn't test the parser. If using A were parsed as the number 42, this test would still pass.

[yuyichao]

Updated.
@JeffBezanson
In this case, how do you think about the test in my other PR. In particular, should I rewrite the ones for export the same way I did with using and import ?

[yuyichao]

I saw this CI failure right after my PR is merged. It looks totally unrelated and disappears after another totally unrelated PR but has this appeared somewhere else before?

[JeffBezanson]

I saw the same thing in #11432.

[mbauman]

Yeah, this has been happening sporadically for at least the past month (see https://travis-ci.org/JuliaLang/julia/jobs/60371436). Is there an API to download and/or search through travis' logs?

[yuyichao]

Is there anything wrong with "Worker 6" (Edit: on 64bit) ???

https://travis-ci.org/JuliaLang/julia/jobs/64106038
https://travis-ci.org/JuliaLang/julia/jobs/64163024
https://travis-ci.org/JuliaLang/julia/jobs/60371436

(Edit2: I guess Worker 9 is also involved in one of them...)

[tkelman]

Is there an API to download and/or search through travis' logs?

That's a really good idea. Travis does have an API, see http://docs.travis-ci.com/api/, though I haven't personally used the log-related parts of it.