Just punch in a zip code. I got "lucky" - only 2 in my development.
Family Watchdog
Wednesday, December 06, 2006
NASA to announce discovery of UFO launch site on mars
I made that headline up, but it caught your eye didn't it? Hey, I could be a reporter for AP. I can make up sensational shit just as good the professionals.
Water? Major geological revelations? Confirmation of Mars global warming?
NASA
Water? Major geological revelations? Confirmation of Mars global warming?
NASA
WASHINGTON - NASA hosts a news briefing at 1 p.m. EST, Wednesday, Dec. 6, to present new science results from the Mars Global Surveyor[...]
SCOTUS 8:1 Thomas dissenting
Apparently Clarence Thomas is the only judge not having their head firmly inserted in their ass.
Seriously - don't we already have enough American citizen illegal drug users, that we don't really need to be importing more from overseas? This is nothing but a huge slap in the face to the American taxpayer who winds up footing the bills for incarceration, other crimes committed to support habits, babies born to them while they're here, etc etc.
[CLARIFICATION]
These people are NOT American citizens.
REUTERS
Seriously - don't we already have enough American citizen illegal drug users, that we don't really need to be importing more from overseas? This is nothing but a huge slap in the face to the American taxpayer who winds up footing the bills for incarceration, other crimes committed to support habits, babies born to them while they're here, etc etc.
[CLARIFICATION]
These people are NOT American citizens.
REUTERS
The Supreme Court ruled on Tuesday that legal immigrants cannot be deported when convicted of relatively minor drug-possession offenses, a decision likely to affect thousands of people.
By an 8-1 vote, the high court handed a setback to the Bush administration and ruled the immigrants cannot be deported for drug offenses that are felony crimes under some state laws, but less serious misdemeanors under federal law[...]
Tuesday, December 05, 2006
How the Philippines deals with foreign demonstrators
Manila Standard
FOREIGNERS taking part in any political rallies against the Association of Southeast Asian Nations meeting in Cebu City next week will be arrested and deported, the Bureau of Immigration said yesterday.
Immigration Commissioner Alipio Fernandez Jr. also said that those arrested and deported would be put on a blacklist and would not be allowed to return.
“Foreigners do not have any business interfering with the political affairs of the country,” he said[...]
USMC Lance Cpl convicted in Philippine rape case
Sounds like he actually did it from the article's description. 40 years is a little on the high side by US incarceration standards, but I really have little sympathy for those who would abuse the locals in this manner.
Manila Standard
Manila Standard
A MAKATI court convicted US marine Lance Cpl. Daniel Smith of rape and sentenced him to 40 years in prison yesterday in a landmark case[...]
[...] In his ruling, Pozon cited 14 pieces of circumstantial evidence that proved Smith raped Nicole.
These included Nicole’s vaginal injuries and bruises on her legs and arms, the testimony of prosecution witnesses who saw Smith carrying the unconscious Nicole out of the Neptune Bar, and Smith’s admission that he had sex with the complainant[...]
Monday, December 04, 2006
How leftists in Fiji deal with "dissent"
Sydney Morning Herald
[...]Speaking on television in Fijian, Commodore Bainimarama all but said dissenters would be arrested when his government took control today, by saying the military would "go and see" any outspoken right-wingers.[...]
Ace reports from Iraq
Associated Press has a new stringer in Iraq. His reporting on the escalating violence appears to be top notch Pulitzer quality stuff.
Ace of Spades
Ace of Spades
[...]R A M A D I -- They came in the dead of night. In the four am desert cold, a gang of ten to twenty masked men raided the small village of Bina'il, systematically raping women and girls, some as young as eight.
None of the victims of the rapes would speak openly about the event with Acewire News Service, owing to the Muslim taboo against victims of rape[...]
The pig farmer versus the muslims
Mr Minority
There is trouble brewing in Katy, Tx (just west of Houston), where the Katy Islamic Association wants to build a mosque and the neighborhood doesn't want it. But it gets worse[...]Dar al-Islam, catch the fever! The Caliphate is reaching out for us and probing to see just how much it can get away with.
Damn you Bill Gates - the saga of the "big bit"
Microsoft threw my current programming project a 6/12 curve ball today.
You see, in the Intel OMF (object module format) that more of less corresponds to what a .OBJ file is that PC compilers and assemblers spit out, there is a thing called a SEGDEF record. The SEGDEF, not suprisingly, tells what the characteristics of a particular segment are. This includes the segment's name, class, combine, alignment characteristics, and of course the segment's length.
Segments are the stuff that make up the code and data in a program. How they lay out and get managed is plainly a matter of supreme importance if things are to actually ummmm...work.
In the 16 bit world, segments were of necessity limited to 64K in length because that's the most you can fit in 16 bits worth of addressability.
HOWEVER - its also quite legal, and happens frequently, that SEGDEF's in OBJ's may describe segments of ZERO LENGTH. Zero length segments are used for a multitude of purposes. Place holders, to force particular orderings in memory, etc.
Now there arises a problem -- the notorious "fence post" class of issues. With only 16 bits available to tell the length of a segment, the largest number you can have in 16 bits is 65535 (64K-1). With zero length segments being legal, you can't do something like say a length of zero means a 1-byte segment and 65535 means a full 64K segment.
Intel solved this issue with a thing called the "big bit". Part of the SEGDEF record includes a bit that says if a segment is a full 65536 bytes long. If the 16 bit length is set to zero and the "big bit" is turned on, then the length is really 65536, not 65535.
Architecturally, this "solved" the problem. Zero length segments are still OK, and you can have full 64K segments as well by using the "big bit".
Alas, along comes the Microsoft Macro Assembler. Versions of MASM from 1981 through roughly 1987 that I've tested don't set the "big bit" when they construct a full 64K length segment. They do however set the SEGDEF that describes them's length to zero.
This bug in MASM caused the OBJ validation phase of my gizmo to choke when it noticed that code/data was being emitted into a (apparently, but incorrectly) zero length segment.
How a bug as egregious as this one somehow managed to persist over several versions of MASM spanning around 6 years is a real mystery. I'll have to look into that apsect further. I'm going to hazard a guess and say it was maybe dealt with in LINK if it was dealt with at all.
To their credit, Microsoft eventually got this fixed. MASM 6.11 doesn't exhibit the problem and sets the "big bit" correctly.
My gizmo now includes a new command line switch: -Fm That will "fix" the broken MASM's "big bit" when it encounters a zero length segment that subsequently has code/data being emitted for it.
I could see this in the first version of MASM. Lots of the 1981 vintage tools and apps were really quite wretched and bug ridden (not just Microsoft's either). But 6+ years? Oy!
You see, in the Intel OMF (object module format) that more of less corresponds to what a .OBJ file is that PC compilers and assemblers spit out, there is a thing called a SEGDEF record. The SEGDEF, not suprisingly, tells what the characteristics of a particular segment are. This includes the segment's name, class, combine, alignment characteristics, and of course the segment's length.
Segments are the stuff that make up the code and data in a program. How they lay out and get managed is plainly a matter of supreme importance if things are to actually ummmm...work.
In the 16 bit world, segments were of necessity limited to 64K in length because that's the most you can fit in 16 bits worth of addressability.
HOWEVER - its also quite legal, and happens frequently, that SEGDEF's in OBJ's may describe segments of ZERO LENGTH. Zero length segments are used for a multitude of purposes. Place holders, to force particular orderings in memory, etc.
Now there arises a problem -- the notorious "fence post" class of issues. With only 16 bits available to tell the length of a segment, the largest number you can have in 16 bits is 65535 (64K-1). With zero length segments being legal, you can't do something like say a length of zero means a 1-byte segment and 65535 means a full 64K segment.
Intel solved this issue with a thing called the "big bit". Part of the SEGDEF record includes a bit that says if a segment is a full 65536 bytes long. If the 16 bit length is set to zero and the "big bit" is turned on, then the length is really 65536, not 65535.
Architecturally, this "solved" the problem. Zero length segments are still OK, and you can have full 64K segments as well by using the "big bit".
Alas, along comes the Microsoft Macro Assembler. Versions of MASM from 1981 through roughly 1987 that I've tested don't set the "big bit" when they construct a full 64K length segment. They do however set the SEGDEF that describes them's length to zero.
This bug in MASM caused the OBJ validation phase of my gizmo to choke when it noticed that code/data was being emitted into a (apparently, but incorrectly) zero length segment.
How a bug as egregious as this one somehow managed to persist over several versions of MASM spanning around 6 years is a real mystery. I'll have to look into that apsect further. I'm going to hazard a guess and say it was maybe dealt with in LINK if it was dealt with at all.
To their credit, Microsoft eventually got this fixed. MASM 6.11 doesn't exhibit the problem and sets the "big bit" correctly.
My gizmo now includes a new command line switch: -Fm That will "fix" the broken MASM's "big bit" when it encounters a zero length segment that subsequently has code/data being emitted for it.
I could see this in the first version of MASM. Lots of the 1981 vintage tools and apps were really quite wretched and bug ridden (not just Microsoft's either). But 6+ years? Oy!
Pimp my blog
For the pimped out version of Purple Avenger CLICK HERE
You can pimp anything apparently by appending its URL to this string:
H/T Gahrie
You can pimp anything apparently by appending its URL to this string:
http://www.psyclops.com/translator/translator.cgi?mode=pimp&url=
H/T Gahrie
Sunday, December 03, 2006
Telemundo censored in Venezuela?
Its an AP story, so its veracity is naturally suspect ;-> If true, I'm not surprised. Dictators don't like people shining a light on their activities.
Houston Chronicle
Houston Chronicle
Grinch(s) steal epiliptec boy's Christmas
Heartless bastards.
LOCAL6
LOCAL6
Authorities in Osceola County, Fla., are searching for the thieves who broke into a home, stole all of the family's Christmas presents and destroyed a nativity scene, according to Local 6 News[...]
[...]"My grandson -- he has epilepsy, and he is very discouraged and confused," grandmother Tingle said. "He is having a very hard day today."[...]
Double trouble
Wow - two disk drives died on me today and started throwing SCSI errors back to the controllers (I'm a SCSI kinda guy for the most part).
A 2.1G Seagate Hawk of unknown origin (it came out of a dumpster a while ago), and a Seagate ST43400N that I'd paid the princely sum of $5 for years ago.
Didn't lose anything other than the time to grab some already on-hand spares and slap them in and reload what was on the dead ones. I always have my critical stuff replicated in many places over many different machines.
A 2.1G Seagate Hawk of unknown origin (it came out of a dumpster a while ago), and a Seagate ST43400N that I'd paid the princely sum of $5 for years ago.
Didn't lose anything other than the time to grab some already on-hand spares and slap them in and reload what was on the dead ones. I always have my critical stuff replicated in many places over many different machines.
Saturday, December 02, 2006
The Abdelwahab Meddeb interview
Interesting stuff here. Meddeb doesn't go lightly on his religious brethren.
Michael Monninger
I have one quibble with one of his statements though:
Michael Monninger
I have one quibble with one of his statements though:
[...]The real danger is not warlike Islam but authoritarian Islam which subjects day-to-day life in its entirety to religious practice.[...]As a practical matter, I fail to see the difference.
More fun with Ryan-McFarland FORTRAN compilers
Getting deeper into the stuff this compiler (and a newer version of it) emit now. You can tell a lot about the internal organization of a compiler by the nature of the OBJ's it spits out.
The RM Fortran compiler was apparently designed to run in extremely modest amounts of memory. Packaging for the earliest version I have indicates it would run with about 128K of free memory -- not 128M -- 128K. That's less memory than the L2 caches on most PC's that have been made in the past decade.
Packaging claims aside, the OBJ's it spits out tend to confirm those modest claims. As any compiler is compiling code, its going to encounter situations (many in Fortran) where a JMP or conditional JMP to a forward memory location is needed. Usually, most compilers would calculate the addresses of these jumps and adjust itself internally as it goes along and emit the blob of compiled code in one shot.
Not so with the RM Fortran compiler. It spits out code with essentially blank place holders in the code where the JMP offsets would go. A blob of code is written to the OBJ that doesn't work because its not complete yet. THEN, after that blob is written out, it emits (many) subsequent records to adjust the JMP offsets in what it just emitted. Essentially, RM Fortran is punting some of the traditional compilation process off onto the linker.
So for Fortran code files that are large, the compiler doesn't really need to swallow them whole -- it takes them small bites at a time, writes out the code for those small bites, and punts the rest to LINK.
Obviously, RM were in a hurry to recycle the memory being taken up by the largish (in relative terms) blobs of code it was working on at any given point and saved just jump offset information. That lets the compiler puke out the code blob early.
Its an interesting concept born of the era when programmers didn't have hard disks and only had machines with maybe 256K and a couple of floppy disks. In terms of compilation speed there's no real penalty to this approach. The quality of the generated code is going to suffer some, the OBJ's will bloat up, and link times would go up some with the linker having to glue together slews of code fragments and apply fixups to them because the compiler didn't bother to do so. All in all, it was a reasonable approach for the 256K PC era (I remember paying hundreds of dollars for a meg of memory). If people were doing mostly floating point number crunching with this product and had 8087's or 287's, the necessarily lesser quality of the non-NPX code wasn't going to matter all that much anyway since those NPX's were relatively slow and integer code was usually waiting on the NPX.
The RM Fortran compiler was apparently designed to run in extremely modest amounts of memory. Packaging for the earliest version I have indicates it would run with about 128K of free memory -- not 128M -- 128K. That's less memory than the L2 caches on most PC's that have been made in the past decade.
Packaging claims aside, the OBJ's it spits out tend to confirm those modest claims. As any compiler is compiling code, its going to encounter situations (many in Fortran) where a JMP or conditional JMP to a forward memory location is needed. Usually, most compilers would calculate the addresses of these jumps and adjust itself internally as it goes along and emit the blob of compiled code in one shot.
Not so with the RM Fortran compiler. It spits out code with essentially blank place holders in the code where the JMP offsets would go. A blob of code is written to the OBJ that doesn't work because its not complete yet. THEN, after that blob is written out, it emits (many) subsequent records to adjust the JMP offsets in what it just emitted. Essentially, RM Fortran is punting some of the traditional compilation process off onto the linker.
So for Fortran code files that are large, the compiler doesn't really need to swallow them whole -- it takes them small bites at a time, writes out the code for those small bites, and punts the rest to LINK.
Obviously, RM were in a hurry to recycle the memory being taken up by the largish (in relative terms) blobs of code it was working on at any given point and saved just jump offset information. That lets the compiler puke out the code blob early.
Its an interesting concept born of the era when programmers didn't have hard disks and only had machines with maybe 256K and a couple of floppy disks. In terms of compilation speed there's no real penalty to this approach. The quality of the generated code is going to suffer some, the OBJ's will bloat up, and link times would go up some with the linker having to glue together slews of code fragments and apply fixups to them because the compiler didn't bother to do so. All in all, it was a reasonable approach for the 256K PC era (I remember paying hundreds of dollars for a meg of memory). If people were doing mostly floating point number crunching with this product and had 8087's or 287's, the necessarily lesser quality of the non-NPX code wasn't going to matter all that much anyway since those NPX's were relatively slow and integer code was usually waiting on the NPX.
DOS on a 486 as a viable development platform
I've got this development project underway where the code is straight ANSI C. It reads files does a bunch of magic stuff and writes files back out. For several weeks now I've been using plain old DOS running on an 10+ year old 486DX4-100 as my development platform.
The old 1989 vintage Turbo C 2.0 compiler (ANSI compliant) and Turbo debugger are completely sufficient to do this work. The old BRIEF editor is very fast on a 486. So far the program fits well within 640K and probably will for at least several more months worth of work.
As a practical matter, there's nothing currently that would make me move it to a faster machine or to a different OS. At some point in the future when basic functionality is settled and the most egregious bugs worked out I'll be making sure the code is truly portable among a slew of different compilers and platforms, but for now trusty old DOS and a geriatric C compiler are doing the job just fine.
Software is curious product in that it doesn't wear out, rot, rust, or decay in any discernible manner. Its as good (or bad) today as it was when it shipped originally.
The old 1989 vintage Turbo C 2.0 compiler (ANSI compliant) and Turbo debugger are completely sufficient to do this work. The old BRIEF editor is very fast on a 486. So far the program fits well within 640K and probably will for at least several more months worth of work.
As a practical matter, there's nothing currently that would make me move it to a faster machine or to a different OS. At some point in the future when basic functionality is settled and the most egregious bugs worked out I'll be making sure the code is truly portable among a slew of different compilers and platforms, but for now trusty old DOS and a geriatric C compiler are doing the job just fine.
Software is curious product in that it doesn't wear out, rot, rust, or decay in any discernible manner. Its as good (or bad) today as it was when it shipped originally.
Friday, December 01, 2006
Be Bop Deluxe - Panic In The World
I had no idea there was any video of these guys anywhere. I saw them at the old Palace Theater in Albany NY some time back in the late 70's.
Subscribe to:
Posts (Atom)