I see this:
// Debug messages
It's good to know that I'm not the only one who has commented out code in their shipping code:)
It's only a five minute presentation but it blew me away and I'm keen to give it a try for real at some point. Video here:
Great share, thank you!
Best demonstration of Poe's Law right here.
there are many reasons to leave code comments besides neglect. though in this case it's neglect :)
#if 20141031 // Date as a valid number != 0
// Active code
// Inactive code
We never have.
When I actually think about it I realize it's probably very nearly never. But it's hard to shake the suspicion :)
Even if you tear it out, it's way more work to try to pull it all back out, line by line, and re-implement it than to comment it out and leave the actual debugging statements in #ifdef blocks that the pre-processor will pull out anyway.
You only make your source control more valuable by not commenting out code; since you can then search for its presence more easily. Good advice, all around.
Version control shows the evolution of design, if you are leaving in dead code you need to take a step back and think about the real solution.
I've never seen anyone dig through VCS history to gain a better understanding of code. And since presumably things change because the understanding evolves, I'm not even sure what the thought process is that would lead someone to do that.
You comment out code because your understanding might not be perfect, you might want the option to easily roll-back, or even have a reminder that a particular change was made. You'll remove it in the next revision or two.
So yeah. I've heard this before. It's complete and total nonsense IME.
One of my favourite interview questions:
A bug is found where given a specific series of user
interactions an error is raised. You search for this error
in code and you find that the error is raised in a very
old module which was written in a different style from
the main codebase by a developer who has long since left
the company. From a quick look around you see that this
code is very complex, and probably quite important. It's
obvious that it will take quite a bit of time to
understand what's going on simply by just reading the
code in the module where this error is raised.
Your job is to fix the bug. How do you approach this
I think if you're leaving commented out code for history's sake, you're Doing It Wrong. I disagree with the GP's idealism as much as you do, however. My beef with it is that if you're checking in commented code, you're obviously not reviewing your own diffs. It means you're likely to commit minor changes which were made for debugging purposes.
// comment this, just to get this stupid module out of my way.
VCS. Maybe it's just a Web vs Other development thing. The history of an Action in Rails is going to be someone using mass-assignment unsafely. Or a dozen stylistic tweaks. Or implementing a pattern. Or removing it.
It's about the worst possible way I can imagine to attempt to understand requirements.
What I do find helpful is "git blame", and just talking to the person who implemented it. And if they aren't available, then hopefully someone who was there at the time, and involved with the feature, is. At least I have a time-frame.
As a last resort, if no one has any clue what's going on? Scrolling through VCS diffs would be an act of desperation perhaps. But I'd much rather look for tests. Automated or a Manual Test Plan. A Specification. Or just use common sense.
At the end of the day it's most likely that I'm tasked with this issue because the original implementation was a scheduling compromise, or the original developer just couldn't think of how to make it simple, so they made it complex.
Actual complexity is rarely justified by requirements I find. Unless I'm the one writing it of course. ;-) Then it's absolutely the only sane way to implement it and you just need to try harder to understand. Duh.
I appreciate your humility, and I largely agree with your approach. You'd probably do quite well in my interview.
With respect to actual complexity rarely being justified, I'm presently a team lead for a system which involves fairly precise modeling of some very piecewise real world processes under very tight performance constraints. There are so many things we just can't generalize, either because there's no clean abstraction, or because abstraction comes with too much inefficiency. We try to keep our processes from smelling too much like old stale spaghetti, but unfortunately some things are just simply complex, and sometimes in the face of such complexity the most elegant and/or performant solution can make purists cringe.
I'm actually going through the ancient CVS history of Mozilla Firefox in order to learn about a relatively poorly understood piece of code that's still in there to this day:
If there aren't tests or specifications to cover the code, I generally assume any bugs are because of a lack of understanding and proceed from there.
Scrolling backwards through history and looking at progressively more naive or prototypical implementations isn't going to tell me anything except the code was likely underspecified IME.
Comments are infrequent, but when I write them, they're usually to try to clarify particularly complex implementation detail. Not to communicate requirements. Comments aren't the ideal place for that IMO.
git bisect, git log, and git blame are all indispensable tools. To counter your anecdote, I use them all the time and see others do so.
There's really no reason to leave dead imports in a file.
Engineering wanted to move to git, so I would assume they are on the path to 100% git, annnnd.... probably already are at this point.
I asked Github if it was OK to upload the tens of gigabytes of source that the entirety of opensource.apple.com is and I got a "Sure, why not?" response. =)
I think the last time I updated these repos was around 10.7 or 10.8
Edit: I was always wondering how I could manipulate git such that anyone could checkout my scripts and create identical git repos (same commit hashes and all) with a single command. I am somewhat hesitant to update the repos now because it would involve rewriting old commits since I haven't solved this problem yet.
Very easy to switch between OSX releases with the tags.
- The main kernel is open source (although not 100% identical to the version in OS X), but many kernel extensions are closed source, including quite basic stuff like disk image mounting.
- In one open source kernel extension I'm interested in, IOUSBFamily, functionality has been randomly disappearing in favor of empty .cpp files. Like several of the opensource releases, it doesn't actually compile...
- A version of CoreFoundation (C level API) is available, but not the full thing. The Objective-C runtime is available, but the core Objective-C libraries have never been.
- libxpc, which is rather low-level functionality added a few releases ago, was never open sourced; launchd is gone in this release, but before that it didn't compile, thanks to missing xpc headers.
- Bootloaders: BootX from PowerPC was open source, but the x86 EFI stuff was always closed source.
- libm is gone this release. cctools may be gone. Some libSystem libraries such as malloc and pthread were separated out in a previous release, but not open sourced; they're back now, though.
Few changes, but some interesting things pop out, like the addition of libmalloc and libpthread and the removal of memcached and securityd.
Works on 10.1
Unfortunate timing since it was finally getting a working port on FreeBSD.
Apparently the launchd code got rolled into xpc, which is closed source.
Bug is not present in setxattr:
edit: Looks like you can: https://github.com/WebKit/webkit/tree/master/Source
It is also simply not sufficient to say "here is a repository with a lot of code in it": you have to be able to specify what exact code was used for the build (which is what I care about, as I'm constantly trying to analyze the version of WebCore on the device: I have no interest in compiling my own copy or building my own browser), and it is not the main WebCore repository's job to keep tags or branches around for specific versions of iOS that Apple distributes.
Does the LGPL really specify that? IIRC the license is pretty vague and that seems way too specific to hold up in court.
They're all at http://trac.webkit.org/browser/tags/. You can map from the LC_SOURCE_VERSION baked into one of WebKit's frameworks back to one of those tags.
It looks to just be missing the final version component, as even versions of iOS 6.0.x have that same version. So, I went and got the code from opensource.apple.com and started bisecting for the version... the code is totally different.
I don't think you understand the situation here: the iOS version of WebCore is not developed in public, and lots of parts of it are redacted. Even in the code dumps from Apple on opensource.apple.com, some of the code is a .a file.
To demonstrate this, as maybe it still isn't clear what is going on, Apple released iOS 6.0 in September of 2012. Apple released the source code for the iOS 6.0 version of WebCore, and it includes a special "platforms/ios" folder.
This folder contains files like ClipboardIOS.h. If we look in the WebKit source code repository, this file did not get "upstreamed" until May of 2013. You simply can't tag something if it isn't even in the source code repository.
(Interestingly, when Apple did finally provide this source code, they also provided the corresponding ClipboardIOS.mm: they did not on opensource.apple.com, and instead provided ClipboardIOS.o as part of libWebCore_armv7.a.)
however, since it's under lgpl, any source you write that uses webkit must also be shared. this is why some of EA's code is published: http://gpl.ea.com/
That components vendor of course then has to make the source of the LGPL dependency available on request. But what about me?
What would I need to do if I wanted to sell a closed source product that uses this MIT licensed component which is of course totally permitted my the MIT license.
Would I have to stop using this MIT licensed component unless I also want to provide the source code of a dependency lib that I might not even be aware of?
If, on the other hand, the MIT licensed product doesn't mention the dependency, and you cannot be expected to have learnt of it elsewhere, you should be of the hook, both ethically and as far as damage lawsuits go. As soon as that "expected to know of" changes, you must change your license and provide the source on request (or remove the dependency or stop shipping your entire product)
Of course, that is an opinion and just theoretical. In practice, who knows what will happen? That is one reason large companies are/used to be worried about using any source that doesn't ship with extensive disclaimers. Large companies are expected to spend more effort researching these things. That lowers the threshold for "should have known". They generally also have more money. That makes them more open for lawsuits if they are found to walk in a gray area.
Nothing that dynamically links with it. Static linking makes your code part of the library and requires source.
It does encourage you to upstream your changes so you don't have to hire developers to keep up with upstream's improvements and deal with merge hell.
[Fingerprint: 92 D3 F3 46 0E BA A5 FE D5 5E C8 AE 19 59 82 57 85 FE AE 88 A5 9D F7 BE FC 47 89 38 5F BC 4A E9 (SHA-256)]
Like the following:
http://www.puredarwin.org/ looks abandoned, and OpenDarwin disappeared long ago - http://www.applematters.com/article/opendarwin-dies-a-lonely...
Ages? https://opensource.apple.com/ looks like it has for a while, except for the addition of 10.10 (I grab CFLite, libclosure, libdispatch, and objc4 whenever they're made available after a release).
+ unsigned int size = inCapacity * sizeof(dictEntry);
That's what I did, before Apple even released a patch for Mavericks.
rutina:~/git/bashcheck@master$ uname -a
Darwin rutina.local 14.0.0 Darwin Kernel Version 14.0.0: Fri
Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
Testing /bin/bash ...
Bash version 3.2.53(1)-release
Variable function parser pre/suffixed [__BASH_FUNC<..>(), apple], bugs not exploitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Found non-exploitable CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Found non-exploitable CVE-2014-6277 (lcamtuf bug #1)
Not vulnerable to CVE-2014-6278 (lcamtuf bug #2)
Or is this just the Darwin kernel code?
Are the aqua/user interface layer also included here?
Any CONTEXT related to this source code would be greatly appropriated.
I tried many years ago to use Darwin in the "haha I can run Mac OSX but not actually buy a Mac" sort of idea - it was an exercise in hard work (as I hadn't a clue what I was doing) and what I did managed to get to boot wasn't massively useful for "real" work (a CLI with no windowing layer) like development etc. or anything you do day to day.
Quite interesting nonetheless, but not massively useful.