If you can't figure out an xml plist config, then you are not smart enough to be in the shell.
1. It's not about figuring it out. Just because you can figure something out doesn't make it optimal or even non-crap.
You scared people clearly don't understand plist files and how they represent records and lists.
2. The grandparent post was talking about XML in general and how it's great for configuration data. That is what I was taking issue with. You can build record/list support on top of XML, but it doesn't fit in naturally.
3. I still think the property list XML format is crap. Property lists are decent; they're not perfect, but their extreme simplicity makes them very useful. The ASCII format is great, so why would you want an XML format?
Does having an XML format lets you leverage XML tools? It might have if property list XML worked with XML instead of simply beating it into submission. Apple created a completely opaque layer on top of XML instead of integrating directly.
The result: something that's more verbose and harder to read than even a natural XML format.
What's worse is that you can't leverage DTD/Schema as much as you could with a natural XML format.
You can't validate semantic structure. (You can ensure that the file is a valid property list XML file, but you can't make sure that it contains launchd configuration info).
DTD/Schema sensitive editors still wont help you out with semantic structure. It can auto-complete "key", "dict", etc. but it can't auto complete "Name", "Age", or "Color".
Hmm...not sure if I agree with that definition of "self-validating" but even so, how is it useful in this case? The program that uses the file expects a certain format and needs to validate the input a certain way, no matter what the DOCTYPE says. Besides, the very fact that the file is in a location associated with launchd is like an implicit DOCTYPE.
Because XML configuration files are self-validating.
How are they self-validating? What does that even mean? XML files can be checked to ensure they follow a certain format, but that's true for practically any file format. (I say "practically" only because it looks like Mr. Halting Problem can screw things up here).
No, you don't get it. Why in hell would you want to write yet another config file parser and use your own awkward config format when you could use standard XML and that very same parser that's already loaded to system RAM as a shared lib?
Ah...I see. There's a shared library. That fact lets me see past its total crappiness as a data format.
Re:Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 2, Interesting
XML is total crap for config files. At least its complexity is somewhat warranted when dealing with document-type data (like HTML or DocBook).
The problem is that XML's data model is fundamentally broken. Most programming language data structures use records, variants, and lists to organize data and this has worked well for years. XML gives you attributes (which cannot contain nested elements), and sub-elements that are matched accoriding to a regular expression. Stupid, stupid, stupid.
I can't see how GOTO has any value in CS. Theory shouldn't ever take shortcuts and in theory if you need faster performance, then you should choose an algorithm that is more efficient in the particular context.
EITHER it is a performance bottleneck OR it is going to cause obvious maintenance problems down the line, THEN there is justification for replacing some CS-compliant structures with GOTOs.
Saying that GOTOs have no place in theory implies that "CS-compliant structures" let you express any algorithm efficiently and clearly at the high-level. But if you're forced to use GOTOs to improve maintainability, then there's a hole in your theory. GOTOs, being generic and powerful (and, as a result, dangerous) act like the catch-all to make your theory complete.
Of course it's slow, but it was always intended to by a hybrid with C.
I agree that you don't always need to be fast. The simplicity of Python when compared to C makes up for the speed difference in many situations. However, it's misleading to say that Python isn't slow.
Frankly, I never understood why Java doesn't have any means to store objects on the stack (apart from perceived simplicity).
Having two types of allocations (and parameter passing semantics) makes things more complicated. It's simpler to think of all allocations being heap allocations. However, there are optimizations to automatically use the stack in some of the cases where it's safe (see escape analysis).
Second, Java and Python are not necessarily slow. [...] In the case of Python, it's usually a matter of spending as much time as possible in a C library (even if that means you have to write the C library).
It's not a matter of swapping "pre-emptively". The whole business is invisible to the user space and the locking is essentially done by the kernel.
I think the guy doesn't know what "preemptively" means. He thinks it means "proactively" or "predictively". (I have a feeling this misunderstanding was partly due to different interpretations of the US' "preemptive" strike.)
What he was trying to say here is that the OS might start copying pages to disk even before it is forced to. Let's say RAM is full. It can either wait until it is forced to page something out, or it can proactively copy a bunch of RAM pages to disk (but keep the RAM copy as well). If a request comes in for a new page of RAM, you've already swapped some stuff to disk and so you can just clear the RAM version and give it to the requestor.
The disadvantage is that you might be unnecessarily copying things to disk, but if you can do it when the system is idle, you don't really lose anything.
Dude, read the Bazaar webpage. Just the front page. It's clearly not a fork. They want to have some level of interoperability, but that's about it. They wrote it in Python and have a totally different user interface.
Re:I just want C++ programs to COMPILE faster
on
GCC 4.0 Preview
·
· Score: 1
I think even when you are on a single processor box, you can get a bit of speedup with -j2.
Compiling is a CPU intensive task (al least when I compile the linux kernel), so the thread context switch will make you spend more time compared to a single thread [blah, blah, blah]
Try it. It's faster.
Re:I just want C++ programs to COMPILE faster
on
GCC 4.0 Preview
·
· Score: 1
One key difference that will never change and is important is C++ is weakly typed and Java is strongly typed. This means types are guaranteed at compile time where as in C++ you can do all types of great/terrible things.
I realize that a lot of people say this, but I think you mean "unsafe" rather than "weakly typed." The C++ type system is rather powerful, actually; much more powerful than the Java type system before generics. Java's runtime guarantee of type integrity just means it is a "safe" language/runtime.
I suppose that you could say that type safety isn't strictly enforced by C++ compilers, but this isn't the case for Java either. Though the overall integrity of the VM-managed data is maintained through dynamic checks, Java lets you do a lot of stupid things with types.
Tabs are not that bad; you just have to be more careful. If you can handle tabs consistently, then tabs are fine. (I happen to use spaces because I've gotten used to it, but spaces do have their disadvantages...)
It seems to me that if the PostgreSQL team had leveraged their position and spent more time developing for open operating systems, businesses would be given the incentive to switch. Instead, they've chosen to accomodate the enterprise windows crowd.
This argument made its rounds a while ago. I think it was when a prominent KDE developer write about how it was a bad idea to port applications to Windows. The counter argument is that they're letting people switch to open source software a little bit at a time (which is easier). Once people are comfortable with using cross-platform applications exclusively, the Windows platform no longer has an unfair advantage. At that point, different operating systems can be judged on their own merits, instead of simply on the availability of application software.
Oh please. Refute the statement, don't attack the messenger. I stand by it.
Give me a break. The assertion of your original post (that a call stack is usually enough) was based entirely upon your personal experience. There was absolutely no deductive arguments or additional premises to support your conclusion. The only thing that could be refuted was your implicit assertion that you have the necessary experience to make such a decision.
While some people do have enough karma capital to get away with an "in my experience", there's no evidence that you are one of them.
Personally, I was fine with stack traces until I started doing embedded work. There are times where the ability to go backwards would *really* speed up the debugging process. Unfortunately, the boards I'm currently dealing with have a lot of custom hardware on it...not sure how easy it would be to get all the necessary specs into the simulator.
Valgrind is great for debugging memory problems (wild pointers, memory leaks). It's not at all like the older memory debugging tools; you just run "valgrind your-program" and it'll rewrite your executable to perform the appropriate checks, then run it. Right now it only supports x86 executables; they're working on PowerPC support.
This question needs be considered, because the poster is staring right at the answer and is still missing it. You can write code. You have a compiler. OPTOMIZE THE COMPILER.
It's less complicated to optimize by hand than to come up with a general optimization algorithm. What makes it even harder is that it has to fit in with the rest of the optimization framework. Sure, the payoff is higher, but it's still out of reach for most programmers.
What kinds of low level optimizations do C compilers do for you automatically and what kinds of things are they unable to determine?
This is actually what I thought the story would be about. I think that the form of the question was reasonably clear to anyone who wasn't desperate to impress others with newly-acquired-but-only-tangentially-related information. Too bad most of the responses were just smug and condescending. "Instead of answering your questions, I'll just suggest that you don't really need to optimize." The worst part is that they all said the same exact thing, drowning a potentially interesting Slashdot topic in noise.
I agree that the submitter does sound a little naive, but hey...before learning some assembly and computer architecture, so was I. I used to think that the speed of my code was rougly proportional to the number of logical operations in my Pascal source code (though I'd like to think I never worried about the difference between "!ptr" vs "ptr==NULL").
I've had that corrected by respected colleagues to "while (done == false)"... is that really any more clear?
One possible reason to avoid "(!ptr)" is because you're mixing pointer and boolean types. The "!" operator is a primarily a boolean operator and so there's nothing wrong with using it on a boolean variable. I wonder if your colleagues would apply the same rule to "true":
while (running == true) {... } if (button.IsPressed() == true) {... }
In fact, you might get yourself into a little trouble by comparing to "true". Since, in C, a false value is a value that is non-zero, comparing to some constant "true" wouldn't work pefectly all the time.
Ideally, the compiler should do the same thing. On the other hand, it is possible that the compiler only used the access-and-increment instruction in the second case, simply because it was less obfuscated.
In any case, induction variable analysis is a pretty standard technique and so there's no reason to use raw pointers in most simple loops. If the usage crosses procedural boundaries, then your particular compiler may or may not help you out there.
Slashdot Mirror
1. It's not about figuring it out. Just because you can figure something out doesn't make it optimal or even non-crap.
2. The grandparent post was talking about XML in general and how it's great for configuration data. That is what I was taking issue with. You can build record/list support on top of XML, but it doesn't fit in naturally.
3. I still think the property list XML format is crap. Property lists are decent; they're not perfect, but their extreme simplicity makes them very useful. The ASCII format is great, so why would you want an XML format?
Does having an XML format lets you leverage XML tools? It might have if property list XML worked with XML instead of simply beating it into submission. Apple created a completely opaque layer on top of XML instead of integrating directly.
A natural XML equivalent would be a little more verbose: Using Apple's XML format, you'll get:The result: something that's more verbose and harder to read than even a natural XML format.
What's worse is that you can't leverage DTD/Schema as much as you could with a natural XML format.
Hmm...not sure if I agree with that definition of "self-validating" but even so, how is it useful in this case? The program that uses the file expects a certain format and needs to validate the input a certain way, no matter what the DOCTYPE says. Besides, the very fact that the file is in a location associated with launchd is like an implicit DOCTYPE.
How are they self-validating? What does that even mean? XML files can be checked to ensure they follow a certain format, but that's true for practically any file format. (I say "practically" only because it looks like Mr. Halting Problem can screw things up here).
Ah...I see. There's a shared library. That fact lets me see past its total crappiness as a data format.
XML is total crap for config files. At least its complexity is somewhat warranted when dealing with document-type data (like HTML or DocBook).
The problem is that XML's data model is fundamentally broken. Most programming language data structures use records, variants, and lists to organize data and this has worked well for years. XML gives you attributes (which cannot contain nested elements), and sub-elements that are matched accoriding to a regular expression. Stupid, stupid, stupid.
Don't worry. I am Indian and had the same initial reaction. But, like others said, it was a direct quote from the Hindu, where it seems to fit better.
Saying that GOTOs have no place in theory implies that "CS-compliant structures" let you express any algorithm efficiently and clearly at the high-level. But if you're forced to use GOTOs to improve maintainability, then there's a hole in your theory. GOTOs, being generic and powerful (and, as a result, dangerous) act like the catch-all to make your theory complete.
person_who_loses_job_after_bubble_burst != donald_knuth
Having two types of allocations (and parameter passing semantics) makes things more complicated. It's simpler to think of all allocations being heap allocations. However, there are optimizations to automatically use the stack in some of the cases where it's safe (see escape analysis).
That means Python is slow.
I think the guy doesn't know what "preemptively" means. He thinks it means "proactively" or "predictively". (I have a feeling this misunderstanding was partly due to different interpretations of the US' "preemptive" strike.)
What he was trying to say here is that the OS might start copying pages to disk even before it is forced to. Let's say RAM is full. It can either wait until it is forced to page something out, or it can proactively copy a bunch of RAM pages to disk (but keep the RAM copy as well). If a request comes in for a new page of RAM, you've already swapped some stuff to disk and so you can just clear the RAM version and give it to the requestor.
The disadvantage is that you might be unnecessarily copying things to disk, but if you can do it when the system is idle, you don't really lose anything.
Dude, read the Bazaar webpage. Just the front page. It's clearly not a fork. They want to have some level of interoperability, but that's about it. They wrote it in Python and have a totally different user interface.
Try it. It's faster.
I realize that a lot of people say this, but I think you mean "unsafe" rather than "weakly typed." The C++ type system is rather powerful, actually; much more powerful than the Java type system before generics. Java's runtime guarantee of type integrity just means it is a "safe" language/runtime.
I suppose that you could say that type safety isn't strictly enforced by C++ compilers, but this isn't the case for Java either. Though the overall integrity of the VM-managed data is maintained through dynamic checks, Java lets you do a lot of stupid things with types.
Tabs are not that bad; you just have to be more careful. If you can handle tabs consistently, then tabs are fine. (I happen to use spaces because I've gotten used to it, but spaces do have their disadvantages...)
This argument made its rounds a while ago. I think it was when a prominent KDE developer write about how it was a bad idea to port applications to Windows. The counter argument is that they're letting people switch to open source software a little bit at a time (which is easier). Once people are comfortable with using cross-platform applications exclusively, the Windows platform no longer has an unfair advantage. At that point, different operating systems can be judged on their own merits, instead of simply on the availability of application software.
Give me a break. The assertion of your original post (that a call stack is usually enough) was based entirely upon your personal experience. There was absolutely no deductive arguments or additional premises to support your conclusion. The only thing that could be refuted was your implicit assertion that you have the necessary experience to make such a decision.
While some people do have enough karma capital to get away with an "in my experience", there's no evidence that you are one of them.
Personally, I was fine with stack traces until I started doing embedded work. There are times where the ability to go backwards would *really* speed up the debugging process. Unfortunately, the boards I'm currently dealing with have a lot of custom hardware on it...not sure how easy it would be to get all the necessary specs into the simulator.
Valgrind is great for debugging memory problems (wild pointers, memory leaks). It's not at all like the older memory debugging tools; you just run "valgrind your-program" and it'll rewrite your executable to perform the appropriate checks, then run it. Right now it only supports x86 executables; they're working on PowerPC support.
Nader didn't run with the Greens this time.
It's less complicated to optimize by hand than to come up with a general optimization algorithm. What makes it even harder is that it has to fit in with the rest of the optimization framework. Sure, the payoff is higher, but it's still out of reach for most programmers.
This is actually what I thought the story would be about. I think that the form of the question was reasonably clear to anyone who wasn't desperate to impress others with newly-acquired-but-only-tangentially-related information. Too bad most of the responses were just smug and condescending. "Instead of answering your questions, I'll just suggest that you don't really need to optimize." The worst part is that they all said the same exact thing, drowning a potentially interesting Slashdot topic in noise.
I agree that the submitter does sound a little naive, but hey...before learning some assembly and computer architecture, so was I. I used to think that the speed of my code was rougly proportional to the number of logical operations in my Pascal source code (though I'd like to think I never worried about the difference between "!ptr" vs "ptr==NULL").
One possible reason to avoid "(!ptr)" is because you're mixing pointer and boolean types. The "!" operator is a primarily a boolean operator and so there's nothing wrong with using it on a boolean variable. I wonder if your colleagues would apply the same rule to "true":
In fact, you might get yourself into a little trouble by comparing to "true". Since, in C, a false value is a value that is non-zero, comparing to some constant "true" wouldn't work pefectly all the time.
Ideally, the compiler should do the same thing. On the other hand, it is possible that the compiler only used the access-and-increment instruction in the second case, simply because it was less obfuscated.
In any case, induction variable analysis is a pretty standard technique and so there's no reason to use raw pointers in most simple loops. If the usage crosses procedural boundaries, then your particular compiler may or may not help you out there.
I reread Coryoth's post and cannot find the place where he insulted your grandmother. Kinda ironic that you accused him of being patronizing and smug.