 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsElectronicsBasicsRepairDesignCADComponentsEquipmentElectrical Engineering ElectronicsKB.com Contact UsLink To UsSearch & Site Map |
Electronics Forum / Design / July 2009Larkin, Power BASIC cannot be THAT good:
The run time in C is 13 seconds here on a 1GHz processor. Can you specify your 'old HP computer' ? I can win maybe 1 second by writing the code a bit different. And a 3GHz would do it in 12 / 4 = 4 seconds... A bigger cache would help a bit perhaps. A Cray would be even better. What does you C code look like? Mine is in the other posting. Else you goofed a factor 10. Seems to me anyways :-) > The run time in C is 13 seconds here on a 1GHz processor. > Can you specify your 'old HP computer' ? [quoted text clipped - 10 lines] > > Seems to me anyways :-) I just tried in Matlab, on a 2GHz core2-duo with 2GB with 32bit signed ints: ~2.5 second with 16bit signed ints: ~1.0 second with 64bit floats: ~4.0 second -Lasse >> The run time in C is 13 seconds here on a 1GHz processor. >> Can you specify your 'old HP computer' ? [quoted text clipped - 18 lines] > >-Lasse Yes, what I think happens is that those core2 duo execute those intructions a lot faster then my Celeron or whatever it is, so that would gain an other 200%, so Larkin's '''Old''' HP' must be a 3 GHz core? Maybe I should upgrade to a more recent processor, but luckely I do not need to add 64M integers :-) > The run time in C is 13 seconds here on a 1GHz processor. > Can you specify your 'old HP computer' ? [quoted text clipped - 10 lines] > > Seems to me anyways :-) Typing the following into Open Watcom, -=-=- #include <stdio.h> #include <stdlib.h> #include <windows.h> #define ARRAY_SIZE 64000000 int main(void) { short *a; int *s; int i; int startTime, endTime; a = malloc(ARRAY_SIZE * sizeof(short)); s = malloc(ARRAY_SIZE * sizeof(int)); if (a == NULL || s == NULL) { printf("Memory allocation failed.\n"); return -1; } printf("Starting...\n"); startTime = GetTickCount(); for (i = 0; i < ARRAY_SIZE; i++) { s[i] += a[i]; } endTime = GetTickCount(); printf("Total time taken adding %i array entries: %f seconds.\n", ARRAY_SIZE, ((float)(endTime - startTime)) / 1000); free(a); free(s); return 0; } -=-=- and saving as test.c and compiling, I get the typical output: -=-=- E:\WATCOM\Projects>test Starting... Total time taken adding 64000000 array entries: 1.453000 seconds. E:\WATCOM\Projects>test Starting... Total time taken adding 64000000 array entries: 1.546000 seconds. -=-=- My computer is an Athalon 2500 at 1.66GHz, 1.1GB PC133 RAM (currently 472MB free, so no problems allocating the test), running Windows XP SP2. Basically state-of-the-art way back in the year 2001. If your computers are taking more than a couple seconds, either your compiler really sucks or your computers suck even more. :-) Tim >> The run time in C is 13 seconds here on a 1GHz processor. >> Can you specify your 'old HP computer' ? [quoted text clipped - 71 lines] > >Tim Tim, you forgot that I was running >2 loops< inside each other, as Larkin's original post mentions: for(j = 0; j < 10; j++) { for(i = 0; i < BIG_SIZE; i++) { mem[i] += b[i]; } } So multiply your result by 10, and you got 15 seconds, even slower then me on the eeePC with 512 MB ram and 900 MHz celeron in Linux with gcc-4.0 :-) Sorry 'bout that ;-) >>> The run time in C is 13 seconds here on a 1GHz processor. >>> Can you specify your 'old HP computer' ? [quoted text clipped - 87 lines] > on the eeePC with 512 MB ram and 900 MHz celeron in Linux with gcc-4.0 :-) > Sorry 'bout that ;-) Just tried Tim's code (with another loop) compiled with Visual C++ 2008 express edition and run on a laptop with a 1.7GHz T2250 and 1GB Ram 2.23s >>>> The run time in C is 13 seconds here on a 1GHz processor. >>>> Can you specify your 'old HP computer' ? [quoted text clipped - 92 lines] > >2.23s Tim's code does not have the 10 x outside loop, so that makes it 22.3 seconds. >>>>> The run time in C is 13 seconds here on a 1GHz processor. >>>>> Can you specify your 'old HP computer' ? [quoted text clipped - 97 lines] > Tim's code does not have the 10 x outside loop, so that makes it 22.3 > seconds. (with another loop) mean't I added the 10 * loop so still 2.23s >>>>>> The run time in C is 13 seconds here on a 1GHz processor. >>>>>> Can you specify your 'old HP computer' ? [quoted text clipped - 99 lines] > >(with another loop) mean't I added the 10 * loop so still 2.23s Yea, I am down to 7 seconds now compiling with -O4 on my eeePC. >>> The run time in C is 13 seconds here on a 1GHz processor. >>> Can you specify your 'old HP computer' ? >>> >>> I can win maybe 1 second by writing the code a bit different. >>> And a 3GHz would do it in 12 / 4 = 4 seconds... >>> A bigger cache would help a bit perhaps. The only way I can get it to run that slow on my 3GHz old P4 HT chip is with full debugging enabled and the optimiser completely disabled in MS C++ Win32 console environment. I would hope for nearly an order of magnitude faster using SSE. NB You really should initialise the arrays first. Regards, Martin Brown >>>> The run time in C is 13 seconds here on a 1GHz processor. >>>> Can you specify your 'old HP computer' ? [quoted text clipped - 7 lines] >C++ Win32 console environment. I would hope for nearly an order of >magnitude faster using SSE. Cool, I just tried with gcc -O4 and it runs in .56 the time :-) >NB You really should initialise the arrays first. That will not affect timing of the loop. >The run time in C is 13 seconds here on a 1GHz processor. >Can you specify your 'old HP computer' ? [quoted text clipped - 10 lines] > >Seems to me anyways :-) Here's my PowerBasic code: =================================================== #COMPILE EXE ' SUM.BAS ' TRY SUMMING A LOT OF INTS INTO AN ARRAY OF LONGS... ' JL MAY 14, 2009 PBCC4 FUNCTION PBMAIN () AS LONG COLOR 15,9 CLS DIM A(64000000) AS INTEGER ' INPUT ADC SAMPLES DIM S(64000000) AS LONG ' SUMMING ARRAY DIM X AS LONG DIM Y AS LONG DIM Z AS LONG ' INIT INPUT ARRAY TO RANDOM-ISH VALUES... FOR X = 1 TO 64000000 ' THIS IS MUCH FASTER A(X) = X AND 32767 ' THAN CALLING RND()! NEXT T! = TIMER PRINT "Start... "; FOR Y = 1 TO 10 FOR X = 1 TO 64000000 S(X) = S(X) + A(X) NEXT NEXT PRINT "Done" E! = TIMER - T! PRINT USING$("Time per loop ##.### sec ##.## ns/add", E!/10, 1E9*E!/(10*64E6)) ' DISPLAY SOME RESULTS TO MAKE SURE IT REALLY WORKED... FOR X = 1 TO 10 PRINT X, A(X), S(X) NEXT FOR X = 63999001 TO 63999010 PRINT X, A(X), S(X) NEXT INPUT A$ END FUNCTION =================================================== On my computer, a 1.9 GHz Xeon with 2G ram, winXP, I get this result... Start... Done Time per loop 0.231 sec 3.61 ns/add 1 1 10 2 2 20 3 3 30 4 4 40 5 5 50 6 6 60 7 7 70 8 8 80 9 9 90 10 10 100 63999001 3097 30970 63999002 3098 30980 63999003 3099 30990 63999004 3100 31000 63999005 3101 31010 63999006 3102 31020 63999007 3103 31030 63999008 3104 31040 63999009 3105 31050 63999010 3106 31060 =================================================== One of my guys did a C version (I refuse to program in C) to run on the Kontron under Linux, a slightly slower CPU, 2G ram. I asked him for his source code, and he spent about a half hour cleaning it up to be presentable... which I asked him NOT to do. Anyhow, here it is: * mathsmash.c - a VERY crude benchmark * * time the sum of 64-million 16-bit integers into 64-million 32-integer sums. * * gcc -O3 mathsmash.c -o mathsmash.o * * NOTE: The loop is performed 10 times to make the measurement duration more reasonable. * * Timing is done by observation or including the system("date") functions. * * */ #define SIXTYFOURMILLION (0x100000 * 64) #define DATA_ARRAY_SIZE SIXTYFOURMILLION #include <stdio.h> int main() { unsigned short *inbound_data; unsigned int *sum_data; int multiply; unsigned long index = 0; #if 0 /* Initialize data */ printf ("Zeroing data\n"); #endif inbound_data = (unsigned short *) malloc (sizeof ( short ) * DATA_ARRAY_SIZE); sum_data = (unsigned *) malloc ((sizeof ( int )) * DATA_ARRAY_SIZE); printf ("inb_ptr = 0x%08x, sum_ptr= 0x%08x\n", inbound_data, sum_data); printf ("\n START sum operation...\n"); // system ("date"); for (multiply = 0; multiply < 10; multiply ++) // 10 x { for ( index = 0; index < DATA_ARRAY_SIZE; ++index ) sum_data[index] += inbound_data[index]; } printf ("\n END sum operation...\n"); // system ("date"); } =================================================== He commented out the system date things because they're buggy or something, and timed it with his wristwatch at about 0.25 seconds per 64M add, about the same as the PowerBasic. He used subscripts, not pointers, as I did. The inner loop compiles to five instructions. My program is prettier. John >>The run time in C is 13 seconds here on a 1GHz processor. >>Can you specify your 'old HP computer' ? [quoted text clipped - 178 lines] > >John Thank you for that code John, but unfortunately I do not have Power BASIC. But you did mention you tried it in C. I wonder if compiling your C code with -O4 in Linux would make it faster then the power BASIC version, as it gains 2x speed here. Forget my remark about -O4, runs the same with your C code as -O3, about 7 seconds on my eeePC. >Forget my remark about -O4, runs the same with your C code as -O3, about 7 seconds on my eeePC. He used -O3, whatever that means. Is that 7 seconds to add the array once, or for 10 times? John >>Forget my remark about -O4, runs the same with your C code as -O3, about 7 seconds on my eeePC. > >He used -O3, whatever that means. From 'man gcc' -O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops and -fgcse-after-reload options. -O4 seems to have disappeared from my man gcc, but gcc accepts it nevertheless. IIRC that was the most severe for speed optimisation known, but I could be wrong. I used tgcc-4.0, but also have 2.95 and 3.3 o nthsi system, some things may have changed and not the mamual... it does exists, people talk about it too, http://gcc.gnu.org/cgi-bin/search.cgi?q=-O4&cmd=Search&m=all&s=DRP >Is that 7 seconds to add the array once, or for 10 times? No, your code, or his code rather then, 10 x loop. So, on a Celeron 900 MHz with 512 MB RAM, but this Celeron is clocked down to 670 or something like that on the eeePC to save power.... So if you multiply 670 * (7 / 2.2) = 2.13 GHz if the processor worked the same. I think that is about in the same ballpark as you have. I must admit pretty good for power-BASIC. >John > Forget my remark about -O4, runs the same with your C code as -O3, about 7 seconds on my eeePC. I suspect this is all limited by the system memory bandwidth. So that as long as the data sizes are the same, everything that is at all efficient will produce the same results.  SignatureJohn Devereux >> Forget my remark about -O4, runs the same with your C code as -O3, about 7 seconds on my eeePC. > > I suspect this is all limited by the system memory bandwidth. It looks like it, with -O4 optimisiation on dual-threaded and single-threaded versions both run in 1.9 seconds here. >>> Forget my remark about -O4, runs the same with your C code as -O3, about 7 seconds on my eeePC. >> I suspect this is all limited by the system memory bandwidth. > > It looks like it, with -O4 optimisiation on dual-threaded and single-threaded > versions both run in 1.9 seconds here. Yes. It is bandwidth limited on the external ram because of the way it hits sequential locations once per loop. Using DDR2 ram execution is roughly 2s and older DDR ram is about 3s in execution. The absolutely dire code generated by debug mode with all optimisation disabled is only 4s. So it isn't really a test of PowerBasics code generation at all. The real test of an optimising compiler is how well it can exploit cache aware alogrithms with multiple nested loops. A cache aware version of this vector add and accumulate (without using SIMD instructions) is about 15% faster than the simple loop on a good optimising compiler (actually that is measured on MSC I haven't checked its code generation for optimisation - too tedious). I suspect gcc might be better. The optimisation totally disabled version compiled by MSC is: for (i = 0; i < ARRAY_SIZE; i++) { 004010BE mov dword ptr [i],0 004010C5 jmp main+0D0h (4010D0h) 004010C7 mov ecx,dword ptr [i] 004010CA add ecx,1 004010CD mov dword ptr [i],ecx 004010D0 cmp dword ptr [i],3D09000h 004010D7 jge main+0F7h (4010F7h) s[i] += a[i]; 004010D9 mov edx,dword ptr [i] 004010DC mov eax,dword ptr [a] 004010DF movsx ecx,word ptr [eax+edx*2] 004010E3 mov edx,dword ptr [i] 004010E6 mov eax,dword ptr [s] 004010E9 add ecx,dword ptr [eax+edx*4] 004010EC mov edx,dword ptr [i] 004010EF mov eax,dword ptr [s] 004010F2 mov dword ptr [eax+edx*4],ecx } 004010F5 jmp main+0C7h (4010C7h) And takes 4s on P4 3GHz with DDR ram. Optimiser turns it into something like mov esi, a mov edi, s mov ecx, ARRAY_SIZE xor edx, edx forloop: movsx eax, word ptr[esi+2*edx] add dword ptr[edi+4*edx], eax inc edx loop forloop And this extremely tight optimised loop code still takes 3s with DDR ram and just under 2s with DDR2 ram. MSC has changed the way it does this. My oldest compiler generates a pointer implementation for array access whereas newer compilers exploit the additional scaled indexing features of later CPUs. The oldest compiler generates very slightly faster code for the loop (at least it does after a manual reordering of the generated instructions). forloop: movsx eax,word ptr[esi] add esi, 2 add dword ptr[edi], eax add edi, 4 loop forloop Code snippets above subject to typos. Be interested to see what code gcc -O4 generates. Regards, Martin Brown >>The run time in C is 13 seconds here on a 1GHz processor. >>Can you specify your 'old HP computer' ? [quoted text clipped - 178 lines] > >John Re: My program is prettier. I don't think so. For one thing your program is shouting. >>>The run time in C is 13 seconds here on a 1GHz processor. >>>Can you specify your 'old HP computer' ? [quoted text clipped - 182 lines] > >I don't think so. For one thing your program is shouting. Real programmers don't use lower case. John On May 16, 10:06 am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > >>>The run time in C is 13 seconds here on a 1GHz processor. > >>>Can you specify your 'old HP computer' ? [quoted text clipped - 186 lines] > > John Nah. Real Programmers don't use anything with 'case' at all. (Which I guess includes binary, octal and decimal, as well as any entry method, especially panel switches.) Tim >On May 16, 10:06 am, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 195 lines] > >Tim The impressive thing about C and C++, as languages and as a culture, is that as programmers become more experienced and "skilled", the readability of their code drops and the bug rate remains high. John >The impressive thing about C and C++, as languages and as a culture, >is that as programmers become more experienced and "skilled", the >readability of their code drops and the bug rate remains high. Well, you should state : "I think that", as it is clearly an opinion not supported by any real data. The bug rate is normally very low, for C programs (dunno about C+++, I do not consider that a language, so you could well be right about that), there a 2 very basic sort of errors in C programs. One is the program flow itself: does it actually do what you want it to do, that is probably the same for all languages and is the essence of programming, the other is out of range pointers and that includes not checking return values like somebody did here in his C example, but that is bad practice. That you cannot read C does not make it less readable by a C programmer. I cannot read Japanese, so I cannot give an opinion on Japanese writings, you cannot read C, so how can you give an opinion on C writings? >John >>The impressive thing about C and C++, as languages and as a culture, >>is that as programmers become more experienced and "skilled", the [quoted text clipped - 12 lines] > >That you cannot read C does not make it less readable by a C programmer. Do C programmers ever read code? They seem to seldom read their own, except when forced to look for a bug. I have seen scads of "professionally" written C that was an uncommented, buggy mess, with code commented out all over the place without explanation. It's a bummer to spend time trying to understand a hunk of code only to discover a little /* thing somewhere above. John >Do C programmers ever read code? They seem to seldom read their own, >except when forced to look for a bug. [quoted text clipped - 3 lines] >without explanation. It's a bummer to spend time trying to understand >a hunk of code only to discover a little /* thing somewhere above. /* LOL, no that did not happen to me, yes I am the one who writes comments that way. */ #define ONE 1 int small = 2; int i; for(i = 0; i < small; i += ONE) { /* I guess it is like using an editor with coloring, if freaked me out, I like black on white, cannot read green on a white background (I always use white background in the editor because the light level is then more constant), such things as 'if' 'for(' and other keywords read, at least to me, and that includes '/*' and '*/', as normal words in a text. Imagine a novel with all nouns in a different color, Oh, should not have mentioned it, somebody is gonna read this and try. As to comments, if you use sane variable names, and no 'a' 'b' 'c' only, then the code is very much self explaining. */ fprintf(stderr, "Hello.\n"); } >>>The impressive thing about C and C++, as languages and as a culture, >>>is that as programmers become more experienced and "skilled", the [quoted text clipped - 20 lines] >without explanation. It's a bummer to spend time trying to understand >a hunk of code only to discover a little /* thing somewhere above. That is why I import projects from others into Eclipse (with CDT). Eclipse gives me a nice list with classes/functions. And Eclipse has an excellent text search function. Very easy while digging into a C/C++ project. SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >>>>The impressive thing about C and C++, as languages and as a culture, >>>>is that as programmers become more experienced and "skilled", the [quoted text clipped - 25 lines] >an excellent text search function. Very easy while digging into a >C/C++ project. Drowning in uncontrolled complexity? Add more automation tools! John >>>>>The impressive thing about C and C++, as languages and as a culture, >>>>>is that as programmers become more experienced and "skilled", the [quoted text clipped - 27 lines] > >Drowning in uncontrolled complexity? Add more automation tools! Looking for something to drive a nail in the wall? Get a hammer! SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- PS, some remark about *your* C programmer, not to piss him / her off, but something I consider very important, he /she uses 'short' and 'int' and 'unsiged short' etc... One should always specify the size of the variables, as those may be different on different machines: This is from libc.info, the reference for C programming with gcc: Integers ======== The C language defines several integer data types: integer, short integer, long integer, and character, all in both signed and unsigned varieties. The GNU C compiler extends the language to contain long long integers as well. The C integer types were intended to allow code to be portable among machines with different inherent data sizes (word sizes), so each type may have different ranges on different machines. The problem with this is that a program often needs to be written for a particular range of integers, and sometimes must be written for a particular size of storage, regardless of what machine the program runs on. To address this problem, the GNU C library contains C type definitions you can use to declare integers that meet your exact needs. Because the GNU C library header files are customized to a specific machine, your program source code doesn't have to be. These `typedef's are in `stdint.h'. If you require that an integer be represented in exactly N bits, use one of the following types, with the obvious mapping to bit size and signedness: * int8_t * int16_t * int32_t * int64_t * uint8_t * uint16_t * uint32_t * uint64_t If your C compiler and target machine do not allow integers of a certain size, the corresponding above type does not exist. If you don't need a specific storage size, but want the smallest data structure with _at least_ N bits, use one of these: * int8_least_t * int16_least_t * int32_least_t * int64_least_t * uint8_least_t * uint16_least_t * uint32_least_t * uint64_least_t If you don't need a specific storage size, but want the data structure that allows the fastest access while having at least N bits (and among data structures with the same access speed, the smallest one), use one of these: * int8_fast_t * int16_fast_t * int32_fast_t * int64_fast_t * uint8_fast_t * uint16_fast_t * uint32_fast_t * uint64_fast_t If you want an integer with the widest range possible on the platform on which it is being used, use one of the following. If you use these, you should write code that takes into account the variable size and range of the integer. * intmax_t * uintmax_t The GNU C library also provides macros that tell you the maximum and minimum possible values for each integer data type. The macro names follow these examples: `INT32_MAX', `UINT8_MAX', `INT_FAST32_MIN', `INT_LEAST64_MIN', `UINTMAX_MAX', `INTMAX_MAX', `INTMAX_MIN'. Note that there are no macros for unsigned integer minima. These are always zero. There are similar macros for use with C's built in integer types which should come with your C compiler. These are described in *Note Data Type Measurements::. Don't forget you can use the C `sizeof' function with any of these data types to get the number of bytes of storage each uses. File: libc.info, Node: Integer Division, Next: Floating Point Numbers, Prev: Integers, Up: Arithmetic > PS, some remark about *your* C programmer, not to piss him / her off, > but something I consider very important, > he /she uses 'short' and 'int' and 'unsiged short' etc... > One should always specify the size of the variables, as those may be different on > different machines: If you have a specific number of bits in mind, use the <stdint.h> types. OTOH, if you need compatibility with library functions, use the appropriate types (which are usually platform-specific). E.g. printf("%d") needs int not int32_t, malloc() wants size_t, etc. This is more of an issue for pointers. The compiler will cast numeric values as needed, but it won't convert pointer targets, so don't pass a pointer to an int32_t to a function which expects an int* (casting the pointer won't help; you need to convert the data). You also need to remember C's implicit casting rules, which can produce some fairly awkward interactions if you mix platform-specific types (int, long, ...) with fixed-width types from <stdint.h>. >>On May 16, 10:06 am, John Larkin >><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 13 lines] >is that as programmers become more experienced and "skilled", the >readability of their code drops and the bug rate remains high. In my experience bugs have more to do with being sloppy (typos), misunderstanding multi-threading and bad design (or no design at all). SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >>>On May 16, 10:06 am, John Larkin >>><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 16 lines] >In my experience bugs have more to do with being sloppy (typos), >misunderstanding multi-threading and bad design (or no design at all). Bugs have mostly to do with typing fast, not reading and checking, and running the code to find some of the bugs. Languages like C encourage dense, risky, tricky code. Languages like Ada do everything they can to discourage it. Most programmers hate languages like Ada and Basic because they slow them down and make them think. C also allows all sorts of memory-management and variable type/range errors that no modern language should allow to happen. Malloc, memcpy, wild pointers, things like that. It's barbaric. Extreme Programming makes the case that two programmers writing a piece of code on one shared screen is more efficient, on average, than one programmer. That's pitiful. You can't argue that C (and its culture) generally results in good or secure executables, because it so obviously doesn't. John >You can't argue that C (and its culture) generally results in good or >secure executables, because it so obviously doesn't. Obviously does, as Linux is written in C (the kernel, the drivers, and many if not most applications). C++ OTOH is not something I consider a language, and you may be right about that. But C is like having the soldering iron on the hardware so to speak. You can do anything right, and anything wrong. While other languages (except for asm) have some more distance, Like you on the bench with the remote control. For real design C is a must :-) For user work BASIC will do. ;-) To be a bit more serious, the old BASIC had those gotos and line numbers, you got stuck with no space between line numbers, and needed a renumber routine. I found asm much more easy than that BASIC because the assembler allowed me nice long labels. BASIC has come a long way since then. >>You can't argue that C (and its culture) generally results in good or >>secure executables, because it so obviously doesn't. > >Obviously does, as Linux is written in C (the kernel, the drivers, and many if >not most applications). The advantage of Linux is that many, many eyeballs review the code, and the authors know that their code will be seen and criticized in public. That probably encourages them to be more careful. Plus, the code is debugged by many, many people. Most programmers work on their bit of code alone. Nobody checks their source code but themselves. They don't comment because they figure they will remember their design intent forever, or because they were never taught to document their own code. >C++ OTOH is not something I consider a language, and you may be right >about that. [quoted text clipped - 5 lines] > >For real design C is a must :-) What do you mean by "real design"? I do real products in assembly. Most truly mission-critical, lives-depend-on-it programming (like the stuff that flies airplanes) is done in Ada. >For user work BASIC will do. BASIC is great for people like engineers who just want to get the computing done, correctly. PRINT USING alone is a good reason to program in BASIC. >;-) > [quoted text clipped - 3 lines] >long labels. >BASIC has come a long way since then. Absolutely. PB has all the modern constructs, WHILE, CASE, TRY/CATCH, graphics, all that. But I still think in state machines, and GOTO is a perfectly good way to structure state machines. Nothing flow-charts as nicely as a program based on GOTOs. The anti-GOTO nonsense was started by Dijkstra, who didn't program much himself and didn't have regular access to a computer. Software should be like hardware: do it the cleanest way, take your time, document it thoroughly, get it right the first pass. It rarely is. If you consider all the components of a complex system, software is the least reliable, the hardest to manage, the hardest to maintain, the most likely to destroy the company, and usually the most expensive. John >>To be a bit more serious, the old BASIC had those gotos and line numbers, >>you got stuck with no space between line numbers, and needed a renumber routine. [quoted text clipped - 8 lines] >by Dijkstra, who didn't program much himself and didn't have regular >access to a computer. Well, in C I avoid goto, in fact there is no need for it. I often even avoid for loops, if I need this: for(i = 0; i < something; i++) {} Then I will likely write: count = 0; while(1) { if(conditon1) {do_this;} if(condition2) {do_that;} if(it_rains) {wear_hat;} if(count > then_what_I_want) break; count++; } The other thing I always try is return if possible. while(1) { if(condition1) {do_this;return OK;} //etc } This is a bit harder to explain but avoids errors and keeps the code clean. Lemme give a real example, this is from xste subtitle editor that I wrote. It allows you to add text subtitles to a video stream, does automatic text formatting etc. Had to figure out things, code has been around for many years now, many downloads. It is, as far as I know, the only subtitle editor available for Linux. It uses a lot of global vars too... you like that if you like BASIC. Also note the parameter checks ever so often, and the debug print statement that can be activated with a command line flag. That means if it ever crashes (it does not) and you run it with debug request, it will print the last variables before the crash, plus where it is, which function, and where in that function, so you can fix it immediately. int create_bitmap_file(struct frame *pa) { int a, c, i, j; int l, h, hh; char *tptr, *cptr; int x, y; char temp[4096]; FILE *fptr; int text_start, max_width, line_len; uint8_t *py; int color; int file_size; int image_size; int bitmap_byte = 0; // -Wall int odd_byte; int error; int padding; int bits; if(debug_flag) { printf("create_bitmap_file(): arg pa=%p\n", pa); } /* argument check */ if(! pa) return 0; /* set all of drawing area to background */ for(i = 0; i < (720 * 576 * 3); i += 3) { image_buffer[i] = pa -> background; } /* some defaults */ pa -> width = 0; pa -> height = 0; pa -> xpos = 0; pa -> ypos = 0; /* end defaults */ line_h_start = h_factor * (double)h_size; line_h_end = (double)h_size - (double)line_h_start; window_bottom = v_size - (v_factor * (double)v_size); /* Set hor_position for start text in all lines to zero, center_text() may overrule this if center_flag. */ for(i = 0; i < MAX_SCREEN_LINES; i++) { screen_text[i][0] = 0; screen_start[i] = 0; // pixels from left used to center text } /* reformat text inserting (multiple) '/n' if too long */ tptr = p_reformat_text(pa, line_h_end - line_h_start); if(! tptr) { printf("create_bitmap_file(): could not reformat text=%s\n", pa -> text); /* return error */ return 0; } /* end if reformat text failed */ /* center text */ if(pa -> status & CENTER_TEXT) p_center_text(tptr, pa); /* text to array screen_text[] */ cptr = tptr; screen_lines = 1; /* at least one */ while(1) /* all chars in tptr */ { i = 0; while(1) /* all chars in a line */ { if(*cptr == '\n') { /* scip the '\n' */ cptr++; /* force string termination */ screen_text[screen_lines - 1][i] = 0; /* point to next screen line */ screen_lines++; break; } /* copy character */ screen_text[screen_lines - 1][i] = *cptr; /* test for end of string tptr */ if(*cptr == 0) break; /* point to next char in screen_lines[][] */ i++; /* point to next char in tptr */ cptr++; } /* end while all characters in line terminated with LF */ /* ready if end of tptr */ if(*cptr == 0) break; } /* end while all lines in tptr */ free(tptr); /* some limit */ if(screen_lines > MAX_SCREEN_LINES) screen_lines = MAX_SCREEN_LINES; line_height = pa -> pfd -> height + pa -> vespace; window_top = window_bottom - (screen_lines * line_height) + pa -> vespace; if(debug_flag) { printf("line_height=%d\n", line_height); printf("screen_lines=%d\n", screen_lines); printf("line_h_start=%d line_h_end=%d\n",\ line_h_start, line_h_end); printf("window_bottom=%d window_top=%d\n",\ window_bottom, window_top); } // Maybe no warn / scip here, input test was already done, this is fuzzy? if(window_top < 0 - line_height) { fl_show_alert("Image for frame", pa -> name, "does not fit.\nSkipped.", 0); return 0; } /* print lines of text on screen in right position */ text_start = INT_MAX; max_width = 0; for(i = 0; i < screen_lines; i++) { /* convert any special characters */ /* j = 0; while(1) { c = screen_text[i][j]; character_lookup(c, &b); screen_text[i][j] = b; if(c == 0) break; j++; } */ /* get text length */ line_len = 0; j = 0; while(1) { c = screen_text[i][j]; line_len += get_h_pixels(c, pa); if(c == 0) break; j++; } x = screen_start[i]; if(x < text_start) text_start = x; if(line_len > max_width) max_width = line_len; y = window_top + (i * line_height); if(debug_flag) { printf(\ "screen_start[%d]=%d window_bottom=%d window_top=%d\n\ line_height=%d x=%d y=%d\n\ text=%s\n",\ i, screen_start[i], window_bottom, window_top,\ line_height, x, y,\ screen_text[i]); } /* int add_text_x(\ int x, int y, char *text, struct frame *pa, int u, int v, double contrast, double transparency) */ add_text(x, y, screen_text[i], pa, 0, 0, 100.0, 0.0); } /* end for all screen_lines */ pa -> ypos = window_top; /* text_start is the start of the most left character start in a (multiline) text. max_width is the length of the text in pixels. */ pa -> height = screen_lines * line_height - pa -> vespace; // + 9; pa -> xpos = text_start; /* add some space for outline */ pa -> width = max_width + 6; /* CVD needs even width */ /* if width is not multiple of 8, make it */ a = pa -> width % 8; if(a) pa -> width += 8 - a; /* CVD needs even height, if height is not multiple of 4, make it */ a = pa -> height % 4; if(a) pa -> height += 4 - a; if(debug_flag) { printf("create_bitmap_file():\n\ frame=%s\n\ text_start=%d max_width=%d\n\ pa>xpos=%d pa->ypos=%d\n\ pa->width=%d pa->height=%d\n\ pa->text=%s\n",\ pa -> name,\ text_start, max_width,\ pa -> xpos, pa -> ypos,\ pa -> width, pa -> height,\ pa -> text); } /* return error if not usable overlay */ error = 0; /* no pointer to text */ if(! pa -> text) error = 1; /* no text */ if(pa -> text[0] == 0) error = 1; /* no width */ if(pa -> width <= 0) error = 1; /* no height */ if(pa -> height <= 0) error = 1; /* negative xpos */ if(pa -> xpos < 0) error = 1; /* negatve ypos */ if(pa -> ypos < 0) error = 1; /* reformatter failed */ if(max_width == 0) error = 1; /* no space left to print, reformatter failed margin? */ if(pa -> xpos >= (h_size / 2) ) error = 1; /* falls of right hand side of screen */ if( (pa -> width + pa -> xpos) >= h_size) error = 1; /* falls of bottom of screen */ if(pa -> height >= v_size ) error = 1; if(error) { if(debug_flag) { printf("create_bitmap_file(): ERROR\n"); } /* return error */ return 0; } /* end if error */ /* lets write our own bitmap, ppmtobmp does not fill in the complete colormap, the h and v size, the ColorsImportant field, and the bitmap size. */ /* open the bmp file for write */ if(pa -> status & TEST_BITMAP) { sprintf(temp, "%s/%s/%s/test.bmp",\ home_dir, selected_data_directory, selected_project); } else { sprintf(temp, "%s/%s/%s/frame%04d.bmp",\ home_dir, selected_data_directory, selected_project, atoi(pa -> name) ); } fptr = fopen(temp, "w"); if(! fptr) { printf(\ "create_bitmap_file(): could not open file %s for write, aborting\n",\ temp); exit(1); } /* 600 x 120 origial .bmp from iauthor. 0000:0000 42 4d 16 8d 00 00 00 00 00 00 76 00 00 00 28 00 BM........v...(. 0000:0010 00 00 58 02 00 00 78 00 00 00 01 00 04 00 00 00 ..X...x......... 0000:0020 00 00 a0 8c 00 00 00 00 00 00 00 00 00 00 10 00 .. ............. 0000:0030 00 00 00 00 00 00 00 00 00 00 ff ff ff 00 00 00 ..........ÿÿÿ... 0000:0040 80 00 00 80 00 00 00 00 48 0a e6 3c f5 bf 00 00 ........H.æ<õ¿.. 0000:0050 7f 10 84 c2 64 7a ff ff c7 3d 98 c2 f7 3e d7 16 ...ÂdzÿÿÇ=.Â÷>×. 0000:0060 ff ff c7 3d 00 00 b0 80 02 00 6f 00 b2 c2 d0 10 ÿÿÇ=..°...o.²ÂÐ. 0000:0070 af 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ¯............... 0000:0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ */ /* print header, all low byte first! */ /* type */ fprintf(fptr, "%c%c", 0x42, 0x4d); /* file_size */ file_size = (pa -> width * pa -> height / 2) + 118; h = file_size / 256; l = file_size - (256 * h); fprintf(fptr, "%c%c", l, h); if(debug_flag) { printf("file_size=%d l=%d h=%d to file=%02x %02x\n",\ file_size, l, h, l, h); } /* 2 x reserved */ fprintf(fptr, "%c%c%c%c%c%c", 0, 0, 0, 0, 0, 0); /* offset to bitmap data */ fprintf(fptr, "%c%c%c%c", 0x76, 0, 0, 0); // 118 /* BitmapInfoHeader starts here, its size */ fprintf(fptr, "%c%c%c%c", 0x28, 0, 0, 0); /* picture width, always < 65535 here (SVHS standard), so highest byte is zero. */ h = pa -> width / 256; l = pa -> width - (h * 256); fprintf(fptr, "%c%c%c%c", l, h, 0, 0); if(debug_flag) { printf("pa->width=%d l=%d h=%d to file=%02x %02x %02x %02x\n",\ pa -> width, l, h, l, h, 0, 0); } /* picture height, always < 65535! so highest byte is zero */ h = pa -> height / 256; l = pa -> height - (h * 256); fprintf(fptr, "%c%c%c%c", l, h, 0, 0); if(debug_flag) { printf("pa->height=%d l=%d h=%d to file=%02x %02x %02x %02x\n",\ pa -> height, l, h, l, h, 0, 0); } /* planes , one plane */ fprintf(fptr, "%c%c", 1, 0); /* bit count, 4 bpp */ fprintf(fptr, "%c%c", 4, 0); /* compression, no compression */ fprintf(fptr, "%c%c%c%c", 0, 0, 0, 0); /* size image */ image_size = pa -> width * pa -> height / 2; hh = image_size / 65536; h = (image_size - (65536 * hh) ) / 256; l = image_size - (65536 * hh) - (256 * h); fprintf(fptr, "%c%c%c%c", l, h, hh, 0); if(debug_flag) { printf("image_size=%d l=%d h=%d hh=%d to file=%02x %02x %02x %02x\n",\ image_size, l, h, hh, l, h, hh, 0); } /* XPelsPerMeter */ fprintf(fptr, "%c%c%c%c", 0, 0, 0, 0); /* YPelsPerMeter */ fprintf(fptr, "%c%c%c%c", 0, 0, 0, 0); /* ColorsUsed */ fprintf(fptr, "%c%c%c%c", 0x10, 0, 0, 0); /* ColorsImportant */ fprintf(fptr, "%c%c%c%c", 0x00, 0, 0, 0); for(i = 0; i < 16; i++) { /* bgr to rgb */ fprintf(fptr, "%c%c%c%c", xste_rgb_palette[i][2], xste_rgb_palette[i][1], xste_rgb_palette[i][0], 0); } /* write bitmap data */ for(y = pa -> height; y > 0; y--) { /* start line of pixels in main screen */ py = \ image_buffer + \ (3 * \ ( ( (pa -> ypos - 1 + y) * h_size ) + \ pa -> xpos\ )\ ); /* get a line from buffer start, to file in RGB */ /* from BMP.txt from the www: If necessary, a scan line must be zero-padded to end on a 32-bit boundary. However, segment boundaries can appear anywhere in the bitmap. So, 32 bits is 4 bytes!!! zero padding. */ odd_byte = 0; bits = 0; for(x = 0; x < pa -> width ; x++) { /* We have 3 bytes per pixel in the buffer, we want to send 4 bits per pixel, so 2 pixels is one byte. For every 6 bytes in the buffer we write one byte! */ color = *py; /* always start line on byte boundary */ /* does win bmp have low byte first in the bitmap ????? */ /* if low nibble, remember */ if(! odd_byte) { /* data to upper 4 bits */ bitmap_byte = color << 4; } else { /* combine */ bitmap_byte |= color; /* to bmp file */ fprintf(fptr, "%c", bitmap_byte); bits += 8; } /* point to next pixel in source */ py += 3; /* reverse odd byte */ odd_byte = 1 - odd_byte; } /* end for all x */ /* Test if we need to pad, need to be at 32 bits boundary. */ padding = bits % 32; if(! padding) continue; /* output an extra nibble */ a = 32 - padding; for(i = 0; i < a / 8; i++) { fprintf(fptr, "%c", 0); } } /* end for y (all lines) */ fclose(fptr); return 1; } /* end function create_bitmap_file*/ >Software should be like hardware: do it the cleanest way, take your >time, document it thoroughly, get it right the first pass. [quoted text clipped - 3 lines] >maintain, the most likely to destroy the company, and usually the most >expensive. Well, I dunno, I have very little problems with very complicated software. Some have thousands of downloads, and most zero error reports. Lately there has been a run on some programs again, clearly somebody wrote about it or linked to it :-) Indeed if you publish open source, it better be good, or you will drawn in email. xste has 33222 lines of C code, not counting the 14 header files.... Bugs? What bugs? Oh, and it does audio + video too of course, has its own players build in. Apart from libforms it interfaces directly with the system.... no SDL stuff or such. Half a megabyte executable or so, no need for bloat. >>>You can't argue that C (and its culture) generally results in good or >>>secure executables, because it so obviously doesn't. [quoted text clipped - 11 lines] > they will remember their design intent forever, or because they were > never taught to document their own code. Right. But this isn't C's fault. You will see more crappy code written in C than in most other languages simply because you will see more code written in C than in most other languages. If you need to tackle a wide range of programming tasks, you need to know C. There is no other language with such a wide range of applicability (with the caveat that C++ is essentially a superset of C). You don't see OS kernels being written in Ada or Python or BASIC. And once you know C, you don't really *need* to know anything else. Sure, there are lots of cases where other languages might be more suitable, but C is usually "good enough". But there are plenty of cases where C/C++ is the only language which is good enough. There are a lot of half-baked programmers whose knowledge of languages started with VB or JavaScript, maybe a couple more languages are learnt for specific tasks, then they learn C and never need to learn another language. >>For real design C is a must :-) > > What do you mean by "real design"? I do real products in assembly. Assembly is a non-starter if you need the code to run on multiple architectures (or if you suspect that it may need to do so in the future). It's also unrealistic for large applications. > Most truly mission-critical, lives-depend-on-it programming (like the > stuff that flies airplanes) is done in Ada. That kind of software development is only feasible if you have the kind of customer who pays $2000 for a screwdriver. IOW, the DoD, NASA, ... er just those two, really. Most software development is rather more price-sensitive. >>To be a bit more serious, the old BASIC had those gotos and line numbers, >>you got stuck with no space between line numbers, and needed a renumber routine. [quoted text clipped - 8 lines] > by Dijkstra, who didn't program much himself and didn't have regular > access to a computer. Dijkstra was right, though; "goto" is the antithesis of structured programming. It's hardly ever used in high-level languages. The main use of "goto" in C is to clean up on errors, which is done using exception handling, constructors, and destructors in C++. > Software should be like hardware: do it the cleanest way, take your > time, document it thoroughly, get it right the first pass. [quoted text clipped - 3 lines] > maintain, the most likely to destroy the company, and usually the most > expensive. That's because it accounts for 99% of the system. Think about implementing a PC with a dozen substantial applications using dedicated logic rather than a CPU and software. You would be lucky to fit it onto a silicon wafer, and even the DoD wouldn't be able to afford one. >>>> You can't argue that C (and its culture) generally results in good or >>>> secure executables, because it so obviously doesn't. [quoted text clipped - 74 lines] > than a CPU and software. You would be lucky to fit it onto a silicon > wafer, and even the DoD wouldn't be able to afford one. It isn't GOTO that's horrible, it's named labels. Every time I come across a named label in code, I have to go figure out every single place in the code where the jump could have originated. Ugly ugly ugly. For a state machine, it would be very unlikely to come from more than 100 lines away, which is barely acceptable. A switch statement in a while(1) loop [or for(;;), which is more idiomatic] is the way to go for state machines. That way you know where the code begins and ends, and the machine code is equivalent. There was a joke article many moons ago proposing a COMEFROM statement, which would silently put a jump anywhere you liked--not very different from a named label! Cheers Phil Hobbs >>>>> You can't argue that C (and its culture) generally results in good or >>>>> secure executables, because it so obviously doesn't. [quoted text clipped - 78 lines] >across a named label in code, I have to go figure out every single place >in the code where the jump could have originated. Subroutines have the same horrible problem: they have names, and can be called from all over the place. John >>>>>> You can't argue that C (and its culture) generally results in good or >>>>>> secure executables, because it so obviously doesn't. [quoted text clipped - 78 lines] > > John It isn't the same, though--the routine has a well-defined beginning and end, and unless the coder is a moron, it does some well-defined thing that is at least vaguely suggested by its name. Also cross-referencing tools (e.g. docxx) do a great job of showing you the program flow. Cheers Phil Hobbs >>>>>>> You can't argue that C (and its culture) generally results in good or >>>>>>> secure executables, because it so obviously doesn't. [quoted text clipped - 87 lines] > >Phil Hobbs Crimson Editor has this "search" thing that lets me find all references to a label. Pretty nifty. John >>>>>>>> You can't argue that C (and its culture) generally results in good or >>>>>>>> secure executables, because it so obviously doesn't. [quoted text clipped - 91 lines] > > John Sure, I use a fancy editor too, but it won't tell you where the execution came from to get there. docxx does. I think a lot of these differences of opinion come from different people's strategies for managing complexity. I like to do it hierarchically, using well-defined interfaces between levels, and keeping each level simple. Classes and templates are a huge help to me there. I don't use the C++ library very much. Most of my big programs are either instrument code or simulators of one kind or another--e.g. a big 3D electromagnetic simulator, an optimizing filter design program (back in the day) and a bunch of physics-based device simulations. Those kinds of things map pretty well onto classes, and some care in choosing the class hierarchy will generally yield a good program that runs fast and doesn't have weird bugs. I don't use exceptions, because for what I do, the best response to most kinds of errors is to print an informative error message and then abort. If I were writing web apps or vehicle control systems, I'd certainly do it differently. C++ was originally a C front end, designed to be like Simula 68, which is more or less how I use it. Cheers Phil Hobbs SignatureDr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net >>>>>>>>> You can't argue that C (and its culture) generally results in good or >>>>>>>>> secure executables, because it so obviously doesn't. [quoted text clipped - 118 lines] > >Phil Hobbs Well, I design electronics, and this is sci.electronics.design. I certainly wouldn't write a web browser in assembly or in BASIC, but then I wouldn't write a web browser at all. At some level of complexity, bugs are unavoidable. One approach to preventing bugs is to not design stuff that complex. Embedded systems have nowhere to print informative error messages to, no option to abort. Simplicity, visibility, and control of *all* the code is the safest way to do mission-critical stuff. My old XP machine is getting pretty stable, though. I don't have to do a forced reboot more than a couple of times a week. John >It isn't GOTO that's horrible, it's named labels. Every time I come >across a named label in code, I have to go figure out every single place [quoted text clipped - 8 lines] >which would silently put a jump anywhere you liked--not very different >from a named label! It could be worse. The FORTRAN "Assigned GOTO" was distinctly worse than a C "goto". The worst such in a traditional language, I think, was the use of the ALTER verb in COBOL, which could modify (at runtime!) the intended target of a single-sentence GOTO paragraph. As a result, you couldn't trust any such GOTO in COBOL to do what the source code said it did - you had to check the rest of the program to see if it was ever ALTERed. >>brrr<<... it gives me chills and a queasy stomach just thinking about it. The worst I've run into recently, is the control language for a radio-repeater controller I've helped set up. The language has a whole bunch of primitive op-codes (which take a variable number of parameters) stored in "macros" (think "subroutines"). Macros can call one another (up to a limited depth), and many are called automatically by the controller under certain conditions (time, carrier received on a radio channel, etc.). No, this control language doesn't have GOTO. Nor, sadly, does it have anything resembling IF/THEN/ELSE. The *only* method it provides to alter the form of control, is for one macro to change the code in another macro (deleting it entirely, inserting or deleting specific opcodes in its list, or copying its contents from a third macro). Yup.. the only way to do *any* conditional coding in this language, is to use self-modifying code. It's like the ALTER verb on meth. It's definitely a waltzing bear. SignatureDave Platt <dplatt@radagast.org> AE6EO Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior I do _not_ wish to receive unsolicited commercial email, and I will boycott any company which has the gall to send me such ads! >> It isn't GOTO that's horrible, it's named labels. Every time I come >> across a named label in code, I have to go figure out every single place [quoted text clipped - 12 lines] > > The FORTRAN "Assigned GOTO" was distinctly worse than a C "goto". True. Every line number was effectively a label. Blech. > The worst such in a traditional language, I think, was the use of the > ALTER verb in COBOL, which could modify (at runtime!) the intended [quoted text clipped - 5 lines] >>> brrr<<... it gives me chills and a queasy stomach just thinking > about it. I've never used COBOL...but anything that subverts compile-time checks like that is evil. Catching stuff at compile time is the next best thing to not coding in bugs at all. > The worst I've run into recently, is the control language for a > radio-repeater controller I've helped set up. The language has a [quoted text clipped - 14 lines] > > It's definitely a waltzing bear. Wow. And why were you using this abomination? You got it free from your brother-in-law or something? Cheers Phil Hobbs >>>> brrr<<... it gives me chills and a queasy stomach just thinking >> about it. > >I've never used COBOL...but anything that subverts compile-time checks >like that is evil. Catching stuff at compile time is the next best >thing to not coding in bugs at all. Agreed. That feature was years (maybe decades?) before "GOTO considered harmful". >> Yup.. the only way to do *any* conditional coding in this language, is >> to use self-modifying code. It's like the ALTER verb on meth. [quoted text clipped - 3 lines] >Wow. And why were you using this abomination? You got it free from >your brother-in-law or something? Naah. I joined the repeater project after the decision to buy/use it was already made. The other guys on the team recruited me because (I strongly suspect) they realized that they were in rather over their heads. It's actually a very flexible and powerful multi-radio- capable controller... it's just *weird* (and a good object lesson as to why hardware engineers ought not to be the sole designers of projects that have a software component :-) I took it as a challenge. It was... but some careful coding and design discipline (and a custom compiler for its language that I scribed up in Perl) actually made it tolerable to program. The most important rule I figure out was "Don't try to optimize changes between operating modes. On any change in mode, reset *everything* to a single known starting state, and then apply one set of mods per mode to handle the variable aspects of the configuration." The users and control operators are happy with the system... that's all that really matters. I've gotten over the trauma, mostly, and don't wake up screaming more than once a month or so :-) SignatureDave Platt <dplatt@radagast.org> AE6EO Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior I do _not_ wish to receive unsolicited commercial email, and I will boycott any company which has the gall to send me such ads! >>>>> You can't argue that C (and its culture) generally results in good or >>>>> secure executables, because it so obviously doesn't. [quoted text clipped - 91 lines] > >Phil Hobbs Over 20 years ago a coworker of mine wrote a comefrom static analysis program to analyze his programs. He was rather shocked to see how much he had been abusing goto. And this was with a version of basic that had subroutines with parameters. > Over 20 years ago a coworker of mine wrote a comefrom static analysis > program to analyze his programs. He was rather shocked to see how > much he had been abusing goto. And this was with a version of basic > that had subroutines with parameters. I regularly use QuickBasic, which is quite capable of OO style subroutines (although calling QB OO, with its narrow "object" functionality, is a stretch), but which of course allows GOTOs. I find there are a number of places were GOTO is simply too useful to pass up. Here's a recent example: . . . FOR i = 1 TO LEN(In$) k = ASC(MID$(In$, i, 1)) l = Ascii2Seven(k) m$ = Num2Hex$(l AND 255) GOSUB PrintByte IF l > 255 THEN m$ = Num2Hex$((l AND &HFF00&) \ &H100) GOSUB PrintByte END IF NEXT . . . So it chews through In$, one byte at a time, doing whatever Ascii2Seven does (ooh, a user-defined function!). The rub is, for expandability reasons, Ascii2Seven may return a one-digit number (i.e., values 0 to 255) or a two-digit number (I believe the sign bit is set in this case). Printing the other byte requires a seperate call to PrintByte, for state reasons. SUB would be inelegant here because a number of variables would either have to be passed as operands or SHAREd globally, neither of which really make any sense. Printing one or both bytes at the same time (which could, in principle, be done with one call to, say, PrintSeven instead of PrintByte) just moves things around and meets the same problem. Other times, I've used GOTO or GOSUB to call a routine which has a lot of common variables (i.e., its scope includes main) or to branch to a single routine from multiple exit points out of a SELECT CASE or somesuch. Most of the time, I do write SUBs and FUNCTIONs, great for compact bits of code that might be useful in other places, or which are fairly specialized but have little effect on other parts of the program (for instance, a game engine, menu, physics, AI and other systems can all be sectioned into seperate subroutines, for the most part). On average I would suppose GOTO and GOSUB count as "rare" (<1% of all subroutine calls?) in my usage. What really matters, and what everyone time and time again keeps missing is, GOTO and SUB must both be used responsibly. Since there is no check on programmers being responsible, there is no check on programmers producing managable code, regardless of language structure. That this argument even exists is proof that programmers are egotistical douchebags who don't want to accept responsibility when they write shitty code. And yes, I'm calling out *everyone* on this argument: you, Dijkstra, everyone who's tried arguing this non sequitur. Dijkstra was smart but that doesn't preclude him or anyone else from being a dbag. ;-) Tim >> Over 20 years ago a coworker of mine wrote a comefrom static analysis >> program to analyze his programs. He was rather shocked to see how [quoted text clipped - 55 lines] >programmers producing managable code, regardless of language >structure. Yes. I write thousands-of-lines programs, in various languages, that are almost entirely flat, with every variable global and static, a big GOTO state machine, with most subroutines done as JSR/RTS or GOSUB/RETURN. If you do this carefully, you get fast, tight, clean code, no possibility of memory or stack problems, and *zero* bugs. If you do any programming carelessly, you get an ugly mess. Anybody who ships embedded systems that have bugs is a bad programmer, in any language. I'm on the mailing list for one analytical instrument software package from a big company that uses all the latest languages and version/bug control tricks. They average about ten new reported bugs per week. John > I'm on the mailing list for one analytical instrument > software package from a big company that uses all the latest languages > and version/bug control tricks. They average about ten new reported > bugs per week. Yeah, but it might be 25 per week if they weren't using those languages/tricks/etc. :-) In your case, John, I suspect that much of the benefit you derive in your programming practices comes from the fact that you seem to normally be doing the entire piece of software yourself, or with just a couple other people. Choice of language can help or hinder the likelihood of creating and then the ease of discovering bugs, but certainly the programmer's own attitude towards software development has a much, much larger influence. It's unfortunate that almost all companies now accept that there will be *numerous* bugs in version 1.0 of whatever it is they ship. What's even worse is that many companies know that publishing their bug list would potentially put them at a competitive disadvantage, so rather than just fixing their stupid bugs in the first place, they don't publish a bug list at all, causing various end-users to have to discover and work around the same bug over and over again. If that's not an incredibly customer-unfriendly attitude, I don't know what it! >> I'm on the mailing list for one analytical instrument >> software package from a big company that uses all the latest languages [quoted text clipped - 17 lines] >to have to discover and work around the same bug over and over again. If >that's not an incredibly customer-unfriendly attitude, I don't know what it! The semiconductor people tend to do the same thing, let multiple users find the same bugs over and over. I know of datasheets that are years old that don't hint about very serious problems. BEWARE THS3062. It's fatally flawed and the latest datasheet is from 2002. How many people have been burned by this one? (I was, literally.) John >> Over 20 years ago a coworker of mine wrote a comefrom static analysis >> program to analyze his programs. He was rather shocked to see how [quoted text clipped - 64 lines] > >Tim There is a fundamental difference between goto and gosub. It is an important one, subroutine invocation saves time and code space without the biggest problems of goto. >>> Over 20 years ago a coworker of mine wrote a comefrom static analysis >>> program to analyze his programs. He was rather shocked to see how [quoted text clipped - 68 lines] >important one, subroutine invocation saves time and code space without >the biggest problems of goto. But GOTO is faster than GOSUB. You can make a very nice state machine with an ON..GOTO (or equivalent CASE...GOTO) structure that dispatches to a number of snippets, each of which does its thing ends with a GOTO back to the top of the state dispatcher. Works like a trained pig. John >>There is a fundamental difference between goto and gosub. It is an >>important one, subroutine invocation saves time and code space without >>the biggest problems of goto. >But GOTO is faster than GOSUB. >You can make a very nice state machine with an ON..GOTO (or equivalent >CASE...GOTO) structure that dispatches to a number of snippets, each >of which does its thing ends with a GOTO back to the top of the state >dispatcher. Works like a trained pig. Unless you're running a processor running in the single digit megahertz, programmer development time, code reliability and maintainability are far more important than raw speed. It hardly matters if a subroutine finishes in 0.0015ms instead of 0.0012 ms when the process being monitored takes 5ms. BASIC is a shitty language because no two implementations are compatible. Everything with named variables, constructs, code blocks, parameter passing, if/then/else, case statements, etc. required proprietary extensions. >>>There is a fundamental difference between goto and gosub. It is an >>>important one, subroutine invocation saves time and code space without [quoted text clipped - 15 lines] >Everything with named variables, constructs, code blocks, parameter passing, >if/then/else, case statements, etc. required proprietary extensions. Do I have to give all the money back? John >>>>There is a fundamental difference between goto and gosub. It is an >>>>important one, subroutine invocation saves time and code space without [quoted text clipped - 15 lines] >>Everything with named variables, constructs, code blocks, parameter passing, >>if/then/else, case statements, etc. required proprietary extensions. >Do I have to give all the money back? Nah. Just learn a completely new proprietary langauge every time you try BASIC with a different vendor. >>>>>There is a fundamental difference between goto and gosub. It is an >>>>>important one, subroutine invocation saves time and code space without [quoted text clipped - 20 lines] >Nah. Just learn a completely new proprietary langauge every time you try >BASIC with a different vendor. I use PowerBasic for Windows apps. Why would I change vendors? If you program C++/.NET, or C#, your programs won't be very portable. If you're careful and a little lucky, you can write Java programs that almost work the same under Windows and Linux. I'm not a programmer, but I do need to program engineering problems. PowerBasic (the console compiler, not the real Windows thing) is fast and works well. These programs don't need to be portable... all I need them to do is to keep running under future revs of Windows. All my old 16-bit PowerBasic/DOS programs seem to work fine under XP, even the graphics. Only serial i/o is flakey, so we migrate them to PBCC, tghe 32-bit version, which does serial and TCP/IP just fine. "Real" windows programming wastes too much effort on the user interface. John >"Real" windows programming wastes too much effort on the user >interface. Exactly! And, a lot of small console programs, as you call them, or command line utilities as I call them in Linux, can in Linux be chained together to do anything you want. You would love Unix / Linux without X11. GUI interfaces are a bit like supermarkets, you can be illiterate and point and grab anything, *IF* you know where it is. Command line is like handing the shopkeeper the shopping list. But it does require people to know how to read and write. For people that do not, for them is 'Object Oriented Behaviour' (OOB) a necessity :-) So now you see the link where OO comes from, from illiteracy. > And, a lot of small console programs, as you call them, or command line > utilities > as I call them in Linux, can in Linux be chained together to do anything you > want. True, although one problem with *NIX command line utilities is that there's no standardization in how control parameters are passed to them. Well, OK, a lot of the newer distributions have tried to "harmonize" this at least for the "core" utilities, but it's still a major PITA at times. Microsoft's PowerShell got this right... instead of using standard text input and output, they just pass objects around (in a chain, if desired), and all the "options" parsing is just calling methods on a well-defined object. > Command line is like handing the shopkeeper the shopping list. > But it does require people to know how to read and write. It's like handing the shopkeeper the shopping list, but only after he's handed you his inventory list and reminded you that your shopping list has to precisely match the items on his inventory list or he'll just barf and typically not do anything at all for you. I personally spend much of my time at a command line, but GUIs definitely have their place. ---Joel >> And, a lot of small console programs, as you call them, or command line >> utilities [quoted text clipped - 5 lines] >of the newer distributions have tried to "harmonize" this at least for the >"core" utilities, but it's still a major PITA at times. Usually I write command line processing by using getopt(), some apps get so big you run out of letters in the alphabet for the command line flags. Then you would have to use the long options. >Microsoft's PowerShell got this right... instead of using standard text input >and output, they just pass objects around (in a chain, if desired), and all [quoted text clipped - 10 lines] >I personally spend much of my time at a command line, but GUIs definitely have >their place. Now think when you have to repeat a command,. say a call to ffmpeg, its easy on the command line nice -n 19 mcamip -x -f 2 -t -a 10.0.0.151 -p 80 -u USERNAME -w PASSWORD -y 2>mcamip-log | \ nice -n 19 ffmpeg -f yuv4mpegpipe -i - -f avi -vcodec h264 -r 2 -b 10 -g 300 -bf 2 -y camera4.avi \ 1>/dev/zero 2>/dev/zero & Just cursor up, and ENTER to repeat. Now if you have to tick boxes in some GUI... and enter filenames... again after exiting that program... And when doing this sort of thing that happens hundreds of times a day. I have used that sort of GUI programs in MS windows, many people write that sort of stuff. It will drive you mad... OK, I was teasing the OOB guys a bit :-) But you know shopping malls,supermarkets, you walk in there with your basket, and fill it up with whatever you see on the shelves that you at that moment *think* you want, or, if the package is done nicely, attracts you to buy it, even if you did not need it, and it was not on your list. The shopkeeper knows this, it is called 'impulse buying', it makes him sell more. It loads you basket with *BLOAT*, same as with GUI. If I want the net status I can just type 'netstat' in my xterm (or console if you are X-less), no need to go through 12 pull down menus or traverse trees in a window manager / 'explorer', much faster to just type that word, if you know what you want. A good shopkeeper *will* find your stuff, he will remember you from your previous shopping visits, and even get specially requested stuff. I use the zsh shell, if I had a hundred commands typed in the recent past, all I have to do is type the first few characters of the one I typed ages ago, say ./xi and then use cursor up, zsh then proposes: grml: ~ # xine rio-grande_part1.ts grml: ~ # xine Astra2_C5.00h24.26-5-2009-126m.ts zsh is a more powerful shell then bash, bash has some nice features too. I have a GUI (run X), but it is only to start very frequently used apps, and even those are often started from a script with the correct parameters when you click on the icon. But I am not denying the use of GUI, it is nice in this newsreader NewsFleX that I wrote, but I do not change the layout of the buttons ... every so many month. > Now if you have to tick boxes in some GUI... and enter filenames... again > after exiting that program... All the GUI-based programs I write remember all the options that were ticked/file names entered/etc... those that don't are poor. They're also smart enough to "notice" if, e.g., a file they've been pointed at has changed on disk and needs to be reloaded. > The shopkeeper knows this, it is called 'impulse buying', it makes > him sell more. > It loads you basket with *BLOAT*, same as with GUI. Yeah, there is something to this... your standard pointy-haired boss is going to be much more impressed with the way the GUI looks than the true performance of a software package. > I use the zsh shell I keep meaning to try that out... years ago I used csh, but when I got back into Linux a few years ago I just stuck with regular old bash. ---Joel >> Now if you have to tick boxes in some GUI... and enter filenames... again >> after exiting that program... >All the GUI-based programs I write remember all the options that were >ticked/file names entered/etc... those that don't are poor. >They're also smart enough to "notice" if, e.g., a file they've been pointed at >has changed on disk and needs to be reloaded. >> The shopkeeper knows this, it is called 'impulse buying', it makes >> him sell more. >> It loads you basket with *BLOAT*, same as with GUI. >Yeah, there is something to this... your standard pointy-haired boss is going >to be much more impressed with the way the GUI looks than the true performance >of a software package. >> I use the zsh shell >I keep meaning to try that out... years ago I used csh, but when I got back >into Linux a few years ago I just stuck with regular old bash. For shell scripting, I use python. All the power of a high level language but interpreted (albeit heavily optimized with saved compilation) and with modules to do just about anything quick and easy. >> And, a lot of small console programs, as you call them, or command line >> utilities [quoted text clipped - 22 lines] > >---Joel I do a lot of engineering programs with sorta-interactive console-mode interfaces. Imagine a screen with rows of single-letter commands like T Temperature 42.3 C A Radiating area 45 sq cm etc, and some computed result at the bottom, like radiated heat in watts. To change the temperature, type T 55 and the computed result changes. That's a lot nicer to drive than a command-line thing, and a lot easier to program than a full Windows app. This isn't fancy, but it works. Some other things, like file crunchers, work best as command-line things, so long as they provide Help. It's hard to embedd gui apps into batch files. John >>I personally spend much of my time at a command line, but GUIs definitely have >>their place. [quoted text clipped - 21 lines] > >John I have this, you can click on an icon and it will pop up: ftp://panteltje.com/pub/xhcs.gif It is the thermostat for the room temperature control, it also shows what I have to pay the electricity guys. You can set the thermostat with it. But the real program is called 'hcs' (from Home Control System) and runs in the background), has been running for >10 years now... You can control it by changing the setpoint in a file too (that is what xhcs does). There is a directory /root/.hcs that holds a lot of info on that control system. You can access that dir over the internet via ssh, or use xhcs with ssh -Y.... So I have both worlds. But the real program hcs is of course a command line program. So there is no need to embed a GUI program in a batchfile, the GUI can run separately. But I do have some GUI programs that can also be run from a batch file without GUI, just with command line flags, xdipo is such a program, this is the GUI mode: ftp://panteltje.com/pub/xdipo2.jpg Or, as used here, from the show script, the command line mode: RECORD_DIR=/mnt/hdd4/video TUNER_POSITIONER=/usr/local/bin/xdipo FILTER=/usr/local/bin/jpinfo TXT_DECODER=/usr/local/bin/jpvtx Elsewhere in the script the player is defined: if ... player="mplayer $aspect -ao alsa:device=hw=1,0 -fs -cache 8192 -vop pp=0x20000 -" else .. player="nice -n -19 xine -D -gf stdin:/" # the actual command: $TUNER_POSITIONER -c 1 -g "$angle" -f $freq -p $pol -s $sym -a "8192" -o | \ $FILTER -p $prog | \ $TXT_DECODER $tpid | \ $player So, all is possible... nice trick hey? > I do a lot of engineering programs with sorta-interactive console-mode > interfaces. Imagine a screen with rows of single-letter commands like [quoted text clipped - 5 lines] > etc, and some computed result at the bottom, like radiated heat in > watts. I use one of these quite often (besides the QuickBasic IDE ;-) ), COIL.EXE by Brian Beezley. Others here may've seen it. It's a quite accurate solenoid calculator. Tim >> And, a lot of small console programs, as you call them, or command line >> utilities [quoted text clipped - 3 lines] > True, although one problem with *NIX command line utilities is that there's no > standardization in how control parameters are passed to them. ??? there is int argc, char *argv[] which is considerably more standardisation than the windows XP or vista command-line has. > Microsoft's PowerShell got this right... instead of using standard text input > and output, they just pass objects around (in a chain, if desired), and all > the "options" parsing is just calling methods on a well-defined object. it seems like an interesting concept. >> True, although one problem with *NIX command line utilities is that >> there's no [quoted text clipped - 4 lines] > which is considerably more standardisation than the windows XP or vista > command-line has. In MS-DOS, it's even easier: you get one string up to 127 characters long. it's up to you to play with it, which is usually tokenization first (which is just what the C compiler does when it cooks up your args). How it's programmed doesn't matter. He's probably referring to switches and order (switches before arguments?). Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms >>> True, although one problem with *NIX command line utilities is that >>> there's no [quoted text clipped - 8 lines] > it's up to you to play with it, which is usually tokenization first (which > is just what the C compiler does when it cooks up your args). This can be a nuisance, as the program's documentation tends to document its behaviour in terms of distinct arguments, without documenting how the string is parsed into arguments. This can be an issue if one of the arguments is an arbitrary string which may contain spaces, quotes etc. Nowadays, you can usually rely upon it using the MSVCRT parser, but you occasionally run into exceptions. It also doesn't help that _spawnvp() et al concatenate their arguments without quoting, so the program doesn't necessarily get the exact same list of arguments which the caller provided. >> In MS-DOS, it's even easier: you get one string up to 127 characters >> long. [quoted text clipped - 6 lines] > string is parsed into arguments. This can be an issue if one of the > arguments is an arbitrary string which may contain spaces, quotes etc. In those cases, either the string would have to go at the end (how else can you tell it's an arbitrary string?), or it would have to be encapsulated somehow (such as quotes). Last time I wrote a command line parser, I happened to be writing in assembly. There, it grabbed a byte, checked if it was a token, delimiter or switch (i.e., "/"). If it was a switch, it scanned for the WORD "?/" or etc. (being that endianness actually reads "/?" as "?/". Odd at a glance, and not useful for more than two character switches, but interesting in its own way.) After each switch was found, a flag was set indicating it had been found, and therefore should not be checked for again. In that particular program, switches could go anywhere in the command line, before or after the argument. The first token found that wasn't a switch was copied as the argument (path, in this case); any subsequent arguments were ignored. Meanwhile, in QBasic, I've done plenty of command lines, but since COMMAND$ is so temping, and because QB sadly doesn't provide any tokenizing functions, I usually just go lame and do something like OPEN COMMAND$ FOR INPUT AS #1, no switches at all. OTOH, in C, you get all parameters tokenized already, so it's quite easy to look at them in order. That's kind of nice. (Hmm, if QB had the foresight, it could be COMMAND$(n) instead!) Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms >>> In MS-DOS, it's even easier: you get one string up to 127 characters >>> long. [quoted text clipped - 31 lines] > >Tim PowerBasic (the console compiler version) has a couple of nice built-in PARSE commands. John >>>> In MS-DOS, it's even easier: you get one string up to 127 characters >>>> long. [quoted text clipped - 31 lines] >> >>Tim >PowerBasic (the console compiler version) has a couple of nice >built-in PARSE commands. Sheesh. It's a phone call for you. The 70's want their interpreted language technology back. >>PowerBasic (the console compiler version) has a couple of nice >>built-in PARSE commands. > > Sheesh. It's a phone call for you. The 70's want their interpreted > language technology back. Hah. Interpreters rule. Unbeaten for debugging, especially for the range of constructs you can reconstruct on-the-fly. Actually, is PowerBasic interpreted, or is it only compiled? FreeBASIC is compile-only. Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms >>>PowerBasic (the console compiler version) has a couple of nice >>>built-in PARSE commands. [quoted text clipped - 7 lines] >Actually, is PowerBasic interpreted, or is it only compiled? FreeBASIC is >compile-only. PB is an excellent compiler. It's better than a lot of C compilers for runtime speed. Debugging is at least as good as any interpretive Basic I know of. John >>>PowerBasic (the console compiler version) has a couple of nice >>>built-in PARSE commands. >> >> Sheesh. It's a phone call for you. The 70's want their interpreted >> language technology back. >Hah. Interpreters rule. Unbeaten for debugging, especially for the range >of constructs you can reconstruct on-the-fly. Yes, but there's been some progress made in the last forty years. BASIC is a piece of sh.t and utterly unuseable unless stacked to the gills with proprietary extensions. Use any of these proprietary extensions, and the code is no longer portable to any other compiler. I use python when I want to use an interpreted language. >Actually, is PowerBasic interpreted, or is it only compiled? FreeBASIC is >compile-only. >>>>PowerBasic (the console compiler version) has a couple of nice >>>>built-in PARSE commands. [quoted text clipped - 8 lines] >BASIC is a piece of sh.t and utterly unuseable unless stacked to the >gills with proprietary extensions. And what's wrong with "proprietary extensions" if they get work done? Use any of these proprietary >extensions, and the code is no longer portable to any other compiler. And why would it need to be? PowerBasic makes it easy for non-programmers to get engineering calculations done quickly and easily. What's wrong with that? John >>>>>PowerBasic (the console compiler version) has a couple of nice >>>>>built-in PARSE commands. [quoted text clipped - 8 lines] >>BASIC is a piece of sh.t and utterly unuseable unless stacked to the >>gills with proprietary extensions. >And what's wrong with "proprietary extensions" if they get work done? That's fine if you never reuse code. Just wonderful if you write everything from scratch and never use third party code libraries. I've got better things to do than write a doubly linked list package for the hundreth time. I'd rather have a language where I can use libraries to do the work use use code examples from others. >>>>>>PowerBasic (the console compiler version) has a couple of nice >>>>>>built-in PARSE commands. [quoted text clipped - 13 lines] >That's fine if you never reuse code. Just wonderful if you write >everything from scratch and never use third party code libraries. .NET is hardly a universal, portable platform. If all you write is text-mode ANSI C, sure, it's fairly portable... as long as you keep your ints and longs and stuff under control. >I've got better things to do than write a doubly linked list package for >the hundreth time. I'd rather have a language where I can use >libraries to do the work use use code examples from others. As an engineer, I'm more interested in number crunching, simulation, graphics, generating embedded code images, stuff like that. There are a few nice collections of Basic subroutines around - curve fitting, FFTs, stuff like that - so I don't always write everything from scratch. And I do often reuse code. I haven't used a linked list in decades. PCs are so fast these days you can waste enormous numbers of cycles on brute-force methods, like linear searching, to save programming time. PowerBasic has a blinding fast SORT command, too. The built-in TCP/IP, graphics, string functions, all that stuff, are easy to use... and have excellent HELP a keystroke away. The help you get with a lot of C libraries is "read the source." Here's a simulation of a vector character generator used in a retrofit for the C130 heads-up display, coded in PowerBasic. The actual product is a VME module that does most of the real work in an FPGA. ftp://66.117.156.8/GR8.jpg The imperfections simulate the effects of finite-bandwidth deflection amplifiers. Works great. John John Larkin a écrit : >>>>>>> PowerBasic (the console compiler version) has a couple of nice >>>>>>> built-in PARSE commands. [quoted text clipped - 26 lines] > you can waste enormous numbers of cycles on brute-force methods, like > linear searching, to save programming time. Well done! You've just got your ticket for a hiring interview at M$ ;-) SignatureThanks, Fred. >John Larkin a écrit : >> [quoted text clipped - 31 lines] >Well done! >You've just got your ticket for a hiring interview at M$ ;-) But my linear searches are 50x as fast as whatever nonsense they are doing. John >> John Larkin a écrit : >>> [quoted text clipped - 30 lines] >> Well done! >> You've just got your ticket for a hiring interview at M$ ;-) Yes. I expect someone just like Larkin is responsible for the glacially slow graphics and charting in XL2007 (and also for degrading the chart trend line polynomial fit to give the same wrong answer as LINEST). > But my linear searches are 50x as fast as whatever nonsense they are > doing. Even if that were true then a decent Shell sort worst case O(N^1.5) algorithm would beat your poxy O(N^2) algorithm when N > 2500. In a real example with random unsorted data as input Shell's sort would be more like O(N^1.3). And an O(Nlog2N) sort would beat it hollow at N > ~500 You really are clueless about algorithms and their relative speeds. Linear search or sort by straight insertion is typically only faster for N<50. Hardware engineers tend to code the even slower Bubble sort. It may be fast enough for your small datasets but it doesn't scale well. Regards, Martin Brown >>> John Larkin a écrit : >>>> [quoted text clipped - 34 lines] >slow graphics and charting in XL2007 (and also for degrading the chart >trend line polynomial fit to give the same wrong answer as LINEST). Not only did I not write Excel, I never use it. Spreadsheets are idiotic toys. >> But my linear searches are 50x as fast as whatever nonsense they are >> doing. [quoted text clipped - 6 lines] >And an O(Nlog2N) sort would beat it hollow at N > ~500 >You really are clueless about algorithms and their relative speeds. How about this: http://www.highlandtechnology.com/DSS/V346DS.html It does all the internals - lookup, DDS, interpolation, modulations, summing, user-programmable microengines - at 128 MHz on 8 channels, the equivalent of roughly 40G saturating math operations per second, on a cheap Spartan FPGA. Well, we did epoxy a heatsink on top. Of course, engineers can parallelize and pipeline, but programmers can't. >Linear search or sort by straight insertion is typically only faster for >N<50. Hardware engineers tend to code the even slower Bubble sort. It >may be fast enough for your small datasets but it doesn't scale well. > >Regards, >Martin Brown Why are you confusing the simple terms "linear search" and "sort"? How very strange. And what difference would it make, anyhow, whether an algorithm scales or not if it doesn't need to scale? John >>>> John Larkin a écrit : >>>>> I haven't used a linked list in decades. PCs are so fast these days >>>>> you can waste enormous numbers of cycles on brute-force methods, like >>>>> linear searching, to save programming time. >>>>> >>>> Well done! >>>> You've just got your ticket for a hiring interview at M$ ;-) >> Yes. I expect someone just like Larkin is responsible for the glacially >> slow graphics and charting in XL2007 (and also for degrading the chart >> trend line polynomial fit to give the same wrong answer as LINEST). > > Not only did I not write Excel, I never use it. Spreadsheets are > idiotic toys. I think you have missed the point of spreadsheets and other scratchpad tools. They allow accountants and scientists to get results from modest amounts of data without them having to learn how to program in detail. They are also excellent for creating test data using a method that has completely different characteristic modes of failure to classical programming languages. >>> But my linear searches are 50x as fast as whatever nonsense they are >>> doing. >> Even if that were true then a decent Shell sort worst case O(N^1.5) >> algorithm would beat your poxy O(N^2) algorithm when N > 2500. In a real [quoted text clipped - 13 lines] > on a cheap Spartan FPGA. Well, we did epoxy a heatsink on top. Of > course, engineers can parallelize and pipeline, but programmers can't. Your hardware is cute. But some of the statements you make about software engineering are risible. >> Linear search or sort by straight insertion is typically only faster for >> N<50. Hardware engineers tend to code the even slower Bubble sort. It [quoted text clipped - 5 lines] > Why are you confusing the simple terms "linear search" and "sort"? How > very strange. Most of the fast binary search methods rely on an ordered array of target data. You have to pay for that sort at some stage. But if you want a pure O(1) solution to replace a linear search then hash tables can be extremely effective. > And what difference would it make, anyhow, whether an algorithm scales > or not if it doesn't need to scale? If it doesn't need to scale then it makes no difference at all. But you need to be *very* sure of that. Programs that originally run inefficiently on small datasets tend to get used on bigger ones until they grind to a standstill. Regards, Martin Brown >>>>> John Larkin a écrit : > [quoted text clipped - 19 lines] >completely different characteristic modes of failure to classical >programming languages. Google "spreadsheet errors." It's hard to imagine a more dangerous way to program important stuff. >>>> But my linear searches are 50x as fast as whatever nonsense they are >>>> doing. [quoted text clipped - 19 lines] >Your hardware is cute. But some of the statements you make about >software engineering are risible. My hardware and my software work. Both are reliable, documented, reproducible, formerly controlled, bug-free, and profitable. Do you find that amusing? >>> Linear search or sort by straight insertion is typically only faster for >>> N<50. Hardware engineers tend to code the even slower Bubble sort. It [quoted text clipped - 11 lines] >But if you want a pure O(1) solution to replace a linear search then >hash tables can be extremely effective. You can only reasonably hash on one field, and I know of no way to, say, search for embedded substrings using hashing. A lot of old tricks made up for limited memory or slow CPUs. Nowadays, with GHz processors and Gbyte rams and 7200 RPM disks, brute force is better than that stuff. It's not elegant, but it works. Some people love the tricks for their own sake. John >>Your hardware is cute. But some of the statements you make about >>software engineering are risible. > >My hardware and my software work. Both are reliable, documented, >reproducible, formerly controlled, bug-free, and profitable. ^^^^^^^ formally Good one, huh? John > >>Your hardware is cute. But some of the statements you make about > >>software engineering are risible. [quoted text clipped - 5 lines] > > Good one, huh? See what happens when you send too much time arguing with dimbulb? SignatureYou can't have a sense of humor, if you have no sense! > On Wed, 10 Jun 2009 06:51:32 -0700, John Larkin >> Martin Brown: [quoted text clipped - 7 lines] > > Good one, huh? ;-) Cheers! Rich >>>>> John Larkin a écrit : > [quoted text clipped - 20 lines] > completely different characteristic modes of failure to classical > programming languages. Such as being impossible to debug. I'm with John on spreadsheets (though not on BASIC)--they're famous for generating reasonable-looking wrong answers, and (unlike programming languages) their testing facilities are zilch. Sort of like the old Royal-McBee drum memory computers, where every instruction contained the address of the next instruction--every line had a GOTO. Brr. Give me Mathcad or Octave for numbers, and little scripts for other sorts of data. Spreadsheets--blech. Cheers, Phil Hobbs SignatureDr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net >>>>>> John Larkin a écrit : >> [quoted text clipped - 22 lines] > >Such as being impossible to debug. Spreadsheets are debugable, at least as much as any interpreted language. >I'm with John on spreadsheets (though not on BASIC)--they're famous for >generating reasonable-looking wrong answers, and (unlike programming >languages) their testing facilities are zilch. Sort of like the old >Royal-McBee drum memory computers, where every instruction contained the >address of the next instruction--every line had a GOTO. I'm certainly not. I use them all the time to debug everything from BOMs to database errors. They also make great tables and simple charts-n-graphs. >Brr. Give me Mathcad or Octave for numbers, and little scripts for >other sorts of data. Spreadsheets--blech. They're perfectly acceptable tools, with the understanding that they are just tools. >>>>>>> John Larkin a écrit : >>>>>>>> I haven't used a linked list in decades. PCs are so fast these days [quoted text clipped - 20 lines] > Spreadsheets are debugable, at least as much as any interpreted > language. In a normal interpreted language, each statement follows the one ahead of it, unless there's an explicit control structure. (Or a named label, but we're assuming reasonable practice here--use GOTOs to escape from a deeply nested loop to a nearby point, say, but not otherwise.) Any spreadsheet cell, on the other hand, can depend on any other spreadsheet cell, without warning and without any way of finding that out in general other than an exhaustive examination of each cell. _Your_ spreadsheets, I'm quite sure, are sensibly structured and reasonably comprehensible in outline. But that is far from the general case, even for spreadsheets that have real money depending on them. A nontrivial spreadsheet that has had more than a couple of people working on it is a disaster to debug--far worse than spaghetti code. >> I'm with John on spreadsheets (though not on BASIC)--they're famous for >> generating reasonable-looking wrong answers, and (unlike programming [quoted text clipped - 5 lines] > BOMs to database errors. They also make great tables and simple > charts-n-graphs. Yep, tables and graphs are about it. >> Brr. Give me Mathcad or Octave for numbers, and little scripts for >> other sorts of data. Spreadsheets--blech. > > They're perfectly acceptable tools, with the understanding that they > are just tools. Well, they're widely accepted, all right, but they still stink. Cheers Phil Hobbs SignatureDr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net "Phil Hobbs" <pcdhSpamMeSenseless@electrooptical.net> wrote in message > A nontrivial spreadsheet that has had more than a couple of people working > on it is a disaster to debug--far worse than spaghetti code. Gee, Phil, ever tried LabView? It's definitely more of a "write only" language, particular if you weren't the original author. > "Phil Hobbs" <pcdhSpamMeSenseless@electrooptical.net> wrote in message >> A nontrivial spreadsheet that has had more than a couple of people working [quoted text clipped - 4 lines] > It's definitely more of a "write only" language, particular if you weren't the > original author. I've tried LabView, all right. I wasted two weeks on it last fall--and promptly went back to the C programs I'd been using before. I have a 16-channel RocketPort RS-232 board, which is the greatest. Cheers Phil Hobbs SignatureDr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net >> "Phil Hobbs" <pcdhSpamMeSenseless@electrooptical.net> wrote in message >>> A nontrivial spreadsheet that has had more than a couple of people [quoted text clipped - 7 lines] > I've tried LabView, all right. I wasted two weeks on it last fall--and > promptly went back to the C programs I'd been using before. Sorry, trying to do too many things at once. The main problem with LabView is that it hides a lot of ultra-important things about your measurement, e.g. when exactly does the sampling occur? I went round and round with National Instruments on that point, and the best they could tell me was that timing information was a device driver function, and there was no way in general of finding it out from the user interface. That's when I gave up. Cheers Phil Hobbs >>> "Phil Hobbs" <pcdhSpamMeSenseless@electrooptical.net> wrote in message >>>> A nontrivial spreadsheet that has had more than a couple of people [quoted text clipped - 16 lines] > >That's when I gave up. We made a couple of user demo things, with the LabView option that creates standalone runnable VIs. The result was umpteen megabytes of CD, full of DLLs and registry mucking and other horrors. Which usually didn't work. We have a guy in Long Island, the best programmer I know, who does wonderful little Java things for us now. He's always broke, hence always available for projects like this. John >"Phil Hobbs" <pcdhSpamMeSenseless@electrooptical.net> wrote in message >> A nontrivial spreadsheet that has had more than a couple of people working >> on it is a disaster to debug--far worse than spaghetti code. >Gee, Phil, ever tried LabView? >It's definitely more of a "write only" language, particular if you weren't the >original author. You want a real write-only language? Try FORTH. OVER + SWAP DO > You want a real write-only language? Try FORTH. > OVER + SWAP DO I have done plenty of user RPL programming of HP calculators. These days, with memory so abundant, I've switched from... 1/x SWAP 1/x + 1/x ...to... "X*Y/(X+Y)" Much easier (and a skosh more numerically accurate, although realistically if one isn't using 0.01% resistors, I doubt it matters here). ---Joel >> You want a real write-only language? Try FORTH. >> OVER + SWAP DO >I have done plenty of user RPL programming of HP calculators. >These days, with memory so abundant, I've switched from... >1/x >SWAP >1/x >+ >1/x >...to... >"X*Y/(X+Y)" >Much easier (and a skosh more numerically accurate, although realistically if >one isn't using 0.01% resistors, I doubt it matters here). Writing readable programs is probably more important than anything else. Unreadable programs are difficult to maintain and will quickly turn to sh.t upon subsequent modifications. I also never use constants like 25480. 24*60*60 is far more readable and less prone to error. It doesn't take a pico second more to execute as the calculation is done at compile time, not run time. Even with an interpreted language, it is only parsed once; if the language system isn't sh.t, the calculated value will be saved in the saved tokenized code. > >> You want a real write-only language? Try FORTH. > >> OVER + SWAP DO [quoted text clipped - 20 lines] > language system isn't sh.t, the calculated value will be saved in the > saved tokenized code. Funny. I would use the 25480, and put the 24*60*60 in a comment. Then again, I don't need to write high-performance code. Michael >> I also never use constants like 25480. 24*60*60 is far more readable >> and less prone to error. It doesn't take a pico second more to [quoted text clipped - 6 lines] > > Then again, I don't need to write high-performance code. I hope not! I define the constant, then use the label. That way, if it changes, you don't have to track down every instance to change the hard numbers. Cheers! Rich > >> I also never use constants like 25480. 24*60*60 is far more readable > >> and less prone to error. It doesn't take a pico second more to [quoted text clipped - 13 lines] > Cheers! > Rich Like in a #define? Funny thing is, 24x60x60 = 86,400, actually... Not likely that 60 seconds in a minute, or 60 minutes in an hour, would change... unless... the client moves from a 24-hour-workday to, say, an 8-hour work day? Michael > Like in a #define? "const int" is usually preferable since then the compiler will be able to perform type checking rather than just blindly inserting text into an expression. Although I did once meet a C compiler that pretty much ignored the "const" part of "const int" and therefore actually allocated memory (in RAM!) and stored the value, fetching it again every time it was needed. (I believe it met the C99/C++ standard of not allowing you to actually change the value, though.) Made for slower code and wasted RAM... which there wasn't a lot of (whereas there was plenty of ROM). (It's also a case where you run the risk of "casting out constness," as Scott Meyers says.) I was pretty surprised... When I'm using decent compilers I'll also use, e.g., 60*60*24 to make it more obvious where the "magic number" came from, knowing that the optimizer will figure out that the express is constant and not re-compute it every time. And I agree that using "const int foo=86400; // 60*60*24" is just asking for trouble in that you're likely to forget to keep both "in sync" if it every has to change. ---Joel > Although I did once meet a C compiler that pretty much ignored the "const" > part of "const int" and therefore actually allocated memory (in RAM!) and > stored the value, fetching it again every time it was needed. It's required to store it somewhere so that you can take its address. "const" variables are still lvalues, not expressions. >> Although I did once meet a C compiler that pretty much ignored the "const" >> part of "const int" and therefore actually allocated memory (in RAM!) and >> stored the value, fetching it again every time it was needed. > > It's required to store it somewhere so that you can take its address. > "const" variables are still lvalues, not expressions. A lot of the older compilers did that copy to ram even when they purported to generate code for embedded systems. The solution was to do the constant tables in assembler and then export a reference to them. The physical address of a const in ROM is known at link time. And you can be sure that no attempt by the CPU to trash a ROM value will ever succeed. The same cannot be said of a value in ram if things go haywire. This immutability of ROM did cause amusement in bank switched user register CPUs like the 9900 and 99k. You could tell it was in big trouble if the user register bank was in ROM where incrementing the program counter doesn't work any more. I never appreciated at the time just how good the 99k was at interrupt handling until I tried to do the same job on a 68k series. Regards, Martin Brown >> >> I also never use constants like 25480. ?24*60*60 is far more readable >> >> and less prone to error. ?It doesn't take a pico second more to [quoted text clipped - 13 lines] >> Cheers! >> Rich >Like in a #define? >Funny thing is, 24x60x60 = 86,400, actually... >Not likely that 60 seconds in a minute, or 60 minutes in an hour, >would change... unless... the client moves from a 24-hour-workday to, >say, an 8-hour work day? No, the point is to remove an opportunity for programmer error. Let the compiler do the math. >> >> You want a real write-only language? Try FORTH. >> >> OVER + SWAP DO [quoted text clipped - 26 lines] > >Michael Interesting, i just checked the multiply and got the familiar 86,400. 25480 seems to be an overflow result. With two 60s in the multiplier chain, two zeroes at the end of the product is expected. YMMV >>>>>>>> John Larkin a écrit : >>>>>>>>> I haven't used a linked list in decades. PCs are so fast these days [quoted text clipped - 25 lines] >but we're assuming reasonable practice here--use GOTOs to escape from a >deeply nested loop to a nearby point, say, but not otherwise.) Intermediate cells can be used for debug. Cells/sheets are named. >Any spreadsheet cell, on the other hand, can depend on any other >spreadsheet cell, without warning and without any way of finding that >out in general other than an exhaustive examination of each cell. Not true. Excel, at least, shows the come-froms. >_Your_ spreadsheets, I'm quite sure, are sensibly structured and >reasonably comprehensible in outline. But that is far from the general >case, even for spreadsheets that have real money depending on them. A >nontrivial spreadsheet that has had more than a couple of people working >on it is a disaster to debug--far worse than spaghetti code. You haven't seen spaghetti code. ;-) Try running a fab on a pile of APL routines, like the one just North of you was twentyish years ago. >>> I'm with John on spreadsheets (though not on BASIC)--they're famous for >>> generating reasonable-looking wrong answers, and (unlike programming [quoted text clipped - 7 lines] > >Yep, tables and graphs are about it. Checking tables form other databases too. >>> Brr. Give me Mathcad or Octave for numbers, and little scripts for >>> other sorts of data. Spreadsheets--blech. [quoted text clipped - 3 lines] > >Well, they're widely accepted, all right, but they still stink. They're wonderful productivity tools. Just like a hammer, they're dangerous in untrained hands. > And an O(Nlog2N) sort would beat it hollow at N > ~500 You really are > clueless about algorithms and their relative speeds. > > Linear search or sort by straight insertion is typically only faster for > N<50. Hardware engineers tend to code the even slower Bubble sort. It may > be fast enough for your small datasets but it doesn't scale well. But is the absolute difference in run-time between the algorithms more than the difference in programming time? If you only run a program once, 30 seconds coding plus 1 minute run-time is an improvement over 5 minutes coding plus 1 second run-time. Even if a program gets used regularly, computers are cheaper than people. For bespoke software, buying a faster computer is often cheaper than paying more to make the software go faster. Nobody a écrit : >> And an O(Nlog2N) sort would beat it hollow at N > ~500 You really are >> clueless about algorithms and their relative speeds. [quoted text clipped - 12 lines] > For bespoke software, buying a faster computer is often cheaper than > paying more to make the software go faster. Depends whether the progammer and the user are the same person or not (from the user's POV). Depends whether there are one or more users. Depends whether users are customers or not. In the latter case, for ex., you have to count wasted time, computing resources increase, or whatever for all your customers. Compare this with your increased production cost, plus some profit, shared among all your customers and you have something more meaningful and probably not the same conclusions. M$ is pretty great at wasting the time and resources of their customers. The point is their sloppiness (their customers time) costs them almost nothing. Except some bad reputation in the long term... SignatureThanks, Fred. >> And an O(Nlog2N) sort would beat it hollow at N > ~500 You really are >> clueless about algorithms and their relative speeds. [quoted text clipped - 5 lines] > But is the absolute difference in run-time between the algorithms more > than the difference in programming time? In most high level languages basic things like efficient sorting, hash tables and searching are already available in a library somewhere. RTFM and use them rather than reinvent the wheel badly. Electronics engineers are more used to this approach than software engineers. They do not automatically try to roll their own electrolytic capacitors or make transistors from scratch every time. > If you only run a program once, 30 seconds coding plus 1 minute run-time > is an improvement over 5 minutes coding plus 1 second run-time. For a use once and throw away program it maybe OK. But these quick hacks have a nasty tendency to end up being used again and again. After the fifth time of using it the second method wins out handsomely. > Even if a program gets used regularly, computers are cheaper than people. > For bespoke software, buying a faster computer is often cheaper than > paying more to make the software go faster. That depends on how often the program is used. Certain commercial programs that are widely used are a lot slower than they should be due to stupidity in the design producing an inefficient bloatware solution. It is always a risk in the time to market versus performance tradeoff. On time, on budget, on spec - pick any two for hardware. You are lucky to get one of these on target with the average software house. Regards, Martin Brown >That depends on how often the program is used. Certain commercial >programs that are widely used are a lot slower than they should be due [quoted text clipped - 3 lines] >On time, on budget, on spec - pick any two for hardware. You are lucky >to get one of these on target with the average software house. Yes. Most programming, as a process, is broken. John >>That depends on how often the program is used. Certain commercial >>programs that are widely used are a lot slower than they should be due [quoted text clipped - 5 lines] > > Yes. Most programming, as a process, is broken. Only if you look at it from a technical or academic perspective. From a business perspective, the process is quite well tuned. Like anything, performance and reliability are worth whatever the market is willing to pay for them, no more and no less. If the market prefers cheap crap over paying for quality, you get cheap crap. >>>That depends on how often the program is used. Certain commercial >>>programs that are widely used are a lot slower than they should be due [quoted text clipped - 12 lines] >is willing to pay for them, no more and no less. If the market prefers >cheap crap over paying for quality, you get cheap crap. But in my experience, the worst software is the most expensive. A lot of the best software is free. John >>Like anything, performance and reliability are worth whatever the market >>is willing to pay for them, no more and no less. If the market prefers >>cheap crap over paying for quality, you get cheap crap. > > But in my experience, the worst software is the most expensive. Niche software is generally both low quality and expensive; the alternative would often be reasonable quality and unaffordable. > A lot of the best software is free. True, but that's not created on a commercial basis. And a lot of the worst software is also free. Free software is liberated from the need to turn a profit, so there's no product sabotage to preserve sales of the enhanced version, or chasing meaningless bullet points at the expense of useful functionality. OTOH, it's also liberated from the need to cater to what users actually want (as opposed to e.g. what the developer thinks they ought to want). >Free software is liberated from the need to turn a profit, so there's no >product sabotage to preserve sales of the enhanced version, or chasing >meaningless bullet points at the expense of useful functionality. > >OTOH, it's also liberated from the need to cater to what users actually >want (as opposed to e.g. what the developer thinks they ought to want). Most important perhaps with much open source software is that it is written by somebody actually *USING* it, created to do some function the person needed, at least in my case. So it will likely do that :-) That is very different from a CEO saying: Let's write a xxx package, competition is making millions with it. And the programmer never even uses it... so it will suck. >>>Like anything, performance and reliability are worth whatever the market >>>is willing to pay for them, no more and no less. If the market prefers [quoted text clipped - 4 lines] >Niche software is generally both low quality and expensive; the >alternative would often be reasonable quality and unaffordable. You are making the common argument that better software has to cost more. What I see is that some people write good code and some don't. We use PADS for pcb layout; it has no known-to-me bugs, it's fast, and it never crashes. LT Spice is great. Agilent's Appcad ditto. Irfanview and Crimson are great. Firefox and Thunderbird too. Most Microsoft and Adobe products are slow and buggy. Why is Hyperterminal still messed up? Adobe Reader is a train wreck. >> A lot of the best software is free. > [quoted text clipped - 5 lines] >product sabotage to preserve sales of the enhanced version, or chasing >meaningless bullet points at the expense of useful functionality. Free software is also usually written by one or a few people (beasts like Linux excepted; but even Linux is better than Windows.) John On Jun 10, 1:21 pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > >>>Like anything, performance and reliability are worth whatever the market > >>>is willing to pay for them, no more and no less. If the market prefers [quoted text clipped - 28 lines] > > John This is the best free software I could find for composing music: http://www.rosegardenmusic.com If I knew Windows programming, I might help volunteer with a port. Alas, ... Michael >>> But in my experience, the worst software is the most expensive. >> [quoted text clipped - 3 lines] > You are making the common argument that better software has to cost > more. What I see is that some people write good code and some don't. Not that it *has* to, just that it often does. Once upon a time, IBM estimated that the computer market amounted to around 20 computers in the entire world. Nowadays, everyone has one, and the software industry is so large that there simply aren't enough "good" programmers to go around. In this environment, some degree of mediocrity is inevitable. > We use PADS for pcb layout; it has no known-to-me bugs, it's fast, and > it never crashes. LT Spice is great. Agilent's Appcad ditto. Irfanview > and Crimson are great. Firefox and Thunderbird too. Most Microsoft and > Adobe products are slow and buggy. That's because Microsoft and Adobe are trying to corner the market, which means that their products have to do absolutely everything that any similar product might possibly want to do, otherwise they leave enough of a market for a competitor to survive. This pretty much guarantees bloatware. Free software (or even less ambitious commercial software) will tend to stick to what it's good at; or at least not bother trying to do what it's particularly unsuited for. >>>> But in my experience, the worst software is the most expensive. >>> [quoted text clipped - 11 lines] >programmers to go around. In this environment, some degree of mediocrity >is inevitable. I don't think the culture, in academia or in business, plans for quality. The big issue that Computer Science should be addressing, the issue where they could actually affect society in a meaningful way, is programming quality. It's my opinion that high-quality software is on average cheaper to make than buggy software. >> We use PADS for pcb layout; it has no known-to-me bugs, it's fast, and >> it never crashes. LT Spice is great. Agilent's Appcad ditto. Irfanview [quoted text clipped - 10 lines] >to stick to what it's good at; or at least not bother trying to do what >it's particularly unsuited for. Consider an X-Y plot: X axis is programmer experience; Y-axis is bug density. The engineering units are admittedly fuzzy, but go with the concept. I think the popular languages and culture tend to make the droop down fron the initial start, but then flatten out or even start to curve back up. More experienced programmers go faster and use trickier constructs and the newest tools to keep their bug rate up. Now consider plotting graphs in different colors for different languages: Fortran, Cobol, C, C++, ADA, Perl, Python, Java. Are we making progress? John >>>>> But in my experience, the worst software is the most expensive. >>>> Niche software is generally both low quality and expensive; the [quoted text clipped - 11 lines] > I don't think the culture, in academia or in business, plans for > quality. The big issue that Computer Science should be addressing, the They have but the young new programmers don't often get the chance to practice what they have been taught when they go into industry. > issue where they could actually affect society in a meaningful way, is > programming quality. > > It's my opinion that high-quality software is on average cheaper to > make than buggy software. That has been known for decades the IBM analysis of formal reviews as a method of early detection of specification errors in 1981 highlighted this early on. Popularised version in the "Mythical Man Month". Formal reviews saved them a factor of 3 in bug fixing costs and reduced the defects found after shipping by a factor of 4. It still isn't standard practice except in the best places. In the UK the problem with every large government computer project stems from the fact that the managers are innumerate civil servants. The new ID card thing should be hilarious. One database to bind them all... The real difficulty is in persuading customers that they do not want a quick hack to give them something ASAP. Most times that is exactly what they ask for even when they don't yet know what they want it to do. It is the job of the salesman to get the order in ASAP so guess what happens... Add in a few of the political factors like the guys who can see that if the computer system works right they will be out of a job and you can see how the specifications end up corrupt at the outset. If you tried to build hardware with the sort of "specifications" some major software projects start out with you would have a rats nest of components miles high by the time it was delivered. >> Free software (or even less ambitious commercial software) will tend >> to stick to what it's good at; or at least not bother trying to do what [quoted text clipped - 3 lines] > density. The engineering units are admittedly fuzzy, but go with the > concept. So far so good. The problem is that the variation of the position of these lines on the graph for different individuals is more than an order of magnitude. That is the worst programmers have a defect curve that is more than 10x higher than the best practitioners. And there are not enough good or excellent programmers. You cannot change the availability of highly intelligent and trained staff so you have to make the tools better. BTW don't blame the programmers for everything - a lot of the problems in the modern software industry stem from late injected feature creep. > I think the popular languages and culture tend to make the droop down > fron the initial start, but then flatten out or even start to curve > back up. More experienced programmers go faster and use trickier > constructs and the newest tools to keep their bug rate up. The newest tools like static testing and complexity analysis are all about detecting as many common human errors at compile time as possible. It is telling that the toolset for this is *only* available in the most expensive corporate version of MS development tools. When they should be in the one sold to students!!! A problem with student projects is that they are small enough that any half decent candidate can rattle them off with or without the right approach. > Now consider plotting graphs in different colors for different > languages: Fortran, Cobol, C, C++, ADA, Perl, Python, Java. Are we > making progress? If you want a safe well behaved curve then something like one of Wirth's languages Pascal or Modula2 is about as good as it gets (for that generation of language). Java is pretty good for safety if a bit slow and Perl has its uses if you like powerful dense cryptic code. APL is even terser and has seen active service in surprising places. Domain specific languages or second generation languages augmented by well tested libraries can be way more productive. Mathematica is one example. Regards, Martin Brown >> Now consider plotting graphs in different colors for different >> languages: Fortran, Cobol, C, C++, ADA, Perl, Python, Java. Are we [quoted text clipped - 5 lines] > and Perl has its uses if you like powerful dense cryptic code. APL is > even terser and has seen active service in surprising places. Perl is the last language you should be using if you want robustness. It actively encourages writing code which works 99% of the time; getting that last 1% requires a tenfold increase in effort. Any task which involves reading structured text should begin with a robust parser which parses everything, not just the outermost layer. The rest of the program operates on data structured as lists, tuples, structures, objects, dictionaries, etc. Manipulating data as structured text using string manipulation functions is the road to hell. I'm convinced this approach has created more security flaws than buffer overflows ever have. Sure, you *can* write correct code in Perl; it just makes doing a half-arsed job so much easier than doing it right. >>> Now consider plotting graphs in different colors for different >>> languages: Fortran, Cobol, C, C++, ADA, Perl, Python, Java. Are we >>> making progress? >> If you want a safe well behaved curve then something like one of Wirth's >> languages Pascal or Modula2 is about as good as it gets (for that >> generation of language). Java is pretty good for safety if a bit slow >> and Perl has its uses if you like powerful dense cryptic code. APL is >> even terser and has seen active service in surprising places. > > Perl is the last language you should be using if you want robustness. It > actively encourages writing code which works 99% of the time; getting that > last 1% requires a tenfold increase in effort. I could not agree more. But I also wanted to make the point that for a quick hack it can also be very powerful if you stay within the envelope. I was intending to contrast the last two with the others which are robust but I see now that you could read it another way. It is the old ambiguity problem with natural language descriptions. > Any task which involves reading structured text should begin with a > robust parser which parses everything, not just the outermost layer. The [quoted text clipped - 4 lines] > is the road to hell. I'm convinced this approach has created more security > flaws than buffer overflows ever have. I'm not so sure. > Sure, you *can* write correct code in Perl; it just makes doing a > half-arsed job so much easier than doing it right. I am not so purist as to insist on perfection. A write once and throw away program can be done in whatever language makes the job easiest. The only tricky thing is making sure that the code really works as intended. Regards, Martin Brown >> Manipulating data as structured text using string manipulation functions >> is the road to hell. I'm convinced this approach has created more security >> flaws than buffer overflows ever have. > > I'm not so sure. I haven't conducted a rigorous survey, but that's my impression from being subscribed to BugTraq for the last 13 years. Injection attacks in (mostly) PHP scripts are the low-hanging fruit of vulnerability analysis; the phrase "shooting fish in a barrel" comes to mind. Some days you might see a dozen posts from one wannabe security researcher who just went looking for the most obvious bugs in PHP scripts, and found no shortage of them. Google says: Results 1 - 10 of about 154,000 for "sql injection attack" Okay, so by page 10 it's lowered its estimate to 73,400, but it's still not exactly obscure. >> Sure, you *can* write correct code in Perl; it just makes doing a >> half-arsed job so much easier than doing it right. > > I am not so purist as to insist on perfection. A write once and throw > away program can be done in whatever language makes the job easiest. The > only tricky thing is making sure that the code really works as intended. Security doesn't matter if the program will only be run by its author on data created by its author; there's no mileage in exploiting your own account. Unfortunately, code which reads and/or writes structured text formats is frequently used in exposed environments, either on web servers or for processing data obtained straight off the 'net. >>> Manipulating data as structured text using string manipulation functions >>> is the road to hell. I'm convinced this approach has created more security [quoted text clipped - 16 lines] > Okay, so by page 10 it's lowered its estimate to 73,400, but it's still > not exactly obscure. I think I will concede the point entirely where PHP Internet exploits are concerned that is a lost cause. But I am not sure if the problems are the fault of processing structured text by string manipulation or inadequate safeguards in the script language. >>> Sure, you *can* write correct code in Perl; it just makes doing a >>> half-arsed job so much easier than doing it right. [quoted text clipped - 5 lines] > data created by its author; there's no mileage in exploiting your own > account. Yes. I had in mind jobs which are essentially turning the rubbish formatted dump of raw data that some manufacturer outputs into a format that is useful to their customer. You would not believe the number of expensive instruments that output measurement data in the most user hostile and bulky formats possible. > Unfortunately, code which reads and/or writes structured text formats is > frequently used in exposed environments, either on web servers or for > processing data obtained straight off the 'net. And that is where it is very prone to abuse. I am still inclined to think that the problem is more with the current implementations and sheer number of bad exploitable scripts around than with the concept itself. Easy to use tools without safety guards is never a good idea. Regards, Martin Brown > I think I will concede the point entirely where PHP Internet exploits > are concerned that is a lost cause. But I am not sure if the problems > are the fault of processing structured text by string manipulation or > inadequate safeguards in the script language. Injection attacks arise from constructing structured text formats by directly manipulating the text. The code inserts a string at a point in the text with the intention that the string will correspond to a node in the parse tree. But if the string contains characters which are significant to the parser, it completely changes the overall structure. E.g. (using C syntax): sprintf(cmd, "SELECT * FROM mytable WHERE mycolumn = '%s';", value); This works fine until the attacker does: /* note the unmatched single quote */ value = "foo';DROP TABLE mytable"; The intention was to "graft" a literal string at a specific point in the parse tree for the SQL command, but you end up with a completely different parse tree. The reason why they're so prevalent in PHP is that the language is designed primarily for interfacing using textual formats, particularly HTML and SQL, but the language designers pushed the task of constructing the data (which is harder than it looks) onto the users. A saner approach would have been to require SQL, HTML, shell commands, etc to be constructed through a DOM-style interface, with the language taking responsibility for generating text with the correct structure. Then the task would only need to be done once, by (hopefully) experienced programmers, rather than thousands of times by novices. >> Unfortunately, code which reads and/or writes structured text formats is >> frequently used in exposed environments, either on web servers or for [quoted text clipped - 4 lines] > sheer number of bad exploitable scripts around than with the concept > itself. Easy to use tools without safety guards is never a good idea. It's a lack of forethought (and simple laziness) from designers. Need to provide an interface to SQL databases? Easy: int execute_sql(const char *cmd); Need a way to run external programs? Even easier: int system(const char *cmd); Need a way to output HTML: document.write(). This approach guarantees that strings obtained from who knows where will end up being passed verbatim to the functions. Even more so when the language encourages the use of strings as the primary datatype. <snip> >Free software is liberated from the need to turn a profit, so there's no >product sabotage to preserve sales of the enhanced version, or chasing >meaningless bullet points at the expense of useful functionality. > >OTOH, it's also liberated from the need to cater to what users actually >want (as opposed to e.g. what the developer thinks they ought to want). You imply that the "meaningless bullet points" are somehow different. > But in my experience, the worst software is the most expensive. Writing bad software is expensive. Bad hardware, too. James Arthur >> But in my experience, the worst software is the most expensive. > >Writing bad software is expensive. Bad hardware, too. The difference being that you can't make money with bad hardware. >> But in my experience, the worst software is the most expensive. > >Writing bad software is expensive. Bad hardware, too. > >James Arthur Yes. And management should be able to force software quality, but usually can't. John >>> But in my experience, the worst software is the most expensive. Selective memory. There is good expensive software too. It tends to exist in niche markets where high development costs have to be spread across a small number of units. >> Writing bad software is expensive. Bad hardware, too. >> >> James Arthur > > Yes. And management should be able to force software quality, but > usually can't. Big company management often pay only lip service to software quality - it is all about maximising their bonuses which usually means minimum time to market and maximum immediate sales. Turnover in the sales staff at software development companies means they are seldom around when the impossible promises they made to the customer have to be delivered. Management know full well when the first version ships that is it riddled with bugs. XL2007 is a good recent example. You can always issue updates that ameliorate the problems later. But a *new* version is it. Once customers have it you can persuade other people to upgrade by making the new file format incompatible with previous versions. I think the cumulative updates to XL2007 (original boxed version) now top 1GB. After all everyone that matters has broadband these days. The big difference now is that nothing physically has to ship. Regards, Martin Brown >>>> But in my experience, the worst software is the most expensive. > [quoted text clipped - 20 lines] >Once customers have it you can persuade other people to upgrade by >making the new file format incompatible with previous versions. There's another interesting graph: X axis is how hard (or expensive) it is to change a product in the field, and Y axis is bug density. The curve dives down. Serious hardware and software designs that are hard to update (like hard asics, auto engine control computers, or the stuff inside flat-screen TVs, or military bear) are debugged pretty hard before being shipped. Mediun things (fpga's, prodcuts that are easily upgraded with a flash stick) are in-between, Stuff that gets weekly updates over the web are often horrible. I see this in my own work: hardware designs are checked exhaustively, and we go out for a batch of expensive multilayer boards (we dom't prototype!) and they are usually right. Assembly programming, I'm pretty careful because the assemble-install-test loop is tedious. On-screen programming is pretty much type and ignite and see what happens. >I think the cumulative updates to XL2007 (original boxed version) now >top 1GB. After all everyone that matters has broadband these days. > >The big difference now is that nothing physically has to ship. Yes, and that makes people care less about bugs. And when a product is so complex that each bug fix spins off more bugs... John > There's another interesting graph: X axis is how hard (or expensive) > it is to change a product in the field, and Y axis is bug density. [quoted text clipped - 5 lines] > easily upgraded with a flash stick) are in-between, Stuff that gets > weekly updates over the web are often horrible. All of which reinforces the view that the software industry really does know what it's doing. If reliability actually matters, you get reliability. If it doesn't, you don't. The extent to which customers might want reliability only matters insofar as it affects their purchasing decisions. >>I think the cumulative updates to XL2007 (original boxed version) now >>top 1GB. After all everyone that matters has broadband these days. [quoted text clipped - 3 lines] > Yes, and that makes people care less about bugs. And when a product is > so complex that each bug fix spins off more bugs... That's mostly just Microsoft. When Linux vendors issue bugfix releases, they usually are just bugfixes, not version upgrades. When I maintained Linux servers, I only bothered using a test server for upgrades. Bug fixes went straight onto the production servers, and I never encountered a regression as a result. For security fixes, leaving an unpatched server facing the internet for another hour was a bigger risk than the patch itself causing problems. >>> Yes. And management should be able to force software quality, but >>> usually can't. You are confusing "excellence" with quality here. If they did not produce a product with *adequate* quality then customers would not buy it and the company would not make a profit. Microsoft must be doing something right since the suckers are all buying Office 2007. >> Big company management often pay only lip service to software quality - >> it is all about maximising their bonuses which usually means minimum [quoted text clipped - 17 lines] > easily upgraded with a flash stick) are in-between, Stuff that gets > weekly updates over the web are often horrible. But that is pure market economics. If it is cheap to fix in the field then it ships earlier and the company banks the cash. The CEOs duty is to maximise shareholder value and his own bonus (sometimes mostly the latter). CPU designs are even more carefully checked and simulated before they go into production on a fab line. It all depends on the upfront capital costs to manufacture and the cost of fixing in the field. You may not like it, but when the in service fix is almost free to the supplier then they will exploit that to their advantage. The company managements job is to find the line between a perfect product delivered too late to make any money at one extreme and a buggy one that fails to sell because it doesn't work. > I see this in my own work: hardware designs are checked exhaustively, > and we go out for a batch of expensive multilayer boards (we dom't > prototype!) and they are usually right. Assembly programming, I'm > pretty careful because the assemble-install-test loop is tedious. > On-screen programming is pretty much type and ignite and see what > happens. You should probably acquire some better in circuit debugging tools then. Post mortem and realtime debuggers have advanced a long way. Even the humble PICs have advanced and cheap debuggers available these days. Bugs are always cheaper to fix the sooner they are caught so it makes sense to use the best tools available for the job. Type and ignite has never been a good method. The coherence length of code written at a terminal has a bad habit of being equal to the number of lines that fit on a display page. Everyone does it for tiny throw away programs but it isn't advisable for anything bigger. >> I think the cumulative updates to XL2007 (original boxed version) now >> top 1GB. After all everyone that matters has broadband these days. [quoted text clipped - 3 lines] > Yes, and that makes people care less about bugs. And when a product is > so complex that each bug fix spins off more bugs... Some of the complexity is unavoidable in very large systems. Your experience with one programmer few months projects does not scale well. A rough guide is that every attempted non-trivial bug fix in a large project has a 50% risk of causing an unwanted side effect. It means some are worth leaving in if there is a workaround. I always recall IBM's FORTRAN G compiler which was so uncertain of its world view that the result of a successful compilation was: NO DIAGNOSTICS GENERATED? Debug showed that the string length of the message was miscounted and the trailing NUL was being printed as "?". Rumour had it that their change procedures made it too onerous to correct this minor cosmetic fault. Regards, Martin Brown >>>> Yes. And management should be able to force software quality, but >>>> usually can't. > >You are confusing "excellence" with quality here. Sigh. I suppose "quality" now means that you can ship it and charge for it and expect thjat it won't crash too bery often and that your customers will find the remaining hundreds of crashes and security vulnerabilities by experiment. There are a couple of reasonable responses to this: use simpler, preferably free, stuff that does the basic job; and if your PC works and is finally mostly stable, don't upgrade. >If they did not produce a product with *adequate* quality then customers >would not buy it and the company would not make a profit. Microsoft must >be doing something right since the suckers are all buying Office 2007. So where are the class-action lawyers when we really need tham? >>> Big company management often pay only lip service to software quality - >>> it is all about maximising their bonuses which usually means minimum [quoted text clipped - 30 lines] >product delivered too late to make any money at one extreme and a buggy >one that fails to sell because it doesn't work. Well, I just think that the tradeoff could be shifted a lot in the quality direction, without extra expense, and with *sooner* deliveries, with different methods and culture. I don't think that security vulns are a marketing tool, especially when everybody now expects that the next release will be just as bad. The world has suffered mightily from the personality defects of Bill Gates. >> I see this in my own work: hardware designs are checked exhaustively, >> and we go out for a batch of expensive multilayer boards (we dom't [quoted text clipped - 8 lines] >are always cheaper to fix the sooner they are caught so it makes sense >to use the best tools available for the job. My embedded stuff works just fine. Things get done quickly and ship bug-free, because I'm careful. >Type and ignite has never been a good method. The coherence length of >code written at a terminal has a bad habit of being equal to the number >of lines that fit on a display page. Everyone does it for tiny throw >away programs but it isn't advisable for anything bigger. My on-screen stuff is mostly engineering utilities or one-time calcs; I'd never ship quickie things like this. But of you're arranging a screen display, the easiest thing to do is run the code, see how it looks, and tweak for beauty, as opposed to planning every character location in advance. Small design iterations can take, literally, 10 seconds. Embedded stuff I write, assemble, read, tweak, read, until it looks perfect, before I ever run it. Reading is a much better way to debug than testing. Reading is also a lost art in many circles. In big systems, roughly half of the bugs are invisible, being module interactions, so no module author is likely to spot them by reading his code. So bugs are found by testing, many of that testing done by users. There must be a better way. John >>>>> Yes. And management should be able to force software quality, but >>>>> usually can't. >> You are confusing "excellence" with quality here. > > Sigh. I suppose "quality" now means that you can ship it and charge > for it and expect thjat it won't crash too bery often and that your Yes. Pretty much that is the decision that the bean counters and suits whose bonuses depend quadratically on shipped product value will take. I am not defending these practices I am merely pointing out how it is. > customers will find the remaining hundreds of crashes and security > vulnerabilities by experiment. > > There are a couple of reasonable responses to this: use simpler, > preferably free, stuff that does the basic job; and if your PC works > and is finally mostly stable, don't upgrade. That is fine for shrink wrap consumer software but it doesn't even begin to address the issues of major commercial projects. >> If they did not produce a product with *adequate* quality then customers >> would not buy it and the company would not make a profit. Microsoft must >> be doing something right since the suckers are all buying Office 2007. > > So where are the class-action lawyers when we really need tham? I hope your defect rate when typing is a lot better when you write programs! >>>> Big company management often pay only lip service to software quality - >>>> it is all about maximising their bonuses which usually means minimum [quoted text clipped - 34 lines] > security vulns are a marketing tool, especially when everybody now > expects that the next release will be just as bad. The trouble is that we tend to hope and pray that the next version will be better. Vista was a dog following after XP which was pretty usable and is still being installed on new kit by savvy corporates. The next 'Doze version does look like it might be an improvement only time will tell. > The world has suffered mightily from the personality defects of Bill > Gates. Digital Research were too cocky by half with IBM over MSDOS. They let Gates get a foothold and win the deal. ISTR IBM licenced MSDOS for $1 per PC through not realising quite how many PCs would get sold. It isn't just Microsoft. Although they do seem to have a higher defect rate than is ideal they also have some very talented people like Steve McConnell who have written very sensible texts on best practice for defensive programming. Trouble is that it all gets forgotten in the final rush to finish, test and ship. Sad thing is the humble programmers typically just get stuffed with free pizzas, jolt and unpaid overtime. It is a great shame IBM & MS fell out over OS/2. That platform was very close to being a robust OS for consumer PCs but Windows was flashier and the world chose slick Willys Windows over IBMs staid OS/2. I think there may still be a few banking systems and airtraffic controls running on OS/2. >>> I see this in my own work: hardware designs are checked exhaustively, >>> and we go out for a batch of expensive multilayer boards (we dom't [quoted text clipped - 10 lines] > My embedded stuff works just fine. Things get done quickly and ship > bug-free, because I'm careful. And the project size is relatively small. >> Type and ignite has never been a good method. The coherence length of >> code written at a terminal has a bad habit of being equal to the number [quoted text clipped - 9 lines] > looks perfect, before I ever run it. Reading is a much better way to > debug than testing. Reading is also a lost art in many circles. I agree. An annotated paper listing or a diagram is hard to beat. > In big systems, roughly half of the bugs are invisible, being module > interactions, so no module author is likely to spot them by reading > his code. So bugs are found by testing, many of that testing done by > users. There must be a better way. This isn't entirely true. Most of the big project integration faults stem from ambiguities in the original specifications but they hit home only when the modules interact. A lot of errors could be found earlier by the right sort of inspections and walk throughs. But you do still have a big problem with system integration of large projects where N modules have N(N-1) possible interactions. For N=1 or 2 this isn't a big deal for N=100 or N=1000 you have to be exceptionally careful to avoid unintended side effects. Regards, Martin Brown >>>>>> Yes. And management should be able to force software quality, but >>>>>> usually can't. [quoted text clipped - 25 lines] > >I hope your defect rate when typing is a lot better when you write programs! When I'm at home, I tend to slouch and prefer dim lighting. And I never learned to type. When I write code, I spell check and re-read and fine-tune everything, several times, including comments. Actually, re-reading is a great way to find bugs and optimize code. Typing slowly and re-reading makes the final code come out *faster* I'm suspicious of people who touch-type pages of code at high speed and pretty much never look at it again until the bug reports become impossible to ignore. >The trouble is that we tend to hope and pray that the next version will >be better. Vista was a dog following after XP which was pretty usable >and is still being installed on new kit by savvy corporates. XP is pretty good, after about a decade of debugging. >The next 'Doze version does look like it might be an improvement only >time will tell. [quoted text clipped - 34 lines] > >And the project size is relatively small. Yup. By choice. I don't want to be a cog in some machine or a Microserf. >>> Type and ignite has never been a good method. The coherence length of >>> code written at a terminal has a bad habit of being equal to the number [quoted text clipped - 11 lines] > >I agree. An annotated paper listing or a diagram is hard to beat. I really want a 14" fanfold laser printer. It's not in this year's budget. John > I always recall IBM's FORTRAN G compiler which was so uncertain of its > world view that the result of a successful compilation was: [quoted text clipped - 3 lines] > the trailing NUL was being printed as "?". Rumour had it that their > change procedures made it too onerous to correct this minor cosmetic fault. Anyway, they were too busy debugging Fortran H--really an amazing compiler when it worked, but, *ahem* not their most robust offering. When I was an undergraduate, I learned Fortran 77 using Fortran G and H, debugging somebody else's published code for radiative transfer in interstellar giant molecular clouds. It eventually worked, amazingly enough--though I never did get that good at Fortran. (I almost met John Backus once, does that count?) ;) Cheers Phil Hobbs >> I always recall IBM's FORTRAN G compiler which was so uncertain of its >> world view that the result of a successful compilation was: [quoted text clipped - 12 lines] > >(I almost met John Backus once, does that count?) ;) I had lunch with Walter Brattain. John >>> I always recall IBM's FORTRAN G compiler which was so uncertain of its >>> world view that the result of a successful compilation was: [quoted text clipped - 15 lines] > > John I heard both Shockley and Teller speak when I was a grad student. Both were pretty creepy. (Teller was still debating Bethe, though both were in their 80s.) On the other hand, I used to share an office wall with Bob Dennard, the inventor of dynamic memory. (He was a couple of offices down on the other side.) Nice guy--ready to help anybody. The guy who designed the first H-bomb used to work at Watson too--Dick Garwin. He was a grad student at Los Alamos in the '50s, and designed the first one by hand--Ivy Mike it was, I think (http://www.archive.org/details/OperationIVY1952). Cheers Phil Hobbs >>>> I always recall IBM's FORTRAN G compiler which was so uncertain of its >>>> world view that the result of a successful compilation was: [quoted text clipped - 19 lines] >were pretty creepy. (Teller was still debating Bethe, though both were >in their 80s.) Brattain was very nice. I was a high-school student and won a trip to Bell Labs in a science fair, and I guess one of his functions was to have lunch with brats like us. I did "meet" Teller at LLNL, as we were both going through security to get in. He was old and frail and they treated him like God. >On the other hand, I used to share an office wall with Bob Dennard, the >inventor of dynamic memory. (He was a couple of offices down on the >other side.) Nice guy--ready to help anybody. I knew one of the inventors of cmos imager chips. The first ones were just standard drams with the lids removed, with refresh leakage making 2-level images. Can't remember his name now. I almost met Lyndon Johnson once. How's that? Had lunch at the next table from Craig, the Craigslist guy; ditto John Madden. Both talked a lot. Madden was more interesting. I did meet Johnny Weismuller at a bar in New Iberia, Louisiana. Top that! So, the rich and famous and Nobel prize winners eat and drink the same stuff that we do. John I played for Coach Madden, does that count? Jim ditto John > Madden. Both talked a lot. Madden was more interesting. >>>>> I always recall IBM's FORTRAN G compiler which was so uncertain of its >>>>> world view that the result of a successful compilation was: [quoted text clipped - 25 lines] >both going through security to get in. He was old and frail and they >treated him like God. John Bardeen was very nice too. My mother knew him fairly well (he was a faculty member with my father, though they didn't know each other well). My mother said that in a crowded room, he would have been voted the least likely to be a (double) Nobel winner. >>On the other hand, I used to share an office wall with Bob Dennard, the >>inventor of dynamic memory. (He was a couple of offices down on the [quoted text clipped - 5 lines] > >I almost met Lyndon Johnson once. How's that? My wife's third cousin (or maybe my MIL's, can't remember). >Had lunch at the next table from Craig, the Craigslist guy; ditto John >Madden. Both talked a lot. Madden was more interesting. [quoted text clipped - 4 lines] >So, the rich and famous and Nobel prize winners eat and drink the same >stuff that we do. >>I almost met Lyndon Johnson once. How's that? > >My wife's third cousin (or maybe my MIL's, can't remember). We were actually in the Oval Office, waiting for him, when something happened and he had to split. We did see his fat behind running across the lawn to get into a helicopter. Gave us the Viet Nam war, he did. And The Great Society. John >>>I almost met Lyndon Johnson once. How's that? >> [quoted text clipped - 5 lines] > >Gave us the Viet Nam war, he did. And The Great Society. The worst part of the Vietnam War, anyway. Yep, by wife whacks me every time I tell someone she's related to him. ;-) >>> That depends on how often the program is used. Certain commercial >>> programs that are widely used are a lot slower than they should be due [quoted text clipped - 11 lines] > is willing to pay for them, no more and no less. If the market prefers > cheap crap over paying for quality, you get cheap crap. Hence Microsoft - the McDonalds of the software industry. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>> That depends on how often the program is used. Certain commercial >>>> programs that are widely used are a lot slower than they should be due [quoted text clipped - 13 lines] > > Hence Microsoft - the McDonalds of the software industry. Hey! Don't knock Mac's! They're good, nutritious food, and tasty, too! Cheers! Rich >>>>> That depends on how often the program is used. Certain commercial >>>>> programs that are widely used are a lot slower than they should be due [quoted text clipped - 15 lines] > >Hey! Don't knock Mac's! They're good, nutritious food, and tasty, too! And you can order one, and have it handed to you on a tray with a Coke, faster than Windows will start up. John > On Fri, 19 Jun 2009 18:03:29 GMT, Rich Grise <richgrise@example.net> >>>> [quoted text clipped - 20 lines] > And you can order one, and have it handed to you on a tray with a > Coke, faster than Windows will start up. Admittedly, I don't go there very much - there's an In-N-Out a couple more blocks down the street. Cheers! Rich >>> Hence Microsoft - the McDonalds of the software industry. >> [quoted text clipped - 4 lines] > >John Yes, but windows will start faster then it takes to resize a reiserfs from 830 to 600 GB: grml: ~ # resize_reiserfs -s 600G /dev/sda8 resize_reiserfs 3.6.19 (2003 www.namesys.com) You are running BETA version of reiserfs shrinker. This version is only for testing or VERY CAREFUL use. Backup of you data is recommended. )))Do I give a sh.t about having to read in 300 DVDs or so again ??? Do you want to continue? [y/N]:y Processing the tree: 0% left 145312383, 2333 /sec )))YES 145312383 seconds ........ )))Well, it seems 400 hours, the point is somewhere I dunno, but I timed some. zsh: suspended resize_reiserfs -s 600G /dev/sda8 ))) So I stopped it with ctrl Z. Now running fsck to see if I can get out of this without a week extra work... That will take 10 minutes to an hour... Then I think if reiserfs works the way I hope it does (sane), that it puts files at the start of a partition, I will use a hex editor to look at some parts of the (new) disk to see if the area above 600 GB is clear, and then repartition... LOL. So, I have learned: Do NOT use reiserfs 3 if you have all 3 GB files on a 830 GB partition, as it is then SLOWER THE A HEAVY SEDATED SNAIL. >>>> Hence Microsoft - the McDonalds of the software industry. >>> [quoted text clipped - 9 lines] >grml: ~ # resize_reiserfs -s 600G /dev/sda8 >resize_reiserfs 3.6.19 (2003 www.namesys.com) From wiki: ReiserFS was the default file system in Novell's SUSE Linux Enterprise until Novell decided to move to ext3 on October 12, 2006 for future releases. [1] Although the change was rumored to be a result of principal author Hans Reiser being charged with the murder of his wife (he was later convicted[2] ) two days earlier, SUSE stated that the timing of the announcement was coincidental and unrelated.[3] John > On Fri, 19 Jun 2009 18:47:28 GMT, Jan Panteltje >> [quoted text clipped - 18 lines] > (he was later convicted[2] ) two days earlier, SUSE stated that the > timing of the announcement was coincidental and unrelated.[3] Reiser is also the default install for Slackware. I've been using it ever since Patrick Volkerding approved it for Slack systems. ;-) I've never lost data at a power outage, knock wood. ;-) ;-) Cheers! Rich >>grml: ~ # resize_reiserfs -s 600G /dev/sda8 >>resize_reiserfs 3.6.19 (2003 www.namesys.com) [quoted text clipped - 9 lines] > >John Well, first I managed to get the reiserfs working again... second I do not give a lot about what side of the bars 'murderers' are on as long as GWBush, he who murdered a million innocent Iraqis, is still on the opposite side of the bars as Hans Reiser there remain logical questions for me :-) Third, more important in the wikipedia article is this: <quote> Also, ReiserFS had a problem with very fast filesystem aging when compared to other filesystems - in several usage scenarios filesystem performance lowered dramatically with time. <end quote> I just found out I am in of of those scenarios, many large files (say average about 3 GB each), on a very large partition (890 GB). At 67 % full, things slow down by more then 50 %. /dev/sda8 897504508 584250820 313253688 66% /mnt/sda8 Holly golly I have 775 disks .. (CD + DVD) now in a box, got myself one of those big alu 1000 DVD storage boxes.... And I still keep finding disks all over the place. A lot are now copied to that harddisk. The box went to the attic. Suse is in bed with MS... I was a Suse user with version 7.2, but then when Novel bought it, and I went to grml www.grml.org More for servers. If you want small and fast, that is the one, it is debian based. I have modified it so it is now more 'Panteltje Linux'. Maybe I should ... hehe ... > If you want small and fast, that is the one, it is debian based. > I have modified it so it is now more 'Panteltje Linux'. > Maybe I should ... hehe Why not? Write some whiz-bang install scripts! Just do X, gpm, the network adapter and all that schtuff automagically, to make as easy to install as Winblows, and Aunt-Tilly friendly. ;-) Cheers! Rich >... >> If you want small and fast, that is the one, it is debian based. [quoted text clipped - 7 lines] >Cheers! >Rich There is one distro run by one man, and it was a good distro the last time I tried it, Slackware. But it takes 24/7 to maintain such a project. I do not think Linux is for the aunt-Tilly types, although for example Xandros makes it much like that on the eeePC, especially after I added some stuff my eeePC is more user friendly, but perhaps only to me :-). To try to imitate MS GUI is a death trap I think. I have some nice key bindings on that eeePC, ctrl Alt C sets up the network connection, ctrl Alt O starts Opera web browser, ctrl Alt T starts an xterm, etc. So much faster then rubbing a pad, clicking icons, and working through menus . ctrl Alt U starts the Usenet news reader. > I have some nice key bindings on that eeePC, ctrl Alt C sets up the > network [quoted text clipped - 4 lines] > menus . > ctrl Alt U starts the Usenet news reader. I have Windows+I set to open Firefox and Windows+O to open my mail/news reader (gasp, OE!). Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms >>> grml: ~ # resize_reiserfs -s 600G /dev/sda8 >>> resize_reiserfs 3.6.19 (2003 www.namesys.com) [quoted text clipped - 12 lines] > second I do not give a lot about what side of the bars 'murderers' > are on as long as GWBush, he who murdered a million innocent Iraqis, A million? I thought it was more like 100,000 lost since the war started, mostly killed by other Iraqis. Here, from an anti-war outfit: http://www.iraqbodycount.org/ SignatureCheers, James Arthur >>>> grml: ~ # resize_reiserfs -s 600G /dev/sda8 >>>> resize_reiserfs 3.6.19 (2003 www.namesys.com) [quoted text clipped - 15 lines] >A million? I thought it was more like 100,000 lost since the war >started, mostly killed by other Iraqis. SH killed over 2 million in his roughly 20-year career, about 100K per year. About a million alone in the war with Iran. John >>>>From wiki: >>>> ReiserFS was the default file system in Novell's SUSE Linux Enterprise [quoted text clipped - 5 lines] >>>> >>>> John >>> Well, first I managed to get the reiserfs working again... >>> second I do not give a lot about what side of the bars 'murderers' >>> are on as long as GWBush, he who murdered a million innocent Iraqis, >> A million? I thought it was more like 100,000 lost since the war >> started, mostly killed by other Iraqis. Clarification: 100k civilians killed, the great majority of whom were from Iraqi-Iraqi violence--Sunnis killing Shia & vice versa--not from US military operations. So, 1 million is off by more than 20:1. > SH killed over 2 million in his roughly 20-year career, about 100K per > year. About a million alone in the war with Iran. > > John Ah, but how many jobs did he create or save, and did he author a nifty filesystem? SignatureCheers, James Arthur >>>> grml: ~ # resize_reiserfs -s 600G /dev/sda8 >>>> resize_reiserfs 3.6.19 (2003 www.namesys.com) [quoted text clipped - 18 lines] >Here, from an anti-war outfit: >http://www.iraqbodycount.org/ The number of death of children by imposing the oil embargo, the number of death by polluting that country with depleted uranium ammo, the number of death because of deliberately creates sectarian violence, etc etc, is all because of US policy to get control of the Iraqi oil fields and push the price of oil way up. Now they want to destabilise Iran too, and Obamama has just OKed drilling in front of the US. If they get enough oil from there, .. then Iran can be bombed? What will happen when the multi-nationals (oilers) one day decide to bomb the US to get the price of oil up? After all, US is no longer the leading world power except for a few H bombs... Maybe Kim from N Korea is working on a H bomb too.... Pakistan, India, China, France, Russia, Israel, maybe Iran, some fireworks :-) (Sorry if I forgot anybody). Then international court of law .. the UN, will war criminal GWBush be sentenced? With US power faltering sure that pressure to do that will increase. After all he is just one guy in Texas, so who really cares ... All is relative is it not? Even Cesar ... OK. >>>>> grml: ~ # resize_reiserfs -s 600G /dev/sda8 >>>>> resize_reiserfs 3.6.19 (2003 www.namesys.com) [quoted text clipped - 40 lines] >Even Cesar ... >OK. You're babbling. John >After all, US is no longer the leading world power except for a few H bombs... >>Maybe Kim from N Korea is working on a H bomb too.... [quoted text clipped - 11 lines] > >John Sure I am babbling, if Kim shoots over the ocean you are closer then me though. When I was a kid i used to read comics about was it 'Buck Danny' fightin gin Sabre fighters in N Korea.. It sure was not Daffy Duck. LOL > On a sunny day (Fri, 19 Jun 2009 11:06:03 -0700) it happened John Larkin > [quoted text clipped - 8 lines] > > Yes, but windows will start faster then it takes to resize a reiserfs from 830 to 600 GB: What sane person resizes a file system? While it has DATA on it??? Thanks, Rich >What sane person resizes a file system? While it has DATA on it??? OK Richman, I will try to explain it to you, so you will be a bit wiser. As the very large file system fills up with hundreds of gigabytes, it becomes slower and slower. To keep speed usable it is better to have several smaller partitions, with separate file systems, so the balanced trees for reiserfs do not grow into the sky. As it is slow with 66 % fill, I could resize it to say 67%, and then resize that partition to 67 %, and then make a new partition of 33 %, and accessing data on that new one would be then be faster, Filling this one up to 100 % would slow down almost to a halt. Actually I would like to try ext4 file system on the newly created partition, to see how it behaves with huge files. > On a sunny day (Fri, 19 Jun 2009 21:32:00 GMT) it happened Rich Grise > [quoted text clipped - 10 lines] > Actually I would like to try ext4 file system on the newly created partition, > to see how it behaves with huge files. Oh. I'd have just verified that I have everything backed up, and used fdisk. To each his own, I guess. ;-) Cheers! Rich > Oh. I'd have just verified that I have everything backed up, and used > fdisk. Well sure, but just resizing the file system saves time and effort compared to restoring backups. >>What sane person resizes a file system? While it has DATA on it??? > [quoted text clipped - 8 lines] >Actually I would like to try ext4 file system on the newly created partition, >to see how it behaves with huge files. Actually, what you have is an extreme case file set. I suggest that you look into using ext2 and giving it a radically different tuning using tunefs. The better speed of ext2 versus ext3 combined with the very low write frequency makes the journaling of ext3/4 unwarranted. >> On a sunny day (Fri, 19 Jun 2009 11:06:03 -0700) it happened John Larkin >> [quoted text clipped - 13 lines] >Thanks, >Rich I do not think of myself as particularly loonie. Just the same, i have resized many file systems along the way. Always just after a backup and normally from outside (not on any mounted / running file system). >>>>>> That depends on how often the program is used. Certain commercial >>>>>> programs that are widely used are a lot slower than they should be due [quoted text clipped - 18 lines] > > John And it won't raise your blood pressure as much, either. (Although a reasonably fresh XP install is tolerable.) Cheers Phil Hobbs SignatureDr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net >>>>>> That depends on how often the program is used. Certain commercial >>>>>> programs that are widely used are a lot slower than they should be due [quoted text clipped - 18 lines] >And you can order one, and have it handed to you on a tray with a >Coke, faster than Windows will start up. Maybe not always: http://cbs4denver.com/investigates/denver.police.suspension.2.1049330.html >>>>> That depends on how often the program is used. Certain commercial >>>>> programs that are widely used are a lot slower than they should be due [quoted text clipped - 15 lines] > >Hey! Don't knock Mac's! They're good, nutritious food, and tasty, too! Saying that McDonalds sells good food is like saying that RadioShaft sells good electronics. > On Fri, 19 Jun 2009 18:03:29 GMT, Rich Grise <richgrise@example.net> >> >>Hey! Don't knock Mac's! They're good, nutritious food, and tasty, too! > > Saying that McDonalds sells good food is like saying that RadioShaft > sells good electronics. De gustibus non disputandum est. ;-) Cheers! Rich >>>>> That depends on how often the program is used. Certain commercial >>>>> programs that are widely used are a lot slower than they should be due [quoted text clipped - 13 lines] > > Hey! Don't knock Mac's! They're good, nutritious food, and tasty, too! You poor bastard... SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- > ftp://66.117.156.8/GR8.jpg > The imperfections simulate the effects of finite-bandwidth deflection > amplifiers. Works great. How many lines of code is that, John? I'm willing to bet that there are few other languages that could pull it off in as few lines of code. Even with something like Python, since graphics aren't native, you end up using one of the windowing toolkits such as wxGTK or wxPython, and "just making a stupid plot" tends to consume a lot more code than one might expect. ---Joel >> ftp://66.117.156.8/GR8.jpg >> The imperfections simulate the effects of finite-bandwidth deflection >> amplifiers. Works great. > >How many lines of code is that, John? 464, including whitespace and comments. I comment a lot. It compiles to 44K, not that that matters any more. >I'm willing to bet that there are few other languages that could pull it off >in as few lines of code. Even with something like Python, since graphics >aren't native, you end up using one of the windowing toolkits such as wxGTK or >wxPython, and "just making a stupid plot" tends to consume a lot more code >than one might expect. I like PowerBasic because almost everything you need is internal to the language and throughly documented. John > 464, including whitespace and comments. I comment a lot. It compiles > to 44K, not that that matters any more. 464... impressive. I stand beside my comment that I think it's unlikely any "mainstream" language could do it in fewer lines! (Without resorting to "obfuscated" or "packed" code, of course.) >> 464, including whitespace and comments. I comment a lot. It compiles >> to 44K, not that that matters any more. > >464... impressive. I stand beside my comment that I think it's unlikely any >"mainstream" language could do it in fewer lines! (Without resorting to >"obfuscated" or "packed" code, of course.) ' NEON.BAS V350 Heads-Up Display Simulator ' ' BY JOHN LARKIN ' HIGHLAND TECHNOLOGY, INC ' MAY 21, 2006 ' THIS PROGRAM INPUTS A LIST OF X/Y/Z POINTS IN CSV FORM, AND ' PLOTS THE VECTOR CHARACTERS DEFINED THEREIN. ' ' SEE FILE NEON.TXT FOR GORY DETAILS ' ' NEON.BAS IS CODED IN POWERBASIC, PBCC V 4.01 ' ' THIS VERSION ALLOWS INPUT IN 'SCOPE' OR 'CHARSET' FORMATS ' AND INCLUDES FINE-GRAIN FILTERING AND RATE SHADING ' REV 2 IS FAT-PIXEL VERSION #COMPILE EXE ' THEY MADE ME SAY THAT ' Function to check for a keystroke... GLOBAL K$ FUNCTION KEYCHEK AS LONG K$ = UCASE$(INKEY$) END FUNCTION ' Function to wait for and get a keystroke... FUNCTION GETKEY AS LONG K$ = UCASE$(WAITKEY$) END FUNCTION FUNCTION PBMAIN ' USER DATA STORAGE: DIM TD(50000) AS SINGLE ' TIME OF POINT DIM BD(50000) AS SINGLE ' BRIGHTUP DATA DIM XD(50000) AS SINGLE ' X DATA DIM YD(50000) AS SINGLE ' Y DATA REV$ = "Neon rev 2" CONSOLE SET LOC 40, 120 ' CONTROL PANEL UPPER-LEFT ON DESKTOP CONSOLE NAME REV$ CONSOLE SET SCREEN 32, 50 ' AND NOT VERY BIG MOUSE ON ' ALLOW CLICKS IN THE CONSOLE WINDOW MOUSE 1 ' TO ABORT A PLOT ZM! = 40 ' DEFAULT ZOOM FACTOR VF! = 0 ' V350 LOWPASS FACTOR = OFF HF! = 0 ' HUD LOWPASS FACTOR DITTO SK% = 0 ' SHOW BEAM-OFF PATH GM! = 0 ' GAMMA OFF, NO SHADING XO! = 0 ' NO X OFFSET YO! = 0 ' OR Y ' TOP: CONSOLE SET FOCUS ' SHOWTIME! COLOR 15,1 : CLS ' WHITE ON BLUE IF ZM! < 1 THEN ZM! = 1 ' RATIONALIZE ZOOM IF ZM! > 1000 THEN ZM! = 1000 LOCATE 2,5 : COLOR 15, 3 : PRINT " Highland V350 HUD Display Simulation "; COLOR 15, 1 ' SHOW MINI-MENU... LOCATE 4,5 : PRINT "File " ; IF F$ = "" THEN PRINT " - none - " ELSE PRINT F$; LOCATE 6, 14 : PRINT USING$("Data points ###,###", N&); LOCATE 7, 14 : PRINT USING$("Time span ###,### us", TSPAN!); LOCATE 8, 14 : PRINT USING$("Time/point ###.### us", DT!); END IF LOCATE 10,5 PRINT USING$("Zoom #### \\ ##.### volts", ZM!, "+-", 10/ZM!); LOCATE 12,5 : PRINT USING$("V350 filter ###.#", VF!); ' SHOW RAW FILTER FACTORS IF VF! = 0 THEN ' FF=0 DISABLES FILTER PRINT " off "; ELSEIF DT! > 0 THEN ' DT=0 IS UNLIKELY BUT POSSIBLE PRINT USING$(" ####.## us", VF!*DT!); END IF LOCATE 14,5 : PRINT USING$("HUD filter ###.#", HF!); ' REPEAT FOR CONJECTURED HUD ' AMPLIFIER RESPONSE TAU IF HF! = 0 THEN PRINT " off "; ELSEIF DT! > 0 THEN PRINT USING$(" ####.## us", HF!*DT!); END IF LOCATE 16,5 : PRINT "Skipmode "; ' SKIPMODE DOESN'T PLOT IF SK% THEN PRINT " ON "; ELSE PRINT "off "; ' NON-BU POINTS LOCATE 21,5 : PRINT USING$("Gamma ###.##", GM!) ' DISPLAY SEMI-USELESS BRIGHTNESS FACTOR LOCATE 28,5 : PRINT "Plot Quit" GETKEY ' ALLOW USER INPUT, AT LAST LOCATE 30,5 ' POSITION CURSOR FOR PROMPTS SELECT CASE K$ CASE "Z" : GOTO KZOOM ' ZOOM CASE "Q" : GOTO PREND ' EXIT PROGRAM CASE "V" : GOTO VFILT ' SET V350 LOWPASS CASE "H" : GOTO HFILT ' SET HUD LOWPASS CASE "P" : GOTO GROUT ' PLOT CASE "F" : GOTO KFILE ' IMPORT DATA CASE "S" : GOTO SKIPIT ' TOGGLE BU SKIP MODE CASE "G" : GOTO GAMMA ' SET INTENSITY SCALER END SELECT BEEP : GOTO TOP ' ' SET GAMMA, THE INTENSITY SCALER ' NUMBERS LIKE 6-8 SEEM TO DO SOMETHING GAMMA: LINE INPUT "Gamma, us : "; Z$ IF Z$ <> "" THEN GM! = VAL(Z$) GOTO TOP ' SET THE ZOOM FACTOR KZOOM: LINE INPUT "zoom 1..1000 : "; Z$ IF Z$ <> "" THEN ZM! = VAL(Z$) GOTO TOP ' SET OUR INTERNAL V350 LOWPASS FILTER TAU VFILT: LINE INPUT "V350 filter factor : "; S$ IF S$ <> "" THEN VF! = VAL(S$) GOTO TOP ' SET THE HUD LOWPASS FILTER TAU HFILT: LINE INPUT "HUD filter factor : "; S$ IF S$ <> "" THEN HF! = VAL(S$) GOTO TOP ' TOGGLE SKIP MODE, SO'S WE DON'T PLOT THE NON-BU POINTS SKIPIT: SK% = SK% XOR 1 GOTO TOP ' ' OPEN A FILE AND SCOOP UP DATA ' ' 'SCOPE' DATA IS CSV AS TIME, BRIGHTUP, Y, X ' ' 'CHARSET' DATA IS CSV AS X, Y, BRIGHTUP ' ' WE ALSO ALLOW ZOOM 10 ' VFIL 10 ' HFIL 35 ' NOTE comment ' SKIP 1 ' XOFF -4 ' YOFF 1.3 ' GAMM 3 KFILE: LINE INPUT "data file name : ", F$ ' DEFAULT .CSV IF INSTR(F$, ".") = 0 THEN F$ = F$ + ".csv" IF DIR$(F$) = "" THEN ' CHECK FOR ACTUAL FILE! BEEP F$ = "" GOTO TOP END IF N& = 0 ' BLAST POINT COUNT XO! = 0 ' AND OFFSETS YO! = 0 OPEN F$ FOR INPUT AS # 1 ' OK, FETCH AND MASH LINES... KLINE: IF ( EOF(1) OR N& > 49999 ) THEN GOTO KLENEX ' CHECK FOR END OF FILE LINE INPUT #1, L$ ' NAB A LINE L$ = UCASE$(L$) ' AND CLEAN UP GENERALLY L$ = TRIM$(L$) ' C$ = LEFT$(L$,4) ' SNIP POSSIBLE 4-LETTER COMMAND J! = VAL(MID$(L$,5)) ' AND POSSIBLE NUMERIC ARG ' SELECT CASE C$ ' CHECK OUT THE COMMANDS... CASE "NOTE" ' IGNORE COMMENTS CASE "TIME" ' IGNORE HEADER LINE CASE "ZOOM" : ZM! = J! ' SET ZOOM FACTOR CASE "XOFF" : XO! = J! ' SET X OFFSET CASE "YOFF" : YO! = J! ' SET Y OFFSET CASE "GAMM" : GM! = J! ' SET INTENSITY GAMMA CASE "VFIL" : VF! = J! ' V350 FILTER TAU CASE "HFIL" : HF! = J! ' HUD FILTER TAU CASE "SKIP" : SK% = J! AND 1 ' SET BU SKIP MODE 0 OR 1 CASE ELSE ' ANYTHING ELSE IS PROBABLY DATA PC% = PARSECOUNT(L$,",") ' SEE HOW MANY FIELDS WE HAVE IF PC% = 4 THEN ' 4 FIELDS IS TEK SCOPE DATA INCR N& TD(N&) = VAL(PARSE$(L$, ",", 1)) ' EXTRACT TIME BD(N&) = VAL(PARSE$(L$, ",", 2)) ' EXTRACT BRIGHTUP VALUE YD(N&) = VAL(PARSE$(L$, ",", 3)) + YO! ' EXTRACT Y VALUE; OFFSET XD(N&) = VAL(PARSE$(L$, ",", 4)) + XO! ' EXTRACT X VALUE END IF IF PC% = 3 THEN ' 3 FIELDS IS 'CHARSET' DATA ' SPANNED TO +-32767 INCR N& R! = 10/32768 ' RENORMALIZE CHARSET DATA TO +-10 VOLTS TD(N&) = 1E-6 * N& ' FAKE 'TIME' AS INTEGER USEC BD(N&) = VAL(PARSE$(L$, ",", 3)) ' EXTRACT BRIGHTUP VALUE, 0 OR 1 YD(N&) = VAL(PARSE$(L$, ",", 2)) * R! + YO! ' EXTRACT Y VALUE XD(N&) = VAL(PARSE$(L$, ",", 1)) * R! + XO! ' EXTRACT X VALUE END IF END SELECT GOTO KLINE KLENEX: IF N& > 2 THEN ' CALC TOTAL TIME SPREAD TSPAN! = (TD(N&) - TD(1)) * 1E6 ' IN MICROSECONDS! DT! = TSPAN! / (N&-1) ' AND STEP SIZE ELSE TSPAN! = 1 ' BUT DO NOTHING SILLY DT! = 1 END IF CLOSE # 1 GOTO TOP ' ' OPEN THE GRAPHICS WINDOW GROUT: IF F$ = "" THEN BEEP : GOTO TOP ' SORRY, NO FILE! LOCATE 28, 15 : COLOR 15,4 : PRINT " PLOTTING "; ' OPEN GRAPHICS WINDOW IF NOT ALREADY OPEN IF HANDL& = 0 THEN GRAPHIC WINDOW REV$, 450, 80, 500, 600 TO HANDL& END IF GRAPHIC ATTACH HANDL&, 0 ' SWITCH TO WORLD COORDINATES GRAPHIC SCALE (-11,16) - (11,-11) GRAPHIC COLOR %WHITE, RGB(40,40,40) ' BACKGROUND SORTA CHARCOAL GRAPHIC CLEAR GRAPHIC COLOR RGB(0,100,100) ' DULL CYAN SORTA ' USE BOXES TO DEFINE THE TEXT AND HUD AREAS GRAPHIC BOX (-10,10.5) - (10,15), 10 ' TEXT BOX GRAPHIC BOX (-10,-10) - (10,10), 5 ' HUD ' DRAW A FEW CURSOR LINES IN HUDSPACE GRAPHIC LINE (-10,0) - (10,0) ' HORIZ GRAPHIC LINE (0,10) - (0,-10) ' VERT ' SHOW PLOT CONTEXT IN UPPER BOX GRAPHIC COLOR %WHITE GRAPHIC SET POS (-9,14.7) GRAPHIC PRINT USING$("FILE : \ \ Points ##### \ \ \ \", F$, N&, DATE$, TIME$) GRAPHIC SET POS (-9,12.7) GRAPHIC PRINT USING$("Timespan ###,### us DT ###.## us", TSPAN!, DT!); GRAPHIC SET POS (-9,11.7) GRAPHIC PRINT USING$("Zoom ###.# Gamma ##.#", ZM!, GM!); GRAPHIC SET POS (3,12.7) GRAPHIC PRINT USING$("V350 filter ###.#", VF!); ' SHOW RAW FILTER FACTORS IF VF! = 0 THEN ' FF=1 DISABLES FILTER GRAPHIC PRINT " off "; ELSEIF DT! > 0 THEN ' AND DT=1 IS JUST SILLY GRAPHIC PRINT USING$(" ####.## us", VF!*DT!); END IF GRAPHIC SET POS (3,11.7) GRAPHIC PRINT USING$("HUD filter ###.#", HF!); ' REPEAT FOR CONJECTURED HUD ' AMPLIFIER RESPONSE IF HF! = 0 THEN GRAPHIC PRINT " off "; ELSEIF DT! > 0 THEN GRAPHIC PRINT USING$(" ####.## us", HF!*DT!); END IF ' ' PLOT THE DATASET RP% = 0 ' ZAP PROGRESS BAR REFERENCE X1! = 0 : Y1! = 0 ' DISCHARGE BOTH XF! = 0 : YF! = 0 ' LOWPASS FILTERS XR! = 0 : YR! = 0 ' ZAP GAMMA REFERENCE POINTS FOR M& = 1 TO N& ' PLUCK RAW X,Y DATA FROM ARRAY X! = XD(M&) * ZM! Y! = YD(M&) * ZM! IF (VF! = 0 AND HF! = 0) THEN ' IF NEITHER FILTER IS ENABLED, XF! = X! ' FAKE FILTERED YF! = Y! ' DATA, GOSUB PIFFL ' PLOT THE POINT GOTO PROG ' AND BAIL END IF ' TO ALLOW FILTERING OF COARSE DATAPOINTS, WE MUST PLOT AT A ' SMALLER TIME INCREMENT THAN THE ACTUAL DATA. ' SO WE'LL PLOT 10 INTERMEDIATE POINTS, SLOWLY! FOR IP% = 1 TO 10 ' APPLY THE V350 LOWPASS FILTER IF VF! > 0 THEN J! = 0.1/VF! ' FILTER X1! = X1! + (X!-X1!) * J! Y1! = Y1! + (Y!-Y1!) * J! ELSE X1! = X! ' OR DON'T Y1! = Y! END IF ' THEN APPLY THE HUD LOWPASS FILTER! IF HF! > 0 THEN J! = 0.1/HF! XF! = XF! + (X1!-XF!) * J! YF! = YF! + (Y1!-YF!) * J! ELSE XF! = X1! YF! = Y1! END IF GOSUB PIFFL ' PLOT A PIX! NEXT IP% ' ' SHOW A PLOT PROGRESS BAR... PROG: P% = 100.0 * M& / N& ' PROGRESS, 0..100 IF P% <> RP% THEN GRAPHIC COLOR %CYAN GRAPHIC LINE (P%/5-10,-10.5) - ((P%+1)/5-10,-10.5) RP% = P% END IF KEYCHEK ' KEY OR MOUSE CLICK BAILS IF K$ <> "" THEN EXIT FOR ' FROM PLOT LOOP NEXT M& GOTO TOP ' ' SUB TO PLOT A POINT IF IT'S IN OUR WINDOW ' ' XR! AND YR! ARE SAVED PREVIOUS POINT ' IF WE'RE IN GAMMA MODE, WE COMPUTE DISTANCE FROM ' THE LAST POINT AND SCALE BRIGHTNESS ' GAMMA IS THE VELOCITY IN MILLIVOLTS/MICROSECOND THAT CORRESPONDS ' TO 100% BRIGHTNESS, FULL WHITE. SSAI'S CHAR SET SEEMS TO LIKE ' 20-PIXEL BASIC STEPS, WHICH IS JUST ABOUT 3 MILLIVOLTS. IF WE SCALE, ' SAY, 1 mV/us TO FULL BRIGHT, AND ASSUME 1 US/POINT, GAMMA = 1 ' WEIRD STUFF HAPPENS IF GAMMA MODE IS ON AND FILTERING IS OFF. ' DON'T DO THAT. PIFFL: IF ( (ABS(XF!) > 10) OR (ABS (YF!) > 10) ) THEN GOTO NOPE IF BD!(M&) < 0.5 THEN ' IF BRIGHTUP IS OFF, IF SK% THEN GOTO NOPE ' SKIP PLOT IF THAT'S IN VOGUE GRAPHIC COLOR RGB(0,100,0) ' OR PLOT BEAM-OFF PATH SORTA DIM RAD! = 0.05 ' GREEN AND SMALLISH ELSEIF GM! = 0 THEN GRAPHIC COLOR RGB(230,0,70) ' NO GAMMA, BRIGHTUP IS ON: USE RED RAD! = 0.14 ' AND FAT PIXEL ELSE ' GAMMA, BRIGHTUP CASE: W! = SQR( (XR!-XF!)^2 + (YR!-YF!)^2 ) ' COMPUTE VECTOR LENGTH, VOLTS W! = W! * 1000 ' NOW MILLIVOLTS IF W! = 0 THEN W! = 0.01 ' HANDLE SPECIAL CASE, NO MOTION XR! = XF! : YR! = YF! ' UPDATE REFERENCE POINTS FOR NEXT TIME L! = 255 * GM! / W! ' COMPUTE BRIGHTNESS, SHORTER=BRIGHTER IF L! > 255 THEN L! = 255 ' OOPS, PHOSPHOR SATURATION! GRAPHIC COLOR RGB(L!,L!,L!) ' XLATE TO GREYSCALE RAD! = 0.14 ' AND USE FAT PIXEL END IF ' PLOT A FAT DOT... GRAPHIC ELLIPSE (XF!-RAD!,YF!+RAD!)-(XF!+RAD!,YF!-RAD!),-1,-1 NOPE: RETURN ' END OF PROGRAM! PREND: END FUNCTION >> ftp://66.117.156.8/GR8.jpg >> The imperfections simulate the effects of finite-bandwidth deflection >> amplifiers. Works great. >How many lines of code is that, John? >I'm willing to bet that there are few other languages that could pull it off >in as few lines of code. Even with something like Python, since graphics >aren't native, you end up using one of the windowing toolkits such as wxGTK or >wxPython, and "just making a stupid plot" tends to consume a lot more code >than one might expect. The difference is that with other languages, you won't have to start over if you want to port to a new platform. >>> ftp://66.117.156.8/GR8.jpg >>> The imperfections simulate the effects of finite-bandwidth deflection [quoted text clipped - 10 lines] >The difference is that with other languages, you won't have to start >over if you want to port to a new platform. The design is done, and it's flying on some AC130's, and we've been paid. Why would I want to port it to another platform? If I did it in C, would the Windows version be directly portable to Linux... graphics and all? The only sorta-platform independent language I know of that does graphics and such is Java. And it's slow. More importantly, it requires gui interface programming, a lot of hassle. John "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > The only sorta-platform independent language I know of that does > graphics and such is Java. And it's slow. More importantly, it > requires gui interface programming, a lot of hassle. You can (and people do) write it in C++ with a cross-platform GUI toolkit such as wxWidgets (free) or qt (not free). The high-level "scripting" languages such as Python and Perl are nominally cross-platform for this same reason. Some versions of Delphi (think, "Pascal on steroids") can also produce cross-platform output. So, there are more options than Java, but for the program you did, where the likelihood you'll need to re-use the code or port it to another platform is rather slim, I think it's pretty hard to argue that PowerBasic *wasn't* a near-optimal strategy. Code re-use is a great concept in theory that's often nowhere near as beneficial in practice when you're paying people for their time. ---Joel >>>> ftp://66.117.156.8/GR8.jpg >>>> The imperfections simulate the effects of finite-bandwidth deflection [quoted text clipped - 22 lines] > >John Well, it all depends. I dunno about the Power BASIC build in routines, but it seems to me in that example you are simply doing a xyplot. I did the xyplot in C for xlib a hundred or so years ago (;-) like this, after porting it from a Linux system without X server, using vgalib, the 'vga' label is still there, and that was ported from YES CP/M code. The function of the array is just as a readback. The 's3' was ported from direct graphics I/O to a s3 graphics card. The whole 'xglgraphi.c' source in C is 209 lines, including comments and empty lines. Anyways what I am saying is: It is very easy usually to plot a dot at x,y in some color in ANY system. xvtx-p, the program that uses the xyplot, displays videotext (Ceefax for the UK). What this does you can see here: ftp://panteltje.com/pub/xvtx-p.gif I have marked the calls to xlib in the below code. There is some more overhead to allocate a display buffer, but the basic code to draw anything in X is very simple. If you want to go fast with graphics in C in Linux, have a look at TinyPTC: http://sourceforge.net/projects/tinyptc/ works on MS windows, Mac, Linux, OSx, BEOS, DOS. I have only tried the Linux version, that prints the surface of mars in 3D from ESA files, I mean real 3D, with shutter glasses. http://panteltje.com/panteltje/space/mars/index.html Cannot promise it works for you, and you have to join ESA to get the data files... It does sequential left right eye, sometimes LR sync is lost, needs some work. Have not felt the urge to look into that, as I did not write that lib... I'd rather debug my own code :-) And I think they never intended it for 3D. int s3getpixel(int x, int y) { int color; color = vga_memory[x + y * HSIZE]; return color; } void s3plot(int x, int y, int color)/*plot 1 dot*/ { static int previouscolor; /* avoid 're appearing' at left and top */ if(x >= HSIZE)return; if(y >= VSIZE)return; if(color != previouscolor) { XSetForeground(mydisplay, xptestgc, color); // <----- xlib call previouscolor = color; } /* XSetBackground(mydisplay, xptestgc, WHITE);*/ XDrawPoint(mydisplay, topwindow, xptestgc, x, y); // <----- xlib call vga_memory[x + y * HSIZE] = color; } >>>> ftp://66.117.156.8/GR8.jpg >>>> The imperfections simulate the effects of finite-bandwidth deflection [quoted text clipped - 22 lines] > >John How about PostScript? Manual available here: http://www.adobe.com/devnet/postscript/pdfs/PLRM.pdf >>The only sorta-platform independent language I know of that does graphics >>and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 3 lines] >> > How about PostScript? It makes PIC assembler look intuitive. PostScript was designed to minimise the burden on the interpreter, not the programmer. >>>The only sorta-platform independent language I know of that does graphics >>>and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 6 lines] >It makes PIC assembler look intuitive. PostScript was designed to minimise >the burden on the interpreter, not the programmer. Hence the use of floating-point math for everything? >>>>The only sorta-platform independent language I know of that does graphics >>>>and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 8 lines] > > Hence the use of floating-point math for everything? FP math is pretty much essential for (real) graphics. Integer-based graphics APIs have (or had) a place in low-resolution video displays where you can see individual pixels, and where the graphics are dominated by unscaled bitmaps and (mostly orthogonal) straight lines. Integer coordinates don't make sense if you're operating at 300+ DPI, in physical dimensions (mm or points rather than pixels), with scaled images, thick (>1 pixel) lines, Bezier curves, arbitrary transformations, etc. >>>>>The only sorta-platform independent language I know of that does graphics >>>>>and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 18 lines] >physical dimensions (mm or points rather than pixels), with scaled images, >thick (>1 pixel) lines, Bezier curves, arbitrary transformations, etc. It was a little OTT in the 1980s. Postscript printers had more powerful CPUs than many of the computers of the day. Not what I'd call minimizing the burden. They scaled it back with PDF (and with the limitations for Type 1 fonts). >>>>> How about PostScript? >>>> [quoted text clipped - 16 lines] > powerful CPUs than many of the computers of the day. Not what I'd call > minimizing the burden. I was referring specifically to the interpreter, rather than the graphics library. The graphics library was certainly heavy-duty, but that was inevitable for generating production-quality graphics. The performance of the LaserWriter relative to the early Macs doesn't seem so extreme when you consider that an office might have had a dozen Macs and one LaserWriter. Also, pushing the work onto the printer allows the same PostScript data to be used for both the office printer and the Linotronic used for final production. That won't work with pre-rendered bitmaps (and generating a full-page, 2450 DPI bitmap on an early Mac was out of the question). > They scaled it back with PDF (and with the limitations for Type 1 fonts). These are interpreter limitations, designed to make the code more like "data" and less like "code". The graphics library is essentially unchanged (e.g. PDF doesn't support alpha-blended bitmaps, even though it's straightforward to implement on a monitor). >>>>> The only sorta-platform independent language I know of that does graphics >>>>> and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 8 lines] > > FP math is pretty much essential for (real) graphics. No it isn't. A 32 bit fixed point or scaled integer can represent and specify a position with 1 micron resolution over a 4km range. The largest commonly used plotters are about A0 or a couple of metres wide. You can do 1000ppi and 65.535" width in 16 bits though it tends to be limiting. It only gets really hairy if you want to zoom in dynamically. Floating point for graphics is certainly *easier* to work with but it isn't essential. > Integer-based graphics APIs have (or had) a place in low-resolution video > displays where you can see individual pixels, and where the graphics are [quoted text clipped - 3 lines] > physical dimensions (mm or points rather than pixels), with scaled images, > thick (>1 pixel) lines, Bezier curves, arbitrary transformations, etc. Integer or fixed point implementations are one of the ways it is done - especially on smaller portable systems with limited grunt like phones. Regards, Martin Brown >>>>>> The only sorta-platform independent language I know of that does >>>>>> graphics [quoted text clipped - 13 lines] > No it isn't. A 32 bit fixed point or scaled integer can represent and > specify a position with 1 micron resolution over a 4km range. Indeed, & that's best-practice in FORTH, for example. But the main reason that PS uses FP is for device independence, so that the same image will output correctly to any device, regardless of the page size or resolution. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>>>The only sorta-platform independent language I know of that does graphics >>>>>and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 18 lines] >physical dimensions (mm or points rather than pixels), with scaled images, >thick (>1 pixel) lines, Bezier curves, arbitrary transformations, etc. Only partially true. 32 bit x-y planes with 24 bit clip regions do many things quite nicely. 4 Gpixel by 4 Gpixel is a very large plane, 16 Mpixel by 16 Mpixel is still a lot of pixels to scale down to a 2 kpixel by 1 kpixel display or a 2.4 Mpixel by 3.3 Mpixel printer. Of course if you do not have to send 6.9 Mpixel to the printer, printing may well be faster. >>>>The only sorta-platform independent language I know of that does graphics >>>>and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 8 lines] > >Hence the use of floating-point math for everything? Not at all, it has 32-bit signed integers as well. >>>> The only sorta-platform independent language I know of that does graphics >>>> and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 7 lines] > > Hence the use of floating-point math for everything? As I've said here before, PostScript is FORTH with FP & graphics. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>>> The only sorta-platform independent language I know of that does graphics >>>>> and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 9 lines] > >As I've said here before, PostScript is FORTH with FP & graphics. WRONG! They are both stack oriented languages but that is the limit of their similarity. >>>>>> The only sorta-platform independent language I know of that does graphics >>>>>> and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 10 lines] > WRONG! They are both stack oriented languages but that is the limit > of their similarity. Bullshit. Pick any standard FORTH command - it works under PS. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>>>>> The only sorta-platform independent language I know of that does graphics >>>>>>> and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 12 lines] > >Bullshit. Pick any standard FORTH command - it works under PS. OK "." >>>>>>>> The only sorta-platform independent language I know of that does graphics >>>>>>>> and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 12 lines] > > OK "." Try it over serial link to a PS printer - it'll work. Of course you'll have to put something on the stack first. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>>>>>>> The only sorta-platform independent language I know of that does graphics >>>>>>>>> and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 15 lines] >Try it over serial link to a PS printer - it'll work. Of course you'll >have to put something on the stack first. Now that is a shame. I do not happen to have any postscript printers. Maybe i can try ghostscript, if i can figure how to run it as an interpreter application. Funny i do not remember finding "." as any kind of operator or function in postscript. Since you are much more familiar with postscript perhaps you can refer me to where in the PLRM is discussed. >>>> Bullshit. Pick any standard FORTH command - it works under PS. >>> [quoted text clipped - 9 lines] > familiar with postscript perhaps you can refer me to where in the PLRM > is discussed. "." isn't a predefined PostScript operator. More generally, the only symbolic operators in PostScript are: [ ] << >> = == [ { and } are language syntax rather than names.] Everything else uses alphabetic names, e.g. the arithmetic operators are named add, sub, mul, and div, the relational operators are named eq, ne, lt, gt, le, and ge, and so on. >>>>> Bullshit. Pick any standard FORTH command - it works under PS. >>>> [quoted text clipped - 21 lines] >named add, sub, mul, and div, the relational operators are named eq, ne, >lt, gt, le, and ge, and so on. That matches what i got from a very partial reading of the PLRM. I did pick up that there is some kind of name to user defined function association thing but it never became clear in my cursory browsing. Nor do i get the multiple stacks yet. >>Everything else uses alphabetic names, e.g. the arithmetic operators are >>named add, sub, mul, and div, the relational operators are named eq, ne, [quoted text clipped - 4 lines] > association thing but it never became clear in my cursory browsing. > Nor do i get the multiple stacks yet. The main ones are the operand stack (i.e. "the stack"), and the dictionary stack. The operand stack is reasonably obvious; values are pushed onto the stack, operators pop their arguments from the stack and push their results onto it. The dictionary stack determines the scope of names. Whenever the interpreter needs to evaluate a name, it looks it up in the topmost dictionary on the dictionary stack. If the lookup fails, it tries the next one down, and so on until it either finds a match or it exhausts the stack (at which point you get an "undefined" error). If you bind a name with "def", it is added to the topmost dictionary on the stack. At startup, there are two dictionaries on the stack: systemdict at the bottom and userdict at the top. The standard operators are defined in systemdict, which is read-only; userdict is where any user-defined bindings go (unless additional dictionaries are pushed onto the dictionary stack). For complex functions, it's often simpler to start by pushing a new dictionary onto the stack so that you can associate names with parameters and intermediate results, rather than having to manipulate the operand stack explicitly with dup, index, roll, etc. Using a new dictionary ensures that you don't accidentally trash any bindings which were being used by the caller; you just pop it off when you're done with it. The other important stacks are the VM stack (the save and restore operators save and restore the state of composite values such as arrays and dictionaries) and the graphics stack (gsave and grestore save and restore the state of the graphics engine, which allows elements of the page to be encapsulated so that any state changes within each element don't affect subsequent elements). >>>Everything else uses alphabetic names, e.g. the arithmetic operators are >>>named add, sub, mul, and div, the relational operators are named eq, ne, [quoted text clipped - 24 lines] >bindings go (unless additional dictionaries are pushed onto the >dictionary stack). Crickey, that is more like a list than a stack. >For complex functions, it's often simpler to start by pushing a new >dictionary onto the stack so that you can associate names with parameters [quoted text clipped - 9 lines] >page to be encapsulated so that any state changes within each element >don't affect subsequent elements). Well the insight in how to use the stacks is notably missing from the PLRM. >>The dictionary stack determines the scope of names. Whenever the >>interpreter needs to evaluate a name, it looks it up in the topmost [quoted text clipped - 10 lines] > > Crickey, that is more like a list than a stack. It's modified as a stack (i.e. dictionaries are pushed onto and popped off the top of the stack) and searched as a list. The end result is equivalent to a dynamically-scoped language. > Well the insight in how to use the stacks is notably missing from the > PLRM. The way that names are resolved is documented. It's up to the programmer as to how (or whether) to make use of the dictionary stack. >>>>>> Bullshit. Pick any standard FORTH command - it works under PS. >>>>> OK "." [quoted text clipped - 7 lines] >>> is discussed. >> "." isn't a predefined PostScript operator. My mistake. That operator is named '=' in PS. Eg: 1 2 3 add add = will print '6' to your terminal. >> More generally, the only symbolic operators in PostScript are: >> [quoted text clipped - 9 lines] > did pick up that there is some kind of name to user defined function > association thing but it never became clear in my cursory browsing. FORTH & PS work by building new words out of existing ones & slapping a name on them. Eg (under Ghostscript): /addsix {6 add =} def ...creates a new function named 'addsix' that adds 6 to whatever number is on the top of the stack & outputs it to your terminal, so: > Nor do i get the multiple stacks yet. The operand & execution stacks work the same way that they do in other languages, it's just that they're split into separate stacks. The only 'new' one is the dictionary stack. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>>>>> Bullshit. Pick any standard FORTH command - it works under PS. >>>>>> OK "." [quoted text clipped - 31 lines] >...creates a new function named 'addsix' that adds 6 to whatever number >is on the top of the stack & outputs it to your terminal, so: I never had an issue with the well known property that both of them are stack languages. I took issue with the idea that FORTH code could be run on a PS system unmodified. Nor did i ever contend that anything you can say in FORTH could not be said in PS. The converse may be true however. >> Nor do i get the multiple stacks yet. > >The operand & execution stacks work the same way that they do in other >languages, it's just that they're split into separate stacks. The only >'new' one is the dictionary stack. I rather think representing graphics operations in a stack is new as well. Now what was that 5th stack? > On Mon, 06 Jul 2009 20:33:27 +1000, Bob Larter <bobbylarter@gmail.com> > [quoted text clipped - 12 lines] > I rather think representing graphics operations in a stack is new as > well. Now what was that 5th stack? Somehow, this reminds me of the PDP-11; it had 16 general-purpose registers that could be used as stack pointers. (or accumulators, indexes, whatever you could use a register for.) Cheers! Rich >>> Nor do i get the multiple stacks yet. >> [quoted text clipped - 4 lines] > I rather think representing graphics operations in a stack is new as > well. Now what was that 5th stack? There are 3 stacks which are explicitly presented as such: the operand stack, dictionary stack, and execution stack. The last one corresponds to "the stack" in more typical languages, and is seldom referenced directly by the program. In addition to the 3 explicit stacks, the VM state and graphics state can be saved and restored, which implies a stack. However, there is no way to access these stacks as such, i.e. you can't determine the stack depth, or access intermediate frames. >>>>>>>>>> The only sorta-platform independent language I know of that does graphics >>>>>>>>>> and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 17 lines] > Maybe i can try ghostscript, if i can figure how to run it as an > interpreter application. If you run it from a commandline, that should work. > Funny i do not remember finding "." as any > kind of operator or function in postscript. Since you are much more > familiar with postscript perhaps you can refer me to where in the PLRM > is discussed. Section 3.8.5. And the operator is renamed '=' instead of '.', which I'd forgotten, but it does the same thing. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>The only sorta-platform independent language I know of that does graphics >>>and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 6 lines] >It makes PIC assembler look intuitive. PostScript was designed to minimise >the burden on the interpreter, not the programmer. I think not. Browse the manual a bit. You may learn something. >>>>The only sorta-platform independent language I know of that does graphics >>>>and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 8 lines] > > I think not. Browse the manual a bit. You may learn something. I don't need a recap; I still maintain a couple of packages which print by feeding PostScript to lpr. No-one uses RPN because it's user-friendly (it isn't), but because it's simple to implement. It's no surprise that RPN never took off outside of contexts where minimalism was a priority (calculators, printers, OpenBOOT, embedded systems generally). RPN doesn't need a parser, only a tokeniser, as the format is simply a linear sequence of tokens. While [...] (array) and <<...>> (dictionary) may look like nesting constructs, they aren't. "[" and "<<" are operators which push a mark onto the operand stack. "]" and ">>" are operators which pull everything from the stack until the first mark. PostScript will happily accept any of "[1 2 3]", "<<1 2 3]" and "mark 1 2 3]" to define an array. {...} (executable array) *is* a nesting construct. However, as it's the only one, implementing it is a matter of a single variable to track the current nesting level; "{" increments, "}" decrements. If the nesting level is non-zero, execution is suppressed. No recursion or parse stack required. >>> The only sorta-platform independent language I know of that does graphics >>> and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 5 lines] > > It makes PIC assembler look intuitive. Oh, steady on! - It's not *that* bad! > PostScript was designed to minimise > the burden on the interpreter, not the programmer. True, but it's no harder to cope with than an RPN calculator, & I'm sure that most people here would have no trouble with one of those. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >> PostScript was designed to minimise >> the burden on the interpreter, not the programmer. > > True, but it's no harder to cope with than an RPN calculator, & I'm sure > that most people here would have no trouble with one of those. Not for simple arithmetic, but it starts to get awkward if you're writing a non-trivial piece of software. It's probably not so bad if you use either PostScript or Forth day in, day out, but I find that I end up having to put a comment describing the current stack contents between every line of code. That, and having every non-trivial function store its arguments in a dictionary so that I can reference them by name. >>> PostScript was designed to minimise >>> the burden on the interpreter, not the programmer. [quoted text clipped - 9 lines] > non-trivial function store its arguments in a dictionary so that I can > reference them by name. It's not a problem if you're used to doing things the FORTH way. The trick is to build low level functions into words, test them thoroughly, then put them together to make your app. If you're used to languages like C, it's true that it's a difficult hurdle to jump. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>> The only sorta-platform independent language I know of that does graphics >>>> and such is Java. And it's slow. More importantly, it requires gui [quoted text clipped - 13 lines] >True, but it's no harder to cope with than an RPN calculator, & I'm sure >that most people here would have no trouble with one of those. Have you tried it? The PLRM is good to go to sleep by. >>>>> ftp://66.117.156.8/GR8.jpg >>>>> The imperfections simulate the effects of finite-bandwidth deflection [quoted text clipped - 22 lines] > > http://www.adobe.com/devnet/postscript/pdfs/PLRM.pdf Great for printed graphics, less useful for on-screen graphics. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- > How many lines of code is that, John? > [quoted text clipped - 3 lines] > such as wxGTK or wxPython, and "just making a stupid plot" tends to > consume a lot more code than one might expect. MatPlotLib (matplotlib.sourceforge.net) seems to have become the standard plotting library for Python. NumPy and SciPy (scipy.org) are also useful tools. But if you're cobbling together a program for a specific task and for personal use, the optimal language is usually whichever one you're most fluent in. >>>>>>>PowerBasic (the console compiler version) has a couple of nice >>>>>>>built-in PARSE commands. [quoted text clipped - 13 lines] >>That's fine if you never reuse code. Just wonderful if you write >>everything from scratch and never use third party code libraries. >.NET is hardly a universal, portable platform. If all you write is >text-mode ANSI C, sure, it's fairly portable... as long as you keep >your ints and longs and stuff under control. >>I've got better things to do than write a doubly linked list package for >>the hundreth time. I'd rather have a language where I can use >>libraries to do the work use use code examples from others. >As an engineer, I'm more interested in number crunching, simulation, >graphics, generating embedded code images, stuff like that. There are >a few nice collections of Basic subroutines around - curve fitting, >FFTs, stuff like that - so I don't always write everything from >scratch. And I do often reuse code. >I haven't used a linked list in decades. PCs are so fast these days >you can waste enormous numbers of cycles on brute-force methods, like >linear searching, to save programming time. >PowerBasic has a blinding fast SORT command, too. The built-in TCP/IP, >graphics, string functions, all that stuff, are easy to use... and >have excellent HELP a keystroke away. The help you get with a lot of C >libraries is "read the source." >Here's a simulation of a vector character generator used in a retrofit >for the C130 heads-up display, coded in PowerBasic. The actual product >is a VME module that does most of the real work in an FPGA. >ftp://66.117.156.8/GR8.jpg >The imperfections simulate the effects of finite-bandwidth deflection >amplifiers. Works great. Too bad it's throwaway code. >>>>>>>>PowerBasic (the console compiler version) has a couple of nice >>>>>>>>built-in PARSE commands. [quoted text clipped - 47 lines] > >Too bad it's throwaway code. It's not. I'm still running PB/Dos programs I wrote 15 years ago. If I ever need to run this HUD simulator in the next 15 years, I don't expect to have a lot of difficulty. You dislike Basic on purely emotional grounds. I like it because it gets engineering done. People use all sorts of stuff to do engineering... Excel, Matlab, Spice, Sonnet, Maple, Mathematica... even LabView. Jillions more. None are especially portable. John >>Hah. Interpreters rule. Unbeaten for debugging, especially for the >>range of constructs you can reconstruct on-the-fly. [quoted text clipped - 5 lines] > > I use python when I want to use an interpreted language. Okay language, lots of features, large userbase. Its main drawback is that it's slower than a heavily-sedated snail. Proprietary extensions aren't really an issue when there's only ever likely to be one implementation. Other than having a larger user base, it doesn't really seem to have any advantages over Lisp. For quick computation and data-processing tasks, I'd pick Haskell, but that's only an option if you can operate outside of the imperative paradigm. That's likely to be an issue for EEs, as embedded programming tends to be heavily state-oriented. >Its main drawback is that >it's slower than a heavily-sedated snail. These sort of expressions are the things I love about learning English on Usenet. LOL I hope that expression is not copyrighted, I may want to use it some day. > Okay language, lots of features, large userbase. Its main drawback is that > it's slower than a heavily-sedated snail. Aw, c'mon, if you think Python is slow, try Ruby! :-) > Other than having a larger user base, it doesn't really seem to have any > advantages over Lisp. Lisp tends to make most people turn tail and run away screaming :-) ... Python is a lot "friendlier" as a first language, but I'd agree with you that, sure, Lisp is just as good as Python... at least for straight "algorithmic" programming. This is kinda like Ubuntu Linux vs. all the other distributions... they're really all largely the same at the core, but "presentation" means a lot -- particularly to new users. I'd like to see a high-level language similar to Python become a popular choice for embedded programming... these days it still tends to be either C or various proprietary flavors of BASIC. I suppose some of this is driven by how little RAM many microcontrollers have (e.g., many Atmel AVRs now have >64kB of flash ROM by <4kB of RAM... ouch!) ---Joel > I'd like to see a high-level language similar to Python become a popular > choice for embedded programming... these days it still tends to be either > C or various proprietary flavors of BASIC. I suppose some of this is > driven by how little RAM many microcontrollers have (e.g., many Atmel AVRs > now have >64kB of flash ROM by <4kB of RAM... ouch!) High-level languages tend to require a fairly substantial run-time infrastructure, which tends to make them a poor fit for the lower-end of embedded programming. Even C is too high-level for a lot of the things you might want to do on a PIC10/12; if you're using instruction cycles for timing, there isn't really much choice but assembler. Also, dynamic memory allocation (especially with garbage collection, but even without it) doesn't fit well with real-time programming. At the higher end (e.g. mobile phones with an ARM, a few MB of RAM/flash and a full OS), Java seems to be the most popular choice, particularly with many of the ARM variants having hardware support for executing Java bytecode directly. > High-level languages tend to require a fairly substantial run-time > infrastructure, which tends to make them a poor fit for the lower-end of > embedded programming. Yeah, but even 16kB of flash ROM and an equal amount of RAM can get quite a lot done. It seems to me that it's the highly unequal ratio we now see between flash ROM and RAM that makes many high-level languages difficult to implement. > Even C is too high-level for a lot of the things you > might want to do on a PIC10/12; if you're using instruction cycles for > timing, there isn't really much choice but assembler. Well, if you're doing something that really needs speed or tight timing, I agree, assembly is the way to go (at least if you don't have any programmable logic around to make things "really hard" :-) ) -- and usually it's not that hard to mix and match C or BASIC with an HLL. At times it just seems like we've regressed a bit in terms of how much we can accomplish on a given piece of hardware, even with a HLL... take a look at some of the old "handheld computers" from the 1980s, e.g., http://www.rskey.org/detail.asp?manufacturer=Casio&model=PB-2000C (32kB RAM, runs interpreted C or assembly) or even http://www.rskey.org/detail.asp?manufacturer=Casio&model=FX-795P (16kB RAM, runs BASIC). Or even the "early advanced" HP calculators, like the HP 28s -- 128kB ROM, 32kB RAM -- incredibly powerful for its day. ---Joel >> High-level languages tend to require a fairly substantial run-time >> infrastructure, which tends to make them a poor fit for the lower-end of >> embedded programming. > > Yeah, but even 16kB of flash ROM and an equal amount of RAM can get quite a > lot done. You aren't going to be able to run Python in that ;) > It seems to me that it's the highly unequal ratio we now see > between flash ROM and RAM that makes many high-level languages difficult to > implement. No, just the numbers really. High-level languages are designed for desktop and server systems. As RAM has increased from a few megabytes through hundreds of megabytes into gigabytes, software has followed suit. No-one is going to worry if the interpreter uses a megabyte before it even gets to printing "hello, world". >> Even C is too high-level for a lot of the things you might want to do >> on a PIC10/12; if you're using instruction cycles for timing, there [quoted text clipped - 8 lines] > RAM, runs BASIC). Or even the "early advanced" HP calculators, like the > HP 28s -- 128kB ROM, 32kB RAM -- incredibly powerful for its day. But by today's standards, BASIC and C are both low-level languages. BASIC has int, float, string, and arrays thereof, C has int, float, struct and array (strings are just arrays of 8-bit ints). Modern HLLs have lists, tuples, dictionaries, objects (OOP), functions as data values, closures, continuations, iterators, arbitrary-precision arithmetic. To put it in perspective: the megabyte of RAM that a modern HLL might use probably costs less than 16K did in the 1980s. If (say) $20-worth of RAM was a reasonable amount to use back then, why isn't it reasonable now? > You aren't going to be able to run Python in that ;) Yeah, but if I rip out all the introspection and class-based stuff, then I can. I suppose at that point I've severely crippled the language, though. :-) > No, just the numbers really. High-level languages are designed for desktop > and server systems. As RAM has increased from a few megabytes through > hundreds of megabytes into gigabytes, software has followed suit. No-one > is going to worry if the interpreter uses a megabyte before it even gets > to printing "hello, world". But years ago "hello, world" *didn't* take up a megabyte, even in C (and C's at a disadvantage in that most people would use printf -- which is large -- and that would tend to pull in all of stdio and stdlib, which are large... languages that at least had basic I/O built-in such as Pascal would do better, I'd think). Here's a quick list, stolen from http://mbishop.esoteriq.org/hellosize.html: a.. Ada - 19K b.. Asm - 432B c.. C - 8.9K d.. C++ - 9.5K e.. C# - 11K f.. Common Lisp - 25MB g.. D - 230K h.. F# - 11K i.. Fortran - 9.3K j.. Haskell - 358K k.. Java - 12K l.. Modula-3 - 11K m.. Oberon-2 - 13K n.. Objective-C - 8.9K o.. OCaml - 121K p.. Pascal - 107K q.. Scheme - 15K r.. Standard ML - 166K C is doing quite well there -- so is Objective-C, for that matter. ---Joel >> You aren't going to be able to run Python in that ;) > [quoted text clipped - 37 lines] > >---Joel Power Basic console compiler: 6.5K EXE file, no RTS. That's including a SLEEP statement so you can see it. John >>> You aren't going to be able to run Python in that ;) >> [quoted text clipped - 37 lines] >> >>---Joel >Power Basic console compiler: 6.5K EXE file, no RTS. That's including >a SLEEP statement so you can see it. That's just wonderful if one line programs are all you can manage. I'd be far more interested in the bytes/line for a typical 10,000 line application. >>>> You aren't going to be able to run Python in that ;) >>> [quoted text clipped - 45 lines] >I'd be far more interested in the bytes/line for a typical 10,000 line >application. Ny heads-up display simulator only took 464 lines. I have no idea how much it might have taked in C or whatever. We recently rewrote our old DOS material control system in PBCC. Here's one screen... ftp://jjlarkin.lmi.net/MAX.jpg It's a single program, 17901 lines (including whitespace and comments), compiles to a 416 kbyte EXE file. Compile takes 1.7 seconds. Runtime is a lot bigger, since we read the entire parts data base (about 5000 parts now) into a memory array at startup, and build/sort a few other arrays. This uses brute-force linear string compares for user 'search' commands, as opposed to some database thing. It's done before you can let go the <enter> key. PowerBasic does have the BLOAT command... http://www.powerbasic.com/support/help/pbcc/_bloat_metastatement.htm John "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > Runtime is a lot bigger, since we read the entire parts data base > (about 5000 parts now) into a memory array at startup, and build/sort > a few other arrays. I believe you typical IT guy would disallow such software on the grounds that it can't readily grow to 5,000,000 parts, so clearly you aren't "planning for the future." :-) > "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > > Runtime is a lot bigger, since we read the entire parts data base [quoted text clipped - 4 lines] > it can't readily grow to 5,000,000 parts, so clearly you aren't "planning for > the future." :-) Then again, John might not plan on having any IT types around. :) SignatureYou can't have a sense of humor, if you have no sense! >> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >> > Runtime is a lot bigger, since we read the entire parts data base [quoted text clipped - 6 lines] > > Then again, John might not plan on having any IT types around. :) I recently hired our first official Software Engineer. Up to now, various engineers programmed as needed. He's very good - does some good hobby-level electronics already - and really wants to learn more about hardware. We're going to let him do a pc board, layout and all, by himself. Rare animal. Still scary, though, letting the software culture into our shop. John > >> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > >> > Runtime is a lot bigger, since we read the entire parts data base [quoted text clipped - 14 lines] > > Still scary, though, letting the software culture into our shop. No kidding. We had a half dozen programmers at Microdyne. They had to be separated from everyone else in the complex. I always found it quite odd that any decent tech or engineer can remember the details on dozens of products, but most programmers can't remember anything from the last program they completed. My guess is that real engineering requires real logic, and most programmers just fake it. SignatureYou can't have a sense of humor, if you have no sense! >PowerBasic does have the BLOAT command... > >http://www.powerbasic.com/support/help/pbcc/_bloat_metastatement.htm Good business decision. >> PowerBasic does have the BLOAT command... >> >> http://www.powerbasic.com/support/help/pbcc/_bloat_metastatement.htm > > Good business decision. <checks it out> Oh, that's excellent. ;^) SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>>> You aren't going to be able to run Python in that ;) >>>> [quoted text clipped - 71 lines] > >John A software company with a sense of humor. > > You aren't going to be able to run Python in that ;) > [quoted text clipped - 37 lines] > > ---Joel How about for Microsoft SQL Server? I'd looove to migrate my SQL Server code in VBA to C. Any ideas? Michael >How about for Microsoft SQL Server? > >I'd looove to migrate my SQL Server code in VBA to C. Any ideas? > >Michael I use PostgresQL, IIRC it is written in C. And I use PhpPgAdmin as frontend (written in php). Who needs MS SQL server? The whole source is small: -rw-r--r-- 1 root root 11609501 2006-05-24 11:20 postgresql-8.1.4.tar.bz2 Here is some more info on their site: http://www.postgresql.org/about/ Runs on MS windows too it seems. Did you by any chance *pay* anything for the MS SQL thing? > On a sunny day (Tue, 9 Jun 2009 16:00:51 -0700 (PDT)) it happened > mrdarr...@gmail.com wrote in [quoted text clipped - 16 lines] > Runs on MS windows too it seems. > Did you by any chance *pay* anything for the MS SQL thing? Our data are hosted by MS SQL Server. I didn't personally buy it - my department did, from various outside contractors. If I told you the full story your eyes would burn out in horror. Michael >> On a sunny day (Tue, 9 Jun 2009 16:00:51 -0700 (PDT)) it happened >> mrdarr...@gmail.com wrote in [quoted text clipped - 22 lines] > >Michael Databases can be problematical. Lots of big organizations have been pitched into chaos for a year or so by signing up with Oracle. John On Jun 10, 8:53 am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > >> On a sunny day (Tue, 9 Jun 2009 16:00:51 -0700 (PDT)) it happened > >> mrdarr...@gmail.com wrote in [quoted text clipped - 27 lines] > > John Ah, Oracle. We may go there yet. Michael >On Jun 10, 8:53 am, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 33 lines] > >Michael One of my biggish customers, in one annual report, notes that "we have almost recovered from the Oracle conversion." Occasionally I get their ECOs and they make absolutely no sense; they don't seem to understand them either. Wasn't it Oracle that trashed HP server deliveries for about 6 months? John >>On Jun 10, 8:53 am, John Larkin >><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 38 lines] >ECOs and they make absolutely no sense; they don't seem to understand >them either. AIUI, our part number and ECO tracking software company has been bought out by Oracle so some day we'll have to migrate over. It's a mess now so I can only imagine what an adventure of Titanic proportions that'll be. >Wasn't it Oracle that trashed HP server deliveries for about 6 months? > >John >>>On Jun 10, 8:53 am, John Larkin >>><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 43 lines] >mess now so I can only imagine what an adventure of Titanic >proportions that'll be. We did our own materials control software, and track ECOs essentially manually. But we're small... about 5000 different parts, 2e6 pieces, and 660 ECOs in the last 20 years. John >>>>On Jun 10, 8:53 am, John Larkin >>>><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 47 lines] >manually. But we're small... about 5000 different parts, 2e6 pieces, >and 660 ECOs in the last 20 years. We're pretty small too. 100 employees, mostly on the business side (sales, marketing, BS), and perhaps 20 or 30 in production. Only seven engineers (two hardware, one mechanical, one layout, and three firmware). Parts? Never counted them, but it's likely not a lot more than that. Our latest ECO number was something like just over 1000 (A RoHS part substitution on a non-RoHS product - just signed off on it). There is no way the owner would allow the business to be run on a cobbled together program. I'm not sure what we have is any better though. In theory it does all the production stuff (BOM control, deviations, etc.) It doesn't link the purchasing database and that's always an amazement (why on Earth did we buy 15000 audio transformers or 6000 wall warts, that we may never use?). >>>>>On Jun 10, 8:53 am, John Larkin >>>>><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 58 lines] >no way the owner would allow the business to be run on a cobbled >together program. Our system isn't cobbled together. We designed it to do exactly what we want. It's a joy to drive. I can search for a part by keywords, see the search results, pop into the full inventory list with starting point from any of the search results. I can select a part and see all the assemblies it's used on. I can select a parts list, see total parts cost, highlight any one part, and pop back into the inventory or where-used bit. Every part can, usually does, have an attached folder with datasheets, photos, engineering notes, anything useful we want to know. The part numbers are very, very logical and organized, as are the description fields. And it's blindingly fast. ftp://jjlarkin.lmi.net/MAX.jpg I'm not sure what we have is any better though. In >theory it does all the production stuff (BOM control, deviations, >etc.) It doesn't link the purchasing database and that's always an >amazement (why on Earth did we buy 15000 audio transformers or 6000 >wall warts, that we may never use?). That's a separate problem. Somebody probably observed 1) we'll sell tons of these and 2) look how good the 10K price is! One search param we have is called BigBux: type a dollar value, and it shows all the parts that we have that many dollars or more of. This invokes the occasional WTF?! reaction. It also catches the situations where somebody typoed the price of a reel of resistors as $12 instead of $0.012 each. John >>>>>>On Jun 10, 8:53 am, John Larkin >>>>>><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 68 lines] >with datasheets, photos, engineering notes, anything useful we want to >know. Our engineering management tools to everything above. The search isn't linear, though. ;-) >The part numbers are very, very logical and organized, as are the >description fields. [quoted text clipped - 11 lines] >That's a separate problem. Somebody probably observed 1) we'll sell >tons of these and 2) look how good the 10K price is! Some of that, but mostly an overly aggressive development schedule. We can't make enough widgets now, so I don't know how the ever expected to sell enough to use the inventory in a reasonable time. Parts sitting on the shelf aren't free, either. >One search param we have is called BigBux: type a dollar value, and it >shows all the parts that we have that many dollars or more of. This >invokes the occasional WTF?! reaction. It also catches the situations >where somebody typoed the price of a reel of resistors as $12 instead >of $0.012 each. ;-) There is a field in the database for projected cost, but it's not linked to the purchasing system so it's rarely filled in. Kinda makes *engineering* difficult. I just demanded that they order a reel of AD8566s. For the project I only need about 1K parts but the cut tape price (DigiKey) was over 3X the full reel price (Arrow). ...so I designed out another part since the 8566s were free. ;-) >>> On a sunny day (Tue, 9 Jun 2009 16:00:51 -0700 (PDT)) it happened >>> mrdarr...@gmail.com wrote in [quoted text clipped - 27 lines] > >John My PPoE is in its third year of chaos from having done that. Three to five more years before all the old CODASYL databases are migrated. > > On a sunny day (Tue, 9 Jun 2009 16:00:51 -0700 (PDT)) it happened > > mrdarr...@gmail.com wrote in [quoted text clipped - 20 lines] > department did, from various outside contractors. If I told you the > full story your eyes would burn out in horror. Then tell Sloman. No one would miss him. SignatureYou can't have a sense of humor, if you have no sense! >> On a sunny day (Tue, 9 Jun 2009 16:00:51 -0700 (PDT)) it happened >> mrdarr...@gmail.com wrote in [quoted text clipped - 22 lines] > >Michael Can't speak for Jan, of course i use only premium horror resistant eyes and have an auto changer system as well, 20 seconds down time max. And i never look at that kind of thing other than seated decently in a chair in a familiar room. > >> On a sunny day (Tue, 9 Jun 2009 16:00:51 -0700 (PDT)) it happened > >> mrdarr...@gmail.com wrote in [quoted text clipped - 28 lines] > And i never look at that kind of thing other than seated decently in a > chair in a familiar room. Ok, try this on for size. Software contractor was tasked with writing completeness checks for the data, but somehow never got around to it over the years. Low priority, I guess. In exasperation, my boss asks me to look into it. I'd taken a few MS Access classes, but my degree is in Chemical Engineering. Eh, I'll give it a shot. A couple of days later, we have working MS Access/VBA code that compares the contractor's work with what we want for the day. (This is for process data: pressures, flowrates, water levels, etc. About 80 locations per day.) Boss asks me to do the same for the chemistry data. A few days later, sure, we've got it. A bit more complex (chemistry data is stored on a LIMS system, and there's about a 1 month delay between the sample collection time and the time the lab uploads the data), but it works. Better than nothing. Software contractor likes it, wants my code so they can make it available online. Sure, fine, whatever. Here you go. Software contractor gives me a box: Visual Studio 2005. Oh, but our IT department doesn't want anyone doing programming except for them. That includes the engineers. Oh, and no workers have Admin rights. Including engineers. So the box goes to waste. We have a meeting with the IT supervisors. They say, sure, no problem, they can do anything we want. Only, they do work in ColdFusion, not HTML/PHP/SQL Server. Oh, and take a number, get in line - maybe a month from now they'll get to what we want done. Oh, and write out the work spec in 5 pages or less. Dude. I can do it myself in minutes, with direct access to the database (which I have). Or send an email to our software contractor, who usually gets it done. D'oh. Michael >> >> On a sunny day (Tue, 9 Jun 2009 16:00:51 -0700 (PDT)) it happened >> >> mrdarr...@gmail.com wrote in [quoted text clipped - 66 lines] > >Michael I read it the first pass and said to my self, i better read between the lines. The consultant could afford to be generous, you accomplished 6 months of their work in 6 days. That sounds a lot like the crazy gyrations i went through to publish to the design people the space qualified parts data bases. Complete with the IT department who wanted to do it in CODASYL databases and charge about 4 person years for it. I piled kludge on kludge until i got something that was just barely acceptable in 6 months by myself. > How about for Microsoft SQL Server? > > I'd looove to migrate my SQL Server code in VBA to C. Any ideas? can VBA call DLLs? C can be used to write DLLs. what sort of things are you doing in VBA that you want to do in C? It's fairly easy to do stuff to postgresql in C C is one of the many languages available for writing stored procedures. bad C can shoot your database in the foot. > > How about for Microsoft SQL Server? > [quoted text clipped - 7 lines] > C is one of the many languages available for writing stored procedures. > bad C can shoot your database in the foot. Not sure if VBA can call DLLs. I'm still a beginner at this. We do completeness checks on the database. Simplified, we compare what the contractor does with what we expect for the day (week, month, semi-annual period). Findings are dumped to Excel spreadsheets. Any holes mean missing data, and we send the contractor a nastygram asking them to fix it (or dock their pay). Michael >>> How about for Microsoft SQL Server? >>> I'd looove to migrate my SQL Server code in VBA to C. Any ideas? [quoted text clipped - 7 lines] > > Not sure if VBA can call DLLs. It can. I wrote a VB app to pull data from a Borland C++ DLL which ran a laser-scanning confocal microscope back in '95 or so. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >> You aren't going to be able to run Python in that ;) > [quoted text clipped - 35 lines] > r.. Standard ML - 166K > C is doing quite well there -- so is Objective-C, for that matter. Nearly all of that is due to the particular languages implementation of its equivalent to printf+io.h. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- > Nearly all of that is due to the particular languages implementation of its > equivalent to printf+io.h. For some of them, sure... but 25MB in LISP!? Just to print "hello, world!?" C'mon... Even Pascal, at 107k -- more than 10x what C requires -- is pretty embarassing. >> Nearly all of that is due to the particular languages implementation of its >> equivalent to printf+io.h. > >For some of them, sure... but 25MB in LISP!? Just to print "hello, world!?" >C'mon... Even Pascal, at 107k -- more than 10x what C requires -- is pretty >embarassing. It's an interpreter. John >>> Nearly all of that is due to the particular languages implementation of its >>> equivalent to printf+io.h. [quoted text clipped - 3 lines] > > It's an interpreter. Not necessarily. Lisp compilers date back to the 1980s - I worked on one. They were among the earliest incremental compilers. I cannot recall exactly what the Procyon Common Lisp compiler for the Mac made of "Hello World" but it would probably have been under 100kb. WCL on a SPARC manages it in about 40kb. See for example: http://www.ai.sri.com/~delacaze/alu-site/alu/table/systems.htm And there were Lisp implementations on the BBC Micro that had to fit into the 64kb address space of the puny 6502. Regards, Martin Brown "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > It's an interpreter. Fair point. Turbo Pascal wasn't though, as I recall... probably explained some of its popularity... (I even wrote a few little utility programs with it back in the late '80s while playing intern at IBM... IBM had an amazing internal network, that already had lots of internally developed bits of software and documentation, much like what the web is today... albeit all accessed through 3270-series text-mode "smart" terminals!) ---Joel >> Nearly all of that is due to the particular languages implementation of its >> equivalent to printf+io.h. > > For some of them, sure... but 25MB in LISP!? Just to print "hello, world!?" > C'mon... Even Pascal, at 107k -- more than 10x what C requires -- is pretty > embarassing. At that size, my guess is that it's a frozen memory image, containing the interpreter, the program, the data, and a lot of free space which was pre-emptively requested from the OS but isn't actually being used for anything. >> Nearly all of that is due to the particular languages implementation of its >> equivalent to printf+io.h. > > For some of them, sure... but 25MB in LISP!? Just to print "hello, world!?" > C'mon... Even Pascal, at 107k -- more than 10x what C requires -- is pretty > embarassing. Well, now you know why nobody writes apps in LISP. ;^) SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- > Well, now you know why nobody writes apps in LISP. ;^) Next you're going to tell me no one writes apps in SmallTalk either. :-) I think this has been an interesting thread for a lot of people, illustrating the huge range of needs that various people have depending on what they're working on... everything from John's "one file per program, in PowerBasic" to Nobody's "thousands of files in multiple language all at once." ---Joel > I'd like to see a high-level language similar to Python become a popular > choice for embedded programming... these days it still tends to be either C or > various proprietary flavors of BASIC. I suppose some of this is driven by how > little RAM many microcontrollers have (e.g., many Atmel AVRs now have >64kB of > flash ROM by <4kB of RAM... ouch!) Hell, the first machine I programmed (NatSemi SC/MP) had only 256 bytes of RAM, & the first machine I owned had 4KB of RAM, & an MS ROM BASIC in 8KB of ROM. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>Hah. Interpreters rule. Unbeaten for debugging, especially for the >>>range of constructs you can reconstruct on-the-fly. [quoted text clipped - 17 lines] >paradigm. That's likely to be an issue for EEs, as embedded programming >tends to be heavily state-oriented. Eh, maybe. Procedural language is not necessarily a good fit for a state machine, nor for relay ladder logic. How good a fit is Haskell? Can you demonstrate? * >>For quick computation and data-processing tasks, I'd pick Haskell, but >>that's only an option if you can operate outside of the imperative [quoted text clipped - 5 lines] > demonstrate? > * I wasn't suggesting using Haskell for embedded programming, but for "support" tasks, e.g. crunching data. You can use it for imperative programming. There are some cases where it would be better than an imperative language, as you get to define the evaluation semantics. >>>There is a fundamental difference between goto and gosub. It is an >>>important one, subroutine invocation saves time and code space without [quoted text clipped - 15 lines] >Everything with named variables, constructs, code blocks, parameter passing, >if/then/else, case statements, etc. required proprietary extensions. You seem to be confusing typical uP interpreter mid-1980's (tinybasic ala Gates) implementations with the actual original language as defined by its originators. http://www.truebasic.com/ http://en.wikipedia.org/wiki/True_BASIC >>>>There is a fundamental difference between goto and gosub. It is an >>>>important one, subroutine invocation saves time and code space without [quoted text clipped - 15 lines] >>Everything with named variables, constructs, code blocks, parameter passing, >>if/then/else, case statements, etc. required proprietary extensions. >You seem to be confusing typical uP interpreter mid-1980's (tinybasic >ala Gates) implementations with the actual original language as >defined by its originators. Not at all. I'm comparing all the myrid basics over the years. "True basic" was just another proprietary extension. It's silly name didn't mean that anybody else would ever follow suit. Even microsoft has released at least 4 versions incompatible with each other. >>>>>There is a fundamental difference between goto and gosub. It is an >>>>>important one, subroutine invocation saves time and code space without [quoted text clipped - 26 lines] > > Even microsoft has released at least 4 versions incompatible with each other. And that's not counting the GUI, or the non win/dos versions. >>>>>>There is a fundamental difference between goto and gosub. It is an >>>>>>important one, subroutine invocation saves time and code space without [quoted text clipped - 24 lines] >> "True basic" was just another proprietary extension. It's silly name >> didn't mean that anybody else would ever follow suit. I recommend that you take that up with Kemeny and Kurtz, who defined and were the main developers of the old Dartmouth BASIC. True BASIC was their implementation for the PC. The history may interest you, or not. >> Even microsoft has released at least 4 versions incompatible with each other. > >And that's not counting the GUI, or the non win/dos versions. >>>>>> There is a fundamental difference between goto and gosub. It is an >>>>>> important one, subroutine invocation saves time and code space without [quoted text clipped - 23 lines] > > And that's not counting the GUI, or the non win/dos versions. Hell, I grew up up with the MS 8KB ROM BASIC versions, & they're not compatible with *anything*. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>>>>> There is a fundamental difference between goto and gosub. It is an >>>>>>> important one, subroutine invocation saves time and code space without [quoted text clipped - 23 lines] >> >> And that's not counting the GUI, or the non win/dos versions. >Hell, I grew up up with the MS 8KB ROM BASIC versions, & they're not >compatible with *anything*. No two versions of BASIC, even from the same company are compatible. At one point, microsoft even made visual basic incompatible with it's last major release. BASIC is only good for throwaway code. Write it; run it; toss it. Toss anything you learn too. >No two versions of BASIC, even from the same company are compatible. >At one point, microsoft even made visual basic incompatible with it's >last major release. BASIC is only good for throwaway code. Write it; >run it; toss it. Toss anything you learn too. Do I have to give all the money back? John > No two versions of BASIC, even from the same company are compatible. > At one point, microsoft even made visual basic incompatible with it's > last major release. BASIC is only good for throwaway code. Write it; > run it; toss it. Toss anything you learn too. So what's your obsession over throwaway code, anyway? The whole premise of "portable code" is silly to begin with. Yes, C _can_ be written to compile on, say, different compilers and different OSs, but that's just /hiding/ the throwaway bits inside #defines. That's worse than maintaining individual copies of the same source, written specifically for their intended compiler-OS combination, because you have to wade through #ifs, #defines and .h's to find out what the hell is going on. In seperate copies, everything is *there* to see, plain and simple. Between copies, the structure is (presumably) identical, differing only in those key places which would otherwise be #defined, so it's no harder to compare them. By the way, I've had excellent success with the small list of programs I've maintained between QuickBasic and FreeBASIC -qb. There are only small differences; much of the code is directly useful. All the old stuff still works; for instance, you automatically get a text console, and you can open windowed graphics in a single statement. Finally, since code always has to be rewritten to reuse it anyway, what difference does it make what language it's in before you rewrite it? From C to C, or C++, or Java, or to many of the other braces type languages, you might only need to refactor some keywords to make it fit. But when you have to rewrite the whole damn thing, it doesn't make much difference what language it's in -- BASIC, C, Java, etc. all share the same imperative program flow structure, and share much of the same syntax and control statements. The program structure and algorithm flowcharts are identical. Converting BASIC to C is very simple; the standard libraries for both are even fairly similar (too bad BASIC has more powerful libraries!). Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms >> No two versions of BASIC, even from the same company are compatible. >> At one point, microsoft even made visual basic incompatible with it's >> last major release. BASIC is only good for throwaway code. Write it; >> run it; toss it. Toss anything you learn too. >So what's your obsession over throwaway code, anyway? The whole premise of >"portable code" is silly to begin with. Yes, C _can_ be written to compile Sure. Why have standards at all? I really like having to do everything from scratch, not having the ability to leverage anybody else's previous work. Oh, the joy of learning a new language every time I write some code. What better use of my time than having the task of rewriting code to use a new version of a compiler because the compiler writers were too lazy to care about any compatibility with other vendors or even with other versions of their owh compilers. Rewriting page after page of previous code to use a new langage is fun! What I really want is to be permentantly locked into using one vendors particular version. If I have 40,000 lines of QA automation to perform regression testing on a software syhstem, I really want to be locked into using a particular compiler version forever. I don't want to be able to use improved libraries because I want to be locked into some ten year old langauge system. >>> No two versions of BASIC, even from the same company are compatible. >>> At one point, microsoft even made visual basic incompatible with it's [quoted text clipped - 20 lines] >improved libraries because I want to be locked into some ten year old langauge >system. What OS are you working in, that will be invariant for the next 10 years? Is all your i/o plain ascii streams? If you have 40K lines of code to test other code, you must be a programmer. So why you are telling engineers how to design electronics, posting to s.e.d., is a bit obscure. Some people use Excel, some use Mathematica, some use Basic, some do Laplace math on grid paper with pencils. Portability is not an issue if a tool solves an engineering problem and the tool will remain available for as long as needed. If I stick to PowerBasic for engineering apps I don't need to rewrite much. Moving a program from Qbasic to PBCC isn't hard, and I can still run 12 year old Qbasic or compiled PDS Basic programs, and still do. What do you do about a 12-year old Pascal program? Or a 30 year old Fortran program? Do you think that C will be the language of choice 20 years from now? And that all the APIs will be the same? I sure hope not. Basic is older than C and will probably survive it. John >> No two versions of BASIC, even from the same company are compatible. >> At one point, microsoft even made visual basic incompatible with it's [quoted text clipped - 11 lines] > (presumably) identical, differing only in those key places which would > otherwise be #defined, so it's no harder to compare them. You have a lot of misconceptions about what portable code looks like. I regularly write code which works on Windows, MacOSX (x86 & PPC), Linux and Solaris, and the code very rarely uses macros. Dealing with architectural differences is mostly an issue of not making any assumptions about widths of primitive types, byte-order, padding, etc. Stick to what's valid according to the language rather than "this compiler on this CPU behaves like this". For dealing with API differences, I'll just write Unix and Windows versions of key functions, with the different versions in different source files. For the project which is in front of me right now, out of 53 C source files (not including headers), 2 are Unix-specific, 2 are Windows-specific, the other 49 are portable. There are precisely 6 #if[def] directives in the entire code (mostly for platform-specific headers), and no platform-specific macros. > Finally, since code always has to be rewritten to reuse it anyway, It doesn't. It might have to be modified, but that's not the same as rewritten. > what > difference does it make what language it's in before you rewrite it? From C > to C, or C++, or Java, or to many of the other braces type languages, you > might only need to refactor some keywords to make it fit. Or you might (and probably will) need to completely rewrite it. C doesn't have classes, Java doesn't have pointers, or half of C++'s OO features, or many of the libraries available to C/C++ code. C and C++ don't have garbage collection. > But when you have > to rewrite the whole damn thing, it doesn't make much difference what [quoted text clipped - 3 lines] > Converting BASIC to C is very simple; the standard libraries for both are > even fairly similar (too bad BASIC has more powerful libraries!). Except that most BASICs are even more primitive than C: not only no OO, but no structures, unions, pointers, function pointers, dynamic allocation, threads, ... If you're used to BASIC, you won't miss these things, but your code will typically be full of hacks and workarounds (although it won't seem this way until you've programmed in a language with more structure). >>> No two versions of BASIC, even from the same company are compatible. >>> At one point, microsoft even made visual basic incompatible with it's [quoted text clipped - 30 lines] >#if[def] directives in the entire code (mostly for platform-specific >headers), and no platform-specific macros. 53?! All the programs I've done in the last few years have each had one source file. The only exception is embedded things that have one uP code source file and one to four FPGA configuration files, which all get built into one rom image file. John >> Finally, since code always has to be rewritten to reuse it anyway, > [quoted text clipped - 10 lines] >many of the libraries available to C/C++ code. C and C++ don't have >garbage collection. So the only languages that allow 40-year old programs to be simply tweaked to compile and run on modern OSs are Fortran, Basic, and Cobol. 40 years from now, they probably will still be. >> But when you have >> to rewrite the whole damn thing, it doesn't make much difference what [quoted text clipped - 7 lines] >but no structures, unions, pointers, function pointers, dynamic >allocation, threads, ... PowerBasic has all that, except maybe threads. John >>For the project which is in front of me right now, out of 53 C >>source files (not including headers), 2 are Unix-specific, 2 are [quoted text clipped - 6 lines] > uP code source file and one to four FPGA configuration files, which > all get built into one rom image file. Another package which I work on has ~2500 C files, 60 C++ files, 160 Python files and 550 Makefiles, resulting in 350 executables and 50 libraries. And that's not all that large; the numbers are inflated by virtue of it being composed of many small modules. Okay, so this isn't "embedded" software, or even "system" software. But the Linux kernel is both of those, and is far bigger (10,000 C files, 1000 assembler files, although not all files will be used on any particular architecture). At that level, things like structure, abstraction, and the development process matter a lot. You can't rely upon programmers understanding the whole thing, or no-one ever making a mistake (particularly when so much of it is for hardware which is inadequately or inaccurately documented). And testing doesn't help much when much of the bug potential is related to concurrency. >>> what >>> difference does it make what language it's in before you rewrite it? [quoted text clipped - 9 lines] > So the only languages that allow 40-year old programs to be simply > tweaked to compile and run on modern OSs are Fortran, Basic, and Cobol. Not at all. You would have just as many problems converting Fortran, Basic or Cobol to each other or to C, C++ or Java. IOW, the claim of "only need to refactor some keywords" is bogus. >>>For the project which is in front of me right now, out of 53 C >>>source files (not including headers), 2 are Unix-specific, 2 are [quoted text clipped - 16 lines] >assembler files, although not all files will be used on any particular >architecture). Thank you, Lord, that I was born a humble circuit designer. John >> No two versions of BASIC, even from the same company are compatible. >> At one point, microsoft even made visual basic incompatible with it's [quoted text clipped - 17 lines] >works; for instance, you automatically get a text console, and you can open >windowed graphics in a single statement. Yup. Once you work out a scientific algorithm in some Basic, it's easy to tweak it for another dialect of Basic. Easier than converting a program from Fortran to Pascal to C++ to Java. I've converted biggish programs from DEC Basic+ or Qbasic or PDS basic to PowerBasic. The only tricky part is if there's graphics involved, but that's a nuisance in most conversions. >Finally, since code always has to be rewritten to reuse it anyway, what >difference does it make what language it's in before you rewrite it? From C [quoted text clipped - 6 lines] >Converting BASIC to C is very simple; the standard libraries for both are >even fairly similar (too bad BASIC has more powerful libraries!). Libraries? Why use libraries, when any decent language has all the features you need built in? Would you buy a cheap car and add after-market power steering and automatic transmission and air conditioning? John >Libraries? Why use libraries, when any decent language has all the >features you need built in? Would you buy a cheap car and add >after-market power steering and automatic transmission and air >conditioning? > >John Now look who is babbling again! Any idea how many libraires there are in C for anything? Including all that 'in a language' would be impossible. Loading BASIC simply would not fit in your terabyte memory. hehe >Libraries? Why use libraries, when any decent language has all the >features you need built in? Would you buy a cheap car and add >after-market power steering and automatic transmission and air >conditioning? Does your favorite basic have: xml processing? web retrieval routines including the ability to fill out forms, handle all http objects call system functions, connect file I/O w/ pipes, traverse directory trees zipfile/bzip/bzip2 file functions ftp/gopher/imap4/soap/nntp/smtp server access rpc calls email, mime, uu, binhex multimedia handling (audio formats, video formats, etc.) cryptographic functions You got that all built in? You have all that on a platform independant langage so if you want your software to run on say an intel atom, you won't have to learn a whole new environment? And yes, I'd buy a cheap car and put in my own car stereo. And I'd expect that car stereo to be just like the one I put in a different maker's car. I'd also expect that car to work on california roads if I travel there without having to specifically have a proprietary package for california roads or wonder if it'l handle idaho roads too if I pass through. >>Libraries? Why use libraries, when any decent language has all the >>features you need built in? Would you buy a cheap car and add [quoted text clipped - 12 lines] > multimedia handling (audio formats, video formats, etc.) > cryptographic functions I'm an engineer and I design electronics. This is s.e.d. Does your C do transient and frequency-domain circuit simulation? I use LT Spice for that. And I use PowerBasic for engineering calcs and graphics. The graphics are great. PB does do ethernet and tcp/ip easily; I use it to talk to and test our ethernet-version products. It takes one line of code to open a tcp/ip session, one line to send a string, one line to get a string, one line to close. All built in, called with plain English words (like TCP OPEN), all with one-key HELP. PB can also do email, stroll around directory trees, do COM stuff, random access arrays of structs in files, all that. Fill out web forms? I don't do that to design electronics. Zip files? Just shell out to do stuff like that, if you have to, which I don't. One fairly new feature I love is TRY...CATCH. It makes error management easy. When you're writing programs to test production instruments, errors are a big part of the game. > >You got that all built in? All that I need. More, actually. You have all that on a platform independant langage >so if you want your software to run on say an intel atom, you won't have to >learn a whole new environment? Windows won't run on Atom? John >>>Libraries? Why use libraries, when any decent language has all the >>>features you need built in? Would you buy a cheap car and add [quoted text clipped - 44 lines] > >John Oh, just checked. PB has data pointers, function pointers, and can call DLLs and system stuff. Not that I would often want to do any of that. It also has threads and nice thread management tools, which look easy to use and might be interesting in some situations. It does have native string variables, tons of neat string functions, and PRINT USING. Print Using is reason enough to program in PB all by itself. John > I'm an engineer and I design electronics. This is s.e.d. Does your C > do transient and frequency-domain circuit simulation? I use LT Spice > for that. And I use PowerBasic for engineering calcs and graphics. The > graphics are great. John, have you tried FreeBASIC? <http://www.freebasic.net/> And if so, how does it compare to PowerBASIC? SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >> I'm an engineer and I design electronics. This is s.e.d. Does your C >> do transient and frequency-domain circuit simulation? I use LT Spice [quoted text clipped - 4 lines] ><http://www.freebasic.net/> >And if so, how does it compare to PowerBASIC? No, I haven't. This is scary: "When the compiler become stable enough - the actual priority - new optimizations will be added, like common sub-expressions elimination, dead code elimination, register variables, among others." http://www.freebasic.net/index.php/about?section=features PB seems absolutely stable and very well optimized. So far, it has the record for doing my 64M-sample signal averaging thing, 207 millisec, better than any C that's been posted here. The PB folks do actual support, too. Email them a question, and they answer. The documentation/HELP/manual are excellent too. I've noticed that free/open software tends to have abysmal, inarticulate documentation if it has any at all. If I save an hour somewhere, it's worth the price of the paid version. John > The PB folks do actual support, too. Email them a question, and they > answer. The documentation/HELP/manual are excellent too. I've noticed > that free/open software tends to have abysmal, inarticulate > documentation if it has any at all. If I save an hour somewhere, it's > worth the price of the paid version. The online help is actually fairly useful. The compiler seems stable enough for the constructs I've used, which isn't many, but it's not crashing left and right anyway. For professional purposes you'd obviously use a professional piece of software, like PB. Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > > I've noticed > that free/open software tends to have abysmal, inarticulate > documentation if it has any at all. It depends a lot on which package you pick -- Python and wxWidgets (the cross-platform GUI toolkit) both have very good documentation, whereas certainly many packages are pretty spartan when it comes to good documentation. Writing documentation isn't the "fun" part of a project, right? >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > >> I've noticed >> that free/open software tends to have abysmal, inarticulate >> documentation if it has any at all. >It depends a lot on which package you pick -- Python and wxWidgets (the >cross-platform GUI toolkit) both have very good documentation, whereas >certainly many packages are pretty spartan when it comes to good >documentation. >Writing documentation isn't the "fun" part of a project, right? I've noticed the exact opposite. Commercial software has some of the worst documentation, usually no how-to guides, and no help forums. When I see a button titled "wackflimflam", it doesn't do me a whole lot of good if all the online help has "Use this button to wack the flim flam." >>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > >>> I've noticed [quoted text clipped - 13 lines] >When I see a button titled "wackflimflam", it doesn't do me a whole lot of >good if all the online help has "Use this button to wack the flim flam." My other favorite is documentation that describes the exact function that you need, but fails to tell you that it is 3 levels down in the 7th optional toolbar, and requires you to be in a certain one of 4 modes before the options several levels up will even be visible. >>> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > >>>> I've noticed [quoted text clipped - 11 lines] >> When I see a button titled "wackflimflam", it doesn't do me a whole lot of >> good if all the online help has "Use this button to wack the flim flam." Classic MS 'help'. > My other favorite is documentation that describes the exact function > that you need, but fails to tell you that it is 3 levels down in the > 7th optional toolbar, and requires you to be in a certain one of 4 > modes before the options several levels up will even be visible. Photoshop's good for that one. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>> I'm an engineer and I design electronics. This is s.e.d. Does your C >>> do transient and frequency-domain circuit simulation? I use LT Spice [quoted text clipped - 13 lines] > > http://www.freebasic.net/index.php/about?section=features Why do you consider these optimisations scary. They are standard now in modern compilers and whilst a cooperative free software development team might take a while to get it correct they are on the right track. I don't approve of declaring register variables but apart from that ~OK. Dead code elimination and determining paths where variables can be used before initialisation during compilation saves time. Some of the unreachable code lurking in a large project is often unintentional. > PB seems absolutely stable and very well optimized. So far, it has the > record for doing my 64M-sample signal averaging thing, 207 millisec, > better than any C that's been posted here. It isn't at all clear why. The sheer volume of data being moved and limited arithmetic means that the test you posted is very insensitive to the quality of code generation and entirely dominated by the performance of the memory subsystem. It is choking on external resources waiting for data all the time. It would be interesting to see the x86 assembler code that Powerbasic has generated. I do not believe in magic. > The PB folks do actual support, too. Email them a question, and they > answer. The documentation/HELP/manual are excellent too. I've noticed > that free/open software tends to have abysmal, inarticulate > documentation if it has any at all. If I save an hour somewhere, it's > worth the price of the paid version. JPEGLIB has reasonable documentation as does WFFT. Incidentally unless you are very interested in precise determination of very low frequencies you are barking up the wrong tree with a million sample FFT. Regards, Martin Brown >>>> I'm an engineer and I design electronics. This is s.e.d. Does your C >>>> do transient and frequency-domain circuit simulation? I use LT Spice [quoted text clipped - 15 lines] > >Why do you consider these optimisations scary. What's scary is that they haven't done them yet, because the compiler isn't stable yet. They are standard now in >modern compilers and whilst a cooperative free software development team >might take a while to get it correct they are on the right track. I [quoted text clipped - 26 lines] >you are very interested in precise determination of very low frequencies >you are barking up the wrong tree with a million sample FFT. "Unless" indeed. John >>Converting BASIC to C is very simple; the standard libraries for both are >>even fairly similar (too bad BASIC has more powerful libraries!). [quoted text clipped - 3 lines] > after-market power steering and automatic transmission and air > conditioning? Yes, libraries. That's how QB did it- your program is linked (real-time, in the interpreter, or by LINK at compile time) with the library that does everything. BCOM45.LIB 215 KB (220,919 bytes) BCOM45, BQLB45 and BRUN45 are the three built in libraries for whatever. Sadly, because LINK is a library level linker, not a module level linker, a simple Hello World program takes 35kB or so. Come to think of it, a Win32 console app compiled in Watcom C takes about that much, too. YMMV. I don't know how modern BASIC compilers do it. I know generic structures are converted to efficient assembly rather than procedure calls (almost everything in QuickBasic is a CALL, *shudder*!). I would guess the power statements (like, just how much Win32 crap is rolled up into a simple SCREEN 12?) are still compiled in a similar way, although where the 'librariness' shows up may be hidden (my copy of FreeBASIC shows a couple moderately sized executables under /bin, they might have code built in). Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms >>>Converting BASIC to C is very simple; the standard libraries for both are >>>even fairly similar (too bad BASIC has more powerful libraries!). [quoted text clipped - 7 lines] >the interpreter, or by LINK at compile time) with the library that does >everything. Qb compiled to pseudocode, and (I think) every "compiled" program dragged all of the runtime system with it. Sure, most modern compilers have the equivalent of compile-time library linking. But PB has it all in one place, under the hood, not a zillion header and include files. At user level, most operations are language inherents, not sub or API calls. Hit F1 for good HELP, including examples, of anything it can do. It's an ideal programming language for engineers who occasionally have to program. It lets you do most anything. C is 37 years old, and was archaic even by 1972 standards. John >>>>Converting BASIC to C is very simple; the standard libraries for both are >>>>even fairly similar (too bad BASIC has more powerful libraries!). [quoted text clipped - 7 lines] >>the interpreter, or by LINK at compile time) with the library that does >>everything. >Qb compiled to pseudocode, and (I think) every "compiled" program >dragged all of the runtime system with it. >Sure, most modern compilers have the equivalent of compile-time >library linking. But PB has it all in one place, under the hood, not a [quoted text clipped - 3 lines] >language for engineers who occasionally have to program. It lets you >do most anything. >C is 37 years old, and was archaic even by 1972 standards. And BASIC? Want to talk about archaic? A language that doesn't have structured datatypes, doesn't have block statements, can't call subprograms, can't pass parameters to subroutines can is only good for nasty horrible spaghetti code unless you use some proprietary extensions that haven't a prayer of ever working on any other system? At least programs written in C are transportable. All BASIC is good for is throaway code. >>>>>Converting BASIC to C is very simple; the standard libraries for both are >>>>>even fairly similar (too bad BASIC has more powerful libraries!). [quoted text clipped - 26 lines] >spaghetti code unless you use some proprietary extensions that haven't a prayer >of ever working on any other system? Several vendors' BASICs do all the things you named. The thing about Basic is that it's not frozen in time like C is. Modern Basics can and do do all that stuff: structs, CASE, WHILE, TRY, THREAD, formal subs, and great inherents like strings and graphics and SORT. PB has great IDE stuff like execution trace, speed profiling, variable watch, single-step, how-did-we-get-here. >At least programs written in C are transportable. Sure. Just spend a pleasant afternoon porting a .NET app to Linux or Apple, or an embedded 8051 program to ARM. Even the meaning of 'int' is ambiguous. And aren't they re-doing .NET right now? >All BASIC is good for is throaway code. I haven't thrown away any of my engineering apps. I must have spun $100 million worth of sales by now based on Basic engineering apps; I'm sure not going to throw the money away. How many Windows 3.1 apps still run under Vista or Linux? All my old PB/Dos .EXE programs still run under XP, even the graphics. You seem to be saying that what you are doing now is not only portable, it always will be, which is absurd. I am saying that I get engineering done in Basic, and it works, which is true. John >>And BASIC? Want to talk about archaic? A language that doesn't have >>structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 7 lines] > Basics can and do do all that stuff: structs, CASE, WHILE, TRY, THREAD, > formal subs, and great inherents like strings and graphics and SORT. And I'd guess that most of it is incompatible with other Basics, and not related to any formal standard. C has most of this in the standard, so you can use the same code with gcc, icc, msvc, ... >>>And BASIC? Want to talk about archaic? A language that doesn't have >>>structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 10 lines] >And I'd guess that most of it is incompatible with other Basics, and not >related to any formal standard. And that matters? >C has most of this in the standard, so you can use the same code with gcc, >icc, msvc, ... Why on earth would I want to do that? I'm an electronics designer. John >>>>And BASIC? Want to talk about archaic? A language that doesn't have >>>>structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 10 lines] >>And I'd guess that most of it is incompatible with other Basics, and not >>related to any formal standard. >And that matters? For throwawayh code, not one bit. >>>>>And BASIC? Want to talk about archaic? A language that doesn't have >>>>>structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 14 lines] > >For throwawayh code, not one bit. I never throw code away. I run .EXEs that I compiled 15 years ago. They still give the right answers. How many Win 3.1 apps are still useful? What's the lifetime of a Linux driver? How often are significant (ie, painful) changes made to .NET? You're just expressing irrational, emotional prejudices for an ancient, messy, chaotic language. I'm just designing electronics. How many bits wide is an 'int' anyhow? John >>>>>>And BASIC? Want to talk about archaic? A language that doesn't have >>>>>>structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 24 lines] > >How many bits wide is an 'int' anyhow? How many bits are in a byte? ;-) >>>>>>>And BASIC? Want to talk about archaic? A language that doesn't have >>>>>>>structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 26 lines] > >How many bits are in a byte? ;-) That's the only one that people usually agree on. PowerBasic has bytes, words (u16), ints (s16), dwords (u32), longs (s32), quadints (s64), single floats, double floats, extended (80 bit) floats, currency, extended currency, and variants. And variable-length strings, fixed-length strings, asciz strings, field strings, and pointers. And a BIT type that can actually be 1 to 31 bits. And TYPES, which are mixed-type structures. And a lot of spiffy operators. See what you can do with a language that's not frozen in time by a bunch of dogmatic committees? Imagine if we still had to use 7400 logic and uA709 opamps to design everything. John >See what you can do with a language that's not frozen in time by a >bunch of dogmatic committees? Imagine if we still had to use 7400 >logic and uA709 opamps to design everything. > >John Imagine if every ua709 had a different pinout. > >See what you can do with a language that's not frozen in time by a > >bunch of dogmatic committees? Imagine if we still had to use 7400 [quoted text clipped - 3 lines] > > Imagine if every ua709 had a different pinout. Imagine you actually making sense. SignatureYou can't have a sense of humor, if you have no sense! >>>>>>>>And BASIC? Want to talk about archaic? A language that doesn't have >>>>>>>>structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 28 lines] > >That's the only one that people usually agree on. ...and people are usually wrong. ;-) >PowerBasic has bytes, words (u16), ints (s16), dwords (u32), longs >(s32), quadints (s64), single floats, double floats, extended (80 bit) [quoted text clipped - 9 lines] >bunch of dogmatic committees? Imagine if we still had to use 7400 >logic and uA709 opamps to design everything. Slowman might even be able to get a job. >How many bits are in a byte? ;-) More interesting, and more philosphical: How many somethings go into a bit? Bits are not really yes / no , true / false, there is a shady area in between ;-) That is where the mystery of logic could hide ;-) >>How many bits are in a byte? ;-) > >More interesting, and more philosphical: How many somethings go into a bit? > >Bits are not really yes / no , true / false, there is a shady area in between ;-) >That is where the mystery of logic could hide ;-) Wrong. A bit is a contraction of "binary digit". It, by definition, can only have two states. >>>How many bits are in a byte? ;-) >> [quoted text clipped - 5 lines] >Wrong. A bit is a contraction of "binary digit". It, by definition, >can only have two states. Na, everybody knows that 'a bit' of something is highly variable ;-) >>> How many bits are in a byte? ;-) >> [quoted text clipped - 5 lines] > Wrong. A bit is a contraction of "binary digit". It, by definition, > can only have two states. Until you connect a 74LSxx output to a 74HCxx input... SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>> How many bits are in a byte? ;-) >>> [quoted text clipped - 7 lines] > >Until you connect a 74LSxx output to a 74HCxx input... If there is a problem (there usually isn't and that can be taken care of with a resistor), it's no longer binary. Do you now what the word "definition" means? >>>>> How many bits are in a byte? ;-) >>>> More interesting, and more philosphical: How many somethings go into a bit? [quoted text clipped - 8 lines] > of with a resistor), it's no longer binary. Do you now what the word > "definition" means? I was joking - lighten up. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>>>>> And BASIC? Want to talk about archaic? A language that doesn't have >>>>>>> structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 21 lines] > > How many bits are in a byte? ;-) Eight, or six, or twelve... ;^) SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>>>>>> And BASIC? Want to talk about archaic? A language that doesn't have >>>>>>>> structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 23 lines] > >Eight, or six, or twelve... ;^) Or whatever you'd like it to be. >>>>>>And BASIC? Want to talk about archaic? A language that doesn't have >>>>>>structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 24 lines] > > How many bits wide is an 'int' anyhow? An "int" is guaranteed by the language to be at least 16 bits wide. (A "long" is guaranteed to be at least 32 bits wide). If you want exact widths you can use the (C99) types int16_t int32_t Or the unsigned versions uint16_t, uint32_t Etc. SignatureJohn Devereux >>> The thing about Basic is that it's not frozen in time like C is. Modern >>> Basics can and do do all that stuff: structs, CASE, WHILE, TRY, THREAD, [quoted text clipped - 4 lines] > > And that matters? It matters if you need to make the code run on a given platform, rather than being forced to choose the platform according to what the code runs on. In the few months I've been reading this group, I've seen several posts regarding the need to maintain legacy PCs because of code which won't run on current systems. >>C has most of this in the standard, so you can use the same code with gcc, >>icc, msvc, ... > > Why on earth would I want to do that? I'm an electronics designer. I take it that you're not using PowerBasic to write embedded software? Because you can use C for that (although using it on an 8-bit CPU is pushing it). With even a little bit of care, you can write code which will work on anything from a cellphone to a mainframe. With more care you can get it to work on an 8-bit microcontroller or soft CPU core. Not all electronic engineering is at the level of gates and latches. An increasing amount of hardware is designed to communicate with PCs, and the protocols aren't getting any simpler. The line between electronic devices and computers is getting ever more blurred; TVs and video recorders have already got to the point of requiring an OS; another decade or two and anything with a plug on it will have one. >>>> The thing about Basic is that it's not frozen in time like C is. Modern >>>> Basics can and do do all that stuff: structs, CASE, WHILE, TRY, THREAD, [quoted text clipped - 19 lines] > >I take it that you're not using PowerBasic to write embedded software? No, we'd never use Windows in an embedded system. But we do use PB for engineering apps, to run test racks, and our company material control system is written in PB. >Because you can use C for that (although using it on an 8-bit CPU is >pushing it). > >With even a little bit of care, you can write code which will work on >anything from a cellphone to a mainframe. With more care you can get it to >work on an 8-bit microcontroller or soft CPU core. But we make scientific and aerospace instruments. Real electronics. And once a product is designed, we don't port it to another platform. We sell it and design something else. Our products are analog-centric; FPGAs and uPs and embedded code just push the data around. >Not all electronic engineering is at the level of gates and latches. This isn't just gates and latches: http://www.highlandtechnology.com/DSS/T346DS.html I did the hardware and firmware for this. The firmware is 68K assembly; it parses and executes almost 400 distinct serial commands. I wrote some PB programs to help generate some of the assembly source, like waveform tables. I did the rom builder utility, a linker of sorts, in PB too... easy. The test/cal program is PB too. There's also a "virtual instrument" thing we did in Java, which is truly platform independent; well, the same executable works on Windows and Linux after some pounding. An >increasing amount of hardware is designed to communicate with PCs, and the >protocols aren't getting any simpler. The line between electronic devices >and computers is getting ever more blurred; TVs and video recorders have >already got to the point of requiring an OS; another decade or two and >anything with a plug on it will have one. We have a bunch of Ethernet-enabled products. One system going together now has Linux on a mini-ITX board buried inside. That will be programmed in C, and not by me. It did take a month to get one Linux driver (furnished by the chip vendor and claimed correct) to work... more time than I usually spend on an entire firmware project. And that's just one driver. It involved recompiling the Linux kernel, of course. Something about different device driver models between 2.1.4.1 and 2.1.4.2 or some such nonsense. So much for portability. John >>> And BASIC? Want to talk about archaic? A language that doesn't have >>> structured datatypes, doesn't have block statements, can't call subprograms, [quoted text clipped - 12 lines] > C has most of this in the standard, so you can use the same code with gcc, > icc, msvc, ... Unless you want to do graphics, or have a GUI. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>>> Converting BASIC to C is very simple; the standard libraries for both are >>>>> even fairly similar (too bad BASIC has more powerful libraries!). [quoted text clipped - 20 lines] > > And BASIC? Want to talk about archaic? True. BASIC is older than C. > A language that doesn't have > structured datatypes, Depends on the version. > doesn't have block statements, Mostly true, although it depends on the version. > can't call subprograms, Not true. > can't pass parameters to subroutines Depends on the version. > can is only good for nasty horrible > spaghetti code unless you use some proprietary extensions that haven't a prayer > of ever working on any other system? Also not true. I've written recursive code in BASIC. Admittedly, it was painful. > At least programs written in C are transportable. > All BASIC is good for is throaway code. Not true. You can write crap code in any language. If nothing else, BASIC's simple enough to be at least usable as pseudocode. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>>> Over 20 years ago a coworker of mine wrote a comefrom static analysis >>>> program to analyze his programs. He was rather shocked to see how [quoted text clipped - 77 lines] > >John Unlike Dykstra, i do understand how to use goto to create case frames. And i use goto in ASM to build state machines as well. Goto is normally unnecessary in complete higher level languages like "C", and should be avoided in such languages. Also gosub normally returns, even in ASM. >>>>On May 16, 10:06 am, John Larkin >>>><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 22 lines] >to discourage it. Most programmers hate languages like Ada and Basic >because they slow them down and make them think. That depends on what they need to think about. Usually it is a workaround for a crappy language. Look at the amount of extensions Borland put into Delphi. Its almost like C. >C also allows all sorts of memory-management and variable type/range >errors that no modern language should allow to happen. Malloc, memcpy, >wild pointers, things like that. It's barbaric. Most of this stuff is deprecated. IIRC most modern compilers have an option that will start to complain when insecure functions are being used. The C++ STL library contains a huge amount of memory management, string handling, linked list, etc functions that make it totally unnecessary to deal with memory yourself. >Extreme Programming makes the case that two programmers writing a >piece of code on one shared screen is more efficient, on average, than >one programmer. That's pitiful. > >You can't argue that C (and its culture) generally results in good or >secure executables, because it so obviously doesn't. That is like saying more people are killed by people driving a Corvette than a Ford. You can argue this either way. Languages like C# and Java catch all kinds of errors. This means the programmers have to worry even less about cleaning up. On the other side C/C++ don't allow to let a pointer slip away. The program will crash. Anyway, good programmers that have an eye for security, resillience / recovery, timing / deterministic behaviour and multi-threading are very scarce. I still believe that a good piece of software starts with a good design. No matter what language is being used. SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >>>>>On May 16, 10:06 am, John Larkin >>>>><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 53 lines] >that have an eye for security, resillience / recovery, timing / >deterministic behaviour and multi-threading are very scarce. As someone recently said, most programmers are by definition mediocre programmers. They are like beginning drivers with bad eyesight given Formula 1 cars to drive. Of course really good programmers - like the authors of C - can - if they're in the mood - write reliable, secure, bug-free code in C. >I still believe that a good piece of software starts with a good >design. No matter what language is being used. Of course. But the language and the culture of C provide too many ways for mere mortals to code junk. It's interesting that the best programming languages, from an outcomes standpoint, are Cobol and Ada. Used Adobe Reader, or IE, or Word, or Vista lately? Crap, produced by the best programmers money can buy. Fly on a plane or use an ATM lately? Did you lose your money or your life? John >>You can't argue that C (and its culture) generally results in good or >>secure executables, because it so obviously doesn't. [quoted text clipped - 4 lines] > You can argue this either way. Languages like C# and Java catch all > kinds of errors. Catching an error at run-time is too late. Much of the time, the biggest difference between using Java and using C is that the former provides a slightly more verbose error message when it terminates the program and loses all of your work due to an out-of-bounds array access. In that regard, code written in interpreted languages is often worse than that written in C, as even the most obvious errors can go undetected if the code doesn't get run (error-handling code is a prime target). >You can argue this either way. Languages like C# and Java catch all >kinds of errors. This means the programmers have to worry even less >about cleaning up. Cool. Since thay have to worry less, they can be even more careless. On the other side C/C++ don't allow to let a >pointer slip away. The program will crash. Anyway, good programmers >that have an eye for security, resillience / recovery, timing / >deterministic behaviour and multi-threading are very scarce. Exactly. That is the dominant programming culture: hack fast, do dense tricky stuff, use as many automated tools as possible, compile until there are no errors, run it and fix any bugs that are impossible to ignore, modify and VCS it until management says it's time to ship the next release, and let the users find the many other bugs. John >Exactly. That is the dominant programming culture: hack fast, do dense >tricky stuff, use as many automated tools as possible, compile until [quoted text clipped - 3 lines] > >John So, John, how's your FFT and reverse in Power Basic? Or do you, as engineer never use FFTs? >>Exactly. That is the dominant programming culture: hack fast, do dense >>tricky stuff, use as many automated tools as possible, compile until [quoted text clipped - 6 lines] >So, John, how's your FFT and reverse in Power Basic? >Or do you, as engineer never use FFTs? I've done some FFTs in PB, not often. There are some public subroutines, and some commercial packages. The stuff I did just worked. The Crescent Software QPSCI-package FFT subroutine FFT1.BAS is about 80 lines, comments included, does forward or reverse, and seems fine. I've also done DFTs in assembly, also no big deal. If all you need are a phase angle or a few spectral lines, a DFT can be a lot easier and faster than an FFT. You can even DFT on the fly as sampled data comes in, avoiding big clumps of computing. We're doing a scientific instrument now, Linux based, and we'll probably use the fftw or maybe the cpu-specific Intel libraries, since speed will matter. This will be all embedded C stuff, which I won't write. After all, I'm not a programmer, or a bookkeeper for that matter. John >>>Exactly. That is the dominant programming culture: hack fast, do dense >>>tricky stuff, use as many automated tools as possible, compile until [quoted text clipped - 14 lines] > >I've also done DFTs in assembly, also no big deal. Yes DFT is easy in C too. >If all you need are a phase angle or a few spectral lines, a DFT can >be a lot easier and faster than an FFT. You can even DFT on the fly as [quoted text clipped - 7 lines] > >John fftw is nice, but changed API a while back. I am still with the old one. Have not used it for a while. Used it for video processing, speed is very important in that case. >>>> On May 16, 10:06 am, John Larkin >>>> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 31 lines] > > John I do all my programming in C++ for things that I need to be fast, and REXX for other stuff. Coding in REXX is about 10x faster. I wouldn't touch BASIC with a barge pole nowadays, though I used to love HP Basic (for the 9816), mainly for its beautiful GPIB integration. I'd still write instrument code that way if I could--but I'd do the fancy stuff in C++. Cheers Phil Hobbs SignatureDr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net >I do all my programming in C++ for things that I need to be fast, and >REXX for other stuff. Coding in REXX is about 10x faster. I wouldn't >touch BASIC with a barge pole nowadays, though I used to love HP Basic >(for the 9816), mainly for its beautiful GPIB integration. I'd still >write instrument code that way if I could--but I'd do the fancy stuff in >C++. C++ is no language, but a speech disability. Only idiots use C++. >> I do all my programming in C++ for things that I need to be fast, and >> REXX for other stuff. Coding in REXX is about 10x faster. I wouldn't [quoted text clipped - 5 lines] > C++ is no language, but a speech disability. > Only idiots use C++. Gee, Jan, for a neural net you sure have a lot of strong opinions. ;) Cheers Phil SignatureDr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net >>> I do all my programming in C++ for things that I need to be fast, and >>> REXX for other stuff. Coding in REXX is about 10x faster. I wouldn't [quoted text clipped - 11 lines] > >Phil It comes from experience (they call that training the net). I was sort of asked to read Stroustrup's book in one job. It became clear to me after a few pages that he did not know how to program, and tried to 'fix' that by inventing a new language (or rather cluttering C with nonsense). This person is responsible, among other things, for the mess MS has made: http://www.research.att.com/~bs/ Even C++ compiler writers could at one point no longer agree what it was about :-) In my view you must be complete idiot if you invent 'operator overloading', and write needlessly long things with :: in between. But ... as with many things, many went for it, many cannot do anything else. Maybe my strong opinion comes from the fact that I started with hardware, then BASIC, then asm...., and then finally C. A bit of php too, nice for websites. Never ever needed the ++ in C for anything, never. >>>> I do all my programming in C++ for things that I need to be fast, and >>>> REXX for other stuff. Coding in REXX is about 10x faster. I wouldn't [quoted text clipped - 21 lines] >A bit of php too, nice for websites. >Never ever needed the ++ in C for anything, never. At some point object oriented programming turns out to be very convenient. It is possible to use OO programming techniques in plain C, but it is a pain in the a.s and memory allocation becomes tedious (just look at the Linux kernel). Thats where C++ kicks in. I have the same background but I gradually started to use more and more C++. SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >>Even C++ compiler writers could at one point no longer agree what it was about :-) >>In my view you must be complete idiot if you invent 'operator overloading', [quoted text clipped - 8 lines] >At some point object oriented programming turns out to be very >convenient. I really do not know for WHAT? The whole paradigm (difficult word had to look it up one time) or say perhaps "concept" of "objects' and 'object oriented' to me only means that the one who talks about it does not realize that processors normally (Turing machines) process things sequentially, >It is possible to use OO programming techniques in plain >C, but it is a pain in the a.s and memory allocation becomes tedious >(just look at the Linux kernel). No problem with Linux kernel in C, it would have been super-bloated and dead long time ago if Linus had allowed C++ in it. I will give an example from the Linux area about C++, and how bad it is; You must have (as a Linux user) have heard of Qt. Qt is some toolset to create a GUI interface... basically. Qt3 was big, and heavy, KDE desktop and a whole lot of applications for that, were, or are, based on it. Qt was a product from Trolltech. Then Qt4 was released, it did not do anything much new, but it took several hours to compile, was incompatible with Qt3, and even the kernel build tools. It was that same adventure - a dead end street- that MS took when using C++ as language -> into bloatware. It bounced (Qt). The people at Trolltech were smart, and sold the whole thing to Nokia IIRC. Now what Nokia wants with it I dunno, but it is the WORST possible thing to have on a small platform with a simple slow processor and little memory like for example a mobile phone. So... but it made Trolltech some money. As a money making machine the commerce in C++ compilers, C++ books, and as a stimulus for ever more powerful hardware buying, C++ does the hardware manufacturers some service. Now I am not against GUIs, I am against C++ related bloat crap... You see you do NOT need an object oriented language for things that perhaps look like objects, like widgets on a screen. If you want a good, fast, small, practically stable, almost bug free, toolkit to make GUIs in Linux use xforms, I use it all the time, libforms is: -rwxr-xr-x 1 root root 1580536 2008-02-04 14:42 /usr/X11R6/lib/libforms.so.1.0* Wow, almost 1.6 MB!!!! Now if I do (du reports in kB): du /usr/local/Trolltech/Qt-4.1.0/ 348855 /usr/local/Trolltech/Qt-4.1.0/ 384 MB YES three hundred eighty four Mega Byte! There is your f*cking C++; Now that should switch on a light in somebodies head. >Thats where C++ kicks in. Yea, kicks the bucket I hope. >I have the >same background but I gradually started to use more and more C++. Well, drugs are addictive too. If you do not mind my asking : What is that incredible application you need that ++ in C for? >>> Even C++ compiler writers could at one point no longer agree what it was about :-) >>> In my view you must be complete idiot if you invent 'operator overloading', [quoted text clipped - 66 lines] > > If you do not mind my asking : What is that incredible application you need that ++ in C for? As I said earlier, it's very good for simulations and instrument code, where a class corresponds to a thing or a specific process (e.g. an oscilloscope, a tunnel current process, or a volume of uniform composition in an EM simulator. If you get the abstractions right and the class hierarchy right, you can handle a lot more complexity with fewer bugs than in C. (Well I can, and so can lots of others. YMMV.) One of the best things about it is that you can replace the implementation of the lower-level stuff and the higher level stuff never even has to know. That's a big help in code profiling and optimization--you can code simple and obvious for the most part, and put the tweaks where they actually do something useful. Of course you have to know what C++ is doing under the covers, e.g. you don't want to call a lot of copy constructors all the time, or you'll die of bloat. That's a minor language wart, about the same nuisance level as checking for null pointers all the time in C. In general OO doesn't make that much difference in programs smaller than, say, 10k lines of code--just the front end of my EM simulator is 12k, and that's a script! Cheers Phil Hobbs SignatureDr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net >As I said earlier, it's very good for simulations and instrument code, >where a class corresponds to a thing or a specific process (e.g. an >oscilloscope, a tunnel current process, or a volume of uniform >composition in an EM simulator. If you get the abstractions right and >the class hierarchy right, you can handle a lot more complexity with >fewer bugs than in C. (Well I can, and so can lots of others. YMMV.) Well, I seem to do that just fine in C. For example in the subtitle editor I was referring to you have fonts, video display, audio track, and the sync between all those, many forms, many output formats, many input formats, I would see only more complexity in C++. You can download the code and look at if if you like. >One of the best things about it is that you can replace the >implementation of the lower-level stuff and the higher level stuff never >even has to know. That's a big help in code profiling and >optimization--you can code simple and obvious for the most part, and put >the tweaks where they actually do something useful. Sure, but if I have a function that does something, with correctly specified interface like for example int draw_picture(struct screen *ps, struct image *pi) than I can change that function, make it faster for example, or add more screen types, more image types, whatever. You talk about profiling, John Larkin would say; 'solve by adding more bloat'.... hell, if you know hat you are doing then WHERE is the problem? And if you do _not_ know what you are doing then not any extra tools will help you get the bugs out! >Of course you have to know what C++ is doing under the covers, e.g. you >don't want to call a lot of copy constructors all the time, or you'll >die of bloat. That's a minor language wart, about the same nuisance >level as checking for null pointers all the time in C. Exactly, same for C. >In general OO doesn't make that much difference in programs smaller >than, say, 10k lines of code--just the front end of my EM simulator is >12k, and that's a script! Scripts can be very powerful. I found out how powerful bash (scripting) can be when somebody wrote DVDwizard in bash... Of course he called every C program you can imagine. >> As I said earlier, it's very good for simulations and instrument code, >> where a class corresponds to a thing or a specific process (e.g. an [quoted text clipped - 9 lines] > see only more complexity in C++. > You can download the code and look at if if you like. It gets very hard to keep everything straight at 10-100+ kloc this way, at least if your program needs to be maintained. Scars accumulate much faster than in C++. >> One of the best things about it is that you can replace the >> implementation of the lower-level stuff and the higher level stuff never [quoted text clipped - 7 lines] > than I can change that function, make it faster for example, or add > more screen types, more image types, whatever. But you have to change everything at all levels if you make a nontrivial change at the bottom--unless you have done all the abstraction correctly, which is what C++ automates. If you find you haven't, it's spaghetti city. > You talk about profiling, John Larkin would say; > 'solve by adding more bloat'.... hell, if you know hat you are doing > then WHERE is the problem? > And if you do _not_ know what you are doing then not any extra tools will help you > get the bugs out! Don't you profile your code? There's really no other way to find out where the bottlenecks are in a nontrivial, competently coded program. If they're obvious without profiling, they shouldn't have been coded in in the first place. >> Of course you have to know what C++ is doing under the covers, e.g. you >> don't want to call a lot of copy constructors all the time, or you'll >> die of bloat. That's a minor language wart, about the same nuisance >> level as checking for null pointers all the time in C. > > Exactly, same for C. There are no copy constructors in C. >> In general OO doesn't make that much difference in programs smaller >> than, say, 10k lines of code--just the front end of my EM simulator is [quoted text clipped - 3 lines] > I found out how powerful bash (scripting) can be when somebody wrote DVDwizard in bash... > Of course he called every C program you can imagine. Cheers Phil Hobbs SignatureDr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net >> Well, I seem to do that just fine in C. >> For example in the subtitle editor I was referring to you have [quoted text clipped - 6 lines] >at least if your program needs to be maintained. Scars accumulate much >faster than in C++. Like I said, this newsreader is 70k lines of C, no problem. As with any code, if I at any time needed to change anything, it would take me several hours to really dig in and see what is connected to what. It is linked list based. This digging in is important, some years ago somebody send me a 'fix' for some function, patch, I applied it after quick look, full faith the person had actually tested his code and understood mine, then it appeared some things stopped working.., But this is not unique to C, it happens in any language. You must see that from huge projects like the Linux kernel + drivers, that C works very well, in fact much better then C++, for projects that have many participants. I think C++ is unusable for such projects :-) You have been had. >>> One of the best things about it is that you can replace the >>> implementation of the lower-level stuff and the higher level stuff never [quoted text clipped - 12 lines] >correctly, which is what C++ automates. If you find you haven't, it's >spaghetti city. That makes no sense to me. If I write (and I speak for myself only, now) a program, I start at the lowest level, and I test one piece at the time, starting at the lowest level. But I do not start at all before I have a clear picture of what I want to do. If you do not have a clear picture of what you want to do, and start the top down approach, then you will have to repeatedly work backwards and re-write the code, no end to the rewrites. An architect who does not know about bricks and concrete will be in big trouble. He will have to learn, and 99.999 % certain have to re-start his dream project from scratch. >> You talk about profiling, John Larkin would say; >> 'solve by adding more bloat'.... hell, if you know hat you are doing [quoted text clipped - 4 lines] >Don't you profile your code? There's really no other way to find out >where the bottlenecks are in a nontrivial, competently coded program. That is, with all respect (I am not picking on you) bull. When writing your program, and especially in AV applications, thatt are *always* time bound and time critical, you know very well where the processor spends most of the time. Usually it is in some codec. Often these specific parts of the codec are written in asm for max performance speed wise. When writing such a codec you count instruction cycles, etc, on a piece of paper... work it out. Who needs a profiler if you know what you are doing? And if you need more info, then a couple of print statements will tell you everything you need to know. I never ever use a debugger either, never, I can read asm, and I use printf. There was a paper by uni Twenthe many years ago that argued against debuggers and for print statements in higher level languages. For me C is a higher level language, as is BASIC, I took that paper to heart, and it works. C++ is of course lower level crap ;-) so nothing you can buy will help you with that :-) >If they're obvious without profiling, they shouldn't have been coded in >in the first place. bull. >>> Of course you have to know what C++ is doing under the covers, e.g. you >>> don't want to call a lot of copy constructors all the time, or you'll [quoted text clipped - 4 lines] > >There are no copy constructors in C. Would be nice if people understood the power of linked lists. I am not even good at that, some people do miracles with that. that is worth more then the whole ++ load of. ... > Would be nice if people understood the power of linked lists. > I am not even good at that, some people do miracles with that. > that is worth more then the whole ++ load of. Ah, if you only knew the power of binary trees... Michael >... > [quoted text clipped - 5 lines] > >Michael Yes, right, and this newsreader uses one, when I started writing it, speed was an issue, think 60 MHz processor, sorting thousands of newsgroups... So for the sorting I used a binary tree. In the current version you can still disable sorting :-) (GROUPS->SORTED DISPLAY) that made it faster... These days with so much processor power and binary trees... things become almost instantaneous. >>... >> [quoted text clipped - 13 lines] >These days with so much processor power and binary trees... things >become almost instantaneous. Even linear searching can be almost instantaneous. In our material control system, at startup we read the entire database into a memory-resident array of records, and a parts search is brute-force linear string compares. It's so fast it doesn't matter. John >>>Ah, if you only knew the power of binary trees... >>> [quoted text clipped - 14 lines] > >John Yes, a linear search is relatively simple. In case of for example a bubble sort, you have to go through the list again and again, until no more elements need swapping position. Although that is all pointer work, it does take worst case many times going through the loop. In case of a binary tree, you just store the info in a sorted way. When reading back the tree you get the sorted result. > ... > [quoted text clipped - 3 lines] > > Ah, if you only knew the power of binary trees... hash tables... > It gets very hard to keep everything straight at 10-100+ kloc this way, at > least if your program needs to be maintained. Scars accumulate much faster > than in C++. I think a very good example of this is SPICE3: Even though it was specifically re-written in C (rather than FORTRAN) to make it easily extensible/changeable, anyone looking to actually implement some extensions faces a much tougher row to hoe than if it had been writte in C++ from the start. Hmm... I wonder what Mike coded LTSpice in? I think the first code I was actually *paid* to write might have been in REXX -- summer internship at IBM after my senior year of high school! >> It gets very hard to keep everything straight at 10-100+ kloc this way, at >> least if your program needs to be maintained. Scars accumulate much faster [quoted text clipped - 9 lines] >I think the first code I was actually *paid* to write might have been in >REXX -- summer internship at IBM after my senior year of high school! Spice2 _was_ written in Fortran. I had to implement a modification of Gummel-Poon (~1980) so that Cbe was properly represented during forward bias... it doesn't keep increasing (as originally modeled)... it actually drops rapidly. ...Jim Thompson | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | Stormy on the East Coast today... due to Bush's failed policies. >> It gets very hard to keep everything straight at 10-100+ kloc this way, at >> least if your program needs to be maintained. Scars accumulate much faster [quoted text clipped - 9 lines] > I think the first code I was actually *paid* to write might have been in > REXX -- summer internship at IBM after my senior year of high school! I love REXX. Mike Cowlishaw wrote it explicitly to minimize nasty surprises, and (with one or two warts, mostly having to do with stem variable handling) he did a beautiful job. In C/C++ etc you have to be a language lawyer to avoid depending on undefined behaviour, e.g. the dependence of static variable initialization on the order of linking different translation units. In REXX, you just blast ahead and it always works. Really a beautiful piece of work. Cheers, Phil Hobbs SignatureDr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net > I really do not know for WHAT? Sure. Let's do everything in assembler. Or, better, directly in the machine codes. > I will give an example from the Linux area about C++, and how bad it is; > You must have (as a Linux user) have heard of Qt. > So... but it made Trolltech some money. That's the point. > As a money making machine the commerce in C++ compilers, C++ books, and as a stimulus > for ever more powerful hardware buying, C++ does the hardware manufacturers some service. > Now I am not against GUIs, I am against C++ related bloat crap... 1. Bloated crap makes money. 2. C++ is just a tool. If used properly, it helps avoiding certain kinds of the dumb mistakes and simplifies the cooperation between the developers. > Wow, almost 1.6 MB!!!! > > Now if I do (du reports in kB): > du /usr/local/Trolltech/Qt-4.1.0/ > 348855 /usr/local/Trolltech/Qt-4.1.0/ > 384 MB YES three hundred eighty four Mega Byte! Who cares. > If you do not mind my asking : What is that incredible application you need that ++ in C for? If you don't mind my questions, what was the largest program piece that you wrote yourself? What was the largest commercial software project that you participated to as a part of a team? Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com >> As a money making machine the commerce in C++ compilers, C++ books, and as a stimulus >> for ever more powerful hardware buying, C++ does the hardware manufacturers some service. [quoted text clipped - 3 lines] >2. C++ is just a tool. If used properly, it helps avoiding certain kinds >of the dumb mistakes and simplifies the cooperation between the developers. I do not think it helps developers. I have seen a clear example how it did help make a bad product from a reasonable one. >> Now if I do (du reports in kB): >> du /usr/local/Trolltech/Qt-4.1.0/ >> 348855 /usr/local/Trolltech/Qt-4.1.0/ >> 384 MB YES three hundred eighty four Mega Byte! > >Who cares. I do, and a lot. Bloat sucks, takes up my time, costs money, under performs, sucks basically. >> If you do not mind my asking : What is that incredible application you need that ++ in C for? SO?????????????????????????????????????? >If you don't mind my questions, what was the largest program piece that >you wrote yourself? >What was the largest commercial software project >that you participated to as a part of a team? That was actually a hardware project, I contributed the hardware design, and the drivers for the hardware. The software department did integrate that with the rest. That was a multi million dollar project. The largest thing I wrote myself, if you mean lines of code, say 70000 lines of C, around that sort of size, for several apps, like for example this newsreader. No problem whatsoever. Else I would not post here now could I? I think (my take) you just got VisualC++, and now are trying to justify you using it? This right? Ever used gcc and Linux? >>>Even C++ compiler writers could at one point no longer agree what it was about :-) >>>In my view you must be complete idiot if you invent 'operator overloading', [quoted text clipped - 10 lines] > >I really do not know for WHAT? The whole idea behind OO is to keep the data and the functions that process the data together in one unit. Even more, functions and data that are internal are hidden from other objects in the program. Sounds complicated but the static keyword makes symbols hidden to other object files in C. Imagine you create a library. The library obviously has internal functions and data that you don't want to export so you declare them static or tell the linker not to export some symbols. That is already some sort of OO programming. OO programming is like building your application from small internal libraries. Another thing they added is object inheritance so you can create derived classes from a base class. Last year I wrote a class that can drawn signals on a 'canvas' (drawing area). From this class I derived two new classes. One that can draw to a printer canvas and one to draw to the screen canvas. Ofcourse the same thing can be done in plain C, but the code would have been much harder to understand. Under the hood a C++ object is nothing more than a pointer to a struct containing pointers to data and functions (vtable). >The whole paradigm (difficult word had to look it up one time) or >say perhaps "concept" of "objects' and 'object oriented' to me only >means that the one who talks about it does not realize that >processors normally (Turing machines) process things sequentially, Sorry, but this doesn't make any sense to me. OO has nothing to do with multi-threading or parallel processing. >>It is possible to use OO programming techniques in plain >>C, but it is a pain in the a.s and memory allocation becomes tedious [quoted text clipped - 5 lines] >I will give an example from the Linux area about C++, and how bad it is; >You must have (as a Linux user) have heard of Qt. Yup. Heard of it. I stayed away from Qt since the beginning. Never liked the fact it is actually closed source. >Qt is some toolset to create a GUI interface... basically. It is way more, it is intended to create cross platform applications. So you can have one source which builds for several platforms. Therefore Qt must provide a universal replacement for several Windows and Linux APIs. That takes a lot of code! I use wxWidgets for that purpose. >Qt3 was big, and heavy, KDE desktop and a whole lot of applications for that, were, >like objects, like widgets on a screen. >If you want a good, fast, small, practically stable, almost bug free, toolkit to make GUIs in Linux >use xforms, I use it all the time, libforms is: >-rwxr-xr-x 1 root root 1580536 2008-02-04 14:42 /usr/X11R6/lib/libforms.so.1.0* >Wow, almost 1.6 MB!!!! I use wxWidgets to write portable applications (I do most development on a Windows machine). I admit wxWidgets is bigger than libforms but wxWidgets does a lot more. I still manage to put X-Windows, GTK2 libraries + engines, a wxWidgets C++ application and misc Linux stuff (busybox, ftp server, etc) into 12MB of flash with several MB to spare on an embedded device (industrial control application). >>I have the >>same background but I gradually started to use more and more C++. > >Well, drugs are addictive too. > >If you do not mind my asking : What is that incredible application you need that ++ in C for? See above. But I doubt C++ has anything to do with Qt being bloatware. Look into Gnash (gnu flash player). Entirely written in C++. It also runs on the hardware platform I mentioned above with plenty of space to spare. SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >>>At some point object oriented programming turns out to be very >>>convenient. [quoted text clipped - 6 lines] >complicated but the static keyword makes symbols hidden to other >object files in C. Yes, but this can be done in C in functions with local vars very easy. >Imagine you create a library. The library obviously has internal >functions and data that you don't want to export so you declare them >static or tell the linker not to export some symbols. That is already >some sort of OO programming. OO programming is like building your >application from small internal libraries. Well, that is one aspect. >Another thing they added is object inheritance so you can create >derived classes from a base class. Last year I wrote a class that can >drawn signals on a 'canvas' (drawing area). From this class I derived >two new classes. One that can draw to a printer canvas and one to draw >to the screen canvas. Ofcourse the same thing can be done in plain C, >but the code would have been much harder to understand. I think not, even the contrary, anytime you define a function and give it a sensible name like (referring to your example): #define DESTINATION_PRINTER 1 #define DESTINATION_SCREEN 2 ... draw_line (int destination, int x1, int x2, int y1, int y2), and you see that even in the C code example I posted early in this or a related thread, it can be called from anywhere in a program simply by name. If you correctly prototype it, then there will be no errors in the way of calling it with the wrong variables. And do parameter checks in the function itself. Important is to use clearly readable defines, function names, and variables. >Under the hood a C++ object is nothing more than a pointer to a struct >containing pointers to data and functions (vtable). Yea, I know that, but I also think that perhaps with statements like 'new' a lot of people do not know what really happens under the hood. >>The whole paradigm (difficult word had to look it up one time) or >>say perhaps "concept" of "objects' and 'object oriented' to me only [quoted text clipped - 3 lines] >Sorry, but this doesn't make any sense to me. OO has nothing to do >with multi-threading or parallel processing. Oh, but it does! What you are referring to seems to be 'modular' (given the example of libs and compacted functions with their own variables). I do not think C++ is anything else then a bad programming style, a speech disability. >>>It is possible to use OO programming techniques in plain >>>C, but it is a pain in the a.s and memory allocation becomes tedious [quoted text clipped - 8 lines] >Yup. Heard of it. I stayed away from Qt since the beginning. Never >liked the fact it is actually closed source. For commercial apps it is nice, as you do not have to release source then of your embedded systems that you sell. You could buy a Qt license, and you would be OK using it commercially. Or are you telling me you are not releasing source and using Linux apps like busybox (see your statement below) in your products? >>Qt is some toolset to create a GUI interface... basically. > >It is way more, it is intended to create cross platform applications. >So you can have one source which builds for several platforms. Well, that may be important if you use different platforms. I bought a copy of Xp for a computer here some month ago, already am sick of it (so now I have win 98 and Xp here LOL). It was actually to try things like that Sony Vegas video editor. I found however it was worse then what I already wrote myself, except for some effects that seem nice... The rest of the Xp apps seem crap too... I installed Visual studio (the free version) on it, but already was longing back for gcc so much that I have not used it. So there really is only one system, Unix (or Linux if you will), that is of any use in this world. >Therefore Qt must provide a universal replacement for several Windows >and Linux APIs. That takes a lot of code! I use wxWidgets for that >purpose. Yes that Wxwidgets or whatever it is called today did not want to compile here, needed things... So rm * -rf fixed that. I think I just found that rm * -rf on that Qt dir would likely make no difference here as I think I use no Qt stuff? Maybe Opera? dunno, but would generate an other 300 MB free disk space, nice for the very long audio and video files I am working with. >I use wxWidgets to write portable applications (I do most development >on a Windows machine). I admit wxWidgets is bigger than libforms but >wxWidgets does a lot more. I still manage to put X-Windows, GTK2 >libraries + engines, a wxWidgets C++ application and misc Linux stuff >(busybox, ftp server, etc) into 12MB of flash with several MB to spare >on an embedded device (industrial control application). I have a web server and stuff in the Linksys WAP54G in < 4MB flash. I have an 2 GB? SDcard with Puppy Linux somewhere.... >Look into Gnash (gnu flash player). Entirely written in C++. It also >runs on the hardware platform I mentioned above with plenty of space >to spare. mmmm I have the macromedia? flashplayer. > For commercial apps it is nice, as you do not have to release source then of > your embedded systems that you sell. > You could buy a Qt license, and you would be OK using it commercially. > Or are you telling me you are not releasing source and using Linux > apps like busybox (see your statement below) in your products? Sun bought Trolltech, now it is LPGL for all platforms. Some time ago, before Sun bought the company, you could bought a commercially licence for Linux, embedded platforms and Windows, or you could use the GPL version (not for Windows). Now you can use it with commercial applications for all platforms for free, if you publish all changes to the Qt library you made. But with LGPL you don't have to publish the source code of your program any more. SignatureFrank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de >> For commercial apps it is nice, as you do not have to release source then of >> your embedded systems that you sell. [quoted text clipped - 9 lines] >But with LGPL you don't have to publish the source code of your program any >more. Ah Sun, OK thanks. But busybox is not LGPL I think. They sued some companies for not releasing source. > Sun bought Trolltech, now it is LPGL for all platforms. Some time ago, > before Sun bought the company, you could bought a commercially licence for Nokia bought trolltech, not Sun. --Kim > Nokia bought trolltech, not Sun. Thanks, you are right: http://www.nokia.com/A4813580 I mixed this up with the Oracle/Sun thing: http://www.sun.com/third-party/global/oracle/ If there are more of such acquires, in the end there will be only a small number of very big companies. SignatureFrank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de >> Nokia bought trolltech, not Sun. > [quoted text clipped - 8 lines] >If there are more of such acquires, in the end there will be only a small >number of very big companies. Well, if Nokia indeed bought it, and if they ever start using it, they will be dead. As it is bloatware. > Well, if Nokia indeed bought it, and if they ever start using it, > they will be dead. > As it is bloatware. Did you ever used one of Nokias development tools or even end user applications for transfering the address book to a mobile phone? Can't be more bloated :-) SignatureFrank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de >> Well, if Nokia indeed bought it, and if they ever start using it, >> they will be dead. [quoted text clipped - 3 lines] >applications for transfering the address book to a mobile phone? Can't be >more bloated :-) Yes, sure I have that Nokia program in Xp. I also tried to install their development tool for Symbian.... well, did it need eclipse? Or some weird java stuff? Anyways it would not install in Linux, or rather I got fed up with it. Then I also tried the google phone thing, that needed also eclipse? Probably all OO stuff ;-) so anyways, but that Nokia program in Xp worked, even with bluetooth, unlike bluetooth with Nokia in Linux, but I have IR working with Nokia in Linux (and any other phone), but with limitations!. And setting all that up took a lot more tine then installing the Nokia program in Xp. that worked out of the box, bloated or not. But Qt, there was an announcement today (in German): http://www.heise.de/newsticker/Nokia-eroeffnet-Ovi-Softwareshop-fuer-Symbian-Sma rtphones--/meldung/138427 Does not seem very well done. http://www.heise.de/newsticker/Plattformunabhaengige-mobile-Entwicklung-mit-Qt-M obility--/meldung/138425 LOL Now it is free, and still nobody wants it? hehe > Did you ever used one of Nokias development tools or even end user > applications for transfering the address book to a mobile phone? Can't be > more bloated :-) Well, I use PC suite a lot. It runs OK, but the startup time is very long. Maybe there is some kind of virtual machine startup involved. After all, these are very simple apps. Then again, I had a Linux PDA, Sharp Zaurus. The GUI uses QT/embedded as I recall and it wasn't particularly bloated. > Well, if Nokia indeed bought it, and if they ever start using it, > they will be dead. > As it is bloatware. There are already S60 and Windows CE ports of Qt available. Qt is not very heavy library. It is split into many modules and not all of them need to be loaded or even built. Especially for embedded platforms the library can be customized. Qt has been used already for years in mobile phones. Just looking into the qt directory size does not tell that much. Full build includes XML parsers, html renderer (based on webkit), database connectors, scripting engines etc. And also debugging symbols for c++ libraries are huge when built with some compilers (gcc for example), but they can be stripped off. --Kim >> Well, if Nokia indeed bought it, and if they ever start using it, >> they will be dead. [quoted text clipped - 14 lines] > >--Kim Well, time will tell. I did rm * -rf on the Qt dir on my PC, and everything still works :-) Not only that, the extra disk space of > 300 MB is already in use now for large wave files. >>>>At some point object oriented programming turns out to be very >>>>convenient. [quoted text clipped - 8 lines] > >Yes, but this can be done in C in functions with local vars very easy. But not global variables inside one object file. C++ adds the ability to have multiple levels of variable scopes. >>Another thing they added is object inheritance so you can create >>derived classes from a base class. Last year I wrote a class that can [quoted text clipped - 16 lines] >And do parameter checks in the function itself. >Important is to use clearly readable defines, function names, and variables. Okay, imagine working with several people on one project. You create a function called draw_circle and your co worker creates a function called draw_circle. Now that is a bit of a problem if you are not using objects. Either you need to refactor or he. >>>The whole paradigm (difficult word had to look it up one time) or >>>say perhaps "concept" of "objects' and 'object oriented' to me only [quoted text clipped - 5 lines] > >Oh, but it does! Absolutely wrong. Where did you get that idea? >>Therefore Qt must provide a universal replacement for several Windows >>and Linux APIs. That takes a lot of code! I use wxWidgets for that >>purpose. > >Yes that Wxwidgets or whatever it is called today did not want to compile here, needed things... >So rm * -rf fixed that. You should have read the manual installed the proper packages and run configure. wxWidgets compiles out of the box on Windows. >>Look into Gnash (gnu flash player). Entirely written in C++. It also >>runs on the hardware platform I mentioned above with plenty of space >>to spare. > >mmmm >I have the macromedia? flashplayer. FYI that doesn't run on MIPS platforms. SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >>>that are internal are hidden from other objects in the program. Sounds >>>complicated but the static keyword makes symbols hidden to other [quoted text clipped - 4 lines] >But not global variables inside one object file. C++ adds the ability >to have multiple levels of variable scopes. I am not sure what you mean here. What I often, if not always, do is use some global vars, namely those vars that are used all over the place so I do not want to pass these to every function. In the main header file for example int debug_flag; will make that available in all source files, without needing further reference to 'extern' or whatever. In the source files you can use static int something; and it will only be known in those source files. etc. >>and you see that even in the C code example I posted early in this or a related thread, >>it can be called from anywhere in a program simply by name. [quoted text clipped - 7 lines] >called draw_circle. Now that is a bit of a problem if you are not >using objects. Either you need to refactor or he. Yes, that would be weird, and it would be weird as it would show there was no communication. But, in your source file you could simply write static ... draw_circle(...) And he could do it in his source file, and no collisions! But that communication thing I referred to is very important, it can make you laugh (or cry), that NASA spacecraft to mars had software that had to check some micro switch on the landing gear to see if it touched ground to know if it could switch off the rocket engine. To bad the spec did not mention the micro switch also was activated when the gear went out. So gear came out, engine stopped, and it smashed on mars into pieces. So communication, have meetings. discuss what you are doing. Else it is a ticket to disaster. >>>>The whole paradigm (difficult word had to look it up one time) or >>>>say perhaps "concept" of "objects' and 'object oriented' to me only [quoted text clipped - 7 lines] > >Absolutely wrong. Where did you get that idea? Well, maybe I have read the wrong books? >>>Therefore Qt must provide a universal replacement for several Windows >>>and Linux APIs. That takes a lot of code! I use wxWidgets for that [quoted text clipped - 5 lines] >You should have read the manual installed the proper packages and run >configure. wxWidgets compiles out of the box on Windows. But I do not NEED WxDinges :-) >>>>Sorry, but this doesn't make any sense to me. OO has nothing to do >>>>with multi-threading or parallel processing. [quoted text clipped - 4 lines] > > Well, maybe I have read the wrong books? Clearly. C++ doesn't include any features specifically related to concurrency. >>>>>Sorry, but this doesn't make any sense to me. OO has nothing to do >>>>>with multi-threading or parallel processing. [quoted text clipped - 7 lines] >Clearly. C++ doesn't include any features specifically related >to concurrency. But then C++ is not really an OO language :-) >>>>>>Sorry, but this doesn't make any sense to me. OO has nothing to do >>>>>>with multi-threading or parallel processing. [quoted text clipped - 9 lines] > >But then C++ is not really an OO language :-) OO has nothing to do with concurrency either. You should do some rm -f on your bookshelf. Did you by any mistake got books from Ammeraal? SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >>But then C++ is not really an OO language :-) > >OO has nothing to do with concurrency either. You should do some rm -f >on your bookshelf. Did you by any mistake got books from Ammeraal? Well, I have http://en.wikipedia.org/wiki/Object_oriented and maintain that C++ is not really an OO language. It also points out what I pointed out before, the relation between GUI related programming and object oriented programming that seems to exists. For the rest I do not care, C gives me the freedom to write in any way I like, without the ++ crap getting in the way. The argument that C++ would be better for groups is killed by the existence of Linux, and many Linux applications. In my view, that what is considered 'OO' is just a help for people who cannot program, or not have the ability to think analytically enough to construct a program that works in a normal way. What really happened with C++, is what happened with me on a much smaller scale for example in comp.os.development.apps I needed at some point to compare 2 files, on 2 http servers, original and mirror. So I wondered if that was possible from my eeePC without actually downloading those long files as 1) it has only few bytes memory left as it is cram full of extra stuff I added, and 2) it wears out the FLASH if you store those files. So I googled, asked... there was no such utility like 'diff' via the network. So I started writing one, not a small job really. Then somebody mentioned why not use 'wget' and pipes. Now that was really attractive, so I wrote a very short C program that used wget and popen() to do the job, works perfectly. Then after that somebody said: 'you can do that in bash: cmp <wget -O - url1 <wget -O- url2' or something like that. So what I wrote I did not need. I wrote it because I did not have enough experience with bash. IN THE SAME WAY Strouskop started writing a lot of crap on top of C because he did not know how to program in C (or know how to program at all if you ask me). Now newbies into programming, the poor suckers that come into that realm, fall for that, they do not know how to program either, like old rats like me and Larkin etc, so they think they _need_ all that ++ crap. And parrot the reasons the sales druid gave when selling them the C++ compiler. Is that clear? >>>But then C++ is not really an OO language :-) >> [quoted text clipped - 39 lines] >they do not know how to program either, like old rats like me and Larkin etc, >so they think they _need_ all that ++ crap. A programmer will spend all his career programming, so wants to play with shiny new toys. As an engineer, I only program when I absolutely have to, and want to get it done ASAP, wrapped up, bug free, and not have to revisit it, so I can get back to designing electronics, which is much more fun. So I use simple tools that are easy to remember how to use, in both the short term and the long term. Imagine having to go back and modify an embedded-product program that was coded in an industry-approved, academically-beloved state-of-the-art structured language: Pascal. John > A programmer will spend all his career programming, so wants to play > with shiny new toys. No. The development of the mass software is a sweat shop production line at which the low wage employees work from 7:00 till 5:00. > As an engineer, I only program when I absolutely > have to, and want to get it done ASAP, wrapped up, bug free, and not > have to revisit it, so I can get back to designing electronics, which > is much more fun. You are the engineer. They are the farmers. > So I use simple tools that are easy to remember how > to use, in both the short term and the long term. So they use the tools which allow them to put the things together so it somehow works. On schedule and within the budget. > Imagine having to go > back and modify an embedded-product program that was coded in an > industry-approved, academically-beloved state-of-the-art structured > language: Pascal. What go back? Ship and forget. The product will be obsolete in less then one year anyway. All of the programmer staff will be turned arround by then as well. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com >> A programmer will spend all his career programming, so wants to play >> with shiny new toys. [quoted text clipped - 25 lines] >one year anyway. All of the programmer staff will be turned arround by >then as well. My best-selling product - over 3000 so far, one a day like clockwork - has been in production for about 13 years now. We still ship even older stuff now and then. A good VME module will make money for 10 years at least. I can go back and read/understand/modify/rebuild the code on these things quickly and easily. The code is archived and so are all the tools. If I do a rebuild today, the executable image will be precisely what the original was, byte for byte. But annual programmer turnover? No wonder so much software is so bad! John >>> A programmer will spend all his career programming, so wants to play >>> with shiny new toys. [quoted text clipped - 28 lines] >My best-selling product - over 3000 so far, one a day like clockwork - >has been in production for about 13 years now. Bizarre. One of my guys just came in with a question from a customer as to whether this temperature controller would work at -175C. We looked at the assembly source code to make sure. It only took a minute or so to find the setpoint variable, and to search for the thing that sets it, and to verify that it errors when the user requests below -200 or above +265C. Good comments, good labels. This code started in 1993 and the latest rev was in 2006. John > You are the engineer. They are the farmers. You are bowels. They process fertilizer. Sometimes bowels develop bugs, and extreme measures are needed to remove those bugs. SignatureYou can't have a sense of humor, if you have no sense! >>>But then C++ is not really an OO language :-) >> [quoted text clipped - 41 lines] >And parrot the reasons the sales druid gave when selling them the C++ compiler. >Is that clear? I'm inclined to recapture the above as 'Don't know about OO. Don't want to know about OO. Therefore OO must be bad'. If you can't program, nothing is going to help. OO doesn't make programming simpler. Its just another way to look at programming and organise modules in a piece software in a more logical way. Using OO doesn't make your program slower either. SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >>Well, I have >> http://en.wikipedia.org/wiki/Object_oriented >I'm inclined to recapture the above as 'Don't know about OO. Don't >want to know about OO. Therefore OO must be bad'. Did you actually read the link? Up to where its says Criticism? <quote> Criticism object-oriented programming as a false annunciation. Usually this claim is founded upon the observation that there are no formal innovations in object-oriented programming -- that the paradigm never brought out a technique or characteristic of programming languages not known to academics by another name. Classes and inheritance are syntactic sugar, whereas polymorphism has long been known to Lisp developers as "dispatching on type." Overall, object-oriented programming, generic programming, and whatever else the designers of static programming languages[clarification needed (see discussion)] add to augment the expressivity of these languages have been formally known to programmers of Lisp for many years[citation needed]. What has been wanting in Lisp is efficiency, and the addition of these techniques to static languages[clarification needed (see discussion)] brings their efficiency to the fore Luca Cardelli wrote a paper titled 'BadEngineering Properties of Object-Oriented Languages'. Richard Stallman wrote in 1995, "Adding OOP to Emacs is not clearly an improvement; I used OOP when working on the Lisp Machine window systems, and I disagree with the usual view that it is a superior way to program."[8] A study by Potok et al. [9] has shown no significant difference in productivity between OOP and procedural approaches. Christopher J. Date stated that critical comparison of OOP to other technologies, relational in particular, is difficult because of lack of an agreed-upon and rigorous definition of OOP.[10]. In [11], a theoretical foundation on OOP is proposed. Alexander Stepanov suggested that OOP provides a mathematically-limited viewpoint and called it, "almost as much of a hoax as Artificial Intelligence" (possibly referring to the Artificial Intelligence projects and marketing of the 1980s that are sometimes viewed as overzealous in retrospect).[12][13] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I like that one :-) :-) Right on! Paul Graham, a successful web entrepreneur and programming author, has suggested that the purpose of OOP is to act as a herding mechanism which keeps mediocre programmers in mediocre organizations from "doing too much damage". This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques. [1] <end quote> >If you can't program, nothing is going to help. OO doesn't make >programming simpler. Its just another way to look at programming and >organise modules in a piece software in a more logical way. No it is not more logical, it borders on insanity. Or more precise on the notion of one who has no clue about how processors do things, someone who does not want to program, a Turing machine ignoramus to put it politely. > Using OO >doesn't make your program slower either. Bloated and slow. MS is an example how that ++ can get out of hand, adding nothing of real interest, real muscle, but tons of bloat and bugs. > (Nico Coesel) wrote in <4a15a93a.1909497593@news.planet.nl>: > [quoted text clipped - 4 lines] > MS is an example how that ++ can get out of hand, adding nothing of real interest, real muscle, > but tons of bloat and bugs. When you write a "language" that illiterates can program in, you get illiterate programmers. ;-) Cheers! Rich >>>Well, I have >>> http://en.wikipedia.org/wiki/Object_oriented [quoted text clipped - 26 lines] >more powerful and more compact techniques. [1] ><end quote> 99.9% of all programmers world wide are using OO to make their jobs easier. Based on the opinions (I see no technical reasoning in the piece you quoted) of a few critics you say 99.9% of the programmers are wrong. If the critics where right, we would not have *any* piece of software available OR nobody would use OO. Therefore it is safe to say OO is a technique which has significant advantages. People tend to adopt technology that has an added value. I think the quick adoption of C# is a good example. Paul Graham obviously likes to make a fool out of himself (I had a good laugh about so much nonsense and opinions posed as facts): http://www.paulgraham.com/noop.html I'm inclined to recapture the text in noop.html as 'Don't know about OO. Don't want to know about OO. Therefore OO must be bad'. At least at the end of the piece Paul admits he has no clue and no experience with OO programming. SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >99.9% of all programmers world wide are using OO to make their jobs >easier. I do not think that number is correct, especially since C++ is no real OO. >Based on the opinions (I see no technical reasoning in the >piece you quoted) of a few critics you say 99.9% of the programmers >are wrong. No you say that. I merely pointed out some misconceptions about the OO stuff. > If the critics where right, we would not have *any* piece >of software available OR nobody would use OO. Makes no sense, the whole of Unix is C for the largest part. The world does not end with MS crap. Neither did it begin with it. MS is a transient, it will go... already Balmer is desperate ... >Therefore it is safe to >say OO is a technique which has significant advantages. 'Therefore???' therefore what? where is your math. >People tend to adopt technology that has an added value. I think the >quick adoption of C# is a good example. The biggest mistake made, and frequently made, by humanity is: 'If 1 million do it, then it must be good.' Hitler worked that way too. 1 million wrong does not make a right :-) This is actually what puts the breaks on science. Like for example why the earth was flat, everybody can see that, right? >Paul Graham obviously likes to make a fool out of himself (I had a >good laugh about so much nonsense and opinions posed as facts): >http://www.paulgraham.com/noop.html >I'm inclined to recapture the text in noop.html as 'Don't know about >OO. Don't want to know about OO. Therefore OO must be bad'. At least >at the end of the piece Paul admits he has no clue and no experience >with OO programming. Na, for me it is: I looked at C++, I have read strousses book, at least part of it until I decided I was wasting my time, and better spend it doing real nice things programming in C, at that time video processing software, I had to use visual C++ at my work, as it had to be MS windblows, but hell what a load of limiting crap. So nice to use gcc and xforms and a couple of xterms and a normal text editor to write your code. And 10x faster too, no stupid windows with irrelevant crap that you need to scroll. No stupid C ++::++::+::+++::++::++::++ constructs. > Na, for me it is: I looked at C++, I have read strousses book, at least > part of it until I decided I was wasting my time, and better spend it I didn't think much of OO techniques until I had written a small handful of programs in them. At least to me, all the reading in the world wasn't going to make it obvious what the real advantage was... Those first programs were in Smalltalk too, but I've recovered from that. :-) > I had to use visual C++ at my work, as it had to be MS windblows, > but hell what a load of limiting crap. What part, MFC or something? Most companies writing "major apps" (Symantec, Corel, even Microsoft themselves) do end up writing their own GUI libraries. Visual Studio itself varies greatly between "crap" and "excellent" depending on exactly which version you're using. The better versions are as good as any *NIX IDE I've used. >>>But then C++ is not really an OO language :-) >> [quoted text clipped - 5 lines] > > and maintain that C++ is not really an OO language. C++ is most definitely an OO language. The OO features account for most of the differences between C and C++. > It also points out what I pointed out before, the relation between GUI related > programming and object oriented programming that seems to exists. OO is a natural fit for GUI toolkits, although it doesn't have to use C++. Both Xt and GTK are written in C but provide OO interfaces. > For the rest I do not care, C gives me the freedom to write in any > way I like, without the ++ crap getting in the way. [quoted text clipped - 4 lines] > or not have the ability to think analytically enough to construct > a program that works in a normal way. Given that you don't use OO and don't appear to even understand it, your opinion of OO doesn't really have a great deal of weight. Of course, it's *possible* to write any application without using an OO language or even OO concepts. But OO can provide very definite benefits in terms of modularity. >> In my view, that what is considered 'OO' is just a help for people who cannot program, >> or not have the ability to think analytically enough to construct >> a program that works in a normal way. > >Given that you don't use OO and don't appear to even understand it, your >opinion of OO doesn't really have a great deal of weight. Strange, as I did program in Visual C++, what according to you is 'OO'. There is nothing to understand in ohoh (Dutch word play), it is just a construct by those who do not know how to program, to cover up for their shortcomings. Just like your argument does not have anything other then 'modularity', I mentioned 'modularity' before, and modularity is something one can achieve in a much simpler and clearer way in C. But as C++ programmers so not really know C, they only know the ++ constructs, so they use those, creating bloat and crap code. You do not have to take my opinion for it, if you trust MIT, this is what they say: (from http://en.wikipedia.org/wiki/Object_oriented) <quote> In the academic realm of MIT there is a long tradition of criticizing object-oriented programming as a false annunciation. Usually this claim is founded upon the observation that there are no formal innovations in object-oriented programming -- that the paradigm never brought out a technique or characteristic of programming languages not known to academics by another name. Classes and inheritance are syntactic sugar, whereas polymorphism has long been known to Lisp developers as "dispatching on type." Overall, object-oriented programming, generic programming, and whatever else the designers of static programming languages[clarification needed (see discussion)] add to augment the expressivity of these languages have been formally known to programmers of Lisp for many years[citation needed]. What has been wanting in Lisp is efficiency, and the addition of these techniques to static languages[clarification needed (see discussion)] brings their efficiency to the fore. <end quote> So, now MIT can be wrong at times, like that wireless power Tesla-re-invention.... But they got rid of that by selling it to Intel.... But they _do_ have some knowledgeable people. Why not listen to that? I mentioned linked lists, and people should know those. Guess what Lisp is based on? http://en.wikipedia.org/wiki/Lisp_programming_language Before any of that OO crap, one should first learn the basics of programming. Then you likely do not want OO. What we need is programming power, to solve problems in the fastest simplest way, not code castles in the sky. Hey that is a nice one :-) >>> In my view, that what is considered 'OO' is just a help for people who cannot program, >>> or not have the ability to think analytically enough to construct [quoted text clipped - 4 lines] > > Strange, as I did program in Visual C++, what according to you is 'OO'. You can write C++ code without using any of the OO features, as it's almost a superset of C. > There is nothing to understand in ohoh (Dutch word play), it is > just a construct by those who do not know how to program, to > cover up for their shortcomings. No, you just don't understand it. > Just like your argument does not have anything other then 'modularity', > I mentioned 'modularity' before, and modularity is something > one can achieve in a much simpler and clearer way in C. Not really. OO provides a different kind of modularity. E.g. it's possible to derive (extend) a class without knowing anything about the data representation. > But as C++ programmers so not really know C, they only know the ++ constructs, > so they use those, creating bloat and crap code. You're just projecting your own ignorance of OO onto people who do understand it. > You do not have to take my opinion for it, if you trust MIT, this is what they say: > (from http://en.wikipedia.org/wiki/Object_oriented) > <quote> Er, that quote wasn't written by "MIT". The author appears to be citing views he doesn't entirely understand, much like you. If you want to argue the pros and cons of OO with me, you need to do so on the merits; appeals to "authority" will get you nowhere. [Especially RMS; his aversion to OO is one of the main reasons why XEmacs remains as a fork rather than having merged with GNU Emacs.] Also, I don't give much credence to academics without much real-world experience. While the academic side has its uses, there's a lot that you can only learn by practical experience. In particular, knowing what works when software is developed and maintained over decades by hundreds of different people, most of whom make relatively minor contributions. > I mentioned linked lists, and people should know those. > Guess what Lisp is based on? > http://en.wikipedia.org/wiki/Lisp_programming_language > > Before any of that OO crap, one should first learn the basics of programming. I learned Lisp long before any OO languages (my first was Smalltalk), and it is one of the few languages that I use regularly. But even Lisp has CLOS, which suggests that even Lisp programmers have a use for OO. > Then you likely do not want OO. > What we need is programming power, to solve problems in the fastest simplest way, > not code castles in the sky. OO doesn't really help if you're only solving small problems. But it can be extremely useful when you're dealing with code which needs to be readily extensible, or is so large that "global" knowledge isn't feasible, or which naturally fits the OO paradigm (e.g. component-based systems and simulations). >> I mentioned linked lists, and people should know those. >> Guess what Lisp is based on? [quoted text clipped - 15 lines] >or which naturally fits the OO paradigm (e.g. component-based systems and >simulations). OK, so to each his own perhaps. 'Language wars', 'editor wars' I have seen it all happening on Usenet. Before we start throwing the pies, maybe we can agree on some statement... like they do after those failed political meetings of our leaders... "That although not a single POV is the same, we have agreed that the weather will likely change frequently and there is still hope for future progress, and a new meeting will be arranged to discuss the issues further." That said, in a final statement, I declare what they call C++ and you refer to that C++ as OO, sucks. Now, well, OK, now that I started to write anyways... what the big mistake is, is in my view that Strouskop (or whatever his name is), and maybe others too, seem to think 'big problems' are things that need to be solved by 'one big program'. If you think that, and would actually try that, then you get huge sources that need to somehow be compiled together, and the thing becomes more and more difficult, and likely impossible, for mere humans, to maintain. This is _not_ how 'big problems' are solved. As I mentioned before, the architect who does not know about stones and concrete, and dreams up a castle. will be in big trouble once building starts. *If* it ever starts, because he may have requested the impossible. I do not know exactly where the limit for a 'big' or a 'small' project is for you, but somebody here mentioned 70k lines of code, maybe 100k, maybe less. In reality something of what _could_ be conceived as a big project, as an example I have here: I want to say 'show ARD' (Ard is a German public broadcaster) and then I want that satellite station to appear on my desktop monitor in full screen, de-interlaced. Now in a way that involves: 1) voice recognition, 2) satellite dish positioning, 3) satellite reception, 4) mpeg2 decoding. 5) mp2 decoding, 5) display, 6) Ceefax (teletext) decoding and display, etc. etc. That would, if you wrote it from scratch, take lot more then say 500k lines of code. But we do not DO it that way, we are smart, and use PROGRAMS to do those essential parts, and Unix (Linux) allows you to chain things together nicely. Also here departs *my* view from what you commonly see in Linux, 'video for Linux' (v4l)..... v4l tries to do all thing by itself, and is therefore always one step behind, as it never supports anything new, as that has not been integrated yet, also an ever changing API, now we are at v4l2, and of course not compatible. I decided to use pipes, and pipe the video stream from one application to the other... A much simpler way, and if you wrote some application, say a filter, or some processing, then you just pipe the stream through it.... So what that boils down to is that you do NOT have one big application, but a whole lot of universally applicable small ones, that are each easy to maintain, and can easily interface with other things in the world, other applications, and hell if you are so inclined you can call these small applications 'objects', buy of course they are not objects, they are different programs, possibly written in different languages, working together to get the job done. In the example I gave you speak into the microphone, that is monitored by 'perlbox voice' (written in you guessed it "perl"), perlbox voice calls the voice recognition suite 'Sphinx2' and the Festival speech synthesiser, both rather large university related projects, Once perlbox recognises the 'show ARD' command, it executes a bash script I wrote called 'show'. The bash script will execute a C program I wrote called 'xdipo' that positions the disk, and then tunes the sat card in the PC to the station ARD (frequency and parameters found in the script), by calling the sat card driver, this driver output the transport stream (.ts that holds all the audio, video, text, etc.. stuff) on /dev/dvb/adapter0/demux0 after tuning it via /dev/dvb/adapter0/frontend0 ... this is then piped to a C program called 'jpinfo' that I wrote that extracts the required streams, that is then piped to the 'xvtx' C program I wrote to display Ceefax (teletext) on screen text if required, that is then piped to xine, a media player written in C++ (I think).... or mplayer (written in C), and those then use the Xwindows system to display it on my screen, and the Alsa sound system to play the sound via the sound card, calling the needed decoders for video and sound. those are written in C and partly asm, and all that runs on top of Linux which is written in C. A million lines of code perhaps (if not more) to 'show ARD'. problems? What problems? Modularity? Right there. Object oriented, not if you use mplayer and not xine... So 'syntactic sugar' is a very polite way to refer to the object oriented paradigm, it comes from wanting to do too much at one time perhaps... maybe, and this is my view, from wanting to do all of the above in one program... Not possible, not in the least because you never have all that knowhow..... Nobody does >?> Nobody ;-) >>> I mentioned linked lists, and people should know those. >>> Guess what Lisp is based on? [quoted text clipped - 22 lines] >somehow be compiled together, and the thing becomes more and more difficult, and likely impossible, >for mere humans, to maintain. I agree with you (for a change). Several others and myself are working on a fairly complex system. We divided the software into several seperate simple programs which share a messaging system and a database. >A much simpler way, and if you wrote some application, say a filter, or some processing, then you just pipe >the stream through it.... This is exactly how Microsoft Directshow works. Its a chain of programs processing audio and/or video. >So what that boils down to is that you do NOT have one big application, but a whole lot of universally applicable small >ones, that are each easy to maintain, and can easily interface with other things in the world, other applications, >and hell if you are so inclined you can call these small applications 'objects', buy of course they are not objects, >they are different programs, possibly written in different languages, working together to get the job done. You just captured the whole meaning of object oriented design. SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >>A much simpler way, and if you wrote some application, say a filter, or >>some processing, then you just pipe the stream through it.... > > This is exactly how Microsoft Directshow works. Its a chain of programs > processing audio and/or video. Except, it's not programs but DLLs which all execute within the application's address space. And the design is heavily OO, with the graph nodes implemented as subclasses of CBaseFilter. >>So what that boils down to is that you do NOT have one big application, >>but a whole lot of universally applicable small ones, that are each easy [quoted text clipped - 5 lines] > > You just captured the whole meaning of object oriented design. Er, not really. That's more a description of modularity in general. OO provides a specific form of modularity through abstraction, i.e. public interface, hidden implementation. Objects are defined by their semantics (what you can do to them) rather than their syntax (what they are made of). The Unix "pipeline" philosophy is contrary to OO, in that it separates the code from the data, so the format of the data must be globally known. OTOH, OO ties the code and data together so that the data is only accessed through its associated code. OO is more about *enforcing* modularity than merely providing it. This allows you to change the "internals" of a component without having to analyse vast amounts of code to see if anything is relying upon the details of the existing implementation. [Unix analogy: the NSS (name-service switch) mechanism allows user and host information to be obtained from plain text files (/etc/passwd, /etc/hosts, etc (no pun intended)), Berkeley DB files, NIS, LDAP, DNS etc. The client just calls e.g. getpwent() rather than parsing /etc/passwd and failing on a system which uses NIS.] Java takes this a step further an uses the encapsulation as a security mechanism. You can pass an object reference to arbitrary code, safe in the knowledge that the recipient can only access the object through the provided interfaces. [Unix analogy: a restricted file which normal (non-root) users can only access via a setuid/setgid binary. E.g. you can't modify /etc/passwd directly, but you can use chsh and chfn to change *your own* shell and full name.] >>>> I mentioned linked lists, and people should know those. >>>> Guess what Lisp is based on? [quoted text clipped - 40 lines] > >You just captured the whole meaning of object oriented design. Could very well be. And object oriented should stop dead right there. Trying to make a programming language object oriented is a fools errand. Object is a worthy abstraction. Carrying it too far is an error, thus c++ is an error. Part of the issue is trying to conflate static languages and dynamic languages, another error. > Now, well, OK, now that I started to write anyways... what the big mistake is, > is in my view that Strouskop (or whatever his name is), and maybe others too, > seem to think 'big problems' are things that need to be solved by 'one big program'. > If you think that, and would actually try that, then you get huge sources that need to > somehow be compiled together, and the thing becomes more and more > difficult, and likely impossible, for mere humans, to maintain. It doesn't need to be a large monolithic executable. If anything, OO is particularly suitable for libraries, as virtual methods make it easy to extend the library without needing to modify the source code. But splitting a program into libraries (or multiple programs) doesn't, by itself, reduce the maintenance burden or the the overall complexity. If all of the libraries fit within a common framework, the system isn't really much different to a monolithic program. If they don't, the system is likely to be even more complex as a result. > I decided to use pipes, and pipe the video stream from one application > to the other... A much simpler way, and if you wrote some application, > say a filter, or some processing, then you just pipe the stream through > it.... There are cases where that imposes an unacceptable performance penalty, as you can't just pass references (pointers) through a pipe; you have to pass the data as well. And you either have to export/import the data to/from a defined protocol, or your internal format becomes the defined protocol, which means that you haven't necessarily modularised anything. It can also become a maintenance nightmare, as you need to extend the protocol in order to add additional data. All modules which process the data have to understand the new protocol, even those which don't use the additional data. OO gets around this by "publishing" the specification while hiding (most of) the implementation details. E.g. you might have a "dictionary" (associative array) class, with methods to add, remove and look-up entries. The implementation could be a B-tree or a hash table or even just an array; code which uses it doesn't need to know the details, and doesn't need to change if the implementation changes. You can even have multiple implementations to allow for different implementations being more efficient for specific use cases, or having additional features, and any code which accepts a dictionary as an argument will work with all implementations, including those which were added later. >> If you think that, and would actually try that, then you get huge sources that need to >> somehow be compiled together, and the thing becomes more and more [quoted text clipped - 9 lines] >really much different to a monolithic program. If they don't, the system >is likely to be even more complex as a result. Actually it does make a difference, you use common 'bricks', like an architect uses the concept of those to build his idea into reality. The manufacturer of the bricks will change and improve his production process, maybe even change the materials used, but the brick spec will stay the same. >> I decided to use pipes, and pipe the video stream from one application >> to the other... A much simpler way, and if you wrote some application, [quoted text clipped - 4 lines] >you can't just pass references (pointers) through a pipe; you have to >pass the data as well. One would think this does, especially for video or multimedia. In practice this does not seem to be the case. Remember even in the drivers, in Linux for example 'copy to user' is used.. for the full data stream. memcpy() is very fast, with little overhead in modern processors. As a real test, no processor temperature increase one can measure from using the above concept. I monitor CPU temp always, as a way to see if the processor has a lot to do... top, xosview, all those tools, check for memory leaks, vmstat. As I am writing this this system is recording C5 from satellite in the UK, while doing time shifted playback with xine (we are in a commercial now), while encoding in a similar way (mcamip) h264 to file, running a web server, and a ftp server with sometimes heavy transient load. And the dns server too. Oh, but it is also playing mp3 in the background, 2 web browsers open, this newsreader, and it controls the home climate system... at the same time, processor load is still very low.. load average is always converging to about 1. Tasks: 126 total, 2 running, 123 sleeping, 0 stopped, 1 zombie Cpu(s): 2.0% us, 6.3% sy, 44.9% ni, 31.4% id, 10.6% wa, 1.7% hi, 3.3% si Hey the recoding pipes do not even show up :-) Pipes are cool. The 2 shown running are the security cam and H264 encoder.... those take some cycles. >And you either have to export/import the data to/from a defined protocol, >or your internal format becomes the defined protocol, which means that you >haven't necessarily modularised anything. You have to agree on a format, like you have to agree on a language when you want to talk to somebody, like agreeing on using English here. Same for applications. You do not normally half way a conversation change language. >It can also become a maintenance nightmare, as you need to extend the >protocol in order to add additional data. 'as'? There is no need to 'change protocol', you have only the data stream, and you can do with that what you want, or split it with 'tee' and feed it to other applications that may change the data stream into other formats, like codecs, there is the top script that decides how the chains are put together, a _true_ top-down approach from that POV, but it could never be created without you knowing what the blocks you use to build the towers can do and stand. To expect a block, or brick to 'be able to everything' because of some mysterious mechanism added to it, is lunacy building, and it will always fail, as bricks should stay bricks and do exactly what they are supposed to do. >All modules which process the >data have to understand the new protocol, even those which don't use the >additional data. >>OO gets around this by "publishing" the specification while hiding >(most of) the implementation details. Well the best of luck with it, no wonder that stuff gets so hopelessly bloated and as I mentioned before, is a dead end street, one with no return, into bloat and disaster. That is what C++ is, and MS is a living, or rather dying (see Vista) example of that. >E.g. you might have a "dictionary" (associative array) class, with methods >to add, remove and look-up entries. The implementation could be a B-tree [quoted text clipped - 6 lines] >argument will work with all implementations, including those which were >added later. Beep, input error. >>>>>Sorry, but this doesn't make any sense to me. OO has nothing to do >>>>>with multi-threading or parallel processing. [quoted text clipped - 7 lines] >Clearly. C++ doesn't include any features specifically related >to concurrency. What languages, besides Ada, do have constructs that deal with concurency? And it must be a language construct, not a common implementation construct. > What languages, besides Ada, do have constructs that deal with > concurency? And it must be a language construct, not a common > implementation construct. Erlang is the current poster child. It uses asynchronous message passing, has awesome performance that scales linearly up to at least hundreds of CPUs, and has been used for more than a decade to build time-critical software (like telephone exchanges for example). There are many functional languages where parallelism doesn't need to be explicit - they are side-effect free so can be automatically parallelised without the programmer even needing to know. Both Erlang and FP require a shift of focus for the programmer, but that's a Good Thing ;-). Clifford Heath. >> What languages, besides Ada, do have constructs that deal with >> concurency? And it must be a language construct, not a common [quoted text clipped - 13 lines] > >Clifford Heath. 1 language identified and verified. Don't think i ever heard of it before. >>Clearly. C++ doesn't include any features specifically related >>to concurrency. >> > What languages, besides Ada, do have constructs that deal with > concurency? And it must be a language construct, not a common > implementation construct. Java has the "synchronized" method qualifier. The language specification also spells out load/store semantics in some detail to ensure consistent semantics for concurrent code. Concurrency was fundamental to Occam, but that's ancient history. Quite a few languages include threading in their standard library (and modern languages tend to put as much as possible into their standard library rather than in the language itself). >>>Clearly. C++ doesn't include any features specifically related >>>to concurrency. [quoted text clipped - 12 lines] >modern languages tend to put as much as possible into their standard >library rather than in the language itself). Thus my limitation. I did not want to hear about C (fork()) and threads let alone heavyweight versus lightweight processes. >>Quite a few languages include threading in their standard library (and >>modern languages tend to put as much as possible into their standard >>library rather than in the language itself). > > Thus my limitation. I did not want to hear about C (fork()) and > threads let alone heavyweight versus lightweight processes. Neither fork() nor pthreads are part of the standard C library as defined by the ANSI/ISO standards. If you exclude language features implemented through the standard library, some languages don't even provide assignment. E.g. in Lisp, assignment is via set/setq/setf functions, not an assignment operator, function definition is via defun, and so on. >>>Quite a few languages include threading in their standard library (and >>>modern languages tend to put as much as possible into their standard [quoted text clipped - 10 lines] >via set/setq/setf functions, not an assignment operator, function >definition is via defun, and so on. Perhaps you will explain to us why Lisp does not provide assignment? What language properties / features causes this to be the case? (Never tried to use Lisp myself.) >>If you exclude language features implemented through the standard library, >>some languages don't even provide assignment. E.g. in Lisp, assignment is [quoted text clipped - 4 lines] > What language properties / features causes this to be the case? > (Never tried to use Lisp myself.) It provides assignment as a function (well, several functions), not as a language feature. The language itself defines the syntax for literal values (integers, strings, lists, ...), and the semantics of evaluation. Evaluating a list calls the function specified by the first element with the remaining elements as arguments; e.g. evaluating (+ 1 2 3) calls the + function with 1,2,3 as arguments, which will return 6. Evaluating (setq x 7) assigns 7 to x. The language itself boils down to: everything except a list evaluates to itself, lists are evaluated as function calls. Everything else (arithmetic, assignment, function definition, conditionals, loops, ...) is implemented by predefined functions. There are no keywords and no infix notation. >>>If you exclude language features implemented through the standard library, >>>some languages don't even provide assignment. E.g. in Lisp, assignment is [quoted text clipped - 20 lines] >implemented by predefined functions. There are no keywords and no infix >notation. Whoosh, i heard that blow by me. Never mind, i can use search tools. >>>> If you exclude language features implemented through the standard library, >>>> some languages don't even provide assignment. E.g. in Lisp, assignment is [quoted text clipped - 20 lines] > > Whoosh, i heard that blow by me. Never mind, i can use search tools. LISP is derived from the lambda calculus, and was at the core of most of the early symbolic algebra packages like REDUCE. In LISP everything is a linked list of functions - and it can be compiled to fast native code. It is exceptionally good for certain types of symbolic programming. WIKI has a short piece on the mathematics which looks superficially OK http://en.wikipedia.org/wiki/Combinatory_logic Unlambda is about as minimalist and cryptic as a Turing complete language can get: http://en.wikipedia.org/wiki/Unlambda Regards, Martin Brown >>>>> If you exclude language features implemented through the standard library, >>>>> some languages don't even provide assignment. E.g. in Lisp, assignment is [quoted text clipped - 36 lines] >Regards, >Martin Brown Can't check it, gasping for air. Oh well, i kinda knew that already. Lambda calculus is on my extensive "to do" list already. >>>>At some point object oriented programming turns out to be very >>>>convenient. [quoted text clipped - 58 lines] >I do not think C++ is anything else then a bad programming style, >a speech disability. Let me up that a bunch. I look at c++ in retrospect in my programming and i conclude that it is a bunch of syntactic heroin. I messes your head and is hellishly addictive, ands degrades your (and mine) ability to write good SW and particularly to write good OO software. >>>>It is possible to use OO programming techniques in plain >>>>C, but it is a pain in the a.s and memory allocation becomes tedious >>>>(just look at the Linux kernel). I will some day. >>>No problem with Linux kernel in C, it would have been super-bloated and dead >>>long time ago if Linus had allowed C++ in it. [quoted text clipped - 51 lines] >>runs on the hardware platform I mentioned above with plenty of space >>to spare. Sounds interesting. I will have to try it. >mmmm >I have the macromedia? flashplayer. >>Even C++ compiler writers could at one point no longer agree what it was about :-) >>In my view you must be complete idiot if you invent 'operator overloading', [quoted text clipped - 11 lines] > (just look at the Linux kernel). Thats where C++ kicks in. I have the > same background but I gradually started to use more and more C++. It's easy enough to implement an OO-style class hierarchy in C. The real kicker is construction and destruction. C++ lets you ensure that an object's constructor is called before anything else uses it, and its destructor is called when it goes out of scope, whether by a return or by an exception. >>I do all my programming in C++ for things that I need to be fast, and >>REXX for other stuff. Coding in REXX is about 10x faster. I wouldn't [quoted text clipped - 5 lines] >C++ is no language, but a speech disability. >Only idiots use C++. You don't need a $2000 carbon fiber fishing pole to catch fish. You just need to know how to fish. John >>>I do all my programming in C++ for things that I need to be fast, and >>>REXX for other stuff. Coding in REXX is about 10x faster. I wouldn't [quoted text clipped - 5 lines] >>C++ is no language, but a speech disability. >>Only idiots use C++. Yup, Yogi Bear does it by hand :-) >You don't need a $2000 carbon fiber fishing pole to catch fish. You >just need to know how to fish. > >John On 16 May, 18:49, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Sat, 16 May 2009 10:17:39 -0700 (PDT), Tim Williams > [quoted text clipped - 206 lines] > > - Show quoted text - Programmers learn to organise the information in their program so that it doesn't swamp out the program itself. Hence, they keep commenting, caps etc to a minimum. It's exactly the same with drawing out a schematic - information is kept to a minimum so it doesn't swamp the circuit, such as not using long power supply or ground lines when a short vcc or gnd label will do. >On 16 May, 18:49, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 215 lines] >circuit, such as not using long power supply or ground lines when a >short vcc or gnd label will do. That makes me yet-again grateful that I'm not a programmer. I comment my code and my schematics. And my breadboards even. I never understood the appeal of destroying information. Is it a job security thing? You'll hate this. Think how much better it would be without comments: .SBTTL . MAXIM : LOAD A SERIAL DAC ; THE MAXIM SERIAL DAC NEEDS 4 BITS OF CONTROL AND 12 BITS ; OF DATA. THE PATTERNS ARE... MAXA = 0000h ; 0ddd LOAD DAC A 10 MHZ XO TRIM MAXB = 1000h ; 1ddd LOAD DAC B 50 MHZ OSC TRIM MAXC = 2000h ; 2ddd LOAD DAC C TRIGGER LEVEL MAXD = 3000h ; 3ddd LOAD DAC D DPLL ADC REF WAKA = 0F000h ; WAKE UP DAC A TRISA = 0F001h ; TRISTATE DAC A WAKB = 0F004h ; WAKE UP DAC B WAKC = 0F008h ; WAKE UP DAC C WAKD = 0F00Ch ; WAKE UP DAC D ; ENTER HERE WITH D4 LOADED WITH A 16-BIT PATTERN, 4 BITS ; OF COMMAND FOLLOWED BY 12 BITS OF DATA. MAXIM: MOVEM.L D4 D7 A2, -(SP) ; PROTECT REGGIES MOVEA.W # PORTD, A2 ; AIM AT THE I/O PORT BMX = 4 ; MAC DAC CS- BITNUM CLK = 2 ; SPI CLOCK DAT = 1 ; SERIAL DATA OUT BCLR.B # CLK, (A2) ; MAKE SURE CLOCK IS LOW AND BCLR.B # BMX, (A2) ; PULL DOWN MAX CS- MOVE.W # 16-1, D7 ; WE'LL BANG 16 BITS LD16: ASL.W # 1, D4 ; TEST A BIT... BCS.S MAX1 ; HOP FOR '1' BCLR.B # DAT, (A2) ; DATA LOW BRA.S MAXCLK MAX1: BSET.B # DAT, (A2) ; DATA HIGH MAXCLK: BSET.B # CLK, (A2) ; POP THE CLOCK HIGH BCLR.B # CLK, (A2) ; AND LOW DBF D7, LD16 ; LOOP FOR 16 BITS BSET.B # BMX, (A2) ; RELEASE CHIP SELECT MOVEM.L (SP)+, D4 D7 A2 RTS John On May 15, 11:27 am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Fri, 15 May 2009 14:34:51 GMT, Jan Panteltje > [quoted text clipped - 181 lines] > > John From what little I remember about C pointers, I believe using subscripts in this case is identical to using pointers. But it's been awhile, so I could be wrong. I am surprised your programmer did not free() the malloc()'ed pointers. Not an issue here, since the program will free() everything upon exiting, but still... Michael >On May 15, 11:27 am, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 187 lines] >subscripts in this case is identical to using pointers. But it's been >awhile, so I could be wrong. The assembly code produced by the C program is only five opcodes, and appears to be about as smart as it can be. The only improvement I can suggest is to count down, not up, so a simple test for zero can end the loop. >I am surprised your programmer did not free() the malloc()'ed >pointers. That was just a test. In the real system, we're going to allocate the buffers (two ADC buffers, one summing buffer) contiguously at startup time and use them forever, shared between various processes. >Not an issue here, since the program will free() everything upon >exiting, but still... Our "exit" is the power switch! John >> On May 15, 11:27 am, John Larkin >> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 5 lines] >>>> I can win maybe 1 second by writing the code a bit different. >>>> And a 3GHz would do it in 12 / 4 = 4 seconds... That is about right for a non-optimising naive native code compiler that saves every loop variable back to memory. When fully optimised to be all in registers the figure should come down to 2.2s or so. >>>> A bigger cache would help a bit perhaps. >>>> A Cray would be even better. [quoted text clipped - 18 lines] >>> DIM A(64000000) AS INTEGER ' INPUT ADC SAMPLES >>> DIM S(64000000) AS LONG ' SUMMING ARRAY There is a small difference between the BASIC and C. You are using signed INTEGERs he is using unsigned. It shouldn't affect the runtime though provided that the C compiler generates the right opcodes. >>> On my computer, a 1.9 GHz Xeon with 2G ram, winXP, I get this >>> result... >>> >>> Start... Done >>> Time per loop 0.231 sec 3.61 ns/add That is believable. Most compilers get between 0.22 and 0.3 depending on how fast the memory subsystem is under sustained sequential access. >>> One of my guys did a C version (I refuse to program in C) to run on >>> the Kontron under Linux, a slightly slower CPU, 2G ram. I asked him >>> for his source code, and he spent about a half hour cleaning it up to >>> be presentable... which I asked him NOT to do. Anyhow, here it is: Have you tested his code on your PC and your code on his embedded system? It could be that DMA transfer of raw data is robbing him of memory bandwidth. Or the Kontron board has other memory speed issues. >>> for (multiply = 0; multiply < 10; multiply ++) // 10 x >>> { >>> for ( index = 0; index < DATA_ARRAY_SIZE; ++index ) >>> sum_data[index] += inbound_data[index]; >>> } It is difficult to see how even the dumbest compiler could get this to take more than 0.5s per loop on modern hardware. Be interesting to see the generated code for this loop. If it looks sensible then we can establish that you are looking at a hardware problem. >>> My program is prettier. Only to boneheaded BASIC hackers. >>From what little I remember about C pointers, I believe using >> subscripts in this case is identical to using pointers. But it's been [quoted text clipped - 4 lines] > suggest is to count down, not up, so a simple test for zero can end > the loop. It is the memory subsystem that isn't performing. You could add additional computation to the loop and it should not affect the timing. Regards, Martin Brown >There is a small difference between the BASIC and C. You are using >signed INTEGERs he is using unsigned. It shouldn't affect the runtime >though provided that the C compiler generates the right opcodes. Since this is signed ADC data, my program is likely to produce better signal averaging. >>>> On my computer, a 1.9 GHz Xeon with 2G ram, winXP, I get this >>>> result... [quoted text clipped - 13 lines] >system? It could be that DMA transfer of raw data is robbing him of >memory bandwidth. Or the Kontron board has other memory speed issues. The original C program summed the data in 0.7 seconds on the Kontron, as against my 0.22 on my Windows PC. They have similar clock rates and both have 2G ram. After a few iterations and mucking with the compiler, he has got his speed down close to mine. It's amusing that a thing this simple, as coded and compiled the obvious way in C, was slow by over 3:1 from my Basic. >>>> My program is prettier. > >Only to boneheaded BASIC hackers. My boneheaded BASIC program is both fast and correct, and is a model for my C programmer to aspire to. I suppose some people prefer C++ code that is elegant, slow, and wrong. But I'm just a simple engineer, so perhaps slow and wrong is a more sophisticated programming methodology these days. >>>From what little I remember about C pointers, I believe using >>> subscripts in this case is identical to using pointers. But it's been [quoted text clipped - 7 lines] >It is the memory subsystem that isn't performing. You could add >additional computation to the loop and it should not affect the timing. Switching to down-counting got me close to 0.2 seconds, so that's about as good as we're going to do. We can move the summing into the acquisition FPGA (which has local DRAM) if we have to, but that would be a real pain to code. John >>On May 15, 11:27 am, John Larkin >><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: [quoted text clipped - 50 lines] >suggest is to count down, not up, so a simple test for zero can end >the loop. The basic program calculates 64 million numbers, the C version 67.1 million. Very short tests are not very usefull to do exact comparison of run times because the OS timers aren't that precise. You should make the test last for at least 20 seconds to cancel effects of task switching. The powerbasic and C version should perform equally. SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- ... > The basic program calculates 64 million numbers, the C version 67.1 > million. Very short tests are not very usefull to do exact comparison > of run times because the OS timers aren't that precise. You should > make the test last for at least 20 seconds to cancel effects of task > switching. The powerbasic and C version should perform equally. You're right! 0x100000 = 1048576; 1048576 x 64 = 67,108,864. Good catch! Michael I tried merging the two arrays into a single array, thinking that this might help the CPU data cache, since the x and y would be right next to each other. Theoretically, the cache should read ahead, and grab both x and y, versus having the two arrays in completely different locations in memory. However, after trying it, it actually runs slower than the original! Original = 1.703 s (best of 3 attempts) Merged = 2.922 s (best of 3 attempts) I'm completely at a loss to explain why it's slower. Maybe someone familiar with the CPU cache can chime in? Compiled with bcc32, running on a dual core Pentium something-or-other laptop. Here's my merged code, modified from Tim Williams' code. #include <stdio.h> #include <stdlib.h> #include <windows.h> #define ARRAY_SIZE 64000000 typedef struct{ int x; short y; } packet; int main(void) { int i, j; int startTime, endTime; packet *arr; if( !(arr = malloc(ARRAY_SIZE * sizeof(packet))) ){ printf("Memory allocation failed.\n"); return -1; } printf("Starting...\n"); startTime = GetTickCount(); for( j=0; j<10; j++ ) for (i = 0; i < ARRAY_SIZE; i++) { arr[i].x += arr[i].y; } endTime = GetTickCount(); printf("Total time taken adding %i array entries: %.3f seconds.\n", ARRAY_SIZE, ((float)(endTime - startTime)) / 1000); free(arr); return 0; } Partial assembly output: ; for( j=0; j<10; j++ ) ; ?live1@96: ; EBX = arr, ESI = startTime xor edx,edx ; ; for (i = 0; i < ARRAY_SIZE; i++) { ; ?live1@112: ; EBX = arr, EDX = j, ESI = startTime @4: xor eax,eax ; ; arr[i].x += arr[i].y; ; ?live1@128: ; EAX = i, EBX = arr, EDX = j, ESI = startTime @6: movsx ecx,word ptr [ebx+8*eax+4] add dword ptr [ebx+8*eax],ecx inc eax cmp eax,64000000 jl short @6 inc edx cmp edx,10 jl short @4 ; ; } ; ; endTime = GetTickCount(); >I tried merging the two arrays into a single array, thinking that this >might help the CPU data cache, since the x and y would be right next [quoted text clipped - 82 lines] > ; > ; endTime = GetTickCount(); What does the "packet" thing do? I can't find it in any of the C or C++ keyword lists. Does it round up the struct size? The loop appears to be crunching 8-byte chunks, so two bytes are dead weight that wastes cache. John > >I tried merging the two arrays into a single array, thinking that this > >might help the CPU data cache, since the x and y would be right next [quoted text clipped - 90 lines] > > John It's a user-defined data structure. Basically, it takes two integers and stores them side-by-side. Let's pretend that we're using 32-bit ints. sizeof(int) = 4 bytes. (It takes 4 bytes to store a 32-bit value... 4x8=32.) By defining a packet, we just have two ints (x and y). 8 bytes to a packet. The idea was just to have them closer together, so that the CPU cache could access them more easily (they're side-by-side, vs. two arrays in random areas of memory.) If the CPU wanted to download 256 bytes of data from memory to cache, it could get 256 divided by 8 packets, or 32 packets at a time sent to faster cache memory. But what surprises me is that this arrangement actually slows down the code. The assembly output isn't much different from Tim Williams' original - it still looks something like movsx ecx,word ptr [somewhere] add dword ptr [somewhere_else],ecx My assembly language experience ends somewhere with the 386, so cache hit/miss is beyond my area of expertise. Sorry. But I thought it might shine a light on a path worth of exploration. Michael > On May 20, 6:57 pm, John Larkin > [quoted text clipped - 120 lines] > > Michael That's odd... I'd expect the assembly output to be movsx ecx,Dword ptr [somewhere] instead of word ptr [somewhere]... double-word. Hmm... Michael >> >I tried merging the two arrays into a single array, thinking that this >> >might help the CPU data cache, since the x and y would be right next [quoted text clipped - 96 lines] >Let's pretend that we're using 32-bit ints. sizeof(int) = 4 bytes. >(It takes 4 bytes to store a 32-bit value... 4x8=32.) But we're not using 32-bit ints. The input is 16-bit signed ADC data and the summing array is 32 bit signed ints. So padding the array up to 8 bytes is a waste of cache and memory bandwidth. And besides, as noted, we are DMAing the ADC data into a contiguous memory buffer and don't have time to move it into slots in another structure. And besides, I suspect that having more cache windows onto the RAM arrays is faster. >By defining a packet, we just have two ints (x and y). 8 bytes to a >packet. [quoted text clipped - 14 lines] >hit/miss is beyond my area of expertise. Sorry. But I thought it >might shine a light on a path worth of exploration. What would halp would be if we could be doing the add loop on two chunks of cache while others were being transferred to/from memory. I'm sure this can be done, but I don't know how. John >> I tried merging the two arrays into a single array, thinking that this >> might help the CPU data cache, since the x and y would be right next [quoted text clipped - 8 lines] >> I'm completely at a loss to explain why it's slower. Maybe someone >> familiar with the CPU cache can chime in? My first instinct was that it might have created an object where indexing was in multiples of 6 bytes, but it has correctly padded to 8. The explanation is that with two distinct arrays you have something else to do inside the loop whilst waiting for the cache to load. The structure you have created hits the same block again far too quickly and so ends up waiting on both every time. Worse when the write through cache is active your read from the second chunk in the same dirty cache line are compromised. Because data lengths are different part way through the old loop with the original code the movsx 16 bit fetch becomes available in cache. The 32 bit fetches and stores are always running ahead of the caches ability to satisfy them. The standard method for cache aware algorithms is to work on as many distinct cache blocks simultaneously as the architecture will allow. That way you are using the delay time of the first fetch constructively. I have to say on the newest Pentiums there is almost no difference. None of the tricks I know will speed it up significantly past 0.22s on my box. There isn't enough work being done inside the inner loop. >> ; arr[i].x += arr[i].y; >> ; [quoted text clipped - 15 lines] > What does the "packet" thing do? I can't find it in any of the C or > C++ keyword lists. Creates a user defined type 8 bytes long containing a .x and a .y > Does it round up the struct size? The loop appears to be crunching > 8-byte chunks, so two bytes are dead weight that wastes cache. Although it might waste cache space having matched size operands in separate arrays might still be faster - SIMD vector instructions are better for that case. SSE 128bit registers can do 4 parallel 32 bit adds moving 16 bytes at a time. You would need to test it. Regards, Martin Brown >>> I tried merging the two arrays into a single array, thinking that this >>> might help the CPU data cache, since the x and y would be right next [quoted text clipped - 64 lines] >Regards, >Martin Brown It's interesting that people seem to be converging to around 0.22 seconds on various machines. I guess we all buy the same DRAM chips. My down-count loop, in Basic, is hitting about 0.207 or so. John >> Although it might waste cache space having matched size operands in >> separate arrays might still be faster - SIMD vector instructions are [quoted text clipped - 3 lines] > It's interesting that people seem to be converging to around 0.22 > seconds on various machines. I guess we all buy the same DRAM chips. It is dominated by memory speed under sustained sequential access. Has anyone tried it on a box with DDR3 ram? > My down-count loop, in Basic, is hitting about 0.207 or so. It would be interesting to see the code it has generated. I see only a tiny difference at all between counting up and counting down. There is a slight gain in doing the opposite of your initialisation code since then the cache will be preloaded with useful data first time around. It would also be interesting in a curious sort of way to see the code that gcc without optimisation generated that was so incredibly slow. It was way off the mark at 0.7s if the box was capable of 0.2s (even the Mickeysoft compiler manages 0.4s without any optimisation). I changed my initialisation code to count down so that the cache would be preloaded with relevant data at the begining. It helps on the older P4s but does nothing at all on the fastest new box. Regards, Martin Brown >>> Although it might waste cache space having matched size operands in >>> separate arrays might still be faster - SIMD vector instructions are [quoted text clipped - 13 lines] >slight gain in doing the opposite of your initialisation code since then >the cache will be preloaded with useful data first time around. The difference is that a branch-not-zero is faster than an immediate compare. Any time you programmers need help understanding how computers work, feel free to ask an engineer. John >>>> Although it might waste cache space having matched size operands in >>>> separate arrays might still be faster - SIMD vector instructions are [quoted text clipped - 6 lines] >> >>> My down-count loop, in Basic, is hitting about 0.207 or so. >> It would be interesting to see the code it has generated. I see only a >> tiny difference at all between counting up and counting down. There is a [quoted text clipped - 3 lines] > The difference is that a branch-not-zero is faster than an immediate > compare. In the stone age that was true. But on the latest CPUs with sophisticated branch prediction, out of order and speculative execution the time to compute the immediate compare is invisible. This is particularly true in this case where the loop doesn't contain enough other computational work to absorb the memory access time. The only way to speed it up is to either vectorise it with SIMD SSE instructions or add judicious prefetch cache hints to the loop code. Branch target alignment to 32 bytes might also help. Most of these tricks have limited utility on the latest quad cores, but they do help on earlier P4 models. > Any time you programmers need help understanding how computers work, > feel free to ask an engineer. You have shot yourself in the foot with this cheap jibe. It is now very clear for all to see that you do not have the first clue about how things execute on modern Intel CPUs. BASIC hacker mentality. It is you who needs to ask an expert. In case you feel inclined to "get a clue" the relevant Intel optimisation manuals are at: http://www.intel.com/products/processor/manuals/index.htm The one you want is right at the bottom titled "Intel® 64 and IA-32 Architectures Optimization Reference Manual" Regards, Martin Brown >>>>> Although it might waste cache space having matched size operands in >>>>> separate arrays might still be faster - SIMD vector instructions are [quoted text clipped - 20 lines] >particularly true in this case where the loop doesn't contain enough >other computational work to absorb the memory access time. Nice in theory, wrong in practise. Try it. >The only way to speed it up is to either vectorise it with SIMD SSE >instructions or add judicious prefetch cache hints to the loop code. [quoted text clipped - 9 lines] >clear for all to see that you do not have the first clue about how >things execute on modern Intel CPUs. BASIC hacker mentality. Try it. I went from 0.225 seconds to 0.207 by counting down. John >>>>>> Although it might waste cache space having matched size operands in >>>>>> separate arrays might still be faster - SIMD vector instructions are [quoted text clipped - 10 lines] >>>> slight gain in doing the opposite of your initialisation code since then >>>> the cache will be preloaded with useful data first time around. >>> The difference is that a branch-not-zero is faster than an immediate >>> compare. A typical spurious Larkin just so story. Arguing from ignorance. Branch prediction and speculative execution on these CPUs is so good that they only mispredict on the final termination before loop exit. >> In the stone age that was true. But on the latest CPUs with >> sophisticated branch prediction, out of order and speculative execution [quoted text clipped - 3 lines] > > Nice in theory, wrong in practise. Try it. I did. Theory and practice agree just fine here. The differences between CPUs though even in the Core 2 family is startling even on the relatively small sample I have immediately to hand. There is absolutely no measurable difference between a count up or count down assembler loop on a Core2 Quad, Core 2 Duo or P4. There is enough slack with the faster CPUs to hide 3 immediate operand instructions without altering the loop timing at all (just detectable on a P4 3GHz). Fastest on the Core 2 Q6600 was the modern array style indexing mov eax, [edi+4*ecx] etc at 2.159 +/- 0.008 This is typical of modern compiler output for x86. Runner up was the cache aware algorithm at 2.190 +/- 0.007 Obvious simple pointer based loop gave 2.233 +/- 0.007 Cutting out word aligned 16 bit reads gave 2.215 +/- 0.008 Loop unrolling slowed it down to 2.250 SIMD was slowest of all at 2.288 (very disappointing) The big surprise was the portable Mobile Core 2 Duo T5200 @ 1.6GHz SIMD was fastest at 2.356 +/- 0.020 Array style indexing next at 2.420 +/- 0.010 Pointer loop using addition 2.450 +/- 0.012 Pointer loop using LOOP 3.225 +/- 0.026 !!!! *Big* surprise using LOOP instruction on this older Core2 CPU slowed things down by a massive 0.8s. I repeated it several times as I didn't believe it at first. But it is a solid result. On older and weaker CPUs the SIMD and cache aware code did better. >> The only way to speed it up is to either vectorise it with SIMD SSE >> instructions or add judicious prefetch cache hints to the loop code. [quoted text clipped - 9 lines] > > Try it. I went from 0.225 seconds to 0.207 by counting down. You have no idea what you are talking about. It is some coincidental change in the generated code (possibly use of LOOP instruction to count down). If you knew how to examine the generated code you would have done so by now. But instead you keep harping on about the magical properties of Power Basic. I grant you its code generator must be fairly good - but the timing pattern on the latest CPUs is extremely flat. In other words any half way reasonable loop construct executes much faster than the memory subsystem can supply the data to work on. Evidence is that it is the write back to main memory that is causing all the problems. The code generated is all that matters going up or down memory makes no difference at all. There is more than enough slack in the loop timing. It is utterly dominated by memory access delays. Regards, Martin Brown >>>>>>> Although it might waste cache space having matched size operands in >>>>>>> separate arrays might still be faster - SIMD vector instructions are [quoted text clipped - 89 lines] >difference at all. There is more than enough slack in the loop timing. >It is utterly dominated by memory access delays. Not utterly. Unless you use some sort of cache prodding to keep the memory bus 100% busy, memory transfers will studder a bit as the add loop works on blocks of cache, and loop speed will affect overall timing somewhat. It would be fun to scope the dram chip selects to see the exact pattern, but I have other priorities. I'm running a 1.87 GHz dual-core Xeon (HP ProLiant "server", 2G ram) Xp Pro, PowerBasic v4. I get 0.225 average summing time counting up, 0.207 counting down. "A typical spurious Larkin just so story. Arguing from ignorance." Ignorance? I ran two versions of a program and measured the execution times. Does that violate the protocols of computer science? John >>>>>>> Although it might waste cache space having matched size operands in >>>>>>> separate arrays might still be faster - SIMD vector instructions are [quoted text clipped - 92 lines] >Regards, >Martin Brown Thank you for taking the time to do the tests that prove what has already been discussed. On May 21, 1:03 am, Martin Brown <|||newspam...@nezumi.demon.co.uk> wrote: > >> I tried merging the two arrays into a single array, thinking that this > >> might help the CPU data cache, since the x and y would be right next [quoted text clipped - 64 lines] > Regards, > Martin Brown Will have to learn the SIMD instructions. I didn't think I had an assembler that could handle even MMX, but apparently FreeBASIC can... DIM i AS long i = 0 asm mov eax,1 cpuid and edx,8388608 mov cl,23 shr edx,cl mov [i],edx end asm if i = 1 then print "You have MMX" else print "No MMX" end if Thanks, Michael > Will have to learn the SIMD instructions. I didn't think I had an > assembler that could handle even MMX, but apparently FreeBASIC can... Interestingly, I got SSE2 code for the inner loop when compiling the C code below with gcc 4.3.2 and -O3 -march=core2. The C code was from John Devereux in the PowerBasic Rocks! thread, just changed a little to print out the time per addition. Oh yeah, doesn't seem to run any faster than "normal" code with addls and movls... Here's the assembler output for the summing loops: xorl %edx, %edx .p2align 4,,10 .p2align 3 .L2: xorl %eax, %eax .p2align 4,,10 .p2align 3 .L3: movdqa a(%eax), %xmm0 paddd s(%eax), %xmm0 movdqa %xmm0, s(%eax) addl $16, %eax cmpl $256000000, %eax jne .L3 incl %edx cmpl $10, %edx jne .L2 And the C code: #include <stdio.h> #include <stdlib.h> #define SIZE 64000000 int s[SIZE]; int a[SIZE]; int main(int argc, char **argv) { unsigned start_usecs, current_usecs, diff_usecs; struct timeval start_timeval, current_timeval; /* get start time */ gettimeofday(&start_timeval, NULL); int x,y; /* The Loop */ for(y=0;y<10;y++) { for(x=0;x<64000000;x++) { s[x] = s[x] + a[x]; } } /* get elapsed time */ gettimeofday(¤t_timeval, NULL); /* calculate the difference */ current_usecs = current_timeval.tv_usec + (1000000 * current_timeval.tv_sec); start_usecs = start_timeval.tv_usec + (1000000 * start_timeval.tv_sec); diff_usecs = current_usecs - start_usecs; fprintf(stderr, "Time used is %d us (%.4f s).\n", diff_usecs, (float) diff_usecs / 1000000.0); fprintf(stderr, "Time used per add is %.4f ns.\n", (float)diff_usecs / 640000.0); fprintf(stderr, "Ready\n"); exit(0); } >> Will have to learn the SIMD instructions. I didn't think I had an >> assembler that could handle even MMX, but apparently FreeBASIC can... [quoted text clipped - 70 lines] > exit(0); >} Actually the largest part of that original C code is from me :-) You can see that from the use of gettimeofday and the subtraction in us. >>> Will have to learn the SIMD instructions. I didn't think I had an >>> assembler that could handle even MMX, but apparently FreeBASIC can... [quoted text clipped - 55 lines] >> } >> Anyone tried to unroll this loop a little? for(x=0;x<64000000;x+4) { s[x] = s[x] + a[x]; s[x+1] = s[x+1] + a[x+1]; s[x+2] = s[x+2] + a[x+2]; s[x+3] = s[x+3] + a[x+3]; } It could reduce the overhead caused by the for loop. SignatureFailure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" -------------------------------------------------------------- >Anyone tried to unroll this loop a little? > [quoted text clipped - 7 lines] > >It could reduce the overhead caused by the for loop. Very clever! It runs indeed faster hre, I tried a shorter version as I do not have that much RAM on the eeePC, and the old one takes 0.6787 seconds, the new one 0.6684 On the Duron 950 I get this (test13 is the old code, test3 your code): Time used is 1257384 us (1.2574 s). Ready grml: ~ # ./test13 memory needed=38 MB mem=0x8c7e940 b=0x8049940 Time used is 1235997 us (1.2360 s). Ready grml: ~ # ./test13 memory needed=38 MB mem=0x8c7e940 b=0x8049940 Time used is 1254768 us (1.2548 s). Ready grml: ~ # ./test3 memory needed=38 MB mem=0x8c7e960 b=0x8049960 Time used is 1153958 us (1.1540 s). Ready grml: ~ # ./test3 memory needed=38 MB mem=0x8c7e960 b=0x8049960 Time used is 1146680 us (1.1467 s). Ready grml: ~ # ./test3 memory needed=38 MB mem=0x8c7e960 b=0x8049960 Time used is 1117692 us (1.1177 s). This is the code I uesed to test: #include <stdio.h> #include <stdlib.h> #include <limits.h> //#define BIG_SIZE 64000000 #define BIG_SIZE 6400000 int32_t mem[BIG_SIZE]; int16_t b[BIG_SIZE]; int main(int argc, char **argv) { int i, j; struct timeval *start_timeval; struct timeval *current_timeval; unsigned long lstart_usecs, lcurrent_usecs, ldiff_usecs; fprintf(stderr, "memory needed=%d MB\n", ( (BIG_SIZE * sizeof(int32_t) ) + (BIG_SIZE * sizeof(int16_t) ) ) / 1000000 ); fprintf(stderr, "mem=%p\n", mem); fprintf(stderr, "b=%p\n", b); start_timeval = malloc(sizeof(struct timeval) ); if(! start_timeval) { fprintf(stderr, "could not allocate space for start_timeval, aborting.\n"); exit(1); } current_timeval = malloc(sizeof(struct timeval) ); if(! current_timeval) { fprintf(stderr, "could not allocate space for current_timeval, aborting.\n"); exit(1); } /* get start time */ gettimeofday(start_timeval, NULL); #define OLD_CODE #ifdef OLD_CODE for(j = 0; j < 10; j++) { for(i = 0; i < BIG_SIZE; i++) { mem[i] += b[i]; } } #else for(j = 0; j < 10; j++) { for(i = 0; i < BIG_SIZE; i += 4) { mem[i] = mem[i] + b[i]; mem[i + 1] = mem[i + 1] + b[i + 1]; mem[i + 2] = mem[i + 2] + b[i + 2]; mem[i + 3] = mem[i + 3] + b[i + 3]; } } #endif // ! OLD_CODE /* get elapsed time */ gettimeofday(current_timeval, NULL); /* calculate the difference */ lcurrent_usecs =\ current_timeval -> tv_usec + (1000000 * current_timeval -> tv_sec); lstart_usecs =\ start_timeval -> tv_usec + (1000000 * start_timeval -> tv_sec); ldiff_usecs = lcurrent_usecs - lstart_usecs; fprintf(stderr, "Time used is %d us (%.4f s).\n", ldiff_usecs, (float)ldiff_usecs / 1000000.0); fprintf(stderr, "Ready\n"); exit(0); } In other languages-- Compiled in FreeBASIC version 0.17b. -=-=- '$DYNAMIC DIM a(64000000) AS SHORT DIM s(64000000) AS INTEGER DIM i AS INTEGER Start! = TIMER FOR i = 0 TO 63999999 s(i) += a(i) NEXT PRINT USING "One pass in ##.### seconds."; TIMER - Start!; -=-=- Typical output: E:\PROGRA~1\FreeBASIC>test One pass in 1.439 seconds. E:\PROGRA~1\FreeBASIC>test One pass in 1.818 seconds. So it offers fairly similar performance. I would suppose PowerBasic is also comparable. Now, I could write the 16 bit assembly version and test that, too, but the 16 bit part would be kind of tricky given the dataset size. ;-) I could test a million loop iterations, but the whole thing would still fit inside processor cache, so it's not a fair comparison. Tim > The run time in C is 13 seconds here on a 1GHz processor. > Can you specify your 'old HP computer' ? [quoted text clipped - 10 lines] > > Seems to me anyways :-) >In other languages-- > [quoted text clipped - 30 lines] > >Tim Ah, a free-basic! I did a google, and downloaded the Linux version. But: test9.bas(1) error 135: Only valid in -lang deprecated or fblite or qb, found 'DYNAMIC' in ''$DYNAMIC' test9.bas(2) warning 24(2): Array too large for stack, consider making it var-len or SHARED test9.bas(3) warning 24(2): Array too large for stack, consider making it var-len or SHARED test9.bas(6) error 137: Suffixes are only valid in -lang deprecated or fblite or qb, found 'Start' in 'Start! =3D TIMER' test9.bas(7) error 12: Expected 'TO' in 'FOR i =3D 0 TO 63999999' test9.bas(7) error 3: Expected End-of-Line, found 'TO' in 'FOR i =3D 0 TO 63999999' test9.bas(8) error 3: Expected End-of-Line, found 'a' in 's(i) +=3D a(i)' test9.bas(11) error 137: Suffixes are only valid in -lang deprecated or fblite or qb, found 'Start' in 'PRINT USING "One pass in ##.### seconds."; TIMER - Start!;' Not enough memory (385 MB) on this PC. Nice BASIC anyways. DIM i AS INTEGER FOR i = 0 TO 10 print "HELLO" NEXT grml: ~ # fbc test10.bas grml: ~ # ./test10 HELLO HELLO HELLO HELLO HELLO HELLO HELLO HELLO HELLO HELLO HELLO LOL I once had some BASIC programs for inductors and stuff... Maybe all gone, CP/M and Sinclair times.. WOW! Have not used BASIC is ages... > On a sunny day (Fri, 15 May 2009 12:09:38 -0700 (PDT)) it happened Tim > Williams <tmoran...@gmail.com> wrote in [quoted text clipped - 39 lines] > But: > test9.bas(1) error 135: Only valid in -lang deprecated or fblite or qb, found 'DYNAMIC' in ''$DYNAMIC' Ah yes, I think I use -lang qb, something like that. Call me old skool. :-p Without the dynamic allocation, the rest of the errors figure... > found 'Start' in 'Start! =3D TIMER' Say, what's the "3D" in this showing up for? Did you copy&paste wrong, or did my message get encoded stupid, or did yours? > WOW! Have not used BASIC is ages... I use it fairly regularly. Despite being DOS, an exorbitantly inefficient environment, it still runs on XP, and does things that (in lieu of a similarly powerful scripting language) are satisfactory for my purposes. I could do C, but I don't know it nearly as well as I know QuickBasic. Tim >Without the dynamic allocation, the rest of the errors figure... > >> found 'Start' in 'Start! =3D TIMER' > >Say, what's the "3D" in this showing up for? Did you copy&paste >wrong, or did my message get encoded stupid, or did yours? Yes, copy and paste, but I left it as it had not enough stack space anyways,,, >> WOW! Have not used BASIC is ages... > [quoted text clipped - 5 lines] > >Tim BASIC is so simple to use, but I have so much C code and apps written now that complicated things like networking would take me a hard time in BASIC. But this one is nice to have around for doing some quick calculations I think. There are so many of those high level languages with powerful networking around these days,,, C is for me some universal thing that does it all without me having to learn yet an other language. >>Without the dynamic allocation, the rest of the errors figure... >> [quoted text clipped - 22 lines] >C is for me some universal thing that does it all without me having to learn >yet an other language. ' EPORT : OPEN TCP/IP PORT AS # 8 EPORT: TCP CLOSE # 8 ' NUKE ANY OPEN ETHERNET COMM CLOSE # 1 ' OR SERIAL PORT CPORT% = 0 LOCATE 18, 1 PRINT " Default IP address = "; IP1$ PRINT " Enter IP address, D for Default : "; LINE INPUT IP$ IF UCASE$(IP$) = "D" THEN IP$ = IP1$ IF IP$ = "" THEN GOTO TOP ERRCLEAR TCP OPEN PORT 2000 AT IP$ AS # 8 TIMEOUT 50 CPORT% = 8 IF ERR THEN LOCATE 22, 10: PRINT "TCP OPEN ERROR" SLEEP 2000 CPORT% = 0 END IF TCP RECV #8, 2000, B$ ' FLUSH THE TCP BUFFER! GOTO TOP and then later, you can... ' CHECK FOR INCOMING TRAFFIC FROM T344... TANK: RPLY$ = "" IF CPORT% = 8 THEN TCP RECV #8, 1, RPLY$ ' GET ONE (!) ETHERNET BYTE ELSE N& = COMM (#1, RXQUE) ' SERIAL: CHECK BUFFER CONTENTS IF N& THEN COMM RECV #1, 1, RPLY$ ' GET ONE BYTE FROM BUFFER END IF This is insanely easy. PB can also, easily, do UDP, SMPT, all that stuff. And all the tools are inherent to the language, not external libraries. Which means everything is clearly documented, both in manuals and in the built-in Help thing. All it does is work. John >>>Without the dynamic allocation, the rest of the errors figure... >>> [quoted text clipped - 83 lines] > >John That is very nice, never knew a BASIC could do that. >>>Without the dynamic allocation, the rest of the errors figure... >>> [quoted text clipped - 83 lines] > >John I guess you are having fun with it. I found this example to be one of the most opaque things that i have ever seen. Ugly as well. Just remember over half of programmers / engineers / instructors / managers / technicians / etc., are not very good at what they do. >>>>Without the dynamic allocation, the rest of the errors figure... >>>> [quoted text clipped - 86 lines] >I guess you are having fun with it. I found this example to be one of >the most opaque things that i have ever seen. Only opaque to people who can't read BASIC. >Ugly as well. So show us some of your beautiful TCP/IP code. Or any of your beautiful code. The BASIC code is part of my test/cal program for this, http://www.highlandtechnology.com/DSS/T346DS.html and it works great. As does the product, run by about 7K lines of assembly coded by yours truly. Zero bugs in the first release. You'd probably think it's ugly, too. I've got a guy who wants 50 of them to replace a bunch of racks full of 20-year-old HP gear that they can't maintain any more. We'll save him about 50:1 on both volume and power consumption. >Just remember over half of programmers / engineers / instructors / >managers / technicians / etc., are not very good at what they do. Well over half. What are you good at? John >>>>>Without the dynamic allocation, the rest of the errors figure... >>>>> [quoted text clipped - 93 lines] >So show us some of your beautiful TCP/IP code. Or any of your >beautiful code. I don't have any, just functional code. >The BASIC code is part of my test/cal program for this, > [quoted text clipped - 11 lines] > >Well over half. What are you good at? Along the way i built a lot of one off screwball test sets that did the job reliably and accurately. Many contained asm code. I wrote code in a lot of languages that worked and was not ugly, some of it is hitting the 20 useful years mark, no maintenance required. Currently i review other engineers work and develop specifications and standards in my PPoE. >John > In other languages-- > [quoted text clipped - 20 lines] > E:\PROGRA~1\FreeBASIC>test > One pass in 1.818 seconds. I get really weird time printouts with that. Using FreeBasic 0.18. time ./test One pass in 19.935 seconds. ./test 0.26s user 0.18s system 95% cpu 0.453 total >> In other languages-- >> [quoted text clipped - 26 lines] >One pass in 19.935 seconds. >./test 0.26s user 0.18s system 95% cpu 0.453 total That would be (I guess is) weird. > In other languages-- > [quoted text clipped - 23 lines] > So it offers fairly similar performance. I would suppose PowerBasic > is also comparable. Wow a free basic... I feel like a kid again. Thanks. Michael On May 22, 9:34 am, mrdarr...@gmail.com wrote: > > In other languages-- > [quoted text clipped - 27 lines] > > Michael I like the Asm Out option (-r). Compiled with the -lang qb option and ran. C:\files\per\FREEBA~1\code>test One pass in 0.006 seconds. C:\files\per\FREEBA~1\code>test One pass in -0.005 seconds. -0.005 seconds, huh? That made me smile. assembly output: .Lt_0009: cmp word ptr [ebp-76], -28673 jle .Lt_000C -28673, huh? How to force long integers in qb... ah well. Something to do. Thanks. Michael On May 22, 9:47 am, mrdarr...@gmail.com wrote: > On May 22, 9:34 am, mrdarr...@gmail.com wrote: > [quoted text clipped - 52 lines] > > Michael Ah that's better... -lang fblite C:\files\per\FREEBA~1\code>..\fbc -lang fblite test.bas C:\files\per\FREEBA~1\code>..\fbc -r -lang fblite test.bas C:\files\per\FREEBA~1\code>test Ten passes in 3.178 seconds. C:\files\per\FREEBA~1\code>test Ten passes in 3.213 seconds. C:\files\per\FREEBA~1\code>test Ten passes in 3.221 seconds. C:\files\per\FREEBA~1\code> Michael > The run time in C is 13 seconds here on a 1GHz processor. > Can you specify your 'old HP computer' ? > > I can win maybe 1 second by writing the code a bit different. > And a 3GHz would do it in 12 / 4 = 4 seconds... > A bigger cache would help a bit perhaps. For adding arrays, memory bandwidth will be the dominant factor. The ALU will spend most of its time idle, waiting upon memory I/O. And if you don't have 512MB of RAM (64M * 2 * 4), then you're going to be swapping, which will totally kill performance. >> The run time in C is 13 seconds here on a 1GHz processor. >> Can you specify your 'old HP computer' ? [quoted text clipped - 8 lines] >And if you don't have 512MB of RAM (64M * 2 * 4), then you're going to >be swapping, which will totally kill performance. ./test2 memory needed=384 MB This because it is (64M * 4) + (64M * 2). From in C: fprintf(stderr, "memory needed=%d MB\n", ( (BIG_SIZE * sizeof(int32_t) ) + (BIG_SIZE * sizeof(int16_t) ) ) / 1000000 ); Plus you need some for the OS and loaded modules, but not much in Linux. > The run time in C is 13 seconds here on a 1GHz processor. > Can you specify your 'old HP computer' ? > > I can win maybe 1 second by writing the code a bit different. > And a 3GHz would do it in 12 / 4 = 4 seconds... > A bigger cache would help a bit perhaps. runtime in C on a 2.4Ghz "intel core2 duo" machine is about 3 seconds. about 2 when multithreaded. > > A Cray would be even better. dunno about that, those beasts are maninly focussed on floating point performance, and this is an integer problem. > What does you C code look like? Mine is in the other posting. here's the multithreaded one I used #include <stdio.h> #include <stdlib.h> #include <time.h> #include <pthread.h> static long S[64000000]; static short A[64000000]; typedef struct argstype { short *a_start; long *s_start; long count; } argstype; static void *thread_func(void *vptr_args) { argstype *arg=vptr_args; { long *sp=arg->s_start; short *ap=arg->a_start; long x=arg->count; do *sp++ += *ap++; while (--x); } return NULL; } int main(int argc,char **argv) { long y,n; n=10; if(argc>1) n=atoi(argv[1]); for(y=0;y<n;++y) { argstype instance_a={A,S,32000000}; argstype instance_b={A+32000000,S+32000000,32000000}; pthread_t thread_a; // start a thread to process half the data if (pthread_create(&thread_a, NULL, thread_func, &instance_a) != 0) { perror("pthread_create"); return EXIT_FAILURE; } // process the other half in the foreground thread_func(&instance_b); // wait for the thread to finish. if (pthread_join(thread_a, NULL) != 0) { perror("pthread_join"); return EXIT_FAILURE; } } return 0; } >> The run time in C is 13 seconds here on a 1GHz processor. >> Can you specify your 'old HP computer' ? [quoted text clipped - 10 lines] >dunno about that, those beasts are maninly focussed on floating point >performance, and this is an integer problem. Cray was (maybe still is?) a vector processing hardware platform. With vector processing I mean this: memory add memory memory address counter So basically clock from one memory into the next via the adder. That is very very fast for huge data sets that all need the same operation. I have done some hardware like that :-) No memory has 'float', it is all integers of some size :-) >> What does you C code look like? Mine is in the other posting. > [quoted text clipped - 62 lines] > return 0; >} OK, I tried that, gcc -o test10 test10.c -lpthread but it wont run on the eeePC, it simply says: Killed Looks like 512 MB is not enough :-) And only one core of course. On an other PC with 385964k RAM it starts swapping: ~# nice -n -19 ./test10 nice -n -19 ./test10 19.25s user 0.63s system 99% cpu 20.046 total > The run time in C is 13 seconds here on a 1GHz processor. > Can you specify your 'old HP computer' ? [quoted text clipped - 10 lines] > > Seems to me anyways :-) This may be of interest. http://www.gamedev.net/reference/articles/article1698.asp Free online version of Michael Abrash's optimization strategies. Michael >> The run time in C is 13 seconds here on a 1GHz processor. >> Can you specify your 'old HP computer' ? [quoted text clipped - 17 lines] > >Michael Nice site :-) Too bad the moron did everythin gin .pdf that loads slow and is useless in a browser. Blame that o adobe (WTF source code in pdf??????). So I deleted that bookmark again. > On a sunny day (Tue, 9 Jun 2009 16:01:21 -0700 (PDT)) it happened > mrdarr...@gmail.com wrote in [quoted text clipped - 26 lines] > Blame that o adobe (WTF source code in pdf??????). > So I deleted that bookmark again. You're impatient. Consider that the book, new, costs US$100+ on amazon.com. In Firefox I just right-click, Save Link As. I did it while reading the various chapters. Check out Chapter 6, and re-evaluate whether this is junk to you. I had no idea the LEA instruction could add so efficiently. http://downloads.gamedev.net/pdf/gpbb/gpbb6.pdf Michael >> Nice site :-) >> Too bad the moron did everythin gin .pdf that loads slow and is useless i= [quoted text clipped - 14 lines] > >Michael So I looked up that chapter. But you know. these days, I write in C, and use gcc as compiler. I have come to trust gcc, its code generation, its libraries. So I could not care less if the processor targeted (I use other platforms then x86 too) had a hardware instruction to do every thing my program needs, As long the as the compiler knows it :-) This is the advantage of C, or as J. Larkin would state: 'Power BASIC', or any high level language. I did some asm programming of x86 in the long ago past, but since 486 DX2 66 MHz I have not kept up with what Intel did, and do not care. The only time I may ever look at x86 or similar complex processor's asm is for fun at the gcc output to see what it generates. I use asm on PIC (only asm, I have that C compiler, but asm is closer to the hardware for me). In my view with good compilers for the sort of thing I do no asm is needed. It may be needed if you write a codec and need max speed perhaps. There are several useful graphics APIs that can be called from C. How fast do you have to go anyways? The latest H264 encoders use Nvidia graphics cards as hardware accelerator. that is so specialised, if you design that sort of soft, then yes, maybe you need to be wizard in x86 asm: http://www.mediacoderhq.com/ Do they use asm? perhaps? > How fast do you have to go anyways? > The latest H264 encoders use Nvidia graphics cards as hardware accelerator. > that is so specialised, if you design that sort of soft, then yes, maybe > you need to be wizard in x86 asm: > http://www.mediacoderhq.com/ > Do they use asm? perhaps? I don't know about them, but to my knowledge ffmpeg and mplayer use a lot of asm. As far as I know, there isn't much of automatic vectorization in C compilers either, so any non-trivial use of SSE and such needs hand coded assembly. OTOH, I think there was a fairly recent "survey" on slashdot about assembly. The result was that few slashdot readers use it, but then I read it as "slashdot reading perl and php coders don't use assembly". Kind of no brainer... >> How fast do you have to go anyways? >> The latest H264 encoders use Nvidia graphics cards as hardware accelerator. [quoted text clipped - 5 lines] >I don't know about them, but to my knowledge ffmpeg and mplayer use a >lot of asm. Yes, those do. And I use ffmpeg mplayer :-) Those are just building blocks. I use libmpeg3 too.... >As far as I know, there isn't much of automatic vectorization in C >compilers either, so any non-trivial use of SSE and such needs hand >coded assembly. >OTOH, I think there was a fairly recent "survey" on slashdot about >assembly. The result was that few slashdot readers use it, but then I >read it as "slashdot reading perl and php coders don't use assembly". >Kind of no brainer... Well, it makes your code non-portable for a start. And, how much is the real gain in speed? With ever more powerful processors and 30 fps or 25 fps TV systems it may no longer matter, except for encoding. And for encoding H264 is the bottle neck ATM, and for that they now start using the Nvidia API. It can be fun programming in asm to get max speed, I have done video on a PIC in asm for example, but if you have enough processing power why bother? > It can be fun programming in asm to get max speed, I have done video on a > PIC > in asm for example, but if you have enough processing power why bother? Video? In ASM? Hah, just the other day I tried getting my breadboarded Z80 to produce NTSC composite. Just bit banging out of a spare data bit or two. No good, one instruction takes about an inch of scan, no time even to read the next line, and the horizontal sync is terribly unreliable due to the variable interrupt latency. With lots of prodding I made a few stable pictures, nothing interactive. Definitely needs support hardware. An AVR at 16MHz would probably do nicely though. Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms >> It can be fun programming in asm to get max speed, I have done video on a >> PIC [quoted text clipped - 10 lines] > >Tim Hi, Tim, well, the 'video' PIC runs on the internal oscillator of about 4 MHz... What it does is remove those annoying pulses that some DVD players insert, the Dutch word is 'beeldverbeteraar', in English 'picture improver'. This is the complete project files, including asm: ftp://panteltje.com/pub/mvp-0.2.zip This is what the thing look like: ftp://panteltje.com/mpv-0.2-pcb.jpg What it does is: It first finds the V sync pulse, then samples the video black level for an empty line, using a HC4053, then waits until just before where those nasty pulses occur, and then replaces that area with the sampled black level. Simple. You may think it is illegal to remove those M * cr * v *s * on pulses, as normally those are only inserted to prevent copying, but my DVD player, a Mustek, *always* added those pulses, also on my own DVDs that I created myself, so I had to design this to be able to make VHS tapes of my own DVDs. Maybe helpful to somebody who has the same crap DVD player (I have put that one with the garbage some time ago). There was more wrong with that player. >> It can be fun programming in asm to get max speed, I have done video on a PIC >> in asm for example, but if you have enough processing power why bother? [quoted text clipped - 7 lines] > pictures, nothing interactive. Definitely needs support hardware. An AVR > at 16MHz would probably do nicely though. You need a shift register, so that it's one iteration per 8 pixels rather than one per pixel. And you still only get 32 columns with a 3.25MHz Z-80 (that's the spec. of the ZX80/81, whose video hardware was an 8-bit shift register, with everything else in software). If you want "pixels" (as opposed to character-sized blocks) on a PIC, you would realistically need to use a 20MHz clock (Fosc/4 = 5MHz), and use either the USART or SSP as a shift register. Otherwise, you're stuck with using a whole 8-bit port so that you can shift out the bits with consecutive "rrf PORTC" instructions. And you get gaps due to the instruction required to load the next byte. > You need a shift register, so that it's one iteration per 8 pixels > rather than one per pixel. Hey, I did it back in the mid-'90s with only a 4-bit shift register! :-) 20MHz CPU, though. These days it is more of a fun "trick" than anything useful, though -- unless you're super cost-constrained, these days a small CPLD makes video almost trivially easy. >> It can be fun programming in asm to get max speed, I have done video on a >> PIC [quoted text clipped - 8 lines] > pictures, nothing interactive. Definitely needs support hardware. An AVR > at 16MHz would probably do nicely though. scan rate is about 16Khz, so about 1000 clocks per line, if you use the USART or SPI for output could probably get VGA resolution. :) > > It can be fun programming in asm to get max speed, I have done video on a > > PIC [quoted text clipped - 8 lines] > pictures, nothing interactive. Definitely needs support hardware. An AVR > at 16MHz would probably do nicely though. 'Vital Industries' did real time broadcast quality NTSC video special effects with a Z80B in the mid '80s. 768 K of 12 bit DRAM for the video Luminance & Chroma signals. It processed one page, while displaying a second. It could also be used as a frame sync, to stabilize & synchronize external video that couldn't be genlocked to the studio timebase. The system filled a full relay rack and used 1,000 amps on the 5 volt rail. SignatureYou can't have a sense of humor, if you have no sense! > 'Vital Industries' did real time broadcast quality NTSC video special > effects with a Z80B in the mid '80s. ^^^^ Really? Sounds interesting . . . > 768 K of 12 bit DRAM for the video > Luminance & Chroma signals. It processed one page, while displaying a > second. It could also be used as a frame sync, to stabilize & > synchronize external video that couldn't be genlocked to the studio > timebase. The system filled a full relay rack and used 1,000 amps on > the 5 volt rail. . . . Except that, no sane amount of hardware alongside a Z80 is going to use that much current. Methinks there was several orders of magnitude more processing power in MSI chips than the puny Z80! :-) Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms > > 'Vital Industries' did real time broadcast quality NTSC video special > > effects with a Z80B in the mid '80s. [quoted text clipped - 11 lines] > use that much current. Methinks there was several orders of magnitude more > processing power in MSI chips than the puny Z80! :-) No. I had to repair the one at WACX in Orlando, Fl. a few times. It was built with early TI 4K * 1 SLOW DRAM that used multiple supply voltages. The entire system had one Z80B microprocessor. I looked at all 65 'C' sized pages of schematics to see for myself. The thing had 24 fans to keep it from melting down. Between the Vital Industries Squeeze Zoom DVE and the Vital Industries video router, it required an additional 15 ton air conditioner for Master Control. This was the very first DVE to meet FCC requirements. The video ADC was over $1400 for a used hybrid, if you could find it. The RAM was interleaved, because it was too slow. The entire firmware was written in machine language, to get the thing to work, at all. It was designed & built in Gainesville Florida around 1982. It looked more like a mini computer than a piece of broadcast gear, and was usually the only digital gear in a studio, other then the sync generator. Most of the grunt work was done with lots of fast latches to route the data between the ADC to DRAM and from RAm to the DAC. Eight bits of luminance, and four bits chroma. Early and crude by today's standards but Vital was selling them faster than they could build them, and getting $250,000+ each. SignatureYou can't have a sense of humor, if you have no sense! > > How fast do you have to go anyways? > > The latest H264 encoders use Nvidia graphics cards as hardware accelerator. [quoted text clipped - 14 lines] > read it as "slashdot reading perl and php coders don't use assembly". > Kind of no brainer... Yep I would guess that the video players and video compressors would use MMX/SSEx instructions extensively. I've got an Intel Core Duo processor here, and was surprised to see the results of mplayer: C:\files\per\mplayer>mplayer MPlayer 1.0rc1-3.4.2 (C) 2000-2006 MPlayer Team CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (Family: 6, Model: 15, Stepping: 11) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0 Compiled with runtime CPU detection. Usage: mplayer [options] [url|path/]filename What, no SSE or SSE2? How can that be? http://en.wikipedia.org/wiki/SSE2 CPUs supporting SSE2 ... Intel Core-based CPUs (Core Duo, Core Solo, etc) Intel Core 2-based CPUs (Core 2 Duo, Core 2 Quad, etc) Ack. Time to upgrade my mplayer? Michael >I've got an Intel Core Duo processor here, and was surprised to see >the results of mplayer: [quoted text clipped - 8 lines] > >What, no SSE or SSE2? How can that be? My Duron 950 supports SSE in mplayer: MPlayer 1.0pre7try2-3.3.6 (C) 2000-2005 MPlayer Team CPU: Advanced Micro Devices Duron Spitfire (Family: 6, Stepping: 1) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx Fast as a speeding bullet! AMD rocks :-) >>I've got an Intel Core Duo processor here, and was surprised to see >>the results of mplayer: [quoted text clipped - 20 lines] > >AMD rocks :-) Oops, correction,. no SSE either, so who needs it :-) I think 3DNow makes it faste. grml: ~ # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 3 model name : AMD Duron(tm) Processor stepping : 1 cpu MHz : 959.555 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips : 1920.76 clflush size : 32 >> > How fast do you have to go anyways? >> > The latest H264 encoders use Nvidia graphics cards as hardware accelerator. [quoted text clipped - 40 lines] > >Michael OK you are running beta software. Detection bugs do seem odd though. > C:\files\per\mplayer>mplayer > MPlayer 1.0rc1-3.4.2 (C) 2000-2006 MPlayer Team Gawd, that old thing might actually predate SSE2 :) Since unfortunately the mplayer developers can't put together a release, their current SVN commit is the thing to use. Or get something vaguely recent, I guess for Windows you want to get SMplayer from http://smplayer.sourceforge.net/ >> How fast do you have to go anyways? >> The latest H264 encoders use Nvidia graphics cards as hardware accelerator. [quoted text clipped - 14 lines] > read it as "slashdot reading perl and php coders don't use assembly". > Kind of no brainer... Well, Slashdot readers are mostly idiots anyway. SignatureW . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^--------------------------------------------------------------- >>Check out Chapter 6, and re-evaluate whether this is junk to you. I >>had no idea the LEA instruction could add so efficiently. [quoted text clipped - 9 lines] > platforms then x86 too) had a hardware instruction to do every thing my > program needs, As long the as the compiler knows it :-) Whether the compiler can make use of it may depend upon your algorithm. E.g. one of Quake's key optimisations was that it only performs one perspective division for every 16 pixels. This is much faster than performing a division per pixel, but visually almost as good; you won't see the difference unless you're looking for it. Why 16 pixels? Because that's how many pixels it can render using the integer ALU while the FPU is (concurrently) performing the division. You could write in C and still get the optimisation (with a sufficiently good compiler), but you would need a reasonable understanding of the x86 in order to structure the code in such a way as to enable the optimisation. The compiler won't perform approximations for you, and you can't test every possible approximation for performance. > >>Check out Chapter 6, and re-evaluate whether this is junk to you. I > >>had no idea the LEA instruction could add so efficiently. [quoted text clipped - 26 lines] > The compiler won't perform approximations for you, and you can't test > every possible approximation for performance. Yep. But clearly, Jan is not interested in programming a Quake graphics engine, or an Unreal graphics engine... Michael >>>Check out Chapter 6, and re-evaluate whether this is junk to you. I >>>had no idea the LEA instruction could add so efficiently. [quoted text clipped - 26 lines] >The compiler won't perform approximations for you, and you can't test >every possible approximation for performance. Sorry late reply, busy here... anyways I am not sure the quest for ever higher resolution graphics and ever more realistic rendering makes much sense. I will give an example from my experience. I had this MS DOS game, it is called vrs-slingshot, and actually a collection of games in 3D. It uses LCD shutter glasses, and needs a special connection to the parallel printer port to drive those glasses. I loved to play that game, but the DOS emulation of win98 no longer played it, and I no longer had any PC with DOS. But the graphics were, by moderns standard, horrible. But it did not matter. It has some jets flying, and if you played it the 3D was so realistic that you would fall of the chair trying to shoot that other plane. Your monitor all of the sudden had the depth of an aquarium.. Hard to explain. I have tried several times to get that game working, even in virtualisers, but no way. So low resolution graphics and speed, the rest is for the imagination to fill in. You see Sony PS3 flipped sort of, in spite of the fact that it has the most powerful graphics around. Who needs it for pacman? ;-) It is the same thing with HDTV, not really what we want. Same thing with a book versus a movie, I did read 'The lord of the rings', had my own imagination what that world looked like, the movie sucked, in spite all the cool effects. It sucked for me because it did not match my imagination. TV in low resolution leaves things for the imagination, this is how the Hollywood wild west cities are build, just the front, it just looks real, as the imagination fills in what is not there. If you become too realistic it becomes boring, too many special effects and it breaks, as did the latest Starwars... Others may disagree, but the whole of multimedia is based on this imagination if you ask me, get too realistic or leave no space for the imagination and it becomes a dead end. > It sucked for me because it did not match my imagination. > TV in low resolution leaves things for the imagination, this is how the > Hollywood > wild west cities are build, just the front, it just looks real, as the > imagination fills in what > is not there. I feel the same way about old games. Doom is the greatest. Who needs accelerated video when you've got 320 x 200 x 256? Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms >> It sucked for me because it did not match my imagination. >> TV in low resolution leaves things for the imagination, this is how the [quoted text clipped - 7 lines] > >Tim 256 fps IS fast. I had MS flight simulator for win 98. I would fly from Europe to South America with it, in real time that takes hours... So I put it at the max speed (32x or so). I then found out that if you pushed it a bit more, it would flip a variable or something and the plane would never be able to come down again :-) You could just let go of the controls and it would stay up there forever. I know they also did things for the Navy, America's enemies need not fear ;-) But Airbus? Do they make their own? >>I feel the same way about old games. Doom is the greatest. Who needs >>accelerated video when you've got 320 x 200 x 256? > > 256 fps IS fast. FPS? Well, Doom will do that today, easily. But I meant colors. ;-) Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms >>>I feel the same way about old games. Doom is the greatest. Who needs >>>accelerated video when you've got 320 x 200 x 256? [quoted text clipped - 4 lines] > >Tim hehe :-) >>E.g. one of Quake's key optimisations was that it only performs one >>perspective division for every 16 pixels. This is much faster than [quoted text clipped - 13 lines] > Sorry late reply, busy here... anyways I am not sure the quest for ever > higher resolution graphics and ever more realistic rendering makes much sense. Maybe not, but there are a few boundaries where a quantitative improvement results in a qualitative improvement. In 3D, it helps if you can manage ~24fps to obtain fluid animation. If it's too slow, you lose a lot of immersion. Similarly, there's a world of difference between flat-shaded or Gouraud-shaded polygons and texture-mapped polygons. This was one of Doom's main strengths: it was the first texture-mapped 3D game with fluid animation. Quake aimed to do the same thing for true 3D, without having to lock the vertical axis. Everything since then has really just been bigger numbers (mostly just higher polygon count). But there's a general principle here which goes beyond Quake. There are plenty of practical applications where you're dealing with continuous (analogue) data and you need results which are accurate to a given tolerance. Being able to use an approximation may result in an order of magnitude difference to the number of CPU cycles required for the task. Often, the accuracy/performance curve can have sharp kinks or even steps, the location of which are determined by fairly low-level architectural details. >> On a sunny day (Tue, 9 Jun 2009 16:01:21 -0700 (PDT)) it happened >> mrdarr...@gmail.com wrote in [quoted text clipped - 39 lines] > >Michael There is something like 2 or 3 separate adders in the address unit since the 8088/8086 days. The bloody lot of them operate in a clock or two to compute EA. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.