I had a Ultrasound Max for the longest time, but when I upgraded my MoBo to a Pentium, the damn thing would just not work. It turned out that the Pentium ISA bus did something really weird to keep the timing at 8MHz. Every 16 clock cycles it would introduce a 1/8 cycle extension, and as far as I could tell, that sent the Ultrasound into a tailspin.
I found that out, of course, after about 10 hours debugging with a digital oscilloscope. The support engineers were so grateful that they replaced my Max for a Ultrasound PnP for NOTHING. And, that worked a treat.
As far as I can remember, the PnP was a PCI card. Unfortuantely, I can't use it in my Mac;)
What I mean is that if I want to pull a small block up in C or perl I just change the indenting. An extra syntax to allow that seems a little silly. I'd think that a (normally phrased) conditional followed by a statement, followed by unindented code, should be interpreted properly without having a new syntax.
I think I understand what you mean here, and it's still a non argument. For example, the following two python snippets are equivalent (underscores used to force indenting: stupid slashdot;):
if somecondition: _ somestatement
if somecondition: somestatement
Ie, no extra syntax to 'pull up' a block, if that was what you meant. OTOH, if you meant taking some statements out of the if block, and have them always execute, then it works just as well in python:
if somecondition: _ statement1 _ statement2
Turns into:
if somecondition: _ statement1 statement2
With the BIG advantage that you don't have to relocate any braces just to take 'statement2' out of the if block. Just unindent. However, if you wanted to bring BOTH statements out of the IF, you need to tell python that you intended to leave the If block empty:
if somecondition: _ pass statement1 statement2
So, yes, there's some extra syntax there (the 'pass'), but that's a GOOD THING in my book, as you're telling the parser that you intended the IF to be empty.
One downside is it's harder to temporarily edit out a block of code with a 'if (0)', because you HAVE to indent the block for it to take effect. In that case, it's easier to just use most editors 'add in a comment marker to all these lines'. There is one saving grace, though, in that the parser has a good chance of picking up badly marked blocks because of the indenting rules.
You don't exactly sound anti-Python, there:) Responding accordingly:
Anyways, the example is also a demonstration of why that brace style isn't the _One True Way_
I thoroughly agree. When I code C I always put the brace on the same line as the condition. That's not how a lot of people code C, though. Furthermore, this is trying to solve a deficiency in the language with a coding style (not the first, nor the last, this'll happen), and if you're making that argument, it also argues for python's indenting requirement. Python just happens to use that indenting as a syntatic construct, which in turn forces indenting. This is a Good Thing in my book.
But, for a typo, any comparison in there is just as bad, it won't do what you expect.
However, you can ensure that common typos are caught by the parser. In python, two common typos are caught. See my previous comment regarding matching indent blocks and the ':' element. Also, python doesn't suffer from accidental use of '=' instead of '==' in a conditional, since a value assignment is a statement, and not an expression. Yes, I'm aware that most modern C compilers catch this error, but not always.
I was writing hello-world type code in python and I remember it as having two syntaxes for an if, one that required an indented block and one that was meant for one line. I found this awkward and I prefer being able to use explicit controls (braces) to put a block where I want it. Was I mistaken?
You're not mistaken. See my other previous comment for details. However, I think this is a non-argument. If you dont want to put the block on the same line, then just don't. All you need to do is indent it some, just like you would be doing anyway.
I do agree that perl's use of regexps is really easy, but Perl gets that because regexps are part of the language. By contrast, Python puts that into a library, which makes it a little harder to use compactly, but certainly not hard to use. Additionally, it allows for very clear use of pre-compiled expressions, and having multiple expression match results active at the same time. Something which is awkward in Perl.
Is this a problem with python, or with the channel that doesn't even allow for leading spaces to lines?
I don't think "can be posted to slashdot as comments without some non-standard befunkery" is a particually good feature point, especially since slashdot still screws up any indenting that would make a piece of C or Perl code readable.
For other channels you can leave the python as-is (since I don't know of any other channels that screw it up the same way slashdot does), you can use pyindent.py, or just encode it.
Python also has block redundancies. You must introduce a new block with the ':' syntatic element. If you indent and you don't have that, the parser gives you a SyntaxError exception (A real python exception, too, that you can trap, if you're doing run-time interpretation of code).
Similarly, if you use ':' and you DON'T indent, you'll also get a SyntaxError.
The only exception would be ending a block earlier than anticipated. Ie, you forget to indend the last line of the block (an example that I raised elsewhere). And, that's something that's going to be pretty damn obvious on the screen. Compare that minor gaff with the following gaff common in C
if ( x < 0 ); { x = 0; underflow = 1; }
Which will NOT do what you expect. This situation is not possible in Python (nor in Perl, actually, but I bet you could find a similar 'one character changes the entire meaning' in perl too;)
Actually, I shouldn't have said 'whitespace to determine semantics', because that's not correct at all. It's 'INDENTING determines semantics' which is a whole bunch less offensive. Apart from the indenting, whitespace is NOT significant in python.
Yes, I did notice that (which is why I commented on it, so you didn't have to). I've also done my fair share of cobol programming and hated it. Python's use of whitespace to determine semantics is wholly different from that.
Personally, I much prefer having the visual structure and 'actual structure' be the same thing, rather than separate concepts as in something like C or perl. The reduction in time debugging programs because of something that looks blocked correctly but isn't, because the {} and indenting mismatch, has been significant. Yes, I appreciate that I could run my C and perl programs though a prettyprinter, but EVERY time a program doesn't work properly? No thanks.
Remember, I'm not saying that this particular feature is a massive boon, only that it's not as significant as a lot of folk make it out to be. When first instroduced to it, I too was turned off by that particular quirk, but after a day, it's second nature. Challenge yourself, surprise yourself... write your next 1000-line project in Python.
It's already available in python. For example, in a if statement, if your true condition is a throwaway statement, you can put it on the same line. Viz:
if x < 0: x = 0
Or even two throwaway statements:
if x < 0: x = 0; underflow = 1
But you need to use indending if your true condition follows multiple lines:
if x < 0:
_ x = 0
_ underflow = 1
_ window.messagebox ( "Underflow." )
(_ is used to force an indent)
If you've got a block, and you're NOT indenting, then I certainly wouldn't want you on my programming team:)
(And, yes, this post gives a good demonstration of one of the downsides of python's indenting requirements. My opinion: the upsides outweigh the downsides)
The lack or addition of a tab in Python usually DOES result in a compile time error (well, as compile-time as scripting languages go... you can run 'compileall.py' on your.py files as a check, too).
There are some cases where it doesn't. ie, if you've forgotten to indend the last like of an IF block, then that line will be excecuted outside of the IF. However, if you just LOOK AT your code, it's bloody obvious what's going on. This is no different than, say, forgetting to put braces after an IF in C, or some other gaff.
-- Used perl, tried python, switched, never looked back.
Two ports on the same host. The ports are connected to various points on a network to measure latency between those parts. The setup we have is fast enough, as long as the timestamps are accurate enough.
I've written (not trying;) a latency meter. Measures the time between the same packet appearing at two ethernet ports. I'm using the difference between the timestamp as reported by libpcap as the 'latency', but I also apply a little filtering to remove time recording noise, and a small amount of priority bias.
Microsecond resolution works pretty well. 10-millisecond resolution just doesn't cut it.
Need 2.2 for microsecond packet timing.
on
Kernel 2.2 - It Lives!
·
· Score: 4, Interesting
I've written a little application around libpcap that needs the microsecond resolution for packet arrival times. 2.2 has that. 2.4 only gives me 10 millisecond resolution.
You're talking about a company that is on it's death throes. Sure, they might be able to get a chunk of goodwill, but without a viable product to sell, they can't convert that goodwill into cash.
The edict of running a public company is to make money. The executives are dutybound to squeeze every last dollar out of what they can before they go under, and rest assured, go under they will.
Unfortuantely, what will happen is that in the liquidation, the IP will be sold off to another company and they, too, will see what sort of money they can squeeze out of it. I bet it's PanIP that buys the IP... any takers?
The suit is against IBM at the moment. There's no guarantee that they won't also go after other companies that have 'used versions of Linux containing contributions made by IBM who misappropriated them from SCO'. No guarantees at all.
A companies purpose is to make money. If they win against IBM (and I'm not betting on that one, no way), then they are dutybound to their shareholders to increase the value of the shares, and then they'll start going after everyone else.
The ONLY valid solution is to lobby government to abandon such intellectual property rights. I don't mean give them up completely, but the current state of affairs is certainly not working.
Professional oboe players cut their own reeds, because they can't get off the shelf reeds that will sound as good. They don't, however, make their own instruments. Their asset is their ability to produce beautiful music, not perfect reeds.
Saying they cut their own reeds is exactly analogous to companies cutting their own code. Of course, they're just cutting the part they need customised, and not all of it.
For example, we'll write our own web application because no application out there does a particuar job as well as we need it to, but we don't write our own OS or Web server or script interpretor, do we? No... we'll build on existing applications.
There is no one 'Right' solution, but it will depend on how closely any application fits the needs of a company. In some cases, an off-the-shelf product will do the job, in others, perhaps a bit of tweaking, and in still others, perhaps a completely new application.
However, obtaining a sending 'identity' needs to be non-free (either by time, or money), or spammers will just obtain as many identities as required in order to send spam AND, a list of 'known spamming identities' needs to be maintained. Ie, this is only marginally better than what we have now.
Alternatively, the identities could be linked to individuals, meaning that you will not want to risk sending spam with your identity. However, this removes a LOT of anonimity of email and I'm sure people, even 'non-spamming' people, will balk at this.
I really do believe that the only solution is to change a small amount (a penny, or something settable by the recipient, for example) to send mail, with the option of the receiver refunding the penny once received.
There NEEDS to be some kind of financial hit for the sender to send spam. It's the only incentive that entities with no concience (Ie, spammers, or corporations) will listen to.
Although it's not detailed in the report, I don't think the scenario you're describing is a problem. All you need to do is to redefine 'sender' to be the originator of the email, and NOT the first MTA the email hits. Ie, the 'sender' is the spamming mail client. The ISP's MTA, for example, would demand the same ticket exchange that the receiving MTA demands. In effect, the resultant ticket exchange is the sending client, and the receiving client... the MTAs just pass tickets along.
Slashdot Mirror
1. Does it play Ogg?
Only if you're referring to "Ogg the Barbarian".
2. How many can you run in a Wolfpack?
About 12, but after a couple of miles, the wolves get antsy and tear them to pieces.
Today? Sheesh... you're behind the times. Roomie got his yesterday! :)
My bad, it was only a 16-bit ISA connector. I found an old brochure.
I had a Ultrasound Max for the longest time, but when I upgraded my MoBo to a Pentium, the damn thing would just not work. It turned out that the Pentium ISA bus did something really weird to keep the timing at 8MHz. Every 16 clock cycles it would introduce a 1/8 cycle extension, and as far as I could tell, that sent the Ultrasound into a tailspin.
I found that out, of course, after about 10 hours debugging with a digital oscilloscope. The support engineers were so grateful that they replaced my Max for a Ultrasound PnP for NOTHING. And, that worked a treat.
As far as I can remember, the PnP was a PCI card. Unfortuantely, I can't use it in my Mac ;)
Hardly innovative. The Gravis Ultrasound was doing all of that long before the AWE32 hit the market.
What I mean is that if I want to pull a small block up in C or perl I just change the indenting. An extra syntax to allow that seems a little silly. I'd think that a (normally phrased) conditional followed by a statement, followed by unindented code, should be interpreted properly without having a new syntax.
;) :
I think I understand what you mean here, and it's still a non argument. For example, the following two python snippets are equivalent (underscores used to force indenting: stupid slashdot
if somecondition:
_ somestatement
if somecondition: somestatement
Ie, no extra syntax to 'pull up' a block, if that was what you meant. OTOH, if you meant taking some statements out of the if block, and have them always execute, then it works just as well in python:
if somecondition:
_ statement1
_ statement2
Turns into:
if somecondition:
_ statement1
statement2
With the BIG advantage that you don't have to relocate any braces just to take 'statement2' out of the if block. Just unindent. However, if you wanted to bring BOTH statements out of the IF, you need to tell python that you intended to leave the If block empty:
if somecondition:
_ pass
statement1
statement2
So, yes, there's some extra syntax there (the 'pass'), but that's a GOOD THING in my book, as you're telling the parser that you intended the IF to be empty.
One downside is it's harder to temporarily edit out a block of code with a 'if (0)', because you HAVE to indent the block for it to take effect. In that case, it's easier to just use most editors 'add in a comment marker to all these lines'. There is one saving grace, though, in that the parser has a good chance of picking up badly marked blocks because of the indenting rules.
You don't exactly sound anti-Python, there :) Responding accordingly:
Anyways, the example is also a demonstration of why that brace style isn't the _One True Way_
I thoroughly agree. When I code C I always put the brace on the same line as the condition. That's not how a lot of people code C, though. Furthermore, this is trying to solve a deficiency in the language with a coding style (not the first, nor the last, this'll happen), and if you're making that argument, it also argues for python's indenting requirement. Python just happens to use that indenting as a syntatic construct, which in turn forces indenting. This is a Good Thing in my book.
But, for a typo, any comparison in there is just as bad, it won't do what you expect.
However, you can ensure that common typos are caught by the parser. In python, two common typos are caught. See my previous comment regarding matching indent blocks and the ':' element. Also, python doesn't suffer from accidental use of '=' instead of '==' in a conditional, since a value assignment is a statement, and not an expression. Yes, I'm aware that most modern C compilers catch this error, but not always.
I was writing hello-world type code in python and I remember it as having two syntaxes for an if, one that required an indented block and one that was meant for one line. I found this awkward and I prefer being able to use explicit controls (braces) to put a block where I want it. Was I mistaken?
You're not mistaken. See my other previous comment for details. However, I think this is a non-argument. If you dont want to put the block on the same line, then just don't. All you need to do is indent it some, just like you would be doing anyway.
I do agree that perl's use of regexps is really easy, but Perl gets that because regexps are part of the language. By contrast, Python puts that into a library, which makes it a little harder to use compactly, but certainly not hard to use. Additionally, it allows for very clear use of pre-compiled expressions, and having multiple expression match results active at the same time. Something which is awkward in Perl.
Is this a problem with python, or with the channel that doesn't even allow for leading spaces to lines?
I don't think "can be posted to slashdot as comments without some non-standard befunkery" is a particually good feature point, especially since slashdot still screws up any indenting that would make a piece of C or Perl code readable.
For other channels you can leave the python as-is (since I don't know of any other channels that screw it up the same way slashdot does), you can use pyindent.py, or just encode it.
And a second followup...
;)
Python also has block redundancies. You must introduce a new block with the ':' syntatic element. If you indent and you don't have that, the parser gives you a SyntaxError exception (A real python exception, too, that you can trap, if you're doing run-time interpretation of code).
Similarly, if you use ':' and you DON'T indent, you'll also get a SyntaxError.
The only exception would be ending a block earlier than anticipated. Ie, you forget to indend the last line of the block (an example that I raised elsewhere). And, that's something that's going to be pretty damn obvious on the screen. Compare that minor gaff with the following gaff common in C
if ( x < 0 );
{
x = 0;
underflow = 1;
}
Which will NOT do what you expect. This situation is not possible in Python (nor in Perl, actually, but I bet you could find a similar 'one character changes the entire meaning' in perl too
Followup...
Actually, I shouldn't have said 'whitespace to determine semantics', because that's not correct at all. It's 'INDENTING determines semantics' which is a whole bunch less offensive. Apart from the indenting, whitespace is NOT significant in python.
Yes, I did notice that (which is why I commented on it, so you didn't have to). I've also done my fair share of cobol programming and hated it. Python's use of whitespace to determine semantics is wholly different from that.
Personally, I much prefer having the visual structure and 'actual structure' be the same thing, rather than separate concepts as in something like C or perl. The reduction in time debugging programs because of something that looks blocked correctly but isn't, because the {} and indenting mismatch, has been significant. Yes, I appreciate that I could run my C and perl programs though a prettyprinter, but EVERY time a program doesn't work properly? No thanks.
Remember, I'm not saying that this particular feature is a massive boon, only that it's not as significant as a lot of folk make it out to be. When first instroduced to it, I too was turned off by that particular quirk, but after a day, it's second nature. Challenge yourself, surprise yourself... write your next 1000-line project in Python.
if x < 0: x = 0
Or even two throwaway statements:
if x < 0: x = 0; underflow = 1
But you need to use indending if your true condition follows multiple lines:
if x < 0:
_ x = 0
_ underflow = 1
_ window.messagebox ( "Underflow." )
(_ is used to force an indent)
If you've got a block, and you're NOT indenting, then I certainly wouldn't want you on my programming team :)
(And, yes, this post gives a good demonstration of one of the downsides of python's indenting requirements. My opinion: the upsides outweigh the downsides)
The lack or addition of a tab in Python usually DOES result in a compile time error (well, as compile-time as scripting languages go... you can run 'compileall.py' on your .py files as a check, too).
There are some cases where it doesn't. ie, if you've forgotten to indend the last like of an IF block, then that line will be excecuted outside of the IF. However, if you just LOOK AT your code, it's bloody obvious what's going on. This is no different than, say, forgetting to put braces after an IF in C, or some other gaff.
-- Used perl, tried python, switched, never looked back.
The first day, it will feel really weird.
The second day, you'll forget all about it, because all you have to do is indend like you'd indent anyway. Ie, what you see IS what you get.
Two ports on the same host. The ports are connected to various points on a network to measure latency between those parts. The setup we have is fast enough, as long as the timestamps are accurate enough.
Thanks, I'll give it a try and see what I get.
;) a latency meter. Measures the time between the same packet appearing at two ethernet ports. I'm using the difference between the timestamp as reported by libpcap as the 'latency', but I also apply a little filtering to remove time recording noise, and a small amount of priority bias.
I've written (not trying
Microsecond resolution works pretty well. 10-millisecond resolution just doesn't cut it.
I've written a little application around libpcap that needs the microsecond resolution for packet arrival times. 2.2 has that. 2.4 only gives me 10 millisecond resolution.
You're talking about a company that is on it's death throes. Sure, they might be able to get a chunk of goodwill, but without a viable product to sell, they can't convert that goodwill into cash.
The edict of running a public company is to make money. The executives are dutybound to squeeze every last dollar out of what they can before they go under, and rest assured, go under they will.
Unfortuantely, what will happen is that in the liquidation, the IP will be sold off to another company and they, too, will see what sort of money they can squeeze out of it. I bet it's PanIP that buys the IP... any takers?
The suit is against IBM at the moment. There's no guarantee that they won't also go after other companies that have 'used versions of Linux containing contributions made by IBM who misappropriated them from SCO'. No guarantees at all.
A companies purpose is to make money. If they win against IBM (and I'm not betting on that one, no way), then they are dutybound to their shareholders to increase the value of the shares, and then they'll start going after everyone else.
The ONLY valid solution is to lobby government to abandon such intellectual property rights. I don't mean give them up completely, but the current state of affairs is certainly not working.
Saying they cut their own reeds is exactly analogous to companies cutting their own code. Of course, they're just cutting the part they need customised, and not all of it.
For example, we'll write our own web application because no application out there does a particuar job as well as we need it to, but we don't write our own OS or Web server or script interpretor, do we? No... we'll build on existing applications.
There is no one 'Right' solution, but it will depend on how closely any application fits the needs of a company. In some cases, an off-the-shelf product will do the job, in others, perhaps a bit of tweaking, and in still others, perhaps a completely new application.
However, obtaining a sending 'identity' needs to be non-free (either by time, or money), or spammers will just obtain as many identities as required in order to send spam AND, a list of 'known spamming identities' needs to be maintained. Ie, this is only marginally better than what we have now.
Alternatively, the identities could be linked to individuals, meaning that you will not want to risk sending spam with your identity. However, this removes a LOT of anonimity of email and I'm sure people, even 'non-spamming' people, will balk at this.
I really do believe that the only solution is to change a small amount (a penny, or something settable by the recipient, for example) to send mail, with the option of the receiver refunding the penny once received.
There NEEDS to be some kind of financial hit for the sender to send spam. It's the only incentive that entities with no concience (Ie, spammers, or corporations) will listen to.
Although it's not detailed in the report, I don't think the scenario you're describing is a problem. All you need to do is to redefine 'sender' to be the originator of the email, and NOT the first MTA the email hits. Ie, the 'sender' is the spamming mail client. The ISP's MTA, for example, would demand the same ticket exchange that the receiving MTA demands. In effect, the resultant ticket exchange is the sending client, and the receiving client... the MTAs just pass tickets along.
Yes, those photos at the URL you mentioned are 9.1, the one I was referring to was the OS/X dock, which is absent in 9.1
Considered that the Mac might be dual-boot ?
Bzzt.
Look at the left side of the screen. That's the OS/X Dock.