> Apparently you didn't read the front of the box that says "For Windows XP Only".
They probably left it out of the readme.nfo.
Re:Magnusson Moss Warranty Act
on
Hack Your Car
·
· Score: 1
Ack, nice bike like that and you've never take it to the Gap?
200 miles is a pansy ride, anyhow. What, three hours each way? And taking roads like the Cherehola Skyway and the BRP to get there, you won't even notice the time fly by.
Lucky bastard. It's over 1000 miles from here, I've only been once. Had to take a trailer, too, 1000 miles on Friday, the gap on Saturday, 100 miles back on Sunday. Do yourself a favour and leave home around 5am, slay the dragon from 8 to 9, rest, and head home. 11am-5pm gets stupid levels of traffic, and you can't have much fun there at dusk.
> Saddly it is winter and damn cold here so I haven't had a chance to in months.
Dress for the weather. I was out last night for an hour, and still commute almost daily.
Oh, and I live in Canada. I'll bet it's colder here than TN/NC! Remember, though, if it's really cold that you need to pay attention to your suspension (fork oil with be thick for the first part of the ride, affecting compression/rebound damping), and your tires will probably not get fully up to temperature.
alert(new point(3,4));...if that's what you like, use it. You can also put the methods outside of the constructor if you want to. Or, you can use function() and create lambda functions if that tickles your fancy.
The only wierd thing with JavaScript OOP is the lack of meaningful automatic inheritance. You have to pretty much do that yourself.
> 3) No file/database support.
C doesn't include file support natively. Neither does C++. I don't know about Java (I'm a C guy), but I suspect it's imported from a class. This goes doubly for database support! BASIC, Pascal, and any other real language I can think of require add-ons for Database support!
The author of the book *could have* written a class to support file *reading* easily enough, in a *completely* DOM-portable format (by retrieving "files" which are stored on a webserver instead of a local disc.. or they could even be in file://). Writing files is non-portable, but if you chose a specific JavaScript implementation, it's very possible. Two specific ones I'm thinking of are NJS JavaScript (hell, I write shell scripts in it sometimes, it's quite handy) and Microsoft's Windows Scripting Host... as long as you're not running JScript inside the web-browser sandbox, it can do full File IO.
Somebody else pointed out using ADO for Database access. That's pretty reasonable, you have to do the same thing in C++. You could also [read-only] use the Tabular Data Control (which has shipped as an OCX with every version of IE since 4.0) to read CSV files and interact with them pretty much the same way you can interact with an RDF.
The list goes on.
The problem you are having is that you cannot see JavaScript as a real programming language for two reasons:
1) It has been horribly, horribly abused in the past 2) There is not a great deal of aftermarket libraries available for the non-Microsoft version of the language. (Whose fault is that? Yours!)
It is entirely possible to write Good Code in JavaScript, although (like any language) it might not meet your needs. The criticisms you make of JavaScript could be made of LISP as well, and I think emacs has proven the point that you can use LISP to write real, non-AI-field programs.. That do I/O an' ever-thing! [albeit in an incredibly bloated manner].
In fact, I would argue that with proper "setup" [include files], JavaScript in the Microsoft environment would be a *far better* tool for teaching programming than, say, GW-Basic. Or possibly even VB (although that tenous at best). Certainly as good as Object-Oriented Turing and other educators' pets.
Getting it to work as well (file io, db access) in the non-MS environment merely requires somebody who cares about these things to write appropriate class libraries for the NJS interpreter. Or the right plug-ins for Mozilla. Etc.
Actually, I use it on a regular basis for just this task, and I even use my regular C-style. The only short-coming is that the C-style I use (which I've used for *years*) doesn't understand C++-style comments (//), so I have to use C-style comments in my JavaScript code, or the colours get all funky.
I suppose I should break down and fix that someday, but somehow, that's really low on my priority list.
Given that JavaScript and C share nearly identical syntactical conventions (at least as far as emacs cares;) means that I have code that looks the way I'm used to it looking, and can use control-meta-q to reindent. And tab will indent how I want it to. And I can edit multiple buffers at the same time.
Perfect! The only problem is training myself not to m-x compile every time I'm ready to test.
The Dragon Book, while one of my favourites (...as I glance over and see it nestled between K&R pre-ANSI 2nd ed. and Tannenbaum's OS book..) is certainly not a good *intro* to programming book, which is what the article is about.
Take a proficient programmer who knows an HLL and assembler, feed him the Dragon Book and you _will_ have a better programmer in the end, though. So your point is certainly valid, but the timing of that book's intro should be carefully planned in a curriculum. If you're not proficient with an HLL, and at least halfway competent in some form of assembler, it will totally fuck you up.
Stick with the 6502 -- you're right, it's close to idealized (I cut my teeth on the VIC) for this type of learning.
The advantage of going with this CPU is that there is *lots* and *lots* of documentation out there on it. Ditto for assemblers, and C compilers. You could avoid reinventing the wheel.
Other good choices:
- mc6809
- mc68hc11
- mc68000 (odd-byte memory addressing may confuse newbies)
- MIPS
MIPS is kind of interesting, we did an entire 4th year compiler project using only 24 instructions.
> Can't toupper() be implemented as a macro that does an array lookup?
Sure, and that would be *totally* obvious to any twelve year old writing it from scratch in ASM. I know, because I did just that about 18 years ago. Except it was converting ASCII to PETSCII, but same code, different array.
Nowadays, as a CS PhD candidate to write toupper() in C and you're going to get a variant of this:
char toupper(char c) {
if ((c >= 'a') && (c = 'z'))
return c + 'a' - 'A'; }...and he probably won't even notice the compiler warnings that his prototypes should be ints (assuming he's including ctype.h, which he probably will, because most of those guys cut and paste the same four hundred #include lines from project to project). Of course, the CS guy will defend his code by saying it also works on EBCDIC, or any other alphabetic encoding. *sigh*
Ask an assembler guy to implement it in C, you'll probably get asked: "fast, or accurate?". Accurate would the lookup table. Fast will get a solution a like this:
char toupper(char c) {
return c & 64 ? c | 32 : c; }
It's not accurate because it fucks up the @ sign and a few other things, but as long as you're just feeding it alphabetic characters, you're good to go. And it would significantly faster than any other solution, as it can be inlined in just a few instructions.
Here it is for 6502 -- a very simple CPU -- ready to use as a function. I could shorten it significantly if the 6502 was more sophisticated (i.e. math unit could work with more than one register):
PLA TAX AND #$40 CMP #$0 BEQ labelONE TXA ORA #$20 PHA RTS.labelONE TXA PHA RTS
I'd had to see the CS's solution, subtraction is (relatively) expensive.
The code could be about half that size if it were inlined, as we could use the BIT instruction to test memory, instead of yanking it through the stack.
Geez, you got any spare key caps? I rescued mine from a government terminal, and a whole pile of the keys (home, end, etc) are mislabeled. At least they send the right scan codes.
IIRC from my super-special "Intel Training" when these things came out, the P60 was rated to operate at temperatures as high as 75C. The wild thing was doing the temperature test -- the "approved method" was to load the DOS edit program, tap the alt key, and wait a while. It seems that the editor went into a very tight loop when the menu thingamagig was up.
Not to put too fine a point on it, but are you not aware that we harpooned the Humpback Whales complete ly out of existance? And nearly did it again, hitting a Bird of Prey with one of those suckers?
Hit eBay, and grab an unlocked Nokia 6190 or 7190. Stuff your SIM with it and be done with it.
The 7190 is a little big for my tastes, but extremely easy to use. It also includes T9, which is a requirement for a frequent SMS user. The front pull-down plate is actually more durable than it looks (trust me, I know), but if you snap it off you can configure the phone to ignore it and it will work just fine. Also, you can buy a OLD 7160 overseas and exchange cases to get that spring-down faceplate like in the first matrix.
The 6190 will answer calls and send SMS, has the old 61xx indestructable form factor, and will probably last forever if you don't snap the antenna off. And if you do, you can fix it by buying any old 61xx (i.e. TDMA 6160) and rescuing the back plate from it. The only thing lacking the 6190 is T9 software.
In case you care, I own both.. as well as a bunch of Motorola products (iTAP is way worse than T9), some erikson products, some siemens products. The Nokia 61xx is a timeless classic; the 71xx is good enough.
Wordperfect 5.1 didn't have a grammar checker built into it; Grammatik (by another company) was an add-on product.
MS logic: If people are paying extra for Grammatik, there must be a market. Lets give it away for free, increase Word dominance, kill Grammatik's market, and not give consumers any more reasons to stick with WP51 (except, of course, that it was WAY faster than Word, had legal/government document templates available for it, and the files were a hell of a lot smaller)
> Apparently you didn't read the front of the box that says "For Windows XP Only".
They probably left it out of the readme.nfo.
Ack, nice bike like that and you've never take it to the Gap?
200 miles is a pansy ride, anyhow. What, three hours each way? And taking roads like the Cherehola Skyway and the BRP to get there, you won't even notice the time fly by.
Lucky bastard. It's over 1000 miles from here, I've only been once. Had to take a trailer, too, 1000 miles on Friday, the gap on Saturday, 100 miles back on Sunday. Do yourself a favour and leave home around 5am, slay the dragon from 8 to 9, rest, and head home. 11am-5pm gets stupid levels of traffic, and you can't have much fun there at dusk.
> Saddly it is winter and damn cold here so I haven't had a chance to in months.
Dress for the weather. I was out last night for an hour, and still commute almost daily.
Oh, and I live in Canada. I'll bet it's colder here than TN/NC! Remember, though, if it's really cold that you need to pay attention to your suspension (fork oil with be thick for the first part of the ride, affecting compression/rebound damping), and your tires will probably not get fully up to temperature.
The how do you explain Canadian Idol?
> how come Playboy has a braille edition?
Ribbed for your pleasure?
Liar.
I keep forgetting less than signs mess up Plain Old Text for some unfathomable reason. ;)
Here are the code snippets, rants were unaffected.
function print()
{
var i;
for (i=0; i < print.arguments.length; i++)
document.body.innerHTML += print.arguments[i];
}
function point(x,y)
{
this.x = x;
this.y = y;
function mPoint_toString()
{
return '(' + this.x + ',' + this.y + ')';
}
this.toString = mPoint_toString;
}
alert(new point(3,4));
1) No print() or echo() function.
...] functions are actually defined INSIDE the class
...if that's what you like, use it. You can also put the methods outside of the constructor if you want to. Or, you can use function() and create lambda functions if that tickles your fancy.
function print()
{
var i;
for (i=0; i 2) Weird OOP syntax [... in normal languages
function point(x,y)
{
this.x = x;
this.y = y;
function mPoint_toString()
{
return '(' + this.x + ',' + this.y + ')';
}
this.toString = mPoint_toString;
}
alert(new point(3,4));
The only wierd thing with JavaScript OOP is the lack of meaningful automatic inheritance. You have to pretty much do that yourself.
> 3) No file/database support.
C doesn't include file support natively. Neither does C++. I don't know about Java (I'm a C guy), but I suspect it's imported from a class. This goes doubly for database support! BASIC, Pascal, and any other real language I can think of require add-ons for Database support!
The author of the book *could have* written a class to support file *reading* easily enough, in a *completely* DOM-portable format (by retrieving "files" which are stored on a webserver instead of a local disc.. or they could even be in file://). Writing files is non-portable, but if you chose a specific JavaScript implementation, it's very possible. Two specific ones I'm thinking of are NJS JavaScript (hell, I write shell scripts in it sometimes, it's quite handy) and Microsoft's Windows Scripting Host... as long as you're not running JScript inside the web-browser sandbox, it can do full File IO.
Somebody else pointed out using ADO for Database access. That's pretty reasonable, you have to do the same thing in C++. You could also [read-only] use the Tabular Data Control (which has shipped as an OCX with every version of IE since 4.0) to read CSV files and interact with them pretty much the same way you can interact with an RDF.
The list goes on.
The problem you are having is that you cannot see JavaScript as a real programming language for two reasons:
1) It has been horribly, horribly abused in the past
2) There is not a great deal of aftermarket libraries available for the non-Microsoft version of the language. (Whose fault is that? Yours!)
It is entirely possible to write Good Code in JavaScript, although (like any language) it might not meet your needs. The criticisms you make of JavaScript could be made of LISP as well, and I think emacs has proven the point that you can use LISP to write real, non-AI-field programs.. That do I/O an' ever-thing! [albeit in an incredibly bloated manner].
In fact, I would argue that with proper "setup" [include files], JavaScript in the Microsoft environment would be a *far better* tool for teaching programming than, say, GW-Basic. Or possibly even VB (although that tenous at best). Certainly as good as Object-Oriented Turing and other educators' pets.
Getting it to work as well (file io, db access) in the non-MS environment merely requires somebody who cares about these things to write appropriate class libraries for the NJS interpreter. Or the right plug-ins for Mozilla. Etc.
> emacs is a bit much for javascript IMO
;) means that I have code that looks the way I'm used to it looking, and can use control-meta-q to reindent. And tab will indent how I want it to. And I can edit multiple buffers at the same time.
Actually, I use it on a regular basis for just this task, and I even use my regular C-style. The only short-coming is that the C-style I use (which I've used for *years*) doesn't understand C++-style comments (//), so I have to use C-style comments in my JavaScript code, or the colours get all funky.
I suppose I should break down and fix that someday, but somehow, that's really low on my priority list.
Given that JavaScript and C share nearly identical syntactical conventions (at least as far as emacs cares
Perfect! The only problem is training myself not to m-x compile every time I'm ready to test.
> Would you use a torch to see what colour your tyre is?
> Maybe there are better examples of this... but I just thought of it....
Would you bum a fag if you needed a cigarette?
Yup.
Although when I went there, there was CISC and EE. I think the last year I was there they added a CE option.
> Like Chem and ChemE
My school offered Chemistry, Engineering Chemistry and Chemical Engineering. Now *that's* confusing. At least to a non-chemist.
The Dragon Book, while one of my favourites (...as I glance over and see it nestled between K&R pre-ANSI 2nd ed. and Tannenbaum's OS book..) is certainly not a good *intro* to programming book, which is what the article is about.
Take a proficient programmer who knows an HLL and assembler, feed him the Dragon Book and you _will_ have a better programmer in the end, though. So your point is certainly valid, but the timing of that book's intro should be carefully planned in a curriculum. If you're not proficient with an HLL, and at least halfway competent in some form of assembler, it will totally fuck you up.
Stick with the 6502 -- you're right, it's close to idealized (I cut my teeth on the VIC) for this type of learning.
The advantage of going with this CPU is that there is *lots* and *lots* of documentation out there on it. Ditto for assemblers, and C compilers. You could avoid reinventing the wheel.
Other good choices:
- mc6809
- mc68hc11
- mc68000 (odd-byte memory addressing may confuse newbies)
- MIPS
MIPS is kind of interesting, we did an entire 4th year compiler project using only 24 instructions.
You are correct, sir.
;)
I used cut and paste -- the number one reason programmers make mistakes like that.
It must be because I was typing a Windows box, it polluted me.
> Can't toupper() be implemented as a macro that does an array lookup?
...and he probably won't even notice the compiler warnings that his prototypes should be ints (assuming he's including ctype.h, which he probably will, because most of those guys cut and paste the same four hundred #include lines from project to project). Of course, the CS guy will defend his code by saying it also works on EBCDIC, or any other alphabetic encoding. *sigh*
.labelONE
Sure, and that would be *totally* obvious to any twelve year old writing it from scratch in ASM. I know, because I did just that about 18 years ago. Except it was converting ASCII to PETSCII, but same code, different array.
Nowadays, as a CS PhD candidate to write toupper() in C and you're going to get a variant of this:
char toupper(char c)
{
if ((c >= 'a') && (c = 'z'))
return c + 'a' - 'A';
}
Ask an assembler guy to implement it in C, you'll probably get asked: "fast, or accurate?". Accurate would the lookup table. Fast will get a solution a like this:
char toupper(char c)
{
return c & 64 ? c | 32 : c;
}
It's not accurate because it fucks up the @ sign and a few other things, but as long as you're just feeding it alphabetic characters, you're good to go. And it would significantly faster than any other solution, as it can be inlined in just a few instructions.
Here it is for 6502 -- a very simple CPU -- ready to use as a function. I could shorten it significantly if the 6502 was more sophisticated (i.e. math unit could work with more than one register):
PLA
TAX
AND #$40
CMP #$0
BEQ labelONE
TXA
ORA #$20
PHA
RTS
TXA
PHA
RTS
I'd had to see the CS's solution, subtraction is (relatively) expensive.
The code could be about half that size if it were inlined, as we could use the BIT instruction to test memory, instead of yanking it through the stack.
Geez, you got any spare key caps? I rescued mine from a government terminal, and a whole pile of the keys (home, end, etc) are mislabeled. At least they send the right scan codes.
IIRC from my super-special "Intel Training" when these things came out, the P60 was rated to operate at temperatures as high as 75C. The wild thing was doing the temperature test -- the "approved method" was to load the DOS edit program, tap the alt key, and wait a while. It seems that the editor went into a very tight loop when the menu thingamagig was up.
Old 5 1/4" HH Seagate hard disks could be damanged (case warp) by using 6-32 UNC screws of the wrong length.
Center IDE-era disks (early maxtors come to mind) could have the PCB damaged by using 6-32 UNC screws of the wrong length (i.e. case screws)
Seen both happen personally. Did neither. The first one ruined the seals on the disk. The second one let the smoke out.
> In RDBMS sometimes zero-length strings are considered 'null', but why
> not just have them be zero length strings?
So, how would you tell the difference between "no string" and a zero-length string?
Not to put too fine a point on it, but are you not aware that we harpooned the Humpback Whales complete ly out of existance? And nearly did it again, hitting a Bird of Prey with one of those suckers?
Yeesh.
Hit eBay, and grab an unlocked Nokia 6190 or 7190. Stuff your SIM with it and be done with it.
The 7190 is a little big for my tastes, but extremely easy to use. It also includes T9, which is a requirement for a frequent SMS user. The front pull-down plate is actually more durable than it looks (trust me, I know), but if you snap it off you can configure the phone to ignore it and it will work just fine. Also, you can buy a OLD 7160 overseas and exchange cases to get that spring-down faceplate like in the first matrix.
The 6190 will answer calls and send SMS, has the old 61xx indestructable form factor, and will probably last forever if you don't snap the antenna off. And if you do, you can fix it by buying any old 61xx (i.e. TDMA 6160) and rescuing the back plate from it. The only thing lacking the 6190 is T9 software.
In case you care, I own both.. as well as a bunch of Motorola products (iTAP is way worse than T9), some erikson products, some siemens products. The Nokia 61xx is a timeless classic; the 71xx is good enough.
Wordperfect 5.1 didn't have a grammar checker built into it; Grammatik (by another company) was an add-on product.
MS logic: If people are paying extra for Grammatik, there must be a market. Lets give it away for free, increase Word dominance, kill Grammatik's market, and not give consumers any more reasons to stick with WP51 (except, of course, that it was WAY faster than Word, had legal/government document templates available for it, and the files were a hell of a lot smaller)
> It isn't the Republicans who are causing 70 and 80 percent of the city's
> votes to go to Dems.
You sure about that?
We don't have to worry about hanging chads. We just put a goddamned X in the box. How fucking complicated does this election shit need to be??
*sigh*
Who even said anything about linux?
Who said anything about running a business? That's just my lab.