parenthephobia

Specifically, Max unifies (many) editing operations on the modifier stack. An object is the result of a sequence of operations on meshes/paths/patches/etc, from a root creation facility.

In Max you can take a torus, say, apply materials, move it about, distort the mesh, apply physics settings, and then go back to the first modifier and change the torus' inner radius.

In Blender, although you can parametrically create a torus with the same options as in Max and customize those settings immediately afterwards, once you edit the created mesh in any way - or even just select another object - you can't edit those settings any more: it becomes "just a mesh".

Max has mesh editing as a stage in the modifier stack (it also has Blender-style "real" mesh editing). You can layer multiple mesh edits on top of each other and toggle each off or whatever you like. Blender can do the same thing, but as shape keys. Both applications can make the same edits to a mesh, but in Blender they can't apply at different points in the modifier stack: they're all effectively applied before all the actual modifiers.

There's an inherent incompatibility between the supposed ways that the staging area can be replaced with other things. If you replace it with a commit you keep amending as you go, but also all commits must pass tests, then you can never commit partially complete code, which defeats the purpose of having the amending commit.

If you interactively choose what to commit at commit time, then you run the risk of failing the test and then, after fixing whatever was wrong, having to remember which parts of which files it was you chose to commit last time. Now, you could choose to have your CVS remember that for you, but then you're basically reinventing a less-capable version of the staging area.

If you simply commit everything, then you can never have any code in your working tree which breaks tests, nor can you have code which isn't logically part of the commit you're currently working on. In practice that means that when you find things that need fixing that aren't directly related to what you're doing, you either fix it and commit it with unrelated changes - which interacts poorly with merging or reverting those commits - or you don't fix it and, most probably, forget about it.

If your workflow is that every commit must be tested, the correct approach is to enforce that rule, rather than banning an only tangentially related feature.

If you have a page with enough elements and nesting going on that indentation doesn't make its structure clear, I find it hard to believe that you'll see </div></div></div> and think "oh yes, I just closed <div class='wombat'>".

A good editor may highlight the region that a </div> covers, and/or show the opening element and/or the "path" to the current element in the status bar.

But, a good editor that understands indented syntax could do the same. It is a fault in code editors that they don't often have good features for navigating around source which uses indenting. This isn't a problem with the syntax.

FWIW, I use SLIM - which is a Jadelike language for Ruby - and I hate having to deal with raw HTML. I find it incredibly hard to navigate, primarily because of the lack of indentation. All too often you think a particular block is contained in some element but it turns out it just looks that way because somebody decided to use indentation whitespace decoratively.

Even if you're lucky, and it is git.internal - rather than source.internal with VSS on one and ClearCase on the other - there may be conflicting repository names. These'll be configured on developer's PCs, CI servers, automated deployment scripts. And that's just one domain name.

That's potentially a lot of work to connect two organizations: who may well not be connecting because of a merger - they may simply be contractors.

If ABC Corp and XZY Corp had their local stuff on internal.abc.com and internal.xyz.com, then all their old domains - and urls - keep working after they connect their networks. Whether and when to merge their services together becomes a decision based on the merits of each merge, rather than something that is forced because they choose a bad naming scheme.

Somebody earning $100k/yr might have, say, $30k/yr left after taxes and expenses, but most companies don't have 140% profit margins.

Most companies aren't Wells Fargo, though, since they don't have $20bn in cash savings, and don't make $36bn profit on their $86bn revenue: a 40% margin.

The numbers only need a slight alteration if we scale the fines by relative disposable income/profit. The $185m fine is about 0.5% of Wells Fargo profits, so for our hypothetical person with $30k/yr left over, it's more like a $154 fine, but he also has a savings account with $16k in.

I'd say the analogy basically checks out in this case.

This applies to each-style loops. Actual Ruby for loops don't have this behaviour.

    a = []
    for i in 1..100
      a << ->{ puts i } # append, to a, a function that prints 'i'
    end
    a[0].call()

In Go, interface variables are a pair of values: a pointer to the concrete value stored in the variable, and a pointer to the type of that concrete value (i.e. the actual struct).

So there are essentially three kinds of nil in Go: a raw nil pointer, an interface variable with both nil value and type pointers, and an interface variable with a nil value pointer, but a non-nil type pointer.

One way that the two "interface nils" differ is that, to follow the article's example, if you have a Cat variable containing a nil *Tabby, you can invoke Meow on it, and it'll print meow. This works because Tabby's Meow doesn't try to dereference its pointer-to-Tabby. However, if you have a Cat variable that's completely empty, invoking Meow on it will fail.

    10.times.map do |i|
      -> { puts i }
    end.shuffle.each(&:call)

I don't think the behaviour in the article is really a problem with loop variables, but with defer. It is odd that defer packages up the function and its arguments when it is defined. Deferring printing i remembers the value of i at that time, whilst deferring printing &i remembers the (unchanging) address of i.

OTOH, having defer remember the values makes things like

    f = open("file1")
    defer f.close()
    ... do stuff ...
    f = open("file2")
    defer f.close()

Go's "problem" is that it can't efficiently give i a new address in each iteration: it'd have to put each one in a new memory location.

Great artists that worked in the medium knew how to make art within the restrictions of the medium that didn't look like it had been restricted by the medium; as great artists do in any medium.

When we only had 16 colours, it was harder to make great-looking art, but that difficulty didn't make the art look better. The essence of pixel art is that (it seems that) every pixel is placed with care. An image which uses 45 colours but looks like a dithered version of a full-colour image does not look like every pixel is placed with care. Quite the opposite: it looks like the image you're looking at isn't even the image the artist wanted you to see.

Hyper Light Drifter has great "pixel art", but couldn't have been achieved on a 16-bit display (without either noticeable banding or dithering). But, the way it uses colour is clearly inspired by great 4-bit artistry. Although there are many more than 16 colors, neighbouring hues are contrasting, blending is used to indicate glows or shadows, and blurring is used to indicate depth.

Some as-yet unidentified process is replenishing the star's isotopes. An idea I've seen[1] is that the radiation from its neutron star sibling, invisible to us, is powerful enough to trigger nuclear reactions in the star's ionosphere.

1. "A hypothesis for explaining the origin of Przybylski’s star (HD 101065)" http://link.springer.com/article/10.1007/s11963-008-1005-7

A previous ruling of the CJEU covered a similar situation to your hypothetical, and ruled that once something is made freely available to the general Internet by the copyright holder, they lose the right to control who can link to that content. Of course, they retain the right to control who can copy it.

YouTube has a system in place for reporting infringing content. It's not necessarily very effective, but it's better - from a legal standpoint - than being told repeatedly that content is infringing and but intentionally and knowingly republishing links to the content each time another set of infringing copies gets taken down.

The ruling is on a matter of law. It isn't a ruling on the guilt of GeenStijl, or anyone else that shares links. It gives the referring court instructions for how to interpret the EU copyright directive, specifically on whether the criminal act of communicating a work to the public without the consent of the copyright owner had occurred.

The Supreme Court of the Netherlands (Hoge Raad) asked the Court of Justice of the European Union (CJEU) to rule on in what circumstances should sharing links to infringing content be considered a "communication to the public", with specific attention to how the decision is effected by the prior availability of the content and whether the person sharing the links knew the content was infringing.

The ruling of the CJEU was that when somebody knowingly shares links to infringing content for money, it should be presumed that they knew the content was infringing. This is not strictly an answer to the question, IMO, but it does establish criminal intent.

It is being generally reported that commercial infringing linking has been generally ruled to be "communication to the public". I don't think that's the ruling, although the part of the judgement that isn't the ruling does say that. It would be interesting to know whether the whole judgement, or just the ruling at the end, is considered binding. I tend to assume the later, since the ruling is a repetition of the last paragraph of the judgement, and why would that happen if the judgement was binding?

(Edit: Removed lots of unnecessary words.)

Aside from that, you're misrepresenting how the torture was designed. The way they defanged the Geneva Convention was not by making sure their interrogations were not torturous, but by interpreting it such that the victims were not subject to the protections of the convention.

Additionally, the convention doesn't define torture. So there's that.

But yes, the Guardian is known for being biased against torture.

It needn't be done this way. When an object is invalidated it could have its class pointer sneakily changed into a special "invalid object" class. Any attempt to do anything concrete with the object would be rebuffed, but normal object accesses wouldn't be changed.

> The thing that concerns me is that explicit ownership passing can introduce as many bugs as it solves. If I have two objects A and B, with A holding a reference to B, then I can freeze A and freely pass it between guilds, but if I try and touch B I'll get an error until that too has been frozen or its ownership transferred.

At least you get an error. Ultimately, the only alternative with comparable performance is sharing mutable references. That avoids this specific problem but is open to the full assortment of problems that can occur with concurrent mutable state, many of which aren't automatically detectable in principle.

> The "Ruby global data" slide also gives me the scream heebie-jeebies, as did finding stack overflow answers on how to unfreeze objects in MRI. I'm sure nothing will go wrong. :-)

If this proposal is adopted it's a simple matter to prohibit unfreezing objects that have been shared. :)

Not that it would really be necessarily. If you're reaching into MRI's internals to unfreeze an object, then it's up to you to make sure that things don't break.

Slowly.

Objects well-suited to transfer would be shallow mutable structures with immutable data "underneath". Immutable data can be shared, so they'd be ignored by the transfer logic.

Another approach likely to be common would be not transferring objects at all, but sending proxy objects to other guilds which transparently marshal method invocations between those guilds and the object's home guild. For large mutable complexes which are intertwined with everything a guild does, that's probably a more manageable approach.

> Making things worse, you would have to make sure that the ownership transfer is atomic - no other part of the program should see the data structure in a “partially transferred” state

This is easy. You just run the transfer operation with the guild's mutex locked. No other guild can have a reference to a mutable object, and an immutable object doesn't need to be transferred.

> In Ruby, what exactly should happen here? Have these guys really thought about the possibilities?

It seems obvious that every linked mutable object is invalidated, so Qux will be transferred.

http://kschiess.github.io/parslet/ is a parser combinator library for Ruby.

The point of the comic is that a character salad is both less secure and harder to remember than four random dictionary words. That's no less true today.

The MD5 hash of "correcthorsebatterystaple" might be trivial to brute-force today, but it is - and always will be - harder to brute-force than "Tr0ub4dor&3", even if in both cases the attacker knows how you generated the password.

It's the nearest thing I've seen to an implementation of lattice/ggplot2-style graphing (from R) for Javascript.

The problems discussed in the article could be solved with any structured data format. Logs could be streams of objects encoded using e.g. JSON, bencoding, or protocol buffers.

I think if you're at the point of running strings on it, you're probably already pretty sure the binary is not above-board.

Googling suggests that global energy usage is estimated to be around 15 terawatts.

Using the most efficient multi-junction solar cells available - which can convert 30% of the light hitting them into electricity - we could generate that with about 6.5 million km² of solar panels: that's about 80% of Australia.

Out at Earth's orbit, it'd need to be 68 million km^2: about the area of the Indian Ocean.