I can't see how this would be useful to build buildings with. How is this an advantage over bolting together a few sections of tubular forms for the columns and tossing in some rebar and concrete? Also, you'd still have to build support for the floors just like you would with traditional concrete. Not to mention having to haul and assemble a building-sized printer at the construction site.
One of the articles mentions that the guy actually plans to print his pavilion in parts and take the parts on-site to assemble. The article says it is still cheaper and faster to do it that way than it is to do it in the traditional way. I'm not sure why that is; I can't think flowing concrete forms could be that expensive. Maybe it is because the materials, sand and epoxy, are so much cheaper than concrete?
That was too insightful a post to have needed to post anonymously.
From which we deduce that the poster just doesn't want to bother with a login, or already used a mod point on this story.
From the lack of dust on the monitor, we can further deduce that the poster keeps too busy to gather dust; and based on the IP address, packet history, and the traces of clay particles detectible on the third line of the post — a rare form of clay used only by coroners, biologists, and the Puppet Master — we know the poster is a biologist employed by UCLA and posting from the shores of Mono Lake itself. Though wholly unnecessary, further proof of the last deduction is furnished by the dirt on the reverse side of the post, dirt which is clearly the residue of a mud splatter, and which contains lethal levels of arsenic.
Now, no modded post contains any trace of arsenic, nor any other indication that this poster has used a mod point on it, from which we can deduce that the poster does not have a Slashdot login at all, and is too busy to create one. But the amount of arsenic found on the post opens an appalling possibility — one that even I never considered! What if the poster was the murderer?
You see, he (or she, but women do not typically use Axe body spray, nor are they to be found on the Internets) does not even try to deny it! I have already taken the liberty of calling the gendarmes around Mono Lake, and given them a precise description of the individual. Soon, our deceased butler friend will have his justice.
So if I read you correctly, being born in the wrong part of town and you are a 'lost cause'?
I read him that if you were born in the wrong part of town and didn't get out of it before your age of majority you were a lost cause. And I mean "get out of it" in a loose sense. Good grades, an artistic calling, an apprenticeship, whatever.
I cannot say I disagree. That could well be the definition of a lost cause: Potential that never did materialize and now never can.
Currently its decompress the audio > real time lossy recompression with worse codec > transmit and then finally decompress. I worked at a company that developed a very nice lossless Bluetooth codec. The tech is out there to do better, it is just a question of adoption and sales.
Mac OS X does a very good job with reflowable layouts, using its "springs and struts" system. It is arguably more effective than Java's over-engineered selection of layout managers. Unfortunately, the iPhone only supports "struts," not "springs," so it is not nearly as good.
(Java has SpringLayout, but that seems to work differently. And I understand that Mac OS X's Core Animation framework provides more powerful layout capabilities.)
You don't have to buy all models of android phones to "prove" it will work. Android Emulator works just fine and you can test different OS versions, screen sizes and resolutions on it. I do own a Motorola droid and do test on it, but I don't lose sleep worrying about how my app will run on different phones, because the emulator testing works well.
This attitude is why software development will never be an "engineering" discipline.
Are you on crack? Java is as fast as or faster than C++? I hope that was sarcasm.
This can happen, given JIT on-the-fly profiling and optimization. It is not true in the general case — in the general case, performance is comparable — but Java can be faster when the C++ code has a lot of const pointer references, uses the default new/delete/malloc/free implementations, or avoids using sophisticated processor instructions for compatibility.
However, Java performance has improved dramatically in the past 10 years since the "Java is slow" meme started, while Objective-C still uses an amazingly slow message handler evaluation mechanism to resolve virtual function calls, instead of anything resembling a real OOP mechanism.
Objective C caches this stuff. Hell, it probably pre-populates the cache at compile time. We are talking about a modern compiler here, not some amateur effort from the 80's. It does data-flow analysis and everything. What you end up with is basically a vtable and a numeric index, plus a bunch of fallback metadata.
How well would it refactor selector names when type of receiver is not known statically?
The type of receiver usually is known statically, because it is usually declared like FancyPants *tweed. How well does Eclipse refactor when you use Class.forName().getMethod()?
You can't cause a memory leak in Java by not doing something, you have to actively do something stupid to trap memory so it can't be collected. Serious difference.
Anything that has back references can easily become uncollectible
More correctly, it isn't that it becomes uncollectible, it is that you are wasting so much memory keeping so much more that you think you are.
Like, you may think you are only keeping an attribute and its value from an XML node, but what you are actually keeping is the entire node, in fact the entire XML tree, plus the complete text file it came from (buffered), plus a line number map, plus the string forms of each element, plus a cross-reference table just in case, plus a similar amount of information from every XML stylesheet or DTD associated with the document, plus their included DTDs, etc.
You can't cause a memory leak in Java by not doing something, you have to actively do something stupid to trap memory so it can't be collected. Serious difference.
Not really. You don't have to actively do something stupid, you just have to not do something smart. Or use a library where someone didn't do something smart.
Anything that has back references can easily become uncollectible, and consequently so can anything that simply refers to other data embedded in a larger structure rather than making a completely independent (and time- and memory-consuming) copy of that data. And a library can have a dozen of those under the hood, where you'd never know about it.
I am working on porting an app I wrote in java to Android. The backed processing will port but UI which is a good bit of it will not.
That is true regardless of whether you are dealing with a phone or not. Back-ends always port easily, GUIs never do, unless you just slap a separate GUI library on top of the native one. Another thing that doesn't port is support for OS facilities like system-wide search.
Fully cross-platform applications are a tantalizing dream, nothing more.
What is the superset of OGG, XML, EBML, and every data structure (including values, lists, tables, tensors, trees, etc) ever created? The GRAPH. That's why I'm working on a general user and programming interface that combines ALL data into one graph.
The GP didn't explain fully. iPhone applications do not have to use the latest APIs. An app can compile to APIs from an older OS version and is thereby insulated from changes in later OS versions. An iPhone developer can abandon the app entirely, and it is fine. But if an app says it uses the latest APIs, but does not build with those APIs, Apple sensibly pulls the app.
Basically, if you want true forwards and backwards compatability the Mac forces you back into the stone ages as far as libraries and the like are concerned, you can't use any of theirs because they will at some point change and break your compatibility, so you have to make all of your own from scratch.
This is not entirely true. Apple keeps old versions of their APIs around. Your app can put an upper limit on the API version it is willing to use, and it will not be aware of any later changes Apple makes.
For example, I have an iPhone app written for iPhone OS 3.0. It says it is written for iPhone OS 3.0. Now, since the release of 3.0 (the current version is 3.1.3), Apple has changed the way certain types of table cells work. But that does not matter to my app. It says it does OS 3.0 APIs, so the iPhone gives it OS 3.0 APIs, and it works as I expect even when running on a device with the latest OS installed.
The same facility is available for Mac OS X. Most developers don't bother with it, so the OS gives them the latest version of the APIs by default, which can break the app. But that is an oversight on the part of those developers.
These ones look like they could be off-by-one errors.
3. Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') 12. Buffer Access with Incorrect Length Value 14. Improper Validation of Array Index 17. Integer Overflow or Wraparound 18. Incorrect Calculation of Buffer Size
Only 5 out of 25? Has the dreaded "off-by-one" error lost its teeth?
Slashdot Mirror
One of the articles mentions that the guy actually plans to print his pavilion in parts and take the parts on-site to assemble. The article says it is still cheaper and faster to do it that way than it is to do it in the traditional way. I'm not sure why that is; I can't think flowing concrete forms could be that expensive. Maybe it is because the materials, sand and epoxy, are so much cheaper than concrete?
Soul stealing is never off-topic!
How exactly does a marine shrimp living at the bottom of the ocean evolve good wood-eating skills?
Molesworth-Enroughty (pronounced Darby)
Oh, that would be hi-larious. Any of you guys live near Mono Lake? Do it. Dooo eeeeet!
That was too insightful a post to have needed to post anonymously.
From which we deduce that the poster just doesn't want to bother with a login, or already used a mod point on this story.
From the lack of dust on the monitor, we can further deduce that the poster keeps too busy to gather dust; and based on the IP address, packet history, and the traces of clay particles detectible on the third line of the post — a rare form of clay used only by coroners, biologists, and the Puppet Master — we know the poster is a biologist employed by UCLA and posting from the shores of Mono Lake itself. Though wholly unnecessary, further proof of the last deduction is furnished by the dirt on the reverse side of the post, dirt which is clearly the residue of a mud splatter, and which contains lethal levels of arsenic.
Now, no modded post contains any trace of arsenic, nor any other indication that this poster has used a mod point on it, from which we can deduce that the poster does not have a Slashdot login at all, and is too busy to create one. But the amount of arsenic found on the post opens an appalling possibility — one that even I never considered! What if the poster was the murderer?
You see, he (or she, but women do not typically use Axe body spray, nor are they to be found on the Internets) does not even try to deny it! I have already taken the liberty of calling the gendarmes around Mono Lake, and given them a precise description of the individual. Soon, our deceased butler friend will have his justice.
For great justice!
I read him that if you were born in the wrong part of town and didn't get out of it before your age of majority you were a lost cause. And I mean "get out of it" in a loose sense. Good grades, an artistic calling, an apprenticeship, whatever.
I cannot say I disagree. That could well be the definition of a lost cause: Potential that never did materialize and now never can.
Currently its decompress the audio > real time lossy recompression with worse codec > transmit and then finally decompress.
I worked at a company that developed a very nice lossless Bluetooth codec. The tech is out there to do better, it is just a question of adoption and sales.
Mac OS X does a very good job with reflowable layouts, using its "springs and struts" system. It is arguably more effective than Java's over-engineered selection of layout managers. Unfortunately, the iPhone only supports "struts," not "springs," so it is not nearly as good.
(Java has SpringLayout, but that seems to work differently. And I understand that Mac OS X's Core Animation framework provides more powerful layout capabilities.)
This attitude is why software development will never be an "engineering" discipline.
This can happen, given JIT on-the-fly profiling and optimization. It is not true in the general case — in the general case, performance is comparable — but Java can be faster when the C++ code has a lot of const pointer references, uses the default new/delete/malloc/free implementations, or avoids using sophisticated processor instructions for compatibility.
http://en.wikipedia.org/wiki/Java_performance
Objective C caches this stuff. Hell, it probably pre-populates the cache at compile time. We are talking about a modern compiler here, not some amateur effort from the 80's. It does data-flow analysis and everything. What you end up with is basically a vtable and a numeric index, plus a bunch of fallback metadata.
How well would it refactor selector names when type of receiver is not known statically?
The type of receiver usually is known statically, because it is usually declared like FancyPants *tweed. How well does Eclipse refactor when you use Class.forName().getMethod()?
More correctly, it isn't that it becomes uncollectible, it is that you are wasting so much memory keeping so much more that you think you are.
Like, you may think you are only keeping an attribute and its value from an XML node, but what you are actually keeping is the entire node, in fact the entire XML tree, plus the complete text file it came from (buffered), plus a line number map, plus the string forms of each element, plus a cross-reference table just in case, plus a similar amount of information from every XML stylesheet or DTD associated with the document, plus their included DTDs, etc.
Not really. You don't have to actively do something stupid, you just have to not do something smart. Or use a library where someone didn't do something smart.
Anything that has back references can easily become uncollectible, and consequently so can anything that simply refers to other data embedded in a larger structure rather than making a completely independent (and time- and memory-consuming) copy of that data. And a library can have a dozen of those under the hood, where you'd never know about it.
I am working on porting an app I wrote in java to Android.
The backed processing will port but UI which is a good bit of it will not.
That is true regardless of whether you are dealing with a phone or not. Back-ends always port easily, GUIs never do, unless you just slap a separate GUI library on top of the native one. Another thing that doesn't port is support for OS facilities like system-wide search.
Fully cross-platform applications are a tantalizing dream, nothing more.
What is the superset of OGG, XML, EBML, and every data structure (including values, lists, tables, tensors, trees, etc) ever created?
The GRAPH. That's why I'm working on a general user and programming interface that combines ALL data into one graph.
Let me google that for you: http://lmgtfy.com/?q=graph+encoding
No point in putting perfectly good alcohol on the floor to evaporate...
"Dude...I drank so much last night, I'm getting buzzed just smelling the vomit..."
There now no one needs to RTFA.
I'm glad I did though. That underground oasis they have in the slideshow is pretty.
Ah, yes wish a library into being. That'll work.
Actually, CPAN is your wishing ring. Want a library? It's there. All you have to do is take it and rewrite it in C. :)
The GP didn't explain fully. iPhone applications do not have to use the latest APIs. An app can compile to APIs from an older OS version and is thereby insulated from changes in later OS versions. An iPhone developer can abandon the app entirely, and it is fine. But if an app says it uses the latest APIs, but does not build with those APIs, Apple sensibly pulls the app.
Dude, I have never had this problem wit teh linuxes ./configure && make install seems to do the trick ;)
Except when you have to update autoconf or libtool, or you get funky GCC errors because the code uses a feature that isn't in the version you have.
This is not entirely true. Apple keeps old versions of their APIs around. Your app can put an upper limit on the API version it is willing to use, and it will not be aware of any later changes Apple makes.
For example, I have an iPhone app written for iPhone OS 3.0. It says it is written for iPhone OS 3.0. Now, since the release of 3.0 (the current version is 3.1.3), Apple has changed the way certain types of table cells work. But that does not matter to my app. It says it does OS 3.0 APIs, so the iPhone gives it OS 3.0 APIs, and it works as I expect even when running on a device with the latest OS installed.
The same facility is available for Mac OS X. Most developers don't bother with it, so the OS gives them the latest version of the APIs by default, which can break the app. But that is an oversight on the part of those developers.
I could easily give it to my halfwit mother and she'd be entirely comfortable with it.
Huh. I'd hate to see the Mother's Day cards she gets from you. :)
These ones look like they could be off-by-one errors.
3. Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
12. Buffer Access with Incorrect Length Value
14. Improper Validation of Array Index
17. Integer Overflow or Wraparound
18. Incorrect Calculation of Buffer Size
Only 5 out of 25? Has the dreaded "off-by-one" error lost its teeth?