The subject says it all. Apparently, it's the standards-based, open-source-conforming way to do it. I've heard paeans sung to FOP but I haven't used it, yet.
It works whether or not journaling is turned on. However, the code has a bug in hfs_relocate:
hfs_global_shared_lock_acquire(hfsmp); if (hfsmp->jnl) { if (journal_start_transaction(hfsmp->jnl) != 0) { return (EINVAL); } }
if the the transaction can't be started, the acquired HFS lock never gets released. After this, the code is careful to record the error and jump to a common epilog that unlocks the HFS subsystem.
> Why not use the command designed for this sort of thing, "chsh"?
Since chsh updates/etc/passwd, and since Mac OS X doesn't generally rely on/etc files but on the NetInfo database, neither would work. You have to use the niutil command or the NetInfo Manager application (it lives in Applications/Utilities).
You surely must be joking... or is it the late hour that impairs my sense of the ironic? Nevertheless, I'd like to advance a disclaim: I religiously perform my hygienic duties on every morn, so I resent your mention of the odorous populace.
What can I say to persuade you that "improved correctness" is Newspeak for "we fixed some bugs", which is more transparent but less palatable for a release note - become - press release?
Actually, the procedural elements of OCaml are so strong than, other than syntax (which is more convenient for functional composition than for imperative sequencing), it is an absolute joy to program UN*X-type filters and transformers in it.
OCaml has a very complete interface to UN*X (including sockets), supports native (POSIX) threading, lots of publicly available libraries exist from regexps to XML parsing, etcetera; so it can be (and is!) used for systems-level programming, much as you would use C or Java.
The only thing that may put down programmers accustomed to the more forgiving, dynamic nature of scripting languages like Perl is that OCaml's type system is very strict, much more so than Java's. On the other hand, it has type inference, whereas you rarely if ever need to type-declare things (other than for documenting, that is).
For the sake of example, this is how you would program wc in OCaml:
let wc fname = let inch = open_in fname and stat = { lines = 0; words = 0; chars = 0 } in begin try while true do begin match input_char inch with '\n' -> stat.lines <- stat.lines + 1; stat.words <- stat.words + 1 | '\t' | ' ' -> stat.words <- stat.words + 1 | _ -> () end; stat.chars <- stat.chars + 1 done with End_of_file -> () end; close_in inch; stat
Sorry for the ugly formatting, but Slash is unforgiving
Jaguar runs beautifully on the B&W G3, if you don't want to wait. Even 10.1 did, and the upgrade to 10.2 was absolutely painless; so I don't expect any problems with Panther either.
You surely can get ahold of an, ahem, "evaluation copy" of 10.2 to play.
I pretty much doubt it. If you notice in the address line, only the street and street number were provided, without indication of office or apartment number. First of all, I doubt the address itself is valid; secondly, if it is, it is a high rise building with 99.95% confidence; so without an office number is anybody's guess where to send gifts to them.
Don't bother calling. The number is disconnected. I just called (I'm in BA, so it's local) and the earnest recorded-message lady informed me of the fact.
I pity the poor soul that gets assigned that number.
You're absolutely right about the bus error. Twelve years of Macintosh-centrism (first 680x0's, then PowerPC's) have conditioned me to align, align, align.
However, look at this:
[puma:~/Desktop] mgiovann% gcc -Wall -O c.c c.c:4: warning: return type of `main' is not `int' c.c: In function `main': c.c:9: warning: implicit declaration of function `exit' [puma:~/Desktop] mgiovann% gcc --version gcc (GCC) 3.1 20020420 (prerelease) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
int foo, *bar, flash, *bang, up, *down, left, *right;
Without reading the line again, what was the type of "up"?
From a linguistic point of view, the problem is that type modifiers are adverbs that modify nouns (the variable declarators) instead of adjectives (the type name) as in every spoken language of the Indoeuropean family. It's a bit like saying "I've bought big oranges and very bananas". C declarators are not intuitive from a natural-language point of view.
I believe that in the general case, the proof for a program will be larger than the program itself, and will be written in a language that is more complex, has poorer abstraction capabilities, and less machine support than the programming language of the program. It would stand to reason that the proof would have at least as many bugs as the software.
Forgive me if you find me rude, but offhand dismissal without cogent arguing really taxes my patience.
Asides from it being perposterous to expect all the developers in the world to write formal proofs for their programs,
Why would that be so, exactly? Dijkstra was especially vocal against this "can't do" attitude. I don't ask for a compelling argument, just for a reasonable one.
this statement is at best a wild assumption. He is proposing that the lack of use of a particular (his) potential solution to a problem is the root cause of the problem.
That's true, but how exactly is that bad? He believed that his method is effective with a passion bordering on mania. Again, if you have alternative explanations for the problem that are reasonable, I'd love to hear them.
Also, I've got to doubt that formal proofs would be worth nearly the tradeoff in terms of time. If you think about it, a program is itself akin to a proof of correctness. If a coder makes a mistake in his initial code, it seems likely he will repeat that error in a formal proof. Peer review could improve the failure rate, but that is a whole nother ballgame.
First off, I think that trading thinking time for debugging/QA testing time is a definite savings (i.e., it makes sense from an economics point of view). Secondly and regarding repeated mistakes, yes and no. Yes you can err in the proof. However, in my experience, errors in a proof feel very different to errors in a program. There's a little voice in your head telling you: "can't be, can't be" and it's not until you go back and recheck your proof and you find your errors that it would rest.
Anecdotal evidence is no evidence at all, I know, so I offer the following argument: consider the proof and the code as two different embodiments of the same solution; doing it twice cuts the probability of errors (not trivial, fifteen-second-to-spot mistakes, but hard errors) by half.
Another argument for is that should an error remain, it's easier (i.e., mechanical) to check the proof; if the code is annotated with the proof steps, it's natural to check for agreement.
I'm a convert; I've found errors in my code that never surfaced in five years of heavy usage but were nonetheless there, just by employing (very simple) formal reasoning. You don't need to acquire much knowledge (a very good grasp of logic; a moderate one of elementary integer functions like floor, minimum and maximum; a modest one of number theory) but you need constant practice to change mindsets.
Eighty percent of code is, allow me a loaded word, "trivial" in the sense that yes, you could have pointer manipulation bugs, a reversed condition in a loop, whatever; but for the twenty percent of remaining code, stopping and pondering about the problem makes the road down towards the solution considerably smoother.
Having a separate window for each project I have open, then tabs for the individual files, would be absolutely perfect! Heck, I'd even pay the $250 ($225) to get that CD if it were the only way to get it. It's that valueable to me.
I've never used them, but maybe filesets will help solve this problem?
In fact I would argue that the most "natural" base for a measurement system is 12 as it is evenly divisible by 2, 3, and 4; whereras base 10 is only divisible by 2 and 5. Thirds and fourths are very common divisions of stuff; fifths are not, so a base 12 system is more user-friendly.
Well, you know what, the Babylonians went the extra mile and threw in a factor of 5 for good measure. Guess what they got. Yes, the obligation to remember the time-tables up to sixty! And degrees, minutes (or primes), seconds, thirds...
JavaScript is a really nice language......with a crappy standard library?
The DOM is not really a JavaScript "library", but is part of the browser API exposed via JavaScript bindings. You could say that what has a crappy library actually are the browsers. The JavaScript "library" is comprised of the intrinsic objects: Number, String, Boolean, Date, RegExp, and Math.
Slashdot Mirror
The subject says it all. Apparently, it's the standards-based, open-source-conforming way to do it. I've heard paeans sung to FOP but I haven't used it, yet.
It works whether or not journaling is turned on. However, the code has a bug in hfs_relocate:
hfs_global_shared_lock_acquire(hfsmp);
if (hfsmp->jnl) {
if (journal_start_transaction(hfsmp->jnl) != 0) {
return (EINVAL);
}
}
if the the transaction can't be started, the acquired HFS lock never gets released. After this, the code is careful to record the error and jump to a common epilog that unlocks the HFS subsystem.
I'd rather not turn journaling on.
>> You can always edit /etc/passwd
> Why not use the command designed for this sort of thing, "chsh"?
Since chsh updatesGravitational waves are waves in the spacetime-metric.
Wouldn't that make the metric negative in the vicinity of the source? What is the meaning of that? Its theoretical consequences?
Call me a Platonist if you will, but I'm under the impression that, if it's negative, it ain't a metric.
So, before you laugh, there might actually be some basis for assuming that "Capricorns are always horny" and "Leos are dishonest".
It's the other way around.
You surely must be joking... or is it the late hour that impairs my sense of the ironic? Nevertheless, I'd like to advance a disclaim: I religiously perform my hygienic duties on every morn, so I resent your mention of the odorous populace.
What can I say to persuade you that "improved correctness" is Newspeak for "we fixed some bugs", which is more transparent but less palatable for a release note - become - press release?
It's an all-or-nothing game. It irks me to no end to hear of "improved correctness". It sounds so phony.
Having vented my spleen, I'll continue perusing the discussion. Thank you very much for listening.
You're right on all three counts, atlhough I'd rather use HTML. I've corrected the program; for anyone interested, it is in here.
Compiled with ocamlopt -o ocwc ocwc.ml, I got these results:
I think it's pretty decent.
Actually, the procedural elements of OCaml are so strong than, other than syntax (which is more convenient for functional composition than for imperative sequencing), it is an absolute joy to program UN*X-type filters and transformers in it.
OCaml has a very complete interface to UN*X (including sockets), supports native (POSIX) threading, lots of publicly available libraries exist from regexps to XML parsing, etcetera; so it can be (and is!) used for systems-level programming, much as you would use C or Java.
The only thing that may put down programmers accustomed to the more forgiving, dynamic nature of scripting languages like Perl is that OCaml's type system is very strict, much more so than Java's. On the other hand, it has type inference, whereas you rarely if ever need to type-declare things (other than for documenting, that is).
For the sake of example, this is how you would program wc in OCaml:
Sorry for the ugly formatting, but Slash is unforgiving
I've noticed that the home page is kind of slow. There's the original, old one at INRIA.
HTH
Jaguar runs beautifully on the B&W G3, if you don't want to wait. Even 10.1 did, and the upgrade to 10.2 was absolutely painless; so I don't expect any problems with Panther either.
You surely can get ahold of an, ahem, "evaluation copy" of 10.2 to play.
I pretty much doubt it. If you notice in the address line, only the street and street number were provided, without indication of office or apartment number. First of all, I doubt the address itself is valid; secondly, if it is, it is a high rise building with 99.95% confidence; so without an office number is anybody's guess where to send gifts to them.
Don't bother calling. The number is disconnected. I just called (I'm in BA, so it's local) and the earnest recorded-message lady informed me of the fact.
I pity the poor soul that gets assigned that number.
You're absolutely right about the bus error. Twelve years of Macintosh-centrism (first 680x0's, then PowerPC's) have conditioned me to align, align, align.
However, look at this:
What am I missing?
Argh... Linux is evil. It should bus error with that program. Also, gcc is evil. It doesn't complain even when using -O3 -Wall.
Hint: there is an uninitialized variable.
From a linguistic point of view, the problem is that type modifiers are adverbs that modify nouns (the variable declarators) instead of adjectives (the type name) as in every spoken language of the Indoeuropean family. It's a bit like saying "I've bought big oranges and very bananas". C declarators are not intuitive from a natural-language point of view.
Have you read "Studio 5, the Stars", in Vermillion Sands, that enormous Ballard little tome of short-stories?
If not, do; read it all.
Oh, don't feel bad. I'm a friendly native ;-)
I'd rather have that than read comments in broken English. At least with comments in a foreign language, I can filter them out.
By the by, the grammatical Spanish would be "Es una variable para la función de la red". Not that it makes much sense anyway, comment-wise.
I believe that is not the case.
Forgive me if you find me rude, but offhand dismissal without cogent arguing really taxes my patience.
Asides from it being perposterous to expect all the developers in the world to write formal proofs for their programs,
Why would that be so, exactly? Dijkstra was especially vocal against this "can't do" attitude. I don't ask for a compelling argument, just for a reasonable one.
this statement is at best a wild assumption. He is proposing that the lack of use of a particular (his) potential solution to a problem is the root cause of the problem.
That's true, but how exactly is that bad? He believed that his method is effective with a passion bordering on mania. Again, if you have alternative explanations for the problem that are reasonable, I'd love to hear them.
Also, I've got to doubt that formal proofs would be worth nearly the tradeoff in terms of time. If you think about it, a program is itself akin to a proof of correctness. If a coder makes a mistake in his initial code, it seems likely he will repeat that error in a formal proof. Peer review could improve the failure rate, but that is a whole nother ballgame.
First off, I think that trading thinking time for debugging/QA testing time is a definite savings (i.e., it makes sense from an economics point of view). Secondly and regarding repeated mistakes, yes and no. Yes you can err in the proof. However, in my experience, errors in a proof feel very different to errors in a program. There's a little voice in your head telling you: "can't be, can't be" and it's not until you go back and recheck your proof and you find your errors that it would rest.
Anecdotal evidence is no evidence at all, I know, so I offer the following argument: consider the proof and the code as two different embodiments of the same solution; doing it twice cuts the probability of errors (not trivial, fifteen-second-to-spot mistakes, but hard errors) by half.
Another argument for is that should an error remain, it's easier (i.e., mechanical) to check the proof; if the code is annotated with the proof steps, it's natural to check for agreement.
I'm a convert; I've found errors in my code that never surfaced in five years of heavy usage but were nonetheless there, just by employing (very simple) formal reasoning. You don't need to acquire much knowledge (a very good grasp of logic; a moderate one of elementary integer functions like floor, minimum and maximum; a modest one of number theory) but you need constant practice to change mindsets.
Eighty percent of code is, allow me a loaded word, "trivial" in the sense that yes, you could have pointer manipulation bugs, a reversed condition in a loop, whatever; but for the twenty percent of remaining code, stopping and pondering about the problem makes the road down towards the solution considerably smoother.
I'm sick of the guys' posturing. Why can't he just let go?
I propose to rename GNU/Linux to GSD Linux, as in "GNU Software Distribution".
I've never used them, but maybe filesets will help solve this problem?
Well, you know what, the Babylonians went the extra mile and threw in a factor of 5 for good measure. Guess what they got. Yes, the obligation to remember the time-tables up to sixty! And degrees, minutes (or primes), seconds, thirds...
The DOM is not really a JavaScript "library", but is part of the browser API exposed via JavaScript bindings. You could say that what has a crappy library actually are the browsers. The JavaScript "library" is comprised of the intrinsic objects: Number, String, Boolean, Date, RegExp, and Math.