We need to dispel the mistique of computers and tech, or they become a new religion.
Man, but you do realise you're on Slashdot right now, no??! What the hell are you doing here then, this is one of the places with the highest technology worship rate anywhere!!
reading employee email helps the boss appear hands-on and accessible
Which proves: we should all give the mailserver passwords to our bosses. Uh oh, wait a minute, he only reads the mails sent to him explicitely?! Sorry, misread that article again...
The fact that people can write entire operating systems in C without having these problems indicates that the problems are with people, not C.
A quick search on google for "memory leak" reveals about 900 messages on lkml.org. On microsoft.com, about 13'000 pages were found. To me, this does not look like a non-issue...
Have you read the article you link against? You don't know a lot about compiler design, do you? Well, don't feel bad, you're not alone. The author of your article does not seem to know a lot about compilers either!
Some comments:
1. All Objects are Allocated on the Heap
Java only allocates primitive data types like int and double and object references on the stack. All objects are allocated on the heap. [...] Anybody using these will definitely hate trading a zero-time stack allocation for a constant-time heap allocation. Put that in a loop and that becomes O (n) vs. zero. Add another loop and you get O (n^2) vs. again, zero.
Zero time allocation? This may be true only if you use these values inside the same method or pass them exactly one method call upwards. If you pass them further, you get O(n) complexity for copying the values on the stack. Passing them m+1 methods upwards from allocation point, gives you O(m*n) copy time. Against O(n) allocation time for objects on the heap.
2. Lots of Casts
[...] Unfortunately, Java doesn't have templates, so Java code is typically full of casts. What does that mean for performance? Well, all casts in Java are dynamic casts, which are expensive. How expensive? [...] The fastest thing you could do is assign a number to each class and then have a matrix that tells if any two classes are related, and if they are, what is the offset that needs to be added to the pointer in order to make the cast. In that case, the pseudo-code for the cast would look something like this:
(1) DestinationClass makeCast (Object o, Class destinationClass) { (2) Class sourceClass = o.getClass ();// JIT compile-time (3) int sourceClassId = sourceClass.getId ();// JIT compile-time
(4) int destinationId = destinationClass.getId ();
(5) int offset = ourTable [sourceClassId][destinationClassId];
(6) if (offset != ILLEGAL_OFFSET_VALUE) { (7) return <object o adjusted for offset>; (8) } (9) else { (10) throw new IllegalCastException (); (11) } (12) }
Quite a lot of code, this little cast!
Yes, quite a lot of code, indeed. But only because you don't have the slightest clue about compilers!
Line (1) Why is your method returning a "destinationClass"?? A dynamic cast check has to return either true or false, but certainly not a class.
Line (4) Determining the cast target during run-time? Are you nuts?! This happens during compile time! Or since when can the static type of a variable change during run-time??
Line (7) Adjusted? Adjusted for what?? There is absolutely no need for "adding" an "offset". Why would you want to do this? The ancestors of a class in the class hierarchy are fixed at compile time, i.e. if you have a field a in class A and fields a and b in class B which inherits from class A, then field a in class A has index 0, fields a and b in class B have index 1 and 2. Example:
A a = new B(); System.out.println(a.a)// prints value at index 0 B b = (B) a; System.out.println(b.a)// prints value at index 1 System.out.println(b.b)// prints value at index 2
The indices are known at compile-time!! A cast only has to return yes or no, valid or invalid.
3. Increased Memory Use
Java programs use about double the memory of comparable C++ programs to store the data. There are three reasons for this:
1. Programs that utilize automatic garbage collection typically use about 50% more memory that pr
From the original article:
there just isn't an elegant way...short of creating a bunch of bugs, and linking them together as dependents (which is a bit inelegant, and error prone)
From your post:...Then you link all the bugs created in the first step to this meta bug by adding them to the "depends on" field....
The original article does NOT talk about the meta bug. It talks about chaining the bugs together linearly. A meta bug intread links the bugs as children of it, which creates a different topology!
A quick and easy method for mozilla is to first create a bug for each module/branch/file (whatever you like) affected. Afterwards, you create a bug and mark it "meta" or whatever you like to name it (in the summary field; of course you could also create an alias). Then you link all the bugs created in the first step to this meta bug by adding them to the "depends on" field.
Et voila, you only have to track the meta bug now, and the issue is resolved after and only after every bug the meta bug depends on has been resolved.
Looks like you have no clue about bugzilla. It is about querying and interacting, no way a PDF could help you in such a situation (except you only use the PDF as a carrier for a big ECMAScript application, but I don't know if this would work).
As it turns out, the staff at JoongAng Daily disliked the fact that I linked to the print view of the article where they don't display ads. Here the corrected link to the article in normal browsing mode:
When two American psychologists studied hundreds of students and focused on the top 10% "very happy" people, they found they spent the least time alone and the most time socialising. Psychologists know that increasing the number of social contacts a miserable person has is the best way of cheering them up. When Jean-Paul Sartre wrote "hell is other people", the arch-pessimist of existentialist angst was wrong.
Hurraaaay for that next students party. Make sure you wear a necklace with your home address (or whereever you want to get dragged when you can't walk for yourself anymore).
--
Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
Well, don't get me wrong. I myself wouldn't want to develop without having a thorough spec (written by either the requirements analysts or myself), but with Linux where there is quite chaotic development in terms that people are writing parts hidden away in their closet and then suddenly want to have it merged into mainline, where noone expected such a thing, it may not be desirable to have an overall spec.
Why not? Specs can change and grow with time as well.
Indeed, but in the Linux development process, I guess that a spec of a new feature is written, then implemented, and if problems occure, the spec is changed again. If you only write a spec, then implement, then change the spec and reimplement again in short cycles, then the spec can serve nothing more as a description one abstraction level higher than the actual code itself, instead of being a planning device with long-term stability.
specs are useful, but depends on objective
on
Linus Says No to 'Specs'
·
· Score: 2, Interesting
Specs are not best for software whose features are to grow with time, and where nobody ones what people want to add more. Specs are best when you have a fixed set of requirements, which you have to meet in order to complete your work.
Still, specs may be useful for example to identify certain aspects of a Linux sub-system. But it may not be desirable to have a full spec defining all the goals of Linux, because these goals are a rapic moving target and therefore steadily changing. Of course, there are some features which are built to stay, but specifying specific features in detail while other objectives are changing or even unknown, is hard and may not give the desired results.
A scientist has described a spider that was trapped and preserved in amber 20 million years ago.
Palaeontologist Dr David Penney, of the University of Manchester, found the 4cm long by 2cm wide fossil during a visit to a museum in the Dominican Republic.
Since the discovery two years ago, he has used droplets of blood in the amber to reveal the age of the specimen.
It is thought to be the first time spider blood has been found in amber and scientists hope to extract its DNA.
Dr Penney, of the School of Earth, Atmospheric and Environmental Sciences, said he had used the blood droplets to trace how, when and where the spider died.
It is a new species from the Filistatidae family commonly found in South America and the Caribbean.
Dr Penney believes it was climbing up a tree 20 million years ago when it was hit on the head by fast flowing resin, became engulfed in the resin and died.
He claims the shape and position of the blood droplets revealed which direction the spider was travelling in and which of its legs broke first.
"It's amazing to think that a single piece of amber with a single spider in it can open up a window into what was going on 20 million years ago," he said.
"By analysing the position of the spider's body in relation to the droplets of blood in the amber we are able to determine how it died, which direction it was travelling in and even how fast it was moving."
He first saw the fossil during a visit to the Museo del Ambar Dominicano, in Puerto Plata, Dominican Republic.
Dr Penney reports his findings in the latest issue of the journal Palaeontology.
Slashdot Mirror
Man, but you do realise you're on Slashdot right now, no??! What the hell are you doing here then, this is one of the places with the highest technology worship rate anywhere!!
Please take your anti-technology rants elsewhere!
Which proves: we should all give the mailserver passwords to our bosses. Uh oh, wait a minute, he only reads the mails sent to him explicitely?! Sorry, misread that article again...
A quick search on google for "memory leak" reveals about 900 messages on lkml.org. On microsoft.com, about 13'000 pages were found. To me, this does not look like a non-issue...
Have you read the article you link against? You don't know a lot about compiler design, do you? Well, don't feel bad, you're not alone. The author of your article does not seem to know a lot about compilers either!
Some comments:
Zero time allocation? This may be true only if you use these values inside the same method or pass them exactly one method call upwards. If you pass them further, you get O(n) complexity for copying the values on the stack. Passing them m+1 methods upwards from allocation point, gives you O(m*n) copy time. Against O(n) allocation time for objects on the heap.
Yes, quite a lot of code, indeed. But only because you don't have the slightest clue about compilers!
Line (1) Why is your method returning a "destinationClass"?? A dynamic cast check has to return either true or false, but certainly not a class.
Line (4) Determining the cast target during run-time? Are you nuts?! This happens during compile time! Or since when can the static type of a variable change during run-time??
Line (7) Adjusted? Adjusted for what?? There is absolutely no need for "adding" an "offset". Why would you want to do this? The ancestors of a class in the class hierarchy are fixed at compile time, i.e. if you have a field a in class A and fields a and b in class B which inherits from class A, then field a in class A has index 0, fields a and b in class B have index 1 and 2. Example:
The indices are known at compile-time!! A cast only has to return yes or no, valid or invalid.
A quick and easy method for mozilla is to first create a bug for each module/branch/file (whatever you like) affected. Afterwards, you create a bug and mark it "meta" or whatever you like to name it (in the summary field; of course you could also create an alias). Then you link all the bugs created in the first step to this meta bug by adding them to the "depends on" field.
Et voila, you only have to track the meta bug now, and the issue is resolved after and only after every bug the meta bug depends on has been resolved.
In other news, an unborn is sued for cognisance as his mother listened to an illegaly downloaded song.
I, for one, welcome our new microbial-community-living-in-blue-ice-vents-insid e-a-frozen-volcano overlords.
In soviet russia, life discovers you.
Imagine a beowulf cluster of researchers on mars.
And who discovers me in my volcano, you insensitive clod!??
Of course. Here we go:
Pringles can antennas already delivered that back in 2001... Now, if there would only come someone along to pick up these pesky crumbs.
Looks like you have no clue about bugzilla. It is about querying and interacting, no way a PDF could help you in such a situation (except you only use the PDF as a carrier for a big ECMAScript application, but I don't know if this would work).
Looks like the staff at JongAng Daily didn't like the fact that I linked to the print version of the article where no ads are shown...
Here is the link to the story in normal viewing mode (whatever normal means under these circumstances...): http://joongangdaily.joins.com/200510/02/200510022 148293739900090609062.html
And hey, trust me, the goatse guy wasn't present on that page until it got published on slashdot.
--
Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
Well, don't get me wrong. I myself wouldn't want to develop without having a thorough spec (written by either the requirements analysts or myself), but with Linux where there is quite chaotic development in terms that people are writing parts hidden away in their closet and then suddenly want to have it merged into mainline, where noone expected such a thing, it may not be desirable to have an overall spec.
Specs are not best for software whose features are to grow with time, and where nobody ones what people want to add more. Specs are best when you have a fixed set of requirements, which you have to meet in order to complete your work.
Still, specs may be useful for example to identify certain aspects of a Linux sub-system. But it may not be desirable to have a full spec defining all the goals of Linux, because these goals are a rapic moving target and therefore steadily changing. Of course, there are some features which are built to stay, but specifying specific features in detail while other objectives are changing or even unknown, is hard and may not give the desired results.
Uhmm, the cheese looks definitely older than on our moon (set zoom to highest level).
No no, it's
...
1. Embrace
2. Extend
3.
4. Profit $$$
A few days more and they did.
Wow, you're one lucky bastard then! I, for one, keep welcoming the look-but-don't-touch-princess-lea overloards in this case.
Spider 'is 20 million years old'
A scientist has described a spider that was trapped and preserved in amber 20 million years ago.
Palaeontologist Dr David Penney, of the University of Manchester, found the 4cm long by 2cm wide fossil during a visit to a museum in the Dominican Republic.
Since the discovery two years ago, he has used droplets of blood in the amber to reveal the age of the specimen.
It is thought to be the first time spider blood has been found in amber and scientists hope to extract its DNA.
Dr Penney, of the School of Earth, Atmospheric and Environmental Sciences, said he had used the blood droplets to trace how, when and where the spider died.
It is a new species from the Filistatidae family commonly found in South America and the Caribbean.
Dr Penney believes it was climbing up a tree 20 million years ago when it was hit on the head by fast flowing resin, became engulfed in the resin and died.
He claims the shape and position of the blood droplets revealed which direction the spider was travelling in and which of its legs broke first.
"It's amazing to think that a single piece of amber with a single spider in it can open up a window into what was going on 20 million years ago," he said.
"By analysing the position of the spider's body in relation to the droplets of blood in the amber we are able to determine how it died, which direction it was travelling in and even how fast it was moving."
He first saw the fossil during a visit to the Museo del Ambar Dominicano, in Puerto Plata, Dominican Republic.
Dr Penney reports his findings in the latest issue of the journal Palaeontology.