Blank page from Docker Image

[sempervictus]

Running the compose with ghcr.io/stakwork/stakgraph-standalone:latest (396251e25d3c) results in a blank gray page in Chrome, FireFox, Chromium, and Brave on Linux.

[fayekelmith]

Hi @sempervictus
Sorry for the delayed response. Are you running on an ARM64** or AMD64 chip? The Docker image is published to work only on AMD64 chips for now: https://github.com/stakwork/stakgraph/blob/main/.github/workflows/publish-standalone.yml

But you can compile it locally for an ARM64 to meet your needs: https://github.com/stakwork/stakgraph/blob/main/standalone/docker-compose.yaml

[sempervictus]

@fayekelmith - seems to be an artifact of that particular build, now it manifests as just hanging and not doing anything after cloning the repo and spinning up the LSP. Its AMD64. I just tried again with your #492 PR and same thing, the resource lock stays locked but no file access or any activity goes on after it downloads everything it needs into the container. Any attempted action after throws an error in the webui with a 503 in the logs.

[fayekelmith]

@sempervictus, sorry hiccup, again... :)
Made a PR #1004 to gracefully handle the LSP cases that are yet to be implemented. Once the PR is reviewed, merged, and released, you should be able to do thesame thing, and it should work. However, for now, please turn on LSP on the static page before ingesting a repo, or if you are using curl, do not add the use_lsp param.

Few languages have LSP well set up and tested: Typescript, Go, and Ruby are reliable... Python, Rust, and Kotlin are yet to be well tested.

[sempervictus]

I have it indexing flashinfer (py+cuda which is more or less CPP) right now - figured out toggling the LSP before i started was the trick :-). Will try the PR fix if i have any time tonight.

While i have your attention here, any reason its running single-thread pinning one CPU at 100% (logically, kernel scheduler is distributing the load between host threads)? Built using the Dockerfile.standalone

[fayekelmith]

When building the graph, the processes are sequential. Some stages of the graph creation depend on others, so if we have multiple threads running, we'll either lose some data or pollute it; that's why we have everything running on 1 thread. I'll explore ways of using multi-threading - we might have some speed gains with that too...

Another issue to look into... I'm hoping for more feedback as you explore the tool :-)

[fayekelmith]

@sempervictus I worked on the using more than 1 thread in #1006 , please can you try it out and let me know what you think?

and the updated C++ CUDA queries in #1005

please let me know how it works for you.