Hacker News new | comments | show | ask | jobs | submit | frozenport's comments login

Also AAC in MP4*


Just like dry counties or final call?

Those apply to everyone in the jurisdiction at least, though blue laws are often widely acknowledged as being religious laws that have fallen through the cracks (even though, oddly, Christianity doesn't have any prohibitions on drinking that I know of). Still, they don't say "you can't eat bacon if you live close to a Jew and they tell you to stop." That's insane that a law is in place that says people of a certain religion can tell you what to do simply by virtue of being near you.

And Blue Sundays (but final call I'm not so sure)

Also the noise violations for the prayer call

Meanwhile Saudi Arabia condemns atheists to death

Not clear how you translate the behavior of single cells into phenotypes, especially when that phenotype may show after many years.

C APIs also offer significantly easier distribution, as you don't need to worry about things like name mangling or support for other languages. Much better than alternatives like COM.

That sounds like a deployment nightmare! Does that mean if you return a pointer from a dynamic library you can't free it in a static library, because they were actually using two allocation systems?

Rust automatically chooses the "best" strategy based on how you're building the source, per https://github.com/rust-lang/rfcs/blob/master/text/1183-swap...

If you're building a dynamic or static library, we use the system allocator because Rust is "subordinate". If you're building a binary, we use jemalloc because Rust is in control and jemalloc is basically the best allocator in town. These behaviors can be manually overridden, and you can also provide your own custom global allocator (see linked RFC for details).

A Rust project using Rust libraries will generally link them in as rlibs, which is basically the Rust equivalent of an object file. rlibs just inherit whatever allocator from what they're linked into.

Rust binaries essentially never dynamically link Rust libraries, mostly for the reason Manishearth said in the sibling. The decision to have different default allocators is because there were problems linking to Rust from C libraries which used the system allocator, because Rust previously was exclusively using jemalloc.

Because Rust libraries being used in Rust projects will be statically linked currently, they will be built using jemalloc. Deploying a pure Rust project is as simple as pushing out a binary (std links to libc, so very few Rust projects are technically pure Rust, but its as good as because the system probably has libc).

Also, as a rule, you don't "free" in Rust at all, and code which defines how the memory is deallocated will be defined in the same library it was allocated in. I don't know the details of what it means when two libraries using two different allocators are interacting, but I don't think its as total a conflict as if you were to try to free a pointer with the wrong allocator's free function.

At the moment Rust doesn't have a stable ABI (aside from things you mark as C-compatible), so dynamic libaries that stick around on your system to do things aren't used much. I bet there will be a solution for this once we stabilize the ABI, though I suspect it may already be solved (I think you can tell rust to dynamically link to the allocator too, or something).

It it nothing new. There are OS which have an heap manager by dynamic library, Windows being one of them.

It is never a good idea to try to release memory in a module that didn't allocate it in first place, specially if one doesn't know how it was allocated.

That's generally the rule in C/C++-land. If you have two shared objects/dlls linked into your program that are linked with different versions of the C++ runtime, it's not safe for an object allocated by one to be freed by the other.

Linux sucks time

MS sucks money

OS X sucks VC money

Linux sucks time

OSX sucks money

MS sucks

I think the comparison with OpenGL is stretched. The problem with OpenGL is that it was made to a describe a limited hardware pipeline corresponding to a graphics card from the mid 90s. Manipulating this state machine is cumbersome and made more difficult by the lack of easy debugging.

I had similar experience, until I realized that my dosage was rather low. You might need 3 pills by 200mg to feel the effects.

That's over the recommended dose. Make sure you're comfortable with the long term side effects if you do that regularly.

Hard to say: http://www.drugs.com/dosage/ibuprofen.html#Usual_Adult_Dose_...

`Usual Adult Dose for Headache Study (n=34) - Prevention of Electroconvulsive therapy (ECT)-induced headache: 600 mg orally 90 minutes prior to the initial ECT session`

That's a medically supervised dose after a rare event. GP post spoke about long term use.

Those sorts of megadoses are used for migraines as well. I've also taken 800 mg for very severe pain on the advice of a doctor. At higher doses on an empty stomach is can give you a buzz of a sort.

And doesn't have the Matlab GUI.

all true, but it is 99% syntax compatible with Matlab. As a student I had saved a lot of money using Octave

What the heck is this article talking about!

Foremost, coherence is a property of tbe light and I dont see any queezing or fock states so the quantum nature is not important. Does the absoption process happen coherently with other protiens? Would this reduce the total amount of light possible to absorb as it requires rejecting the incoherent photons?

What are these guys talking about?!

My (vague) understanding of the phenomenon being discussed is that it was discovered that, in some of the proteins involved in photosynthesis, the electrons were passed around via multiple, quantum-entangled pathways. This allows (supposedly!) better energy transmission than classical physics would.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact