This Zen parable is faulty wisdom (like so much of Mahayana and Vajrayana fanfiction)
Please don't promote sectarian strife here.
HN user
(Permission granted for Hacker Monthly to publish my comments and/or submissions.)
This Zen parable is faulty wisdom (like so much of Mahayana and Vajrayana fanfiction)
Please don't promote sectarian strife here.
When shading, the artist will just have to be very conscious of the angle of incidence from the light source.
The artist should be doing this already!
As it happens, I'm working on something like this right now...
My current best solution is to use mouse/pen movement as cspline sample points, even when not drawing. The motion as you swing into a curve, even before the pen touches down, often predicts the trajectory of the pen stroke. (This also lets you "swing in" a circle without getting ugly linear segments).
This may be of limited utility on a touch-based device, however.
Try the Droid Sans Mono variant with slashed zero.
http://blog.cosmix.org/2009/10/27/a-slashed-zero-droid-sans-...
Your mention of Kanji is particularly salient, as the blog post catches these skeuomorphic icons in the act of evolving from pictograms to ideograms...
You say idiom, I say chronic lack of imagination.
In a perfect world having a list where 25% of the names are potential trouble-makers [...]
... would be pointless, as a perfect world would have no concept of "trouble".
down to Costa Rica and overland to Ecuador
Should it be improved this way?
A hard real-time system can fail by running a piece of code too soon as well as too late.
OTOH, a soft real-time program like a video game or voice chat could profit from this.
So the box was more fun without the game cartridge...
Because of their life experience, I wouldn't be so quick to reject either of these fellows' advice out of hand.
You can prototype with the null-GC until you run out of memory...
> I think it's disingenuous to just throw out "take that energy and try to build a company" as an alternative.
As someone who's just read your comment, I'd like to say: calm down, and re-read the parent comment with an open mind. It's dripping with life experience.
... but if it does all three, put a ring on it!
Interesting. The OP got me thinking along the lines of manually tagging salient features of each model (as well as ranking models by salience, either manually or automatically based on criteria related to the object that the model represents).
Maybe a solver for classic Nintendo games?
http://jeremykun.com/2012/03/22/nintendo-np-hard/
(Caveat: http://www.cs.virginia.edu/~robins/The_Limits_of_Quantum_Com... )
His attempt to restore a culture of listening to users is not a non-contribution; it could have saved GNOME.
GNOME needs a gadfly like him. Or rather, needed.
If GNOME's developers have truly become indifferent or outright hostile to the needs of actual users, then the project is doomed to irrelevance.
Ah, ok. I somehow got the impression from your comments that you were the Olav mentioned in the blog post.
It reveals the culture behind the infamous "No.", so it's topical.
(And presumably the ban is still in effect.)
I can sympathize. Just don't burn out... let yourself code for fun every now and then. :)
> FWIW, I totally agree that just a "No." is bad, entirely understand what it resulted in. However, going after a developer in a bugreport is not tolerable behaviour as well.
So why did you go after him?
(I realize that by "a developer" you meant yourself, not Felipe. I still consider this a fair question.)
> Bottom line: These people, [whether] they are arrogant, impolite or unsympathetic to users does not refute the fact that they are giving their time to the project.
> GNOME has been under fire since the famous GNOME 3 release and I would understand the remaining developers to be a little touchy on the matter. At some point, you either stop - or you decide: Fuck this - I will just ignore user-input, because it sucks.
To put it bluntly: if they've given up on making what users want, what's so special about their giving their time to the project?
Why should anyone care, other than for fear that the developers will continue to make things even worse?
Have you considered that your day job is a revenue stream that lets you work on the personal projects you want?
If that's the case, then just give yourself permission to make what you really want to make.
Not quite.
http://www.historyofinformation.com/expanded.php?id=3454
When the humanist hand was invented, the prevailing hand for illuminated manuscripts was blackletter. While either is aesthetically pleasing, the humanist hand caught on because it was readable and vastly more ergonomic to write.
Practice some dip pen calligraphy and you'll quickly notice that a humanist hand feels natural, and takes much less effort than blackletter to form beautiful characters.
Blackletter (as an everyday hand) persisted in church manuscripts (and in Germany, perhaps due to a cultural love of precise craftsmanship), but it's not surprising that many monks also adopted humanist: if your job is copying written works by hand, it makes sense to keep your eyes and hands under as little strain as possible.
P.S. What's a "typeface"? ;)
> Well, a shiv is a homemade knife-like implement, such as one created and used in a prison environment.
You've clearly never done hard time up at IE6 Zero-Security Penitentiary.
Fair enough. The enums themselves aren't a problem; they just seem symptomatic of a pile-on-more-stuff mentality.
Python has been getting bloated in recent years. Why not just do the following?
def enum(*args):
return dict(zip(args, range(len(args))))
colors = enum('red', 'green', 'blue')
# {'blue': 2, 'green': 1, 'red': 0}Modern OpenGL exploits immutable data for parallelism all over the place. It also lets (and expects!) you to upload model data (vertices, colors, texture-coords, etc) to the GPU, so you only need to re-upload things that have changed.
You can even stream textures asynchronously using PBOs (pixel buffer objects), and use dual PBOs like double buffers (or using copy-on-write techniques to only re-upload dirty rectangles...)
Next step: run a genetic meta-algorithm to optimize the initial parameters... judge fitness based on, say, result_quality / runtime...
(Or fastest-to-achieve-reasonable-result...)