procrastitron

GitLab has an open issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/4084) to use git-appraise (https://github.com/google/git-appraise) for storing pull requests in the repository.

You are right; I got it backwards.

That statement is true of NP-complete; if you can solve any NP-complete problem in P time, then you can solve every NP-hard problem in P time.

That's not right.

The names of the classes can be confusing, but ${CLASS}-hard means "no harder than ${CLASS}", not " no easier than ${CLASS}".

So, for instance, every problem in P is NP-hard.

${CLASS}-complete, on the other hand, means that its members are both:

1. ${CLASS}-hard and 2. No easier than any other problem in ${CLASS}.

git-appraise (https://github.com/google/git-appraise) does this for reviews and there is a tool (https://github.com/google/git-pull-request-mirror) for importing pull requests into the git-appraise format.

I agree with you, and I prefer the --no-ff merge option for submitting reviews, but I think the argument for it would be a lot stronger if 'git bisect' supported a --first-parent flag the same way that 'git log' does.

There's also integration with GitHub pull requests for that:

https://github.com/google/git-pull-request-mirror

Yes, this includes comments.

There's an Eclipse plugin, if that's what you mean: https://github.com/google/git-appraise-eclipse

There's also dulwich, which is in Python: https://github.com/jelmer/dulwich

"Tracing garbage collection has better throughput than reference counting, but reference counting has lower and more predictable latency."

Exactly this. I would actually back off a bit and only claim that reference counting has more predictable latency, but the point is to sacrifice throughput in order to reduce worst case latency.

I wrote an operating system in a purely functional dialect of Lisp; http://losak.sf.net

There are a few things I learned in the process that I think are relevant here:

1. Forget garbage collection in the sense of any variant of mark-and-sweep. For an operating system latency is more important than through put, so you really want real time memory management. If you use reference counting, then there is a lazy variant that gives you just that; no pauses due to reclaiming free memory. The downside with reference counting is that it doesn't work with cycles in heap-allocated memory, but if your data is all immutable then you can prevent cycles from being created in the first place.

2. Treat mutable memory as a form of I/O. Even if you just want to use memory mapped I/O, you will need some way to read and write to (some portion of) memory. Set aside a fixed block of memory (say, for instance, the first 10 MB), and only allow that memory to be read and written in an imperative fashion. Keep the managed heap completely separate from that mutable block, and don't allow any direct access to the managed memory.

3. You can actually perform preemptive multitasking entirely at compile time (or at program load time for apps not included when you build a binary for your OS). I've done this for both my OS and for Scheme (https://github.com/ojarjur/multischeme). It works extremely well and winds up being much faster than using the native primitives usually used for building multitasking support. For more details on exactly how to do it see the link to my Scheme implementation.

4. The biggest difficulty the author will hit, and the most likely cause for performance issues, will be in code generation. Since the proposal is for a new bytecode, the author will have to implement their own interpreter and/or JIT compiler for it, and writing an efficient one is an extremely large chunk of work. I've built an operating system and a programming language, and the language is by far the harder project. This is why I went from working on a new OS written in a new language to re-implementing my compile-time multitasking technique for Scheme; it allows me to take advantage of all of the hard work people have done to make compilers for that language which produce fast code.

Can someone familiar with the process explain where this lies in the standardization process?

Does "final draft" mean this is the official R7RS-small standard, does it mean this is the final text being sent to the steering committee for endorsement, or does it mean something else entirely?

I would take the fact that they gave you no response at all for 3 months as a huge red flag.

As does Java, but they get it wrong for arrays. I don't know if C# has that problem or not.

This doesn't change the crux of your comment, but the post office does give them a price break; in fact it gives everyone a price break, all you have to do is sort your mail by zip code.

The way it works is if you send enough mail to the same zip code, then you pay a certain discount (a few cents per mail piece) if you package all of that mail together. The amount of the discount varies depending on if you sort by 5 digit zip code, or just 3 digit zip code prefix.

Restricting the problem to a fixed size input makes factoring an O(1) operation; so I still don't see what all the fuss is about.

Unless you know a way of extending this to handle an arbitrary amount of I/O then it's just a way of implementing nondeterministic finite state machines; which are no more powerful than deterministic finite state machines.

That page doesn't seem to have been updated in the several years since I first came across it. As such, any efforts targeting Xen or KVM wouldn't have existed at the time the list was put together.

We often see the word "founder" used as an abbreviation of the phrase "startup founder", but that only applies when used in the context of discussing a startup.

The word itself is perfectly applicable in various contexts that have nothing to do with startup companies; charities, political parties, bands, and internal projects. As such, referring to Buchheit as the founder of Gmail is reasonable.

What makes you think they had that requirement? At least their current job listings don't mention anything like that (http://www.google.com/intl/en/jobs/uslocations/mountain-view...).

My suggestion would be that if you want to join Google then just send them your resume. Let them decide whether or not they want you rather than deciding that for them.

You might be surprised at how large an impact adding unit tests can have on existing code. It makes it feasible to start incrementally fixing the spaghetti while having some assurance that you aren't breaking existing functionality. Granted, it's not a panacea, but it does have a huge impact.

That all being said, the concept of "taking ownership" without having any control of how you do your job is bullshit. The only way to solve that problem is to tell management that they are solely to blame, but the solution you get may be to no longer work for them; you have to decide for yourself if it's worth the risk.

I assumed that comment was a reference to the Nook.

I've lived in Texas for most of my life, imoving between Dallas and Austin, and I can attest to the spirit of what the cab driver told you; Austin is radically different from the rest of the state. Austin is a staunchly liberal college town while the rest of the state is extremely right-wing.

Well, lambda calculus is Turing complete, so you could just stick with a call-by-value version of that. However, you'd want to add macros if you wanted to extend the syntax of the language. Since you mentioned car and cdr in lambdas, they'd be defined like this:

NIL = (lambda (x) (lambda (y) y))

CONS = (lambda (ar) (lambda (dr) (lambda (op) (op ar dr))))

CAR = (lambda (expr) (expr (lambda (ar dr) ar)))

CDR = (lambda (expr) (expr (lambda (ar dr) dr)))

Lazy doesn't just mean deferred; an unnecessary computation might never be performed at all. Take for example a function where the recursive argument is never called:

sample = (\this->(\x->x))

Then, (Y sample) can reduce as follows:

1: (Y sample)

2: (sample (Y sample))

3: ((\this->(\x->x)) (Y sample))

4: (\x->x)

Now, if your evaluation strategy required evaluating arguments to final form before applying an operator to them, then line 2 would expand forever:

2: (sample (Y sample))

3: (sample (sample (Y sample)))

4: (sample (sample (sample (Y sample))))

... And so on.

However, neither call-by-need (lazy) nor call-by-name evaluation strategies require evaluating an argument before applying some operator to it. Thus, in languages that support either of those evaluation strategies, the operator can be evaluated to the point where it throws away the argument, and the argument need never be evaluated.

This is a contrived example but real world recursion works for the same reason; at some point in the evaluation of the function, it no longer needs to be applied recursively, and once it reaches that base case, the recursive function can be discarded.

The Y combinator only works in languages with either a lazy or call-by-name evaluation strategy. If you run it in a language with an eager evaluation strategy then it actually would result in an infinite loop. For those languages you would have to use the Z combinator or an equivalent. The z-combinator is just the Y combinator with the argument wrapped in a thunk to prevent premature evaluation.

I like this idea, but perhaps in addition to being overloaded, the term "hacker" is also too broad. The constructive sense of hacker can apply to any domain; hardware, software, social engineering, etc. I would suggest any new terms be more specific.

Personally, I would appreciate a term that can be used to specifically refer to software hackers; something that conveys the concept of programming as an artistic medium.

This as atrocious reporting.

First of all, you DO forget how to ride a bicycle. Anyone whose gone for more than a decade without riding on and tried to take it back up should be able to attest to that.

Secondly, this research doesn't seem to have anything to do with retaining memories; just how they are formed.

I actually really like it but, of course, beauty is in the eye of the beholder.

I don't think it needs to be a black and white thing where either you are stuck with a single vendor or the user experience goes to hell. There is a middle ground between anarchy and dictatorship.