I live in South Australia and buy power from the grid, and I think I would have noticed if this were true as presented here.
The referenced article appears to refer to wholesale spot prices - the electricity market in Australia is, through an artificial market created in the wake of privatization, structured as wholesale provider (usually, generators) selling to retail entities, that then sell power to end users. Consumers sign up for an "agreed tariff" contract arrangement with a pricing structure at least as opaque as any mobile phone regime, and retailers buy off the wholesalers at spot prices that vary more or less minute by minute, depending on demand. Those wholesale prices do routinely spike and crash over the course of a day - especially during summer - as factories start up and shut down, people turn their air conditioners on and off, and so on. It doesn't help that power is distributed across different timezones - SA users routinely use power generated in Victoria, and vice versa, which itself creates artificially high peaks and troughs.
It also doesn't help that politics gets involved - most providers see the writing on the wall and are trying to transition away from coal-based generation, but with a major coal industry to support they've seen significant push-back from government, which last year proposed putting out to tender the construction of new coal-based generation, because private industry wasn't willing to undertake it in a free market.
For the benefit of any non-antipodeans, I'd observe that these would be Australian magpies - not closely related to Eurasian mapgpies (which are corvids).
Australian magpies are smart birds that form complex social structures, and can identify - and establish enduring relationships with - individual people. Currawongs are their near cousins, most common in the East of Asutralia; both are related to the Butcherbirds.
Wild guess, things get tricky when you install your next OS update - expect a complaint that you're installing on 3rd party hardware. If so, expect to hand over money at an Apple store to fix it.
You misunderstand how BCCs (or perhaps the SMTP envelope) works.
BCC, like any email header, is part of the email body, and is likely to be preserved as part of the email body until 'final delivery', at which point it *may* be removed by the MTA. I say *may*, because what constitutes final delivery isn't as well-defined as you might suppose (think procmail or fetchmail), and MTAs may be configured to preserve Bcc for the benefit of users/downstream mail systems. And *any* MTA that handles a copy of the message may see the BCC header, as it isn't guaranteed to be removed until delivery, if at all.
The SMTP envelope is what actually determines routing in a pure SMTP system, and MUAs typically construct the SMTP envelope from the email body when talking to whatever SMTP agent you configure them to use - but this isn't always the case (think mailing lists). Additionally, the SMTP envelope only carries those addresses you're asking the SMTP server to route - if you're the originating MUA that's every addressee, but if you're a recipient's MTA that's only the addresses you're expected to actually deliver to.
A further wrinkle, which I glossed over in my original post, involves the 'Received from' headers that each MTA will add to the meesage - if they are receiving the message for a single recipient this will generally include the recipient address, so for best security (i.e., to protect the recipient's identity even if someone third party stumbled across a copy of the message including all headers, as it was deliviered to the anonymous recipient) you'd ideally want them to have two separate mailboxes on the same mail system, and send it to both - that way the 'Received from' headers would nwever contain an actual recipient address.
If you are trying to keep the addressee information private, it shouldn't appear in the body *or* headers of the email at all - the SMTP envelope is the only place it has to appear.
Of course, that would mean not sending an email on the spur of the moment without any precautions or planning, so I suppose that renders it implausibly difficult for people aspiring to an elected office.
You're fine with firmware that's soldered onto the board as a non-FRU mask-programmed ROM, but if it's loaded as a vendor-supplied blob that can (at least in principle) be updated as issues are identified, that's bad?
I hadn't noticed what source you're citing as your authority, but our development process reflected (among other things) the requirements of our strategic partners which included firms like Intel, which went over the place and the development process with a fine-tooth comb just before I started.
You've referred several times to maintaining objective distinctions between alpha, beta and rc, but those of your posts that I've read seem not to demonstrate that, and appear to blur the line in a way that makes it hard for me (at least) to see what you believe those distinctions are; but then, you've posted so many responses to this article I may simply have missed it. Care to provide a URL to the post where you set out those objective distinctions, or cite the authority you rely on?
Well we're all entitled to our own opinions and interpretations, but in the last place I did development feature freeze always preceded or coincided with the transition from alpha to beta: adding new features implies adding untried code, which (however clean it looked to the developer) would be classified as alpha quality by the standard of those who set the rules.
We also never (well, *almost* never) provided beta software to anyone outside our organization - beta was always about debugging, and preparing to pass formal testing. Important customers or those with urgent needs might occasionally see release candidates (which were considered 'post-beta').
In the olden days there was also a gamma stage, but you rarely hear about that nowadays.
OSS changes the rules and blurs the lines between beta and RC, but any significant new code is always alpha in my book.
Bribes are rarely paid either to or by governments, but pass between corrupt individuals and corporations. It takes more than the will of the government to prevent corruption (I'm sure the US is opposed to corruption, but in the past US corporations have made and received bribes; and at least equally so in Britain) and preventing corruption doesn't magically make the money involved available for the public good, although it may (e.g.) reduce defence spending in the medium term by permitting a (more) free and efficient market to develop.
You don't need to blame Reagan for the cold war; there are plenty of other things you could blame him for - for instance, his campaign team worked secretly and hard to delay the release of US hostages in Iran so Carter wouldn't get credit for it.
Do I have a point? Not really, except that trust requires far more than simply a lack of blame, and that arguing the toss about whether trust or blame is justified demonstrates an absence of trust, justified or not.
According to the Register article, Dell say they only support the OS they install; as they do not install an OS in these boxes, it appears there are *no* software support costs involved. So that (at least, that in so many words) does not explain the higher price.
Your diet affects the receptors in and overall composition of neural membranes, and real-world things like reading a novel, learning the piano, or selling insurance affect its overall structure; any skill you learn, anything you can remember and draw from in later life.
Right now, for the most part, we have only the coarsest understanding of the nature and significance of these changes, and what's 'bad' as opposed to good or neutral; but they are real and there, as evidenced by your ongoing personal growth since puberty - you just aren't the same person you were 5 years ago, regardless.
And, of course, if Marijuana didn't have any effect on your brain at all, I expect you'd change suppliers at the very least:)
Some things you should bear in mind to go along with your argument:
- Schizophrenia is a 'young person's' disease: the greater majority (80% rings a bell) of 'regular' schizophrenia manifests in juveniles or young adults, so it's not clear whether a reduced risk in adults is in any way peculiar to a cannabis-induced psychosis;
- There's substantial evidence for 'self-medication' in both diagnosed and undiagnosed schizophrenics - their 'real world' may be so confused and distressing that anything that reduces their anxiety, or their awareness of and sense of personal involvement in their daily life, may be very attractive; this makes it hard to distinguish a drug-induced psychosis from an existing one that is either aggravated by drug use, or simply accompanied by self-medication.
You don't specify which study you're referring to, but some such studies have been criticised for poor sampling; e.g., selecting their sample from a group that has already received psychiatric treatment.
That's not to say you're wrong or right, but to point out that science in this area is difficult to produce and interpret for many reasons.
On this particular route, most of your objections aren't really a concern.
Modern trains can (and generally do) use regenerative braking anyway, but for most of the drive you would probably average about 1 rail crossing every few hundred kilometers, and over that part of the trip the total rise and fall probably need not be more than about 1000 feet (get out an atlas and check out the contour lines over most of Australia, ignoring the east coast).
The trains only need to be as light as you'd prefer for acceleration, but of course for freight the weight of the train would not be the limiting factor.
Oh, and solar cells tend not to just break unless you hit them, and I expect never to travel on a fusion-powered train.
While the Comnmodore is ubiquitous, it's the original Monaro that is the true icon. They were made in the 1970's and were every young Australian male's wet dream, but faded from view as petrol prices rose and people became more concerned with economy; the originals are highly collectible, and Holden re-invented the Monaro recently and they've become quite popular (but nothing like they were).
The Commodore line appeared about the same time as the Monaro faded from view and, while thoroughly ubiquitous (no bad thing, when 70% of our land area would be more than 3 hours' drive from a well-stocked dealership), is an Australian icon only in the same sense that, say, the cockroach is a Texan icon.
Just as an aside, the canard about Greece being a democracy (the only 'true' democracy, the first democracy, whatever) really needs to have a stake driven through its heart and extinguished once and for all.
Firstly, most people say 'Greece' when they really mean 'Athens, from time to time'; Greece was a geographical region, not a nation or federation of any meaningful kind, and had no government of its own; Athens had periods of government-by-the-people interspersed with Tyranny.
Only citizens got to vote in Athens; doesn't sound so bad until you realise that this excluded slaves, women, and many other residents whoe weren't born in Athens; someone somewhere has estimated that less than 5% of the population were citizens.
The Vikings were at least as democratic; they had 'kings' and so on, but they ruled by consent and were subject to potential replacement by the population at regular gatherings called Things, which also thrashed out laws, major disputes and so on; government and leadership in Viking communities was not by fiat or divine authority, but with the support and approval of the group.
Of course they still held slaves who didn't have a say (but in much smaller numbers than in Athens), and women (generally, but not always) were effectively disenfranchised, but this contrasts with Athenian democracy which was essentially a private club available only to an elite. There's also clear evidence that slaves and women had legal protection in most Viking communities (although it was much cheaper to kill a slave than a freeman), which wasn't really the case in Athens.
The oldest democracy still in existence is almost certainly Iceland, founded by Vikings, and which has a recognizably democratic form of government that dates back to the 11th or 12th century.
An additional concern, and one not addressed by the notice on methlabs.org, is that the passwords they are asking you to confirm and then replace are, presumably, the same passwords in the 'backups' used by the 'developer group'; if the methlabs.org site were both sincere and competent, they would have told you to change your passwords with *both* the Empire and the Rebel Alliance (and using different new passwords for each), as there's obviously some doubt as to which side is which.
As it is, he's advising you to suspend your own judgement and assume that methlabs.org is the only one you should trust; while it may be true, and they'd know if it was, providing instructions that don't allow you to CY own A is dubious and unnecessary.
And whether he's trustworthy or not, he's effectively asking you for the keys to your identity with the other group. Noone deserves that level of trust, least of all in a situation like this.
If you really want to 'pass a filehandle' and don't want the convenience of modern methods or passing a reference to its symbol table, you can always pass the underlying file descriptor number, but I can't see the appeal myself; the methods you despise arose when Perl was very young and file handles were first added as 'first and a half class citizens', and Perl5 gives you a more convenient, modern alternative; it's not Perl5's fault if you won't use them when you want portable, scalable code.
The CORBA issues you have are almost certainly the fault of your CORBA interface; in the glue that ties Perl to C, it's much harder to get the memory management right - the interface has to ensure that C and Perl agree not only on the size and structure of items, but who's responsible for managing them; it's possible that (e.g.) the C Corba routines were being passed memory allocated by Perl and then passing it to free() or realloc(), or just hanging on to it until after Perl had GC'd it. Or something silly like passing an int when you need a long, or allocating a buffer of 32 bytes for a string of no more than 32 characters, etc.
I can't comment on Parse::RecDescent, never having actually used it; however the changelog for version 1.24 references a bugfix that sounds like it may be your issue.
Personally, when writing code that may have to read multiple ini files multiple times (sadly, a common requirement), I'd normally use a global hash to cache the parsed files - if there's one thing worse than attempting to extract allegedly useful information from a knock-kneed, illegitimate format like an.ini file, it's wasting time parsing the same file twice.
And Haskell looks really neat - as a one-time fan of declarative languages I think most people take far too narrow a view on what a language should look like and how it should 'work', and I'm more than happy to give a cheer for functional languages.
>...why did the other poster put an arrow between the brackets?
'->' is the dereferencing operator; it's a postfix operator that translates as 'the thing this is a reference to', but also turns up in the OO syntax as a way to reference an object's methods.
I omitted it because I can, and I'm lazy; the '[0]' is something that's only available for arrays, and as a convenience Perl5 allows me to omit the dereference in contexts like this where there's no ambiguity; for instance if I say
my $a = [ { squared => 0, cubed => 0 },
{ squared => 1, cubed => 1 },
{ squared => 4, cubed => 8 }
]; then I can use
$a->[2]{squared}
Well, you can't have your cake and eat it too; I told you what to do with @a, which is what you used in your example; for my alternative, you'd use
$a->[0][0]
instead; (almost) any reference can be dereferenced in this way.
FE:
my $x = sub {
return shift;
}
my $a = $x->(1);
Unless you do something to localize it, a variable is global; if you don't specify a scope then there are few options. This is true of almost all languages that don't rely on explicit declarations. If you aren't familiar with the concept, then I'm guessing you've done a fair bit more PHP or VB than Perl (and haven't read many of the Perl manpages).
Using a glob reference doesn't solve this problem - just disguises it by creating a reference to a symbol table slot; unless you've done something to ensure that the reference is to a localized variable, it's a poor practice that would be non-portable in any context; like using hard-coded file descriptor numbers would be in a C library function (to which this practice is broadly equivalent).
Your comment 'If it works with a goddamn hash table, it should work with a frigging filehandle as well!' is just wrong; hash tables are purely internal constructs, whereas file handles are connected to the Real World and must conform to the requirements of the underlying system calls; in Perl4, each filehandle maps onto a file descriptor number that is global to the application - nothing you or I can do about that, although we're free to shuffle around how they're hooked up internally. Perl4 passes this model up to your code, and maps each descriptor to a symbol name (some pre-defined, some created as you open & close file handles); Perl5 provides an abstraction layer that hides these details, but they're still there underneath. If you don't want the hassle of dealing with the nuts-and-bolts (and you strike me as the kind of person who doesn't), use the abstraction layer and this particular poblem will largely go away.
Perl 5 provides a clean, almost infinitely flexible OO environment you can use to build clean, scalable, protable code; if you don't use them, then I can't see it as Perl's fault if your code isn't clean, portable or scalable.
The corollary is that Perl5 provides almost complete compatible with Perl4, and if you take advantage of that then you shouldn't be surprised if your Perl5 code looks like Perl4, and is relatively unportable and unscalable.
As for your application issues, I'll pass more or less silently over issues like blaming the language because coder's can't type, and handing apparently untested code onto users; but some of the things you mentioned would prompt me to say 'Check the scope of your variables'; as for segfaults from an over-eager garbage collector - excuse me?? The only issues I've ever had with the garbage collector in Perl is that it's sometimes so cautious to avoid breaking circular references that it needs explicit help (which,m along with uncontrolled use of globas, may explain the 'memory leaks' you saw).
And if you're paying, feel free to foist some of that horror my way:)
Just because things *can* be hard or ugly, doesn't mean they *need* to be.
To answer your question:
$a[0][0]
Also, you don't need @{$a[0]}; $a[0] is every bit as much the 'first row of the matrix', just expressed as a reference than a list; in practice, it's more likely that's what you want most of the time anyway.
As for filehandles, if you want to write code that is reusable or scale, you'll do something like this:
use IO::File;
my $fh = new IO::File('/etc/passwd');
or you will need to take special measures to avoid polluting the global namespace (just like in any other language that allows you to use globals for your own ends).
Many of the things you (and most people) complain about are things that are in Perl5 because they were in Perl4, and the Perl community has never been keen to break compatibility with a huge library of existing code, or require people to change their habits just because; however that doesn't mean you're smart to use them in projects of any scale.
Well, LEFT JOIN should give you a whee.blib = for every row in foo; the whole point of a LEFT JOIN is that you'll get a 'dummy row' with NULLs for whee.* if there is no 'real' row in whee that satisfies the JOIN condition. If that's not happening for you, then either MySQL's LEFT JOIN is broken or perhaps it's something about how you're typing 'WHERE whee.blib IS NULL'.
Alternatively, if you're joining o an indexed column and the index is corrupt or incomplete the DBMS may not find all of the rows vin an index scan.
It shouldn't matter when the WHERE is evaulated, the same rows will be found - it's just open to the query planner to use the WHERE clause to restrict the number of joined rows it considers. rather than to do a full left join (including rows with whee.* set to NULL for rows in foo without a corrresponding whee which satisfies the join condition) and then wade through the results.
SELECT * FROM foo LEFT JOIN whee ON bar.foo = whee.blib WHERE whee.blib IS NULL;
The DBMS can optimize this however it likes; using the WHERE clause to limit the JOINed rows is a basic optimization, easy for the optimizer to spot. The NOT IN clause may be more efficient still (requires less smarts from the optimizer), but in its absence the LEFT JOIN is potentially orders of magnitude better than HAVING - it depends how big whee and bar are, and how many rows there are in the result set.
Slashdot Mirror
I live in South Australia and buy power from the grid, and I think I would have noticed if this were true as presented here.
The referenced article appears to refer to wholesale spot prices - the electricity market in Australia is, through an artificial market created in the wake of privatization, structured as wholesale provider (usually, generators) selling to retail entities, that then sell power to end users. Consumers sign up for an "agreed tariff" contract arrangement with a pricing structure at least as opaque as any mobile phone regime, and retailers buy off the wholesalers at spot prices that vary more or less minute by minute, depending on demand. Those wholesale prices do routinely spike and crash over the course of a day - especially during summer - as factories start up and shut down, people turn their air conditioners on and off, and so on. It doesn't help that power is distributed across different timezones - SA users routinely use power generated in Victoria, and vice versa, which itself creates artificially high peaks and troughs.
It also doesn't help that politics gets involved - most providers see the writing on the wall and are trying to transition away from coal-based generation, but with a major coal industry to support they've seen significant push-back from government, which last year proposed putting out to tender the construction of new coal-based generation, because private industry wasn't willing to undertake it in a free market.
For the benefit of any non-antipodeans, I'd observe that these would be Australian magpies - not closely related to Eurasian mapgpies (which are corvids). Australian magpies are smart birds that form complex social structures, and can identify - and establish enduring relationships with - individual people. Currawongs are their near cousins, most common in the East of Asutralia; both are related to the Butcherbirds.
Wild guess, things get tricky when you install your next OS update - expect a complaint that you're installing on 3rd party hardware. If so, expect to hand over money at an Apple store to fix it.
My favourite will probably always be The Reproductive System by John Sladek.
and I'm sure we all agree it's a tremendous achievement; but before we get too congratulatory, remember - now we have to bring them back.
You misunderstand how BCCs (or perhaps the SMTP envelope) works.
BCC, like any email header, is part of the email body, and is likely to be preserved as part of the email body until 'final delivery', at which point it *may* be removed by the MTA. I say *may*, because what constitutes final delivery isn't as well-defined as you might suppose (think procmail or fetchmail), and MTAs may be configured to preserve Bcc for the benefit of users/downstream mail systems. And *any* MTA that handles a copy of the message may see the BCC header, as it isn't guaranteed to be removed until delivery, if at all.
The SMTP envelope is what actually determines routing in a pure SMTP system, and MUAs typically construct the SMTP envelope from the email body when talking to whatever SMTP agent you configure them to use - but this isn't always the case (think mailing lists). Additionally, the SMTP envelope only carries those addresses you're asking the SMTP server to route - if you're the originating MUA that's every addressee, but if you're a recipient's MTA that's only the addresses you're expected to actually deliver to.
A further wrinkle, which I glossed over in my original post, involves the 'Received from' headers that each MTA will add to the meesage - if they are receiving the message for a single recipient this will generally include the recipient address, so for best security (i.e., to protect the recipient's identity even if someone third party stumbled across a copy of the message including all headers, as it was deliviered to the anonymous recipient) you'd ideally want them to have two separate mailboxes on the same mail system, and send it to both - that way the 'Received from' headers would nwever contain an actual recipient address.
John.
Well, not very.
If you are trying to keep the addressee information private, it shouldn't appear in the body *or* headers of the email at all - the SMTP envelope is the only place it has to appear.
Of course, that would mean not sending an email on the spur of the moment without any precautions or planning, so I suppose that renders it implausibly difficult for people aspiring to an elected office.
John.
So, from what you say:
You're fine with firmware that's soldered onto the board as a non-FRU mask-programmed ROM, but if it's loaded as a vendor-supplied blob that can (at least in principle) be updated as issues are identified, that's bad?
Interesting tradeoff...
John.
I hadn't noticed what source you're citing as your authority, but our development process reflected (among other things) the requirements of our strategic partners which included firms like Intel, which went over the place and the development process with a fine-tooth comb just before I started.
You've referred several times to maintaining objective distinctions between alpha, beta and rc, but those of your posts that I've read seem not to demonstrate that, and appear to blur the line in a way that makes it hard for me (at least) to see what you believe those distinctions are; but then, you've posted so many responses to this article I may simply have missed it. Care to provide a URL to the post where you set out those objective distinctions, or cite the authority you rely on?
John.
Well we're all entitled to our own opinions and interpretations, but in the last place I did development feature freeze always preceded or coincided with the transition from alpha to beta: adding new features implies adding untried code, which (however clean it looked to the developer) would be classified as alpha quality by the standard of those who set the rules.
We also never (well, *almost* never) provided beta software to anyone outside our organization - beta was always about debugging, and preparing to pass formal testing. Important customers or those with urgent needs might occasionally see release candidates (which were considered 'post-beta').
In the olden days there was also a gamma stage, but you rarely hear about that nowadays.
OSS changes the rules and blurs the lines between beta and RC, but any significant new code is always alpha in my book.
John.
That depends what you mean by 'Taiwan'.
Bribes are rarely paid either to or by governments, but pass between corrupt individuals and corporations. It takes more than the will of the government to prevent corruption (I'm sure the US is opposed to corruption, but in the past US corporations have made and received bribes; and at least equally so in Britain) and preventing corruption doesn't magically make the money involved available for the public good, although it may (e.g.) reduce defence spending in the medium term by permitting a (more) free and efficient market to develop.
John.
You don't need to blame Reagan for the cold war; there are plenty of other things you could blame him for - for instance, his campaign team worked secretly and hard to delay the release of US hostages in Iran so Carter wouldn't get credit for it.
Do I have a point? Not really, except that trust requires far more than simply a lack of blame, and that arguing the toss about whether trust or blame is justified demonstrates an absence of trust, justified or not.
John.
According to the Register article, Dell say they only support the OS they install; as they do not install an OS in these boxes, it appears there are *no* software support costs involved. So that (at least, that in so many words) does not explain the higher price.
John.
Almost everything you do modifies the brain.
:)
Your diet affects the receptors in and overall composition of neural membranes, and real-world things like reading a novel, learning the piano, or selling insurance affect its overall structure; any skill you learn, anything you can remember and draw from in later life.
Right now, for the most part, we have only the coarsest understanding of the nature and significance of these changes, and what's 'bad' as opposed to good or neutral; but they are real and there, as evidenced by your ongoing personal growth since puberty - you just aren't the same person you were 5 years ago, regardless.
And, of course, if Marijuana didn't have any effect on your brain at all, I expect you'd change suppliers at the very least
John.
Some things you should bear in mind to go along with your argument:
- Schizophrenia is a 'young person's' disease: the greater majority (80% rings a bell) of 'regular' schizophrenia manifests in juveniles or young adults, so it's not clear whether a reduced risk in adults is in any way peculiar to a cannabis-induced psychosis;
- There's substantial evidence for 'self-medication' in both diagnosed and undiagnosed schizophrenics - their 'real world' may be so confused and distressing that anything that reduces their anxiety, or their awareness of and sense of personal involvement in their daily life, may be very attractive; this makes it hard to distinguish a drug-induced psychosis from an existing one that is either aggravated by drug use, or simply accompanied by self-medication.
You don't specify which study you're referring to, but some such studies have been criticised for poor sampling; e.g., selecting their sample from a group that has already received psychiatric treatment.
That's not to say you're wrong or right, but to point out that science in this area is difficult to produce and interpret for many reasons.
John.
On this particular route, most of your objections aren't really a concern.
Modern trains can (and generally do) use regenerative braking anyway, but for most of the drive you would probably average about 1 rail crossing every few hundred kilometers, and over that part of the trip the total rise and fall probably need not be more than about 1000 feet (get out an atlas and check out the contour lines over most of Australia, ignoring the east coast).
The trains only need to be as light as you'd prefer for acceleration, but of course for freight the weight of the train would not be the limiting factor.
Oh, and solar cells tend not to just break unless you hit them, and I expect never to travel on a fusion-powered train.
John.
While the Comnmodore is ubiquitous, it's the original Monaro that is the true icon. They were made in the 1970's and were every young Australian male's wet dream, but faded from view as petrol prices rose and people became more concerned with economy; the originals are highly collectible, and Holden re-invented the Monaro recently and they've become quite popular (but nothing like they were).
The Commodore line appeared about the same time as the Monaro faded from view and, while thoroughly ubiquitous (no bad thing, when 70% of our land area would be more than 3 hours' drive from a well-stocked dealership), is an Australian icon only in the same sense that, say, the cockroach is a Texan icon.
John.
Just as an aside, the canard about Greece being a democracy (the only 'true' democracy, the first democracy, whatever) really needs to have a stake driven through its heart and extinguished once and for all.
Firstly, most people say 'Greece' when they really mean 'Athens, from time to time'; Greece was a geographical region, not a nation or federation of any meaningful kind, and had no government of its own; Athens had periods of government-by-the-people interspersed with Tyranny.
Only citizens got to vote in Athens; doesn't sound so bad until you realise that this excluded slaves, women, and many other residents whoe weren't born in Athens; someone somewhere has estimated that less than 5% of the population were citizens.
The Vikings were at least as democratic; they had 'kings' and so on, but they ruled by consent and were subject to potential replacement by the population at regular gatherings called Things, which also thrashed out laws, major disputes and so on; government and leadership in Viking communities was not by fiat or divine authority, but with the support and approval of the group.
Of course they still held slaves who didn't have a say (but in much smaller numbers than in Athens), and women (generally, but not always) were effectively disenfranchised, but this contrasts with Athenian democracy which was essentially a private club available only to an elite. There's also clear evidence that slaves and women had legal protection in most Viking communities (although it was much cheaper to kill a slave than a freeman), which wasn't really the case in Athens.
The oldest democracy still in existence is almost certainly Iceland, founded by Vikings, and which has a recognizably democratic form of government that dates back to the 11th or 12th century.
John.
An additional concern, and one not addressed by the notice on methlabs.org, is that the passwords they are asking you to confirm and then replace are, presumably, the same passwords in the 'backups' used by the 'developer group'; if the methlabs.org site were both sincere and competent, they would have told you to change your passwords with *both* the Empire and the Rebel Alliance (and using different new passwords for each), as there's obviously some doubt as to which side is which.
As it is, he's advising you to suspend your own judgement and assume that methlabs.org is the only one you should trust; while it may be true, and they'd know if it was, providing instructions that don't allow you to CY own A is dubious and unnecessary.
And whether he's trustworthy or not, he's effectively asking you for the keys to your identity with the other group. Noone deserves that level of trust, least of all in a situation like this.
John.
If you really want to 'pass a filehandle' and don't want the convenience of modern methods or passing a reference to its symbol table, you can always pass the underlying file descriptor number, but I can't see the appeal myself; the methods you despise arose when Perl was very young and file handles were first added as 'first and a half class citizens', and Perl5 gives you a more convenient, modern alternative; it's not Perl5's fault if you won't use them when you want portable, scalable code.
.ini file, it's wasting time parsing the same file twice.
The CORBA issues you have are almost certainly the fault of your CORBA interface; in the glue that ties Perl to C, it's much harder to get the memory management right - the interface has to ensure that C and Perl agree not only on the size and structure of items, but who's responsible for managing them; it's possible that (e.g.) the C Corba routines were being passed memory allocated by Perl and then passing it to free() or realloc(), or just hanging on to it until after Perl had GC'd it. Or something silly like passing an int when you need a long, or allocating a buffer of 32 bytes for a string of no more than 32 characters, etc.
I can't comment on Parse::RecDescent, never having actually used it; however the changelog for version 1.24 references a bugfix that sounds like it may be your issue.
Personally, when writing code that may have to read multiple ini files multiple times (sadly, a common requirement), I'd normally use a global hash to cache the parsed files - if there's one thing worse than attempting to extract allegedly useful information from a knock-kneed, illegitimate format like an
And Haskell looks really neat - as a one-time fan of declarative languages I think most people take far too narrow a view on what a language should look like and how it should 'work', and I'm more than happy to give a cheer for functional languages.
John.
Forgot one of your questions:
...why did the other poster put an arrow between the brackets?
>
'->' is the dereferencing operator; it's a postfix operator that translates as 'the thing this is a reference to', but also turns up in the OO syntax as a way to reference an object's methods.
I omitted it because I can, and I'm lazy; the '[0]' is something that's only available for arrays, and as a convenience Perl5 allows me to omit the dereference in contexts like this where there's no ambiguity; for instance if I say
my $a = [ { squared => 0, cubed => 0 },
{ squared => 1, cubed => 1 },
{ squared => 4, cubed => 8 }
];
then I can use
$a->[2]{squared}
Well, you can't have your cake and eat it too; I told you what to do with @a, which is what you used in your example; for my alternative, you'd use
:)
$a->[0][0]
instead; (almost) any reference can be dereferenced in this way.
FE:
my $x = sub {
return shift;
}
my $a = $x->(1);
Unless you do something to localize it, a variable is global; if you don't specify a scope then there are few options. This is true of almost all languages that don't rely on explicit declarations. If you aren't familiar with the concept, then I'm guessing you've done a fair bit more PHP or VB than Perl (and haven't read many of the Perl manpages).
Using a glob reference doesn't solve this problem - just disguises it by creating a reference to a symbol table slot; unless you've done something to ensure that the reference is to a localized variable, it's a poor practice that would be non-portable in any context; like using hard-coded file descriptor numbers would be in a C library function (to which this practice is broadly equivalent).
Your comment 'If it works with a goddamn hash table, it should work with a frigging filehandle as well!' is just wrong; hash tables are purely internal constructs, whereas file handles are connected to the Real World and must conform to the requirements of the underlying system calls; in Perl4, each filehandle maps onto a file descriptor number that is global to the application - nothing you or I can do about that, although we're free to shuffle around how they're hooked up internally. Perl4 passes this model up to your code, and maps each descriptor to a symbol name (some pre-defined, some created as you open & close file handles); Perl5 provides an abstraction layer that hides these details, but they're still there underneath. If you don't want the hassle of dealing with the nuts-and-bolts (and you strike me as the kind of person who doesn't), use the abstraction layer and this particular poblem will largely go away.
Perl 5 provides a clean, almost infinitely flexible OO environment you can use to build clean, scalable, protable code; if you don't use them, then I can't see it as Perl's fault if your code isn't clean, portable or scalable.
The corollary is that Perl5 provides almost complete compatible with Perl4, and if you take advantage of that then you shouldn't be surprised if your Perl5 code looks like Perl4, and is relatively unportable and unscalable.
As for your application issues, I'll pass more or less silently over issues like blaming the language because coder's can't type, and handing apparently untested code onto users; but some of the things you mentioned would prompt me to say 'Check the scope of your variables'; as for segfaults from an over-eager garbage collector - excuse me?? The only issues I've ever had with the garbage collector in Perl is that it's sometimes so cautious to avoid breaking circular references that it needs explicit help (which,m along with uncontrolled use of globas, may explain the 'memory leaks' you saw).
And if you're paying, feel free to foist some of that horror my way
John.
Just because things *can* be hard or ugly, doesn't mean they *need* to be.
To answer your question:
$a[0][0]
Also, you don't need @{$a[0]}; $a[0] is every bit as much the 'first row of the matrix', just expressed as a reference than a list; in practice, it's more likely that's what you want most of the time anyway.
As for filehandles, if you want to write code that is reusable or scale, you'll do something like this:
use IO::File;
my $fh = new IO::File('/etc/passwd');
or you will need to take special measures to avoid polluting the global namespace (just like in any other language that allows you to use globals for your own ends).
Many of the things you (and most people) complain about are things that are in Perl5 because they were in Perl4, and the Perl community has never been keen to break compatibility with a huge library of existing code, or require people to change their habits just because; however that doesn't mean you're smart to use them in projects of any scale.
John.
Well, LEFT JOIN should give you a whee.blib = for every row in foo; the whole point of a LEFT JOIN is that you'll get a 'dummy row' with NULLs for whee.* if there is no 'real' row in whee that satisfies the JOIN condition. If that's not happening for you, then either MySQL's LEFT JOIN is broken or perhaps it's something about how you're typing 'WHERE whee.blib IS NULL'.
Alternatively, if you're joining o an indexed column and the index is corrupt or incomplete the DBMS may not find all of the rows vin an index scan.
It shouldn't matter when the WHERE is evaulated, the same rows will be found - it's just open to the query planner to use the WHERE clause to restrict the number of joined rows it considers. rather than to do a full left join (including rows with whee.* set to NULL for rows in foo without a corrresponding whee which satisfies the join condition) and then wade through the results.
huiac at internode.on.net
You should read up further on JOIN types.
4 84920
SELECT * FROM foo LEFT JOIN whee ON bar.foo = whee.blib WHERE whee.blib IS NULL;
The DBMS can optimize this however it likes; using the WHERE clause to limit the JOINed rows is a basic optimization, easy for the optimizer to spot. The NOT IN clause may be more efficient still (requires less smarts from the optimizer), but in its absence the LEFT JOIN is potentially orders of magnitude better than HAVING - it depends how big whee and bar are, and how many rows there are in the result set.
Also proposed in
http://slashdot.org/comments.pl?sid=161173&cid=13
huiac at internode.on.net