4 ms·

Could you give some examples, please?

• nostrademons 16y ago
  Some that I've worked with directly: I'm currently doing a lot of stuff with LLVM. LLVM is actually fairly well-documented for an open-source project: there's at least a bunch of tutorials and Doxygen. Despite this, there've still been a bunch of times I've had to go back to the source. I had to hunt around to figure out how to disable the default dlsym() behavior and explicitly expose all functions I want the compiled code to be able to access. And then I found this didn't work when I statically linked the binary; I had to ask a coworker who's a dev on the project what was up, and it turned out it was a bug in the compiler framework. For my startup, I was doing a bunch with mtasc and swfmill. Beyond basic command-line options, there's pretty much no reference for how to put these together to generate a Flash file of moderate complexity. I basically just tried things that sorta looked like the demo examples, and permuted them until they worked. A few years back, I did a bunch with Netbeans. I had to look at the source code for virtually everything. I had to manually trace back deadlocks by seeing which framework code was holding which monitors. I had to grep the codebase to figure out which Lookup file a particular extension point was checking. Most of the APIs, I just had to try and see whether they did with I want. Usually, the only open-source libraries that work smoothly are the ones that lots of people are already using. They got that way because the early adopters put up with a bunch of pain and contributed back to fixing the problems they encountered. If you're fine with trailing the pack, you can rely on the documentation. But if you're going to lead the pack, you often have to write the documentation.