I don't expect everyone to read every single line of the code for a project they are trying to use, that isn't very reasonable. What I do see though, is that a lot developers have a mental barrier to actually opening up the source code for the project they are trying to use. They will read the documentation, run the tests, use the example code, but when they are faced with a problem that could be solved through a one or two line change in the source code, they shut down completely. The point is that you shouldn't be afraid to jump into the source code. Even if you don't fully understand the source code, in many cases you should be able to isolate your issue to a specific block. If you can reference this block ( or line numbers ) when opening up your support request, it will help the author better understand your problem.

@tmoschou You can find the source for Apple's pkill on opensource.apple.com/source. It's together with other utilities in the collection adv_cmds. Maybe you can spot the bug.

Instead read this gems brief source code completely before use OR copy the code straight into your codebase.

Yes they are the same command. This part of apt's cmdline/apt.cc source file proves it:

You can see the implementation here: https://github.com/sveltejs/sapper/blob/339c417b24e8429d3adc9c9f196bf159a5fce874/runtime/src/server/middleware/get_page_handler.ts#L137

A bit of a tour through the Ruby source code seems necessary as the documentation is a bit thin.

:structured - Lumberjack::Formatter::StructuredFormatter - crawls the object and applies the formatter recursively to Enumerable objects found in it (arrays, hashes, etc.).

If you look at the source code you'll see that they're exactly the same thing.

Read the code! No, really. I wrote this code to be read.

The only place I can find it is in the sprockets-rails gem. javascript_include_tag calls this: def find_debug_asset(path) if asset = find_asset(path, pipeline: :debug) raise_unless_precompiled_asset asset.logical_path.sub('.debug', '') asset end end

Check yourself some shell-sources.

If interested, you can check the plain old /bin/sh signal handling in the source code here.

Treating the web as a compile target has a lot of implications, many negative. For example “view source” is a beloved feature of the web that’s an important part of its history and especially useful for learning, but Svelte’s compiled output is much harder to follow than its source. Source maps, which Svelte uses to map its web language outputs back to its source language, have limitations.

they're in the svelte compiler: https://github.com/sveltejs/svelte/blob/master/src/compiler/compile/nodes/Element.ts#L668 (search for the warning text)

I don't read comments as I think they are dangerous

Docker 19.03 does this automatically # by setting the DOCKER_HOST in # https://github.com/docker-library/docker/blob/d45051476babc297257df490d22cbd806f1b11e4/19.03/docker-entrypoint.sh#L23-L29

“The source code for Falcon is so good, I almost prefer it to documentation. It basically can’t be wrong.”

source

From error.c

We believe load test scripts should be plain code to get all the benefits of version control, as opposed to say unreadable and tool generated XML.

I was going through the source for Thin and noticed that instead of using require, Marc-Andre Cournoyer was using a method called autoload to load thin's constituent parts.