Linux does not have to be popular. It must have the software that enables people to 1) do their jobs 2) allow them to be entertained either through gaming or streaming content. Do you think the average Xbox user gives a shit about the OS that runs on the console?
You're confusing popularity in mindshare with popularity in use. Without popularity in use, Linux won't attract the titles and so we won't have the second item you claim it must have.
Linux or Android or iOS or whatever will attract the titles as it grows market share. Steam on Linux should already have been a wake up call. But go ahead and press the snooze button. Steam on Linux would have been unthinkable a decade earlier.
The entire article here is about Microsoft no longer dominating the market and losing share. That is backed up with numbers and graphs. So you are effectively arguing that no matter what happens with market share, Linux won't attract titles because once the titles were all on Microsoft and will therefore stay there forever.
Windows will always have a place . . . in the hearts of people that like to play video games on the PC.
Meanwhile there are lots of people with real work to do.
Android and iOS devices are gradually becoming gaming platforms. Nothing happens overnight. It's a gradient. A gradual shift in color. But when you are at the other side of the gradient, you suddenly recognize that things have changed from where you started. Just as IBM didn't take microcomputers seriously. Then they didn't take seriously that they were losing their monopoly. Just as Microsoft ignored the internet until it was too obvious to ignore. Then continued to ignore what people wanted in computers. Netbooks should have been a warning that the ever declining price of hardware was going to create a paradigm shift in personal computing.
I want Ballmer to stay and continue to steer Microsoft in whatever direction he thinks it needs to go.
Since Microsoft is so good at copying Apple, in another "me too" moment, Microsoft should bring back Gates.
Maybe Gates can bring back some kind of BASIC language? Can't call it
"visual". How about Tiles BASIC? Yeah, that's it! And it works on
Metro. You program it by sliding colored tiles around!
Each line accepts tiles that are slid from a palette of statement templates.
Within each template are slots for expressions and other required values.
Office works perfectly fine on the elite pad 900, surface, and the lenovo tablet 2 that I've tested. I see no problems with office on MS tablets.
My how that sounds like IBM in 1990 saying that mainframe business applications work just fine on IBM microcomputers like the AS/400. I see no problems with mainframe software on an AS/400 microcomputer. Hey everyone . . . stop it . . . stop it I say! Stop rewriting business applications for these other pesky microcomputer toys. If you don't stop I'm going to hold my breath!
Really, where are the numbers? Why is Google hiding the real numbers just like they do for the badly selling Chromebooks? They do release numbers(see Android activations) if they are good, so they must be bad. Even Microsoft has come
Please produce for our enjoyment those real numbers that evil Google is hiding from us.
Microsoft owns both gaming and workplace PC's. Nothing is going to take that from them. Tablets aren't meant to replace PC's, they're just too different kind of devices. Microsoft has nothing to worry about.
Let's rewind to a previous millennium long ago swept away in the sands of time. Let's go way back to . . . 1990.
IBM owns both mainframe and PC's. Nothing is going to take that from them. PCs aren't meant to replace mainframes, they're just too different kind of devices. IBM has nothing to worry about.
Then the sudden realization hit. IBM's PCs were priced at monopoly prices and people were not buying them. The company was in crisis and had to reinvent itself. It got new management. Times got leaner. And they weren't committed to past management decisions.
By 2000 we had a much nicer IBM that was focused on its profitable mainframes and was friendly to both Linux and Java.
After Microsoft reinvents itself, it will have retreated to and focus on its profitable business. Microsoft has a very profitable and serviceable business with its Enterprise software Windows, Outlook, Exchange, Office, SQL Server, etc. Like IBM before it, Microsoft has already begun embracing open source (Apache, PHP, etc etc) that enabled its enterprise customers to do what they do.
Like IBM, Microsoft won't go away. Probably ever. But it will become a smaller and gentler Microsoft without the nastiness and bullying once it has been de-fanged of its monopoly power.
There are multiple ways to improve the USPTO without spending taxpayer money.
For example, the USPTO could charge large patent application fees for patent applications that are rejected; but charge low fees for patents that are granted. That would change the incentives for both the examiners and the filers of patent applications. If a patent is later re-examined and is found that it should not have been granted, then there should be an even larger penalty, and additional penalties for litigating based on an invalid patent.
Another approach would be to simply scale up what the patent office is currently doing, but not use so much human labor to do it. Simply throw all patent applications into a large room full of cats with PATENT GRANTED stamps attached to their feet.
By root I meant "the root set". The set from which all reachable objects are traced by the GC.
If a variable in the stack references a large structure of objects, then those objects are inherently reachable. If that local variable is the only reference to those objects, then setting it to null suddenly makes those objects unreachable. As you say, it does not automatically call the GC. But that does not matter. If the next operations in the method eat up more memory, and memory pressure is great enough, then the GC will be called and those unreachable objects will be reclaimed. If the GC is not called, then it didn't matter to set that variable to null. But I am talking about making some large amount of data unreachable long before the current method is about to end. It is possible that the GC may be called and reclaim that data before the current method ends.
The local variable is passed to subroutines, but those do not make any other references to the large structure other than through the passed parameter. Then they return. So the local variable is used.
As I said, I have only have a situation like this very rarely. So the closest thing I could do to "dispose" of the data structure was to simply make it unreachable -- and hence eligible for GC. If I did not set that local variable to null, then those objects are not eligible for GC because they are still reachable via the stack. I hope all that makes sense.
I know that there are all kinds of optimizations built in. But I am not aware of any that take care of this particular case. I do know about the optimization you mention of a local that is not passed around and the compiler can prove becomes garbage immediately when the method exits. But again the definition of the problem here is that the method is far from exiting, but I want to make a large structure unreachable so it is a candidate for GC, if the GC needs to be called. (More likely GC is running as a thread.)
Finalizers won't help. There is plenty of documentation that finalizers may never even be run.
I have, and still to this day, consider whether the time I did this null assignment is a form of premature optimization. After all, what if the system never runs out of memory. But in this particular case, I did know that this large structure was no longer needed, so I assigned null to the local variable that pointed to it. Not a big deal. And not a common practice.
I know the JVM is amazingly sophisticated. The JIT. The inlining. The re-compiling of inlined functions if the class they came from is changed on the fly. And other amazing things the JVM does.
The object does not hold external resources. It simply is large. I do generally let the JVM manage the memory. That's what GC is for. But there are a lot of optimizations that have to line up right for this particular case to happen automatically. A local variable holds a reference to a large structure. At some point, the last reference to the local variable has been made, and the structure it points to is no longer needed. But the GC can see that the local variable is on the stack and part of the root set. Now the compiler and/or JIT compiler might recognize when there are no more references to a local, or it falls out of scope, and thus arrange things so that the GC could recognize that this structure is now garbage. But I didn't want to assume that all implementations might.
Also see a sibling post I replied to right near yours. I should have mentioned that I do a null assignment like this very rarely.
First, I agree it is generally not a good idea. I thought I mentioned that I only did this rarely. But I think I failed to say that. I only do this null assignment rarely (I think only once, maybe twice, in a project I've been on for years) when there is a large structure, and I mean large, and I want to get rid of it before entering some other significant operation where it is no longer needed.
Your statement that the GC will claim it regardless would depend upon the implementation of a lot of things. It would be necessary for the JVM to know that this local variable, which holds a pointer to a large structure, is actually no longer referenced in the rest of the current method, even though the variable is in scope and non null. Then the GC would need to know that and consider that this actual reference from the stack is really no longer part of the root set because the local variable won't be used in the rest of its current method. While I know that Sun/Oracle's JVM might do this, as it already does many other amazing things, I didn't want to assume that all possible implementations might do it. I didn't even want to assume that the non hotspot "client" JVM might do it.
In matrix multiply, the types of elements do not have to be the same. They only have to be types the add and multiply functions can accept and return values for. Those returned values must also be acceptable as subsequent inputs for some operations like matrix inversion.
Examples of matrix element types that would commonly be expected to work: integers (fixnums such as int or long), floats (such as double), unlimited integers (like BigInteger) or unlimited fixed point (like BigDecimal), or fractions (ratio of two integers).
In a CAS, values might even be symbols (PI, e, i) or symbolic expressions (3a+b^2). As long as the multiply function can accept a ratio (1/2) and a symbolic expression (3a+b^2) and return a new value ((3a+b^2)/2). Then matrix multiply doesn't much care what the underlying types are.
But some function does. Ultimately in this case, the add and multiply functions. This is where the cost of dynamic languages often bites (depending on implementation). For most everyday (non CAS) cases, it is a huge waste to have to check the types of arguments for addition. The compiler should have known and hardcoded the call to the correct type promotions and addition subroutine.
I know Lisp, and am starting to use Clojure. But I do not know ML. I've wanted to look deeper at it for years. Unfortunately, I am unable to understand your reference to inferred static typing until I look deeper. Thank you.
Your sig: APK? You mean an Android application file with the ".apk" extension.:-)
I am not disagreeing with you. Just offering a comment.
While static typing does require that you write more "code" or write more text into your program, you are getting something very valuable in exchange for that minor effort.
Back in about 1982 I remember this argument about strongly typed languages. It was asked by the presenter (don't remember who) "What if I could wave my magic wand so that if you typed your program into the computer three times, it would be free of bugs. Would you do it?" Most people agreed that they would. Static typing is a small form of that. It doesn't make your program bug free, but it does catch a significantly large set of problems at compile time for a very minor cost in human effort.
You mention that Dynamic typing requires you to write more tests. Viewed another way, the compiler's type system is the first line of unit testing. If it compiles, then you have just passed a large set of unit tests that you did not have to write -- or maybe that you did write in the form of type declarations.
Another large benefit of strong typing is that it improves the "toolability" of the language. The compiler can be strongly integrated into the editor and can then offer a lot of assistance right in the editor. (Eclipse, Visual Studio, etc) This is a productivity booster. Also you no longer have to wait for a compile because compile problems are spotted almost as soon as you type in a complete statement in the editor. The toolability also extends to refactoring operations. If you rename a variable or function it precisely renames all references to it from anywhere else in the entire program. Try that with a dynamic language. You IDE can also precisely show you all references to a variable or function from anywhere else in the project.
Dynamic typing means that when you get to the point of doing actual work on a value (eg, Math.min(), Math.cos(), String.substring() etc) then those deepest functions must always test the type of the argument -- at runtime. Every time. Within loops, etc. unless you have a very sophisticated implementation
Now, all that said, I also agree with you that dynamically typed languages are very useful and productive. Especially for prototyping, or projects small in scope. Or projects where the data in the problem domain may be mostly untyped (example: a computer algebra system (CAS)). In a CAS, the matrix multiply, for example, just needs to add and multiply values from elements in the matricies. It doesn't care what types they are. It just needs the add and multiply functions to be able to operate upon those values. But God have mercy on the maintainer of a gigantic system written in a dynamic language.
> I would add the ability to be able to deallocate memory in a exact moment where you considered necessary.
> Garbage collection is ok, but in some situations I needed more control over when to release memory.
In Java, the closest thing I find to immediate deallocation is to be sure that one function, or even one inner set of curly braces has a variable which is the only reference to some large structure, and then set that variable to null to make the structure unreachable. At that point, it is in the hands of the GC. If memory pressure is not high enough to cause the GC to deallocate the structure, then it didn't matter anyway. Otherwise, the GC will reclaim the memory.
It is indirect "deallocation" at best. You must be sure you have only one reference to the structure you want to deallocate. I find it helpful to confine the only reference to the structure to be a single variable within the scope of some pair of curly braces. Either the curly braces of the function it is within, or some inner set of curly braces within the function.
I have often wondered when using an inner set of curly braces within a function if simply letting the variable go out of scope when the closing curly brace is reached is enough to make the structure unreachable. It might not be. Depending upon how the compiler, and the JVM behave (and the JVM is amazingly sophisticated) the variable may or may not continue to exist within the stack frame, but simply not be visible to other code within the function but outside of the curly braces where the variable was defined. So I expressly set the variable to null before the closing curly brace to ensure that my only reference to the structure disappears. It is important to pay attention that you did not inadvertently make some other reference to the root or other internal part of the structure you want "deallocated".
I have begun to doubt my position and wonder if we don't have some responsibility to artificially 'cripple' the solution and in doing so protect the user from themselves
That tells me he should consider working for Apple.
> As long as we can still manage servers while sitting at our desks, I say go for it.
As long as I can sit at my desk eating Doritos(tm), not engage in any sort of physical activity, and never have to go outside into the bright sunlight, then I say go for it!
> any lawyer worth his or her degree will slap them with a defamation lawsuit.
Assuming your family doesn't stone you to death first. Remember, the pr0n from Prenda Law's clients is gay pr0n. Since Prenda has accused your IP address based on their slipshod investigation, then you must be guilty.
Watching the Prenda pr0n means you downloaded it and thus committed copyright infringement. The only way to obtain Prenda gay pr0n is to download it, as Prenda's clients do not offer their gay pr0n for sail. The fact that Prenda sends you a settlement letter doesn't mean you are guilty, it is merely an accusation based on a slipshod "investigation". Of course, if you don't pay, all your family and neighbors will be contacted for further "investigation" to ask them if they know anything about you downloading the gay pr0n of Prenda Law's clients.
The six figures he's talking about comes from the statutory damages for copyright infringement. (Not that you're guilty, but just merely accused. But hey, isn't it just cheaper to settle for a few thousand bucks rather than spend much more fighting it in court, and potentially losing, meaning a judgement against you for six figures?) Plus you don't want your family and neighbors finding out you may watch gay pr0n and thus they stone you to death.
Just FYI . . . for those following along with the Prenda fiasco, the Prenda pr0n is all gay pr0n. Yes. Seriously.
People who are merely accused by Prenda risk having their relatives told that you watch gay pr0n, so that your relatives would stone you to death, even if the Prenda accusation turns out to be untrue.
Slashdot Mirror
Linux or Android or iOS or whatever will attract the titles as it grows market share. Steam on Linux should already have been a wake up call. But go ahead and press the snooze button. Steam on Linux would have been unthinkable a decade earlier.
The entire article here is about Microsoft no longer dominating the market and losing share. That is backed up with numbers and graphs. So you are effectively arguing that no matter what happens with market share, Linux won't attract titles because once the titles were all on Microsoft and will therefore stay there forever.
Meanwhile there are lots of people with real work to do.
Android and iOS devices are gradually becoming gaming platforms. Nothing happens overnight. It's a gradient. A gradual shift in color. But when you are at the other side of the gradient, you suddenly recognize that things have changed from where you started. Just as IBM didn't take microcomputers seriously. Then they didn't take seriously that they were losing their monopoly. Just as Microsoft ignored the internet until it was too obvious to ignore. Then continued to ignore what people wanted in computers. Netbooks should have been a warning that the ever declining price of hardware was going to create a paradigm shift in personal computing.
No.
I want Ballmer to stay and continue to steer Microsoft in whatever direction he thinks it needs to go.
Since Microsoft is so good at copying Apple, in another "me too" moment, Microsoft should bring back Gates.
Maybe Gates can bring back some kind of BASIC language? Can't call it "visual". How about Tiles BASIC? Yeah, that's it! And it works on Metro. You program it by sliding colored tiles around!
Each line accepts tiles that are slid from a palette of statement templates. Within each template are slots for expressions and other required values.
Maybe it should be called BASIC Fingerpainting?
> Microsoft earns a lot of money for each android tablet.
Not forever. Anyone that thinks that is a strategy for saving Microsoft is . . . well, beyond delusional.
Another good strategy: Start looking through the furniture cushions for loose change.
My how that sounds like IBM in 1990 saying that mainframe business applications work just fine on IBM microcomputers like the AS/400. I see no problems with mainframe software on an AS/400 microcomputer. Hey everyone . . . stop it . . . stop it I say! Stop rewriting business applications for these other pesky microcomputer toys. If you don't stop I'm going to hold my breath!
Please produce for our enjoyment those real numbers that evil Google is hiding from us.
Let's rewind to a previous millennium long ago swept away in the sands of time. Let's go way back to . . . 1990.
Then the sudden realization hit. IBM's PCs were priced at monopoly prices and people were not buying them. The company was in crisis and had to reinvent itself. It got new management. Times got leaner. And they weren't committed to past management decisions.
By 2000 we had a much nicer IBM that was focused on its profitable mainframes and was friendly to both Linux and Java.
After Microsoft reinvents itself, it will have retreated to and focus on its profitable business. Microsoft has a very profitable and serviceable business with its Enterprise software Windows, Outlook, Exchange, Office, SQL Server, etc. Like IBM before it, Microsoft has already begun embracing open source (Apache, PHP, etc etc) that enabled its enterprise customers to do what they do.
Like IBM, Microsoft won't go away. Probably ever. But it will become a smaller and gentler Microsoft without the nastiness and bullying once it has been de-fanged of its monopoly power.
There are multiple ways to improve the USPTO without spending taxpayer money.
For example, the USPTO could charge large patent application fees for patent applications that are rejected; but charge low fees for patents that are granted. That would change the incentives for both the examiners and the filers of patent applications. If a patent is later re-examined and is found that it should not have been granted, then there should be an even larger penalty, and additional penalties for litigating based on an invalid patent.
Another approach would be to simply scale up what the patent office is currently doing, but not use so much human labor to do it. Simply throw all patent applications into a large room full of cats with PATENT GRANTED stamps attached to their feet.
Roomba proves that robots can revolutionize domestic cat transportation.
Now they just need to provide a way for the cat to steer the darned thing and provide a more comfortable surface for the cat to sit on.
> What we call incompetent, newly minted MBA drones call efficiency optimization.
New and old MBA drones call this bonuses. Look, I did something! I reduced headcount of people who understand our critical systems to only one!
I understand how GC works.
By root I meant "the root set". The set from which all reachable objects are traced by the GC.
If a variable in the stack references a large structure of objects, then those objects are inherently reachable. If that local variable is the only reference to those objects, then setting it to null suddenly makes those objects unreachable. As you say, it does not automatically call the GC. But that does not matter. If the next operations in the method eat up more memory, and memory pressure is great enough, then the GC will be called and those unreachable objects will be reclaimed. If the GC is not called, then it didn't matter to set that variable to null. But I am talking about making some large amount of data unreachable long before the current method is about to end. It is possible that the GC may be called and reclaim that data before the current method ends.
The local variable is passed to subroutines, but those do not make any other references to the large structure other than through the passed parameter. Then they return. So the local variable is used.
As I said, I have only have a situation like this very rarely. So the closest thing I could do to "dispose" of the data structure was to simply make it unreachable -- and hence eligible for GC. If I did not set that local variable to null, then those objects are not eligible for GC because they are still reachable via the stack. I hope all that makes sense.
I know that there are all kinds of optimizations built in. But I am not aware of any that take care of this particular case. I do know about the optimization you mention of a local that is not passed around and the compiler can prove becomes garbage immediately when the method exits. But again the definition of the problem here is that the method is far from exiting, but I want to make a large structure unreachable so it is a candidate for GC, if the GC needs to be called. (More likely GC is running as a thread.)
Finalizers won't help. There is plenty of documentation that finalizers may never even be run.
I have, and still to this day, consider whether the time I did this null assignment is a form of premature optimization. After all, what if the system never runs out of memory. But in this particular case, I did know that this large structure was no longer needed, so I assigned null to the local variable that pointed to it. Not a big deal. And not a common practice.
I know the JVM is amazingly sophisticated. The JIT. The inlining. The re-compiling of inlined functions if the class they came from is changed on the fly. And other amazing things the JVM does.
The object does not hold external resources. It simply is large. I do generally let the JVM manage the memory. That's what GC is for. But there are a lot of optimizations that have to line up right for this particular case to happen automatically. A local variable holds a reference to a large structure. At some point, the last reference to the local variable has been made, and the structure it points to is no longer needed. But the GC can see that the local variable is on the stack and part of the root set. Now the compiler and/or JIT compiler might recognize when there are no more references to a local, or it falls out of scope, and thus arrange things so that the GC could recognize that this structure is now garbage. But I didn't want to assume that all implementations might.
Also see a sibling post I replied to right near yours. I should have mentioned that I do a null assignment like this very rarely.
First, I agree it is generally not a good idea. I thought I mentioned that I only did this rarely. But I think I failed to say that. I only do this null assignment rarely (I think only once, maybe twice, in a project I've been on for years) when there is a large structure, and I mean large, and I want to get rid of it before entering some other significant operation where it is no longer needed.
Your statement that the GC will claim it regardless would depend upon the implementation of a lot of things. It would be necessary for the JVM to know that this local variable, which holds a pointer to a large structure, is actually no longer referenced in the rest of the current method, even though the variable is in scope and non null. Then the GC would need to know that and consider that this actual reference from the stack is really no longer part of the root set because the local variable won't be used in the rest of its current method. While I know that Sun/Oracle's JVM might do this, as it already does many other amazing things, I didn't want to assume that all possible implementations might do it. I didn't even want to assume that the non hotspot "client" JVM might do it.
In matrix multiply, the types of elements do not have to be the same. They only have to be types the add and multiply functions can accept and return values for. Those returned values must also be acceptable as subsequent inputs for some operations like matrix inversion.
:-)
Examples of matrix element types that would commonly be expected to work: integers (fixnums such as int or long), floats (such as double), unlimited integers (like BigInteger) or unlimited fixed point (like BigDecimal), or fractions (ratio of two integers).
In a CAS, values might even be symbols (PI, e, i) or symbolic expressions (3a+b^2). As long as the multiply function can accept a ratio (1/2) and a symbolic expression (3a+b^2) and return a new value ((3a+b^2)/2). Then matrix multiply doesn't much care what the underlying types are.
But some function does. Ultimately in this case, the add and multiply functions. This is where the cost of dynamic languages often bites (depending on implementation). For most everyday (non CAS) cases, it is a huge waste to have to check the types of arguments for addition. The compiler should have known and hardcoded the call to the correct type promotions and addition subroutine.
I know Lisp, and am starting to use Clojure. But I do not know ML. I've wanted to look deeper at it for years. Unfortunately, I am unable to understand your reference to inferred static typing until I look deeper. Thank you.
Your sig: APK? You mean an Android application file with the ".apk" extension.
I am not disagreeing with you. Just offering a comment.
While static typing does require that you write more "code" or write more text into your program, you are getting something very valuable in exchange for that minor effort.
Back in about 1982 I remember this argument about strongly typed languages. It was asked by the presenter (don't remember who) "What if I could wave my magic wand so that if you typed your program into the computer three times, it would be free of bugs. Would you do it?" Most people agreed that they would. Static typing is a small form of that. It doesn't make your program bug free, but it does catch a significantly large set of problems at compile time for a very minor cost in human effort.
You mention that Dynamic typing requires you to write more tests. Viewed another way, the compiler's type system is the first line of unit testing. If it compiles, then you have just passed a large set of unit tests that you did not have to write -- or maybe that you did write in the form of type declarations.
Another large benefit of strong typing is that it improves the "toolability" of the language. The compiler can be strongly integrated into the editor and can then offer a lot of assistance right in the editor. (Eclipse, Visual Studio, etc) This is a productivity booster. Also you no longer have to wait for a compile because compile problems are spotted almost as soon as you type in a complete statement in the editor. The toolability also extends to refactoring operations. If you rename a variable or function it precisely renames all references to it from anywhere else in the entire program. Try that with a dynamic language. You IDE can also precisely show you all references to a variable or function from anywhere else in the project.
Dynamic typing means that when you get to the point of doing actual work on a value (eg, Math.min(), Math.cos(), String.substring() etc) then those deepest functions must always test the type of the argument -- at runtime. Every time. Within loops, etc. unless you have a very sophisticated implementation
Now, all that said, I also agree with you that dynamically typed languages are very useful and productive. Especially for prototyping, or projects small in scope. Or projects where the data in the problem domain may be mostly untyped (example: a computer algebra system (CAS)). In a CAS, the matrix multiply, for example, just needs to add and multiply values from elements in the matricies. It doesn't care what types they are. It just needs the add and multiply functions to be able to operate upon those values. But God have mercy on the maintainer of a gigantic system written in a dynamic language.
> I would add the ability to be able to deallocate memory in a exact moment where you considered necessary.
> Garbage collection is ok, but in some situations I needed more control over when to release memory.
In Java, the closest thing I find to immediate deallocation is to be sure that one function, or even one inner set of curly braces has a variable which is the only reference to some large structure, and then set that variable to null to make the structure unreachable. At that point, it is in the hands of the GC. If memory pressure is not high enough to cause the GC to deallocate the structure, then it didn't matter anyway. Otherwise, the GC will reclaim the memory.
It is indirect "deallocation" at best. You must be sure you have only one reference to the structure you want to deallocate. I find it helpful to confine the only reference to the structure to be a single variable within the scope of some pair of curly braces. Either the curly braces of the function it is within, or some inner set of curly braces within the function.
I have often wondered when using an inner set of curly braces within a function if simply letting the variable go out of scope when the closing curly brace is reached is enough to make the structure unreachable. It might not be. Depending upon how the compiler, and the JVM behave (and the JVM is amazingly sophisticated) the variable may or may not continue to exist within the stack frame, but simply not be visible to other code within the function but outside of the curly braces where the variable was defined. So I expressly set the variable to null before the closing curly brace to ensure that my only reference to the structure disappears. It is important to pay attention that you did not inadvertently make some other reference to the root or other internal part of the structure you want "deallocated".
> Are you sure you want to delete that file?
More like:
Unable to format drive A:. Formatting drive C: instead.
When he makes a statement like:
That tells me he should consider working for Apple.
As long as robots are forbidden from filing sexual harassment complaints, then I say go for it!
> As long as we can still manage servers while sitting at our desks, I say go for it.
As long as I can sit at my desk eating Doritos(tm), not engage in any sort of physical activity, and never have to go outside into the bright sunlight, then I say go for it!
How many times have we seen 'redacted' legal documents as a PDF with black bars overlaying the text? (See Groklaw for past examples.)
1. Open the PDF in Acrobat Reader.
2. Select All
3. Copy
4. Switch to text file editor (not Edlin!)
5. Paste
. . . .
6. Profit?
Does this demonstrate a failure in understanding information security?
> any lawyer worth his or her degree will slap them with a defamation lawsuit.
Assuming your family doesn't stone you to death first. Remember, the pr0n from Prenda Law's clients is gay pr0n. Since Prenda has accused your IP address based on their slipshod investigation, then you must be guilty.
Watching the Prenda pr0n means you downloaded it and thus committed copyright infringement. The only way to obtain Prenda gay pr0n is to download it, as Prenda's clients do not offer their gay pr0n for sail. The fact that Prenda sends you a settlement letter doesn't mean you are guilty, it is merely an accusation based on a slipshod "investigation". Of course, if you don't pay, all your family and neighbors will be contacted for further "investigation" to ask them if they know anything about you downloading the gay pr0n of Prenda Law's clients.
The six figures he's talking about comes from the statutory damages for copyright infringement. (Not that you're guilty, but just merely accused. But hey, isn't it just cheaper to settle for a few thousand bucks rather than spend much more fighting it in court, and potentially losing, meaning a judgement against you for six figures?) Plus you don't want your family and neighbors finding out you may watch gay pr0n and thus they stone you to death.
> I am not ashamed to admit I watch porn.
Just FYI . . . for those following along with the Prenda fiasco, the Prenda pr0n is all gay pr0n. Yes. Seriously.
People who are merely accused by Prenda risk having their relatives told that you watch gay pr0n, so that your relatives would stone you to death, even if the Prenda accusation turns out to be untrue.
> An absurd TLA overloading.
To be more concise, simply say: ATO. (ATO = Absurd TLA Overloading.)