julia.readthedocs.org/en/latest search result

[yuyichao]

Ref JuliaLang/julia#11527

The search result in the latest julia doc returns "Python function" instead of Julia function from time to time without any change from julia side.

[yuyichao]

Not meant to push here but just for your information if you'd like to track it down. The search result was good this morning (~7-8 hours ago) and it is showing python functions now.

[agjohnson]

The original issue here was more obvious, it was a failure on our end during the requirements processing stage. However, that issue is no longer present, and the build servers are all running the same environment now.

If we could track this down to a commit or build, that would help. It's showing Julia functions now that I've had a chance to look at it. If you notice constructs labeled as Python in the search, make note of the commit in READTHEDOCS_DATA javascript object on the page.

[yuyichao]

@agjohnson I'll do that. It's sth like the following right? (note that this is a good commit)

READTHEDOCS_DATA.commit
"cd8be5841e5f17aecd47409bc3962d458425b226"

[agjohnson]

Indeed, that way we can pin the issue to a single build, which hopefully surfaces some differences in build output

On Jul 1, 2015, at 4:50 AM, Yichao Yu notifications@github.com wrote:

@agjohnson I'll do that. It's sth like the following right? (note that this is a good commit)

READTHEDOCS_DATA
.commit

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

Anthony Johnson
aj@ohess.org
@agjhnsn

[yuyichao]

READTHEDOCS_DATA.commit
"126b5d41947b96fe1db4a1450fc5c5d4beae5187"

Is bad at this moment.

[yuyichao]

It was good for a while today but it is now bad again.

Current commit

READTHEDOCS_DATA.commit
"2cbb72a0a813c367fd8b03d8d10273d0a429f015"

[yuyichao]

READTHEDOCS_DATA.commit
"2c1ac1814f2b41824f69d827ccc6fc20ea4904aa"

Still bad

[yuyichao]

[yuyichao]

READTHEDOCS_DATA.commit
"59a1e9cac1ded47b08059bff31a4337175cc7a49"

is bad again...

[agjohnson]

Great, this is a good sample set, I'll poke around the associated builds and try to pinpoint where and why this is happening

[yuyichao]

@agjohnson Thanks for looking into this! I might be imagining but it seems less likely to happen around noon EST (i.e. around this time everyday).

[yuyichao]

I just see Python function again when I was searching for fft just now. Commit is

READTHEDOCS_DATA.commit
"e3dfa5678bd801a2f704f491db57c4416856a846"

FWIW, this might be the first time I see a broken one around this time of the day recently....

[agjohnson]

Looked into this a little more, it's happening across all the servers, so there is no correlation between a single server here. I'll keep looking. There are some sphinx errors on overlapping object names, but normally that wouldn't cause anything like what you're seeing

[yuyichao]

FWIW, I just noticed that functions are not the only thing that goes wrong. I was searching blas and it shows up as "Python module"

READTHEDOCS_DATA.commit
"a8e9189176b5f2c592ce576d867c75b1a75eb5cb"

[yuyichao]

Ping. Any update on this recently? We've released the 0.4 version and now more and more people are confused by this now. (See the ping back from our issue tracker above)

[agjohnson]

Sorry, this fell off my radar. I'll see if I can have any luck reproducing this inside/outside an RTD environment. This has been entirely elusive so far, so if you come up with any more information that could help track this down, that would be helpful.

Something is triggering this on the Sphinx level, though I can't think of any reason triggering a build from RTD would have any different effect.

[ericholscher]

Just did a bit more digging, and it looks like the functions are getting indexed as both Python and Julia objects. You can see this more clearly in a console:

Search._index.objects["Base"]["copy"]
[58, 4, 1, ""]

// On a working search

Search._index.objnames[1]
["py", "function", "Python function"]
Search._index.objnames[4]
["jl", "function", "Julia function"]

// On the broken search

Search._index.objnames[1]
["jl", "function", "Julia function"]
Search._index.objnames[4]
["py", "function", "Python function"]

So I'm guessing that there is some non-deterministic sorting going on with the search indexes, and when they are sorted in the first way, the "Julia" function comes up first, and the second way "Python" comes up. We need to look a bit more as why they're being indexed into both object domains.

[agjohnson]

Yes, and I think this points to the need for a proper Julia domain. Overriding the Python name and prefix isn't enough to create proper indexes. All of the Julia objects are still stored in the domain representation as Python objects. Where the python domain is still loaded, this would cause duplication on indexed objects.

For instance: https://github.com/sphinx-doc/sphinx/blob/master/sphinx/domains/python.py#L247-L255

[ericholscher]

I believe this code is where it is iterating over both domains, and finding the objects: https://github.com/sphinx-doc/sphinx/blob/master/sphinx/search/__init__.py#L278 -- I'm guessing our build servers have different dict sorting order, and so that is why sometimes it sorts properly and other times it sorts a different way.

[agjohnson]

Closing this here and moving to JuliaLang/JuliaDoc/issues#16. A proper domain should resolve the issues with indexing.

[yuyichao]

@agjohnson Thanks for looking into this.

[agjohnson]

@yuyichao Sure thing, keep us posted if the domain doesn't fully resolve your issues.