Live data from Hacker News

Show HN: Sourcetrail – Get productive on unfamiliar source code

sourcetrail.com

41–50 of 119 posts

Re: Show HN: Sourcetrail – Get productive on unfamiliar source code

#41
post #38

Do you also have arrows to methods in your own class? In addition, how does this relate to code maps in VS? https://msdn.microsoft.com/en-us/library/jj739835.aspx Seems they cover a similar thing.

Yes, Sourcetrail also shows class internal calls and accessed fields. Code Maps in VS has a different approach because they try to keep the graph small by making the user add symbols. So if you are trying to see every access of a symbol it is easy to miss something. Sourcetrail on the other hand keeps the graph small and comprehensible by showing only one level of dependencies. You don't need to add anything yourself. So you cannot miss any relation ;)

Re: Show HN: Sourcetrail – Get productive on unfamiliar source code

#43

Earlier quoted context omitted.

How's the performance on a large codebase? North of 500k lines, few thousand cpp/h files, 40+mb

We have been working on that for the past few month. Right now the performance is pretty good for C++ projects up to around 2 million lines of code. For C projects the performance is even better! If you want to test it, just download the pre-indexed clang project (900k loc) from our website ( https://www.sourcetrail.com/downloads#extra ). Indexing the project took 12 minutes on a 5 year old laptop.

Really great news! I think I'll give this a demo when I have some capacity.

Thanks

Re: Show HN: Sourcetrail – Get productive on unfamiliar source code

#44

How different is this from CodeLens ? Seems like most of these features are in CodeLens anyways, maybe the licensing for CodeLens?? CodeLens => https://msdn.microsoft.com/en-us/library/dn269218.aspx

CodeLens is great for finding references within the IDE. It also provides information about the history, which Sourcetrail doesn't do yet.

I would say we go a step further, by also providing a visual representation of the references to symbol, which quickly conveys how a symbol is embedded into the rest of the code base, without even reading a line of code. That makes exploring a lot faster.

Re: Show HN: Sourcetrail – Get productive on unfamiliar source code

#45

How different is this from CodeLens ? Seems like most of these features are in CodeLens anyways, maybe the licensing for CodeLens?? CodeLens => https://msdn.microsoft.com/en-us/library/dn269218.aspx

I think you're thinking of CodeMAP, not CodeLENS.

CodeMap => https://docs.microsoft.com/en-us/visualstudio/modeling/use-c...

Re: Show HN: Sourcetrail – Get productive on unfamiliar source code

#46
Hm does anyone know of a web-based tool like this that uses Clang as a back end? I want to put open source code like the bash and Python interpreters in it and be able to navigate symbolically. And I want nice permalinks.

EDIT: It looks like https://woboq.com/codebrowser.html is what I want. The code available but not under and open source license. https://github.com/woboq/woboq_codebrowser/

I will probably try this, but I'm interested in alternatives!

Re: Show HN: Sourcetrail – Get productive on unfamiliar source code

#48

Can you please share the roadmap for adding new language support?

To be honest: We have not decided what language we will pick up next. Our first priority is to improve on our Java coverage. In a few months we should be ready to choose our next language. We are thinking about either tackling Python or implement support for a more recent language like Kotlin, Swift or Go.

A Lisp might be an easy language to target, because of its consistent syntax and "code is data" philosophy. With Clojure, you could both reuse some of your work on Java, and support Clojure's Java interop. Attempting to support Clojure would drive improvements in the Java support.

Re: Show HN: Sourcetrail – Get productive on unfamiliar source code

#49

Earlier quoted context omitted.

You don't need it to be fully automated. For dynamic languages you would have people in the loop to annotate the parts the tool couldn't figure out.

This seems like no better off. Documentation is historically always out of date the second its written. The same would be true for annotation.

As noted by others the annotations would be active checks. More like proofs in coq than static text. That way you'd be building up a logical understanding of the code base that was machine verifiable sidestepping the issue of stale comments.

If done properly this could even feed into code dynamics to capture information on the runtime information. So that at every point in the program you could start asking questions like how many times did this line execute, what was the type of this variable at this point, how much memory was allocated, and so on and so forth.

Post reply on HN