Use this section to talk about technical computer-related topics Message Lifetime: 365 days Thoughts of the day: MOV AX,BX Each Forum consists of a message database with attached files. There are eight basic levels of user access: Zero, Read, Download, Write, Upload, Co-Op, Forum-Op, and Sysop. "Read" access means that you can read messages only; "Download" access means you can also download files; "Write" access allows you to write (or post) messages; "Upload" access means that you can also upload attachments, but that the Forum-Op must approve them for download; "Co-Op" uploads are "pre-approved". You have "Sysop" access to this Forum. Your Forum-Op is "Super Nova". Please note: your account is charged 60 credits for each minute you spend in this Forum. In addition, you are given 300 credits each time you write a message, given 300 credits for each file uploaded, and not charged for each file downloaded. If a file you upload is approved for download, the Forum-Op might arrange for you to receive a bonus. All messages posted to this Forum are preserved indefinitely, until erased by the Forum-Op. Welcome, Sysop, to Programming: Computer programming R ... Read messages W ... Write a message F ... Find messages T ... Teleconference S ... Select a new Forum ? ... Description of this Forum M ... Modify a message E ... Erase a message A ... Approve files (0 waiting) O ... Operations menu Select a letter from this list, or X to exit: flfff Date: Monday, December 14, 1992 9:56pm Forum: Programming From: Indranie Msg#: 272926 To: ** ALL ** *EXEMPT* Re: Twas The Night Before Implementation (Copy by Lythande) TWAS THE NIGHT BEFORE IMPLEMENTATION Twas the night before implementation And all through the house Not a program was working, Not even a browse. The programmers hung by their tubes in despair, With hopes that a miracle soon would be there. The users were nestled all snug in their beds, While visions of inquiries danced in their heads. When out of the COPE there arose such a clatter, I sprang from my desk to see what was the matter. And what to my wondering eyes should appear, But a super programmer (with a six pack of beer). His resume glowed with experience so rare, He turned out great code with a bit pusher's flair. More rapid than eagles, his programs they came, And he whistled and shouted and called them by name: On Update! On Add! On Inquire! On Delete! On Batch Jobs! On Closing! On Functions Complete! His eyes were glazed over, fingers nimble and lean, From weekends and nights spent in front of a screen. A wink of his eye and a twist of his head, Soon gave me to know that I had nothing to dread. He spoke not a word, but went straight to his work, Turning specs into code, then turned with a jerk; And laying his finger upon the "enter" key, The systems came up and worked perfectly. The updates updated; the deletes, they deleted; The inquiries inquired and closings completed. He tested each whistle, and tested each bell. With nary an ABEND, and all had gone well. The system was finished, the tests were concluded, The users last changes were even included. And the user exclaimed with a snarl and a taunt, "It's just what I asked for, but not what I want!" Date: Friday, July 9, 1993 6:57pm Forum: Programming From: Conundrum Msg#: 376787 To: Rand *EXEMPT* Re: lpf.txt File: LPF.TXT (Copy by Lythande, Reply to #376353, Reply to #375880, R*) And sometimes it chooses wrong. Are a bunch of people smarter than one person? As far as the intelectual property stuff, I'd better just give you the entire league for programming speil. Conundrum||murdnunoC Date: Sunday, September 7, 1997 3:31pm Forum: Programming From: Antonio Msg#: 741025 To: Indranie Re: cgi and html (Reply to #703208, Reply to #674042, Reply to #669154, R*) (1 reply) Hellow. My name is Antonio and I would like some advice on how to incorporate C/C++, Assembly, and Windows to develope fast prgrams. Can I write certain segments of code in these defferent languages and piece them together latter. Would that be difficult and/or increase the runtime of my programs. Can anyone explain to me how I can access CD ROM and other multimedia capabilities into my program code? Date: Friday, January 23, 1998 2:48am Forum: Programming From: Conundrum Msg#: 744089 To: Antonio Re: cgi and html (Reply to #741025, Reply to #703208, Reply to #674042, R*) (1 reply) 1. This has nothing to do with CGI and/or HTML 2. Windows isn't a language. 3. The best way to combine C/C++ and ASM is to write the entire thing in C/C++, and try to use the internal optimizations there (especially since most causes of slowdown aren't based on it being 5 times as slow, as C might cause in a worst case, but because your algorithym isn't efficient, which is easier to fix in a high-level language like C++. If you profile your code, and decide that it's not fast enough because of one or two small, specific routines, you might want to recode just those routines in assembly (which you can do). Date: Friday, January 23, 1998 9:44am Forum: Programming From: Editor Msg#: 744110 To: Conundrum Re: cgi and html (Reply to #744089, Reply to #741025, Reply to #703208, R*) (1 reply) C >2. Windows isn't a language. That's right. A curse maybe, but not a language. (G) C >3. The best way to combine C/C++ and ASM is to write the entire thing C > C/C++, and try to use the internal optimizations there (especially C > since most causes of slowdown aren't based on it being 5 times as C > slow, as C might cause in a worst case, but because your algorithym C > isn't efficient, which is easier to fix in a high-level language li C > C++. If you profile your code, and decide that it's not fast enoug C > because of one or two small, specific routines, you might want to r C > just those routines in assembly (which you can do). Given the sophistication of these modern compilers, its hard to justify writing assembler code nowadays. In fact, in many cases, its hard to justify attempts to improve code efficiency. I had a programming who wrote a program to do some file manipulation. She really worked hard at minimizing I/O, etc., etc., When she was done, for the heck of it, wrote the program again, just writing simple straightforward code, and letting Unix worry about optimizing the I/O. The simple version of the program ran better than the "optimized" version. So now I focus 90% of my effort on simplicity and clarity. If I look at that code in 10 years, I don't want to have to go to a therapist to remember why I did it the way I did it. --- þ WinQwk 2.0 a#0 þ Unregistered Evaluation Copy Date: Friday, January 30, 1998 1:47am Forum: Programming From: Conundrum Msg#: 744351 To: Editor Re: cgi and html (Reply to #744110, Reply to #744089, Reply to #741025, R*) (1 reply) Damned straight. Hell, I often go whole hog, and write my code in "better" languages (perl and Java, mostly) over "faster" languages, like C and C++ (though I can and do certainly code in C/C++ if I need to). If the algorithm is bad, profiling in ASM won't help. If the algorithm is good, profiling might help a bit. Date: Friday, January 30, 1998 1:07pm Forum: Programming From: Editor Msg#: 744370 To: Conundrum Re: cgi and html (Reply to #744351, Reply to #744110, Reply to #744089, R*) (1 reply) C >Damned straight. C >Hell, I often go whole hog, and write my code in "better" languages C >(perl and Java, mostly) over "faster" languages, like C and C++ (thoug C >I can and do certainly code in C/C++ if I need to). C > If the algorithm is bad, profiling in ASM won't help. C > If the algorithm is good, profiling might help a bit. And what the compilers won't do for you, the hardware often will. Intel is now shipping 333 Mhz chips. I don't even know if they are producing 200s anymore. At this rate we'll probably have 500-700Mhz chips on store shelves before the end of the millenium. --- þ WinQwk 2.0 a#0 þ Unregistered Evaluation Copy Date: Monday, February 2, 1998 11:39pm Forum: Programming From: Conundrum Msg#: 744440 To: Editor Re: cgi and html (Reply to #744370, Reply to #744351, Reply to #744110, R*) (1 reply) ED>C > If the algorithm is bad, profiling in ASM won't help. ED>C > If the algorithm is good, profiling might help a bit. ED>And what the compilers won't do for you, the hardware often will. ED>Intel is ED>now shipping 333 Mhz chips. I don't even know if they are producing 200s ED>anymore. At this rate we'll probably have 500-700Mhz chips on store ED>shelves before the end of the millenium. There's a practical limit to megahertz,l but I expect to see 300 mhz chips that run 200 times as fast or faster in reasonable time. But again, the hardware does the same type of increase as assembly -- 2-3-100 times as fast, rather than exponentially faster (as improving the algorithm can make it). All of this just means that coding in a modern language and ignoring assembly like the plague is even more important than it used bo be. Date: Tuesday, February 3, 1998 11:02am Forum: Programming From: Editor Msg#: 744459 To: Conundrum Re: cgi and html (Reply to #744440, Reply to #744370, Reply to #744351, R*) (1 reply) C >ED>C > If the algorithm is bad, profiling in ASM won't help. C >ED>C > If the algorithm is good, profiling might help a bit. C >ED>And what the compilers won't do for you, the hardware often will. C >ED>Intel is C >ED>now shipping 333 Mhz chips. I don't even know if they are producing C >ED>anymore. At this rate we'll probably have 500-700Mhz chips on store C >ED>shelves before the end of the millenium. C > C >There's a practical limit to megahertz,l but I expect to see 300 mhz C >chips that run 200 times as fast or faster in reasonable time. But C >again, the hardware does the same type of increase as assembly -- C >2-3-100 times as fast, rather than exponentially faster (as improving C >the algorithm can make it). All of this just means that coding in a C >modern language and ignoring assembly like the plague is even more C >important than it used bo be. Mhz isn't everything. We'll see wider fetches, better cache, pipeling and more. Not to mention special instructions and coprocessors. Like I said, the most expensive thing today is the time spent analyzing the problem and validating the software. Not the hardware. Every few years I say that I am stunned and will no longer be impressed by new developments. And then someone does something even MORE incredible, for LESS money, and I'm stunned again. --- þ WinQwk 2.0 a#0 þ Unregistered Evaluation Copy Date: Tuesday, February 3, 1998 11:20pm Forum: Programming From: Conundrum Msg#: 744477 To: Editor Re: cgi and html (Reply to #744459, Reply to #744440, Reply to #744370, R*) (1 reply) ED>Mhz isn't everything. We'll see wider fetches, better cache, pipeling and ED>more. Not to mention special instructions and coprocessors. Yes, this was the meaning of my "300 mhz chips that run 200 times as fast" comment -- As much as we are increasing the clock rate, that is far from the greatest caause of improvement. ED>Like I said, the most expensive thing today is the time spent analyzing the ED>problem and validating the software. Not the hardware. Every few years I ED>say that I am stunned and will no longer be impressed by new developments. ED>And then someone does something even MORE incredible, for LESS money, and ED>I'm stunned again. Though at some point, we're going to have a breed of software which is capable of writing/debugging code which duplicates its functionality, and then things will REALLY get interesting. Date: Wednesday, February 4, 1998 10:37am Forum: Programming From: Editor Msg#: 744495 To: Conundrum Re: cgi and html (Reply to #744477, Reply to #744459, Reply to #744440, R*) (1 reply) C >ED>Mhz isn't everything. We'll see wider fetches, better cache, pipeli C >ED>more. Not to mention special instructions and coprocessors. C >Yes, this was the meaning of my "300 mhz chips that run 200 times as C >fast" comment -- As much as we are increasing the clock rate, that is C >far from the greatest caause of improvement. C > C > C >ED>Like I said, the most expensive thing today is the time spent analy C >ED>problem and validating the software. Not the hardware. Every few ye C >ED>say that I am stunned and will no longer be impressed by new develo C >ED>And then someone does something even MORE incredible, for LESS mone C >ED>I'm stunned again. C > C > Though at some point, we're going to have a breed of software C >which is capable of writing/debugging code which duplicates its C >functionality, and then things will REALLY get interesting. hehehe..... software that writes other software. Hope I have plenty of warning. I'll have to find an isolated island and stock up on barterables. --- þ WinQwk 2.0 a#0 þ Unregistered Evaluation Copy Date: Thursday, February 5, 1998 12:45am Forum: Programming From: Conundrum Msg#: 744502 To: Editor Re: cgi and html (Reply to #744495, Reply to #744477, Reply to #744459, R*) (1 reply) ED>hehehe... software that writes other software. Hope I have plenty of ED>warning. I'll have to find an isolated island and stock up on barterables. I wouldn't worry about true electronic inteligence causing the end of civilization; it's more likely to carry us with it. I'd say give it 5 years (to give us time to get past the end of the industrial world on January 1st, 2000), and see what's been developed before we make any real predictions along this line, but with game theory and 5GL compiler tech coming along, I see some possibilities along these lines. Date: Thursday, February 5, 1998 8:55am Forum: Programming From: Editor Msg#: 744517 To: Conundrum Re: cgi and html (Reply to #744502, Reply to #744495, Reply to #744477, R*) (1 reply) C >ED>hehehe... software that writes other software. Hope I have plenty o C >ED>warning. I'll have to find an isolated island and stock up on barte C > C >I wouldn't worry about true electronic inteligence causing the end of C >civilization; it's more likely to carry us with it. I'd say give it 5 C >years (to give us time to get past the end of the industrial world on C >January 1st, 2000), and see what's been developed before we make any r C >predictions along this line, but with game theory and 5GL compiler tec C >coming along, I see some possibilities along these lines. C > Everyone worries about 1/1/2000. I wonder how many remember that 2000 isn't a leap year. Or for that matter, the 32 bit "seconds since epoch" clock wraps in 2038. --- þ WinQwk 2.0 a#0 þ Unregistered Evaluation Copy Date: Wednesday, February 11, 1998 11:52pm Forum: Programming From: Conundrum Msg#: 744649 To: Editor Re: cgi and html (Reply to #744517, Reply to #744502, Reply to #744495, R*) (1 reply) ED>Everyone worries about 1/1/2000. I wonder how many remember that 2000 isn't ED>a leap year. Or for that matter, the 32 bit "seconds since epoch" clock ED>wraps in 2038. I knew about both of these, actually. I'm not TOO worried about the leap year -- aside from knowing about the div 400 thing in early College, I suspect it will cause lots of things to go off, but nothing to completely break. The time_t (2038) fun is another matter -- at best, it requires switching time_t to SIGNED int, recompiling everything, and praying; at worst, having to switch to a long int, and praying a lot. We'll see how fast things actually switch over, but there are systems NOW which use a 64 bit time_t, if few of them. Date: Thursday, February 12, 1998 10:00am Forum: Programming From: Editor Msg#: 744659 To: Conundrum Re: cgi and html (Reply to #744649, Reply to #744517, Reply to #744502, R*) (1 reply) C >ED>Everyone worries about 1/1/2000. I wonder how many remember that 20 C >ED>a leap year. Or for that matter, the 32 bit "seconds since epoch" c C >ED>wraps in 2038. C > C >I knew about both of these, actually. I'm not TOO worried about the C >leap year -- aside from knowing about the div 400 thing in early C >College, I suspect it will cause lots of things to go off, but nothing C >to completely break. C > The time_t (2038) fun is another matter -- at best, it requires C >switching time_t to SIGNED int, recompiling everything, and praying; a C >worst, having to switch to a long int, and praying a lot. We'll see h C >fast things actually switch over, but there are systems NOW which use C >64 bit time_t, if few of them. Uh huh... and how many structures do you have out there that use a 4 byte time_t that are going to get longer? And how many aligned structures are going to get screwed up because they are now two bytes off? And how many structures that were carefully optimized for best network performance are now going to be slightly too big, bringing the network to its knees? I think it will have to be an unsigned int, recompile, and lots of prayers. --- þ WinQwk 2.0 a#0 þ Unregistered Evaluation Copy Date: Friday, February 13, 1998 2:10am Forum: Programming From: Conundrum Msg#: 744663 To: Editor Re: cgi and html (Reply to #744659, Reply to #744649, Reply to #744517, R*) (1 reply) ED>Uh huh... and how many structures do you have out there that use a 4 ED>byte ED>time_t that are going to get longer? And how many aligned structures are ED>going to get screwed up because they are now two bytes off? And how many ED>structures that were carefully optimized for best network performance are ED>now going to be slightly too big, bringing the network to its knees? ED>I think it will have to be an unsigned int, recompile, and lots of prayers. True enough, though it would be nice to have the extra many-thousand years before the next switch, rather than a paltry 80 or so. Conundrum, who STILL doesn't understand why time_t started as a SIGNED int. Date: Friday, February 13, 1998 8:47am Forum: Programming From: Editor Msg#: 744671 To: Conundrum Re: cgi and html (Reply to #744663, Reply to #744659, Reply to #744649, R*) (1 reply) C >ED>Uh huh... and how many structures do you have out there that use a C >ED>byte C >ED>time_t that are going to get longer? And how many aligned structure C >ED>going to get screwed up because they are now two bytes off? And how C >ED>structures that were carefully optimized for best network performan C >ED>now going to be slightly too big, bringing the network to its knees C > C >ED>I think it will have to be an unsigned int, recompile, and lots of C > C >True enough, though it would be nice to have the extra many-thousand C >years before the next switch, rather than a paltry 80 or so. C > C >Conundrum, who STILL doesn't understand why time_t started as a SIGNED C >int. Never even occurred to me until I tried it, but it seems like a good trade off in comparing dates. If you do: int diff; time_t x,y; diff=x-y; You can have a jolly old time figuring out if diff is valid if x is less than y and both x and y are unsigned longs. At least with signed longs there is no ambiguity for interpretation by compiler writers. --- þ WinQwk 2.0 a#0 þ Unregistered Evaluation Copy Date: Tuesday, February 24, 1998 12:23am Forum: Programming From: Conundrum Msg#: 744827 To: Editor Re: cgi and html (Reply to #744671, Reply to #744663, Reply to #744659, R*) (1 reply) ED>Never even occurred to me until I tried it, but it seems like a good trade ED>off in comparing dates. If you do: ED> int diff; ED> time_t x,y; ED> diff=x-y; ED>You can have a jolly old time figuring out if diff is valid if x is less ED>than y and both x and y are unsigned longs. At least with signed longs ED>there is no ambiguity for interpretation by compiler writers. Good point, though a better solution would be to preform the extra calculation, for god's sake, and double your code lifetime. But lazyness wins out.... Date: Tuesday, February 24, 1998 12:23pm Forum: Programming From: Editor Msg#: 744840 To: Conundrum Re: cgi and html (Reply to #744827, Reply to #744671, Reply to #744663, R*) C >ED>Never even occurred to me until I tried it, but it seems like a goo C >trade C >ED>off in comparing dates. If you do: C > C >ED> int diff; C >ED> time_t x,y; C >ED> diff=x-y; C > C >ED>You can have a jolly old time figuring out if diff is valid if x is C >ED>than y and both x and y are unsigned longs. At least with signed lo C >ED>there is no ambiguity for interpretation by compiler writers. C > C >Good point, though a better solution would be to preform the extra C >calculation, for god's sake, and double your code lifetime. But C >lazyness wins out.... Not necessarily laziness. I put in a BICARSA system in 1980 for a "small" business. I had the owner of the business looking over my shoulder while I was coding. He didn't know what I was doing, but he knew that the longer the clock ran, the more it cost him. Its like the year 2000 stuff. Today everyone is huffing and puffing over the short sightedness. Back in 1980, if I had invested an extra 10% of the guys "huge" and expensive 64mb disk in keeping "century" data he would have had my head. Ummm... actually, knowing him he would have cut somewhat lower. --- þ WinQwk 2.0 a#0 þ Unregistered Evaluation Copy Date: Thursday, March 19, 1998 8:10pm Forum: Programming From: Amiga Msg#: 745466 To: ** ALL ** Re: Speaken of FAST 300mhz PROCESSORS! File: BOXER.TXT Here is some INFORMATION which was on CNET (the computer news show) It's on the BOXERs.. For those who don't know- the BOXERs are new computers which will be based on the AMIGA Operating System- and will have multi 300mhz processors...... You can download the FILES (at the end of this message) ;-) Date: Thursday, March 19, 1998 8:12pm Forum: Programming From: Amiga Msg#: 745467 To: ** ALL ** Re: PC mag says A few words about the AMIGA File: PCMAG.TXT Hey, check this out- (A PC MAG) says A few words about the AMIGA.. ya can download the file----> End of list! Select a Sysop option (R,W,F,T,S,M,E,A,O,X to exit or ? for menu):