Of course, according to you, lava is not subject to natural cooling and will retain its temperature forever after. Now who is making whose monkeys cry?
Lava doesn't flow very far if you release it slowly. It simply won't stay liquid for very long, it cools down and solidifies. Heck, a controlled lava release is actually problematic because the solidified front has a good chance of overrunning and entombing your facilities in - you guessed it - solid lava rock.
We have no idea what it means that the ecosystem is stressed, and how it affects any effects of rates and magnitudes of change of domesticated plants' genes. The "stressed ecosystem" is an anthropomorphic weasel word. It means something, but that meaning provides no insight into much else.
To be frank, one of the last nice things I'd like to see domesticated is oak. It took simply too long for the oak to produce fruit once a seed is planted, for farmers throughout the centuries to try and domesticate it. If GM is the answer to domesticating oak, I'm all for it. Domesticated acorns would be a great thing to have, IMHO.
Human plant domestication done without modern labs has essentially squeezed into 12,000 years what would happen without humans in many millions of years.
Nice story. I'm so sorry to hear about your daughters. I do agree that bad bureaucrats are just bad, but it's upon us to manipulate them for our ends as much as we can.
Selecting for random mutations is one aspect of genetically modifying organisms, just that you mutate the genes using a naturally occurring process, without needing a modern biotech lab. That's how almonds came to be edible, that's how wheat doesn't need to pollinate with other strains, etc.
If the definition of GMO includes modifications of individual genes for a desired outcome, then most of the domesticated plants we have are in fact GMO. You don't need a modern lab to do GMO, you can use processes that occur naturally. They are no less effective, they just take more time. Pretty much everything that we eat that is of plant origin comes from domesticated varieties of the plants, and those often are significantly genetically modified. Don't eat wild almonds, and good luck farming your natural, pre-domestication wheat grass.
What has HFCS got to do with it? It'd be the same as if they had used cane or beet sugar. The problem is that a lot of the developed world is getting a taste for sweets. Everyfuckingthing in the U.S. has added sugar, starting with staples such as everyday bread and morning cereals. They even add sugar to processed meats ("honey" baked ham, anyone?). All those would do just fine with zero added sugar, it's just a matter of marketing processes that have altered the populace's tastes. Ultimately yes, the money might be coming from the corn farming lobby, whatever. Let's not blame the plant (corn) or the chemical (HFCS) on it, though, because those are not to blame.
You do realize that today's mechatronics technology could completely replace hand weeding? Manipulators and image recognition are where they need to be, only that it's not an avenue that was pursued at a wide scale since it's very new. It has been in the last 5-8 years or so where we have the necessary price points for the necessary technology such as pocket supercomputing on GPUs, cheap motors, drives, cameras, etc.
In the longer term (say 25 years), a visionary company a-la SpaceX could offer industrial scale farming done with zero pesticides for insects that approach the plants from the outside. As long as you can see them and reach them externally, mechatronics can deal with them. Now this would of course force the bugs underground, but that gives us some time to figure things out.
And what's the difference between "intentionally" introducing mutations than just waiting for a random bit-flip? You do realize that a lot of domesticated plants had had functionally significant mutations selected for in order to be useful? Mutations going as far as changing the mode of reproduction of the plant!
Genetic modification (in today's context) is about producing individual specimens with modified or new genes
Man, the "natural" selection done by farmers over the centuries includes selecting for useful random gene mutations. These days we simply don't wait for chance to do the genetic engineering for us, we do it ourselves - as far as modified genes go. Adding new genes happens in nature as well, only it takes so damn long that humans haven't apparently been long around enough for it to be of much use. So, plant domestication as practiced through millennia is often gene modification done by chance and selected for. A whole damn lot of those has been needed to domesticate many of the plants we take for granted today! That's why almonds don't kill you, that's why grains don't require a cross-pollination, and so on.
I don't know what your problem is, since Qt 5 actually makes it easier than Qt 4! That's my experience, at least. Heck, I've been able to get Qt 5 core to run on Zilog's ZNEO. It even performs OK for a proof of concept, and that's practically a platform that runs at 10MIPS and has a 24 bit address space. I use a custom LLVM port to compile it. I need to do more work on cross-module constant propagation to get it to be where I want it to be, but it runs and is usable. And it all runs on bare metal, no OS.
In fact, I use an LLVM-based internal port to a micro controller where the usual calling convention puts parameters and return values in static memory locations. Those are laid out in memory by the linker, based on the call tree to facilitate overlapping data of the functions that don't coexist in any path through the call tree. Recursive functions that aren't tail calls are either forbidden, or, if enabled, they then use stack.
On all platforms, the bits still end up on the screen, and you can still pass a binary bitmap to the platform API to put on the screen. Wouldn't you know, that's what Qt in fact does all the time! For non-Qt-Quick-2 code, Qt uses its own rendering backend (called raster) on all platforms by default, and the entirety of interface between Qt 5's gui module and the OS, apart from synchronization primitives, is bitmaps and I/O+timer events. Seriously.
Not even then. LGPL merely mandates that there must be a way to re-link your binaries to modified Qt binaries. All you need to distribute for a commercial closed-source, statically-linked app is the object files. Heck, you can, you know, pack them into a static archive! Who'd have thought!
So, you're a troglodyte who thinks code generation is for wimps. Why don't you hand-punch machine code on punched cards, then? I mean, why stop code generation at the level of a C++ compiler? Why don't go all the way down?
Tell you what: if you want to be less productive, it's up to you. People who know their craft have long ago figured out what is well handled by code generators, and you know, they do use them.
I think you don't quite get what "hardware accelerated graphics means". It means that you convert normal human-accessible primitives like lines, polygons, splines, gradients, etc. to discretized geometries accompanied by shader programs. Those are then passed to an OpenGL or DirectX implementation that runs them on a GPU. Even for non-accelerated output, there's still geometry and processing bits that get run on a CPU (or even a GPU) to rasterize the output. Sometimes the intermediate form is passed around (say, a PDF). The "hardware accelerated graphics" you speak of are very low-level and pretty much useless without higher level library support.
You seriously need to look at the eigen project to understand that C++ with its templates can actually generate better numerical machine code than C. Yes, all with different math for different things. You demonstrably don't grok idiomatic C++. A whole lot has happened there in the last 13 years. Yes, admittedly it all reads like functional-style workarounds for stuff that was mostly a solved problem with LISP, but hey, at least it's a mainstream language that produces efficient assembly.
You must really not have a feel for how modern C++11 code can look like, and what templates are used for. You're stuck in the C-with-objects mentality.
Slashdot Mirror
Of course, according to you, lava is not subject to natural cooling and will retain its temperature forever after. Now who is making whose monkeys cry?
Lava doesn't flow very far if you release it slowly. It simply won't stay liquid for very long, it cools down and solidifies. Heck, a controlled lava release is actually problematic because the solidified front has a good chance of overrunning and entombing your facilities in - you guessed it - solid lava rock.
The problem is that template metadata that's actually needed to instantiate them is awfully close to a serialized AST
And why would that be a problem? Because, you know, actually it isn't a problem!
We have no idea what it means that the ecosystem is stressed, and how it affects any effects of rates and magnitudes of change of domesticated plants' genes. The "stressed ecosystem" is an anthropomorphic weasel word. It means something, but that meaning provides no insight into much else.
To be frank, one of the last nice things I'd like to see domesticated is oak. It took simply too long for the oak to produce fruit once a seed is planted, for farmers throughout the centuries to try and domesticate it. If GM is the answer to domesticating oak, I'm all for it. Domesticated acorns would be a great thing to have, IMHO.
Human plant domestication done without modern labs has essentially squeezed into 12,000 years what would happen without humans in many millions of years.
It's possible. You have to be slow and deliberate. My teeth didn't complain too much.
Oh, the header files will be there, except that the compiler won't actually read them, it'll read the unit files instead.
Nice story. I'm so sorry to hear about your daughters. I do agree that bad bureaucrats are just bad, but it's upon us to manipulate them for our ends as much as we can.
Selecting for random mutations is one aspect of genetically modifying organisms, just that you mutate the genes using a naturally occurring process, without needing a modern biotech lab. That's how almonds came to be edible, that's how wheat doesn't need to pollinate with other strains, etc.
If the definition of GMO includes modifications of individual genes for a desired outcome, then most of the domesticated plants we have are in fact GMO. You don't need a modern lab to do GMO, you can use processes that occur naturally. They are no less effective, they just take more time. Pretty much everything that we eat that is of plant origin comes from domesticated varieties of the plants, and those often are significantly genetically modified. Don't eat wild almonds, and good luck farming your natural, pre-domestication wheat grass.
Not if you, you know, chew them. Swallowing them whole is pretty useless.
What has HFCS got to do with it? It'd be the same as if they had used cane or beet sugar. The problem is that a lot of the developed world is getting a taste for sweets. Everyfuckingthing in the U.S. has added sugar, starting with staples such as everyday bread and morning cereals. They even add sugar to processed meats ("honey" baked ham, anyone?). All those would do just fine with zero added sugar, it's just a matter of marketing processes that have altered the populace's tastes. Ultimately yes, the money might be coming from the corn farming lobby, whatever. Let's not blame the plant (corn) or the chemical (HFCS) on it, though, because those are not to blame.
You do realize that today's mechatronics technology could completely replace hand weeding? Manipulators and image recognition are where they need to be, only that it's not an avenue that was pursued at a wide scale since it's very new. It has been in the last 5-8 years or so where we have the necessary price points for the necessary technology such as pocket supercomputing on GPUs, cheap motors, drives, cameras, etc.
In the longer term (say 25 years), a visionary company a-la SpaceX could offer industrial scale farming done with zero pesticides for insects that approach the plants from the outside. As long as you can see them and reach them externally, mechatronics can deal with them. Now this would of course force the bugs underground, but that gives us some time to figure things out.
And what's the difference between "intentionally" introducing mutations than just waiting for a random bit-flip? You do realize that a lot of domesticated plants had had functionally significant mutations selected for in order to be useful? Mutations going as far as changing the mode of reproduction of the plant!
You have no idea how it works, then.
Genetic modification (in today's context) is about producing individual specimens with modified or new genes
Man, the "natural" selection done by farmers over the centuries includes selecting for useful random gene mutations. These days we simply don't wait for chance to do the genetic engineering for us, we do it ourselves - as far as modified genes go. Adding new genes happens in nature as well, only it takes so damn long that humans haven't apparently been long around enough for it to be of much use. So, plant domestication as practiced through millennia is often gene modification done by chance and selected for. A whole damn lot of those has been needed to domesticate many of the plants we take for granted today! That's why almonds don't kill you, that's why grains don't require a cross-pollination, and so on.
Unit files for C++ would be an implementation detail, they'd require zero changes to the language standard.
I don't know what your problem is, since Qt 5 actually makes it easier than Qt 4! That's my experience, at least. Heck, I've been able to get Qt 5 core to run on Zilog's ZNEO. It even performs OK for a proof of concept, and that's practically a platform that runs at 10MIPS and has a 24 bit address space. I use a custom LLVM port to compile it. I need to do more work on cross-module constant propagation to get it to be where I want it to be, but it runs and is usable. And it all runs on bare metal, no OS.
Undefined behavior doesn't mean implementation-defined behavior!! Don't use them interchangeably!
In fact, I use an LLVM-based internal port to a micro controller where the usual calling convention puts parameters and return values in static memory locations. Those are laid out in memory by the linker, based on the call tree to facilitate overlapping data of the functions that don't coexist in any path through the call tree. Recursive functions that aren't tail calls are either forbidden, or, if enabled, they then use stack.
On all platforms, the bits still end up on the screen, and you can still pass a binary bitmap to the platform API to put on the screen. Wouldn't you know, that's what Qt in fact does all the time! For non-Qt-Quick-2 code, Qt uses its own rendering backend (called raster) on all platforms by default, and the entirety of interface between Qt 5's gui module and the OS, apart from synchronization primitives, is bitmaps and I/O+timer events. Seriously.
Not even then. LGPL merely mandates that there must be a way to re-link your binaries to modified Qt binaries. All you need to distribute for a commercial closed-source, statically-linked app is the object files. Heck, you can, you know, pack them into a static archive! Who'd have thought!
So, you're a troglodyte who thinks code generation is for wimps. Why don't you hand-punch machine code on punched cards, then? I mean, why stop code generation at the level of a C++ compiler? Why don't go all the way down?
Tell you what: if you want to be less productive, it's up to you. People who know their craft have long ago figured out what is well handled by code generators, and you know, they do use them.
I think you don't quite get what "hardware accelerated graphics means". It means that you convert normal human-accessible primitives like lines, polygons, splines, gradients, etc. to discretized geometries accompanied by shader programs. Those are then passed to an OpenGL or DirectX implementation that runs them on a GPU. Even for non-accelerated output, there's still geometry and processing bits that get run on a CPU (or even a GPU) to rasterize the output. Sometimes the intermediate form is passed around (say, a PDF). The "hardware accelerated graphics" you speak of are very low-level and pretty much useless without higher level library support.
You seriously need to look at the eigen project to understand that C++ with its templates can actually generate better numerical machine code than C. Yes, all with different math for different things. You demonstrably don't grok idiomatic C++. A whole lot has happened there in the last 13 years. Yes, admittedly it all reads like functional-style workarounds for stuff that was mostly a solved problem with LISP, but hey, at least it's a mainstream language that produces efficient assembly.
You must really not have a feel for how modern C++11 code can look like, and what templates are used for. You're stuck in the C-with-objects mentality.