Progress Report On Translation Of GEBC To Pascal

I decided to use GTK2 to write the GUI for my translation. Unfortunately, after hours of study, I could not decipher how to write the GUI in Pascal. I was in a mode where I could get a menu but no buttons or buttons but no menu, for hours… Then I discovered a shortcut. Check out qGTK.pas, a unit that allows a few simple calls in sequence to draw the menus and input fields and buttons, with no detailed knowledge of GTK…

This is just a few minutes work poking around in some examples:
mybc_menus
My code?
program mybc;
uses qgtk2;
procedure Reset;
begin
end;
procedure Solve;
begin
end;
procedure save;
begin
end;
procedure RangeTable;
begin
end;
procedure graph;
begin
end;
procedure Memory1;
begin
end;
procedure Memory2;
begin
end;
begin
qstart('My Ballistics Calculator',nil,nil );
qmnu('File');
qsubmnu('Save',@save);
qmnu('Analyze');
qsubmnu('RangeTable',@RangeTable);qsubmnu('Graph',@graph);
qmnu('Memory');
qsubmnu('Memory 1',@Memory1);qsubmnu('Memory 2',@Memory2);
qNextRow;
qNextRow;
qNextRow; qButton('Solve', @Solve); qButton('Reset',@Reset);
qNextRow;
qGo;
end.

Of course it doesn’t do much now, but it’s easy to see how to code the rest. It’s just some arrays and number-crunching that I’ve been doing for ages… This should be a much more reliable package after I’m done with it. GEBC can crash on a few clicks in the “right” order… I haven’t been able to sort out all the C-code in there.

seeQgtk.pas.

Status Update 2013-11-01: The engine checks out in Pascal. I was getting a division by zero due to an off-by-one error. I am not sure where that came from but I might have made an error in the looping. Perhaps C just ignores that… The largest deviations are about 0.25% in some paths. Since I may tune up the calculations I won’t worry about that yet. There seems to be an off-by-one problem in the data-structure and some items were displayed in reverse order but I can produce a decent range table and it does respond to input values and the programme can save and load parameters to a file.
Screenshot_MyBC_2013-11-01
Next, I will change the PBR (Point-Blank Range) calculation because it works from the centre of the target. It’s much more effective to hold lower on the target because the path drops more steeply after the second zero. I could make that hold a parameter but I normally just take the 6 o’clock position on the “vital zone” or target.

Remaining to be done are the graphing and file-export options. GEBC has a rather wide and useful array of file-formats, one of it’s best features.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in firearms, technology and tagged . Bookmark the permalink.

146 Responses to Progress Report On Translation Of GEBC To Pascal

  1. That Exploit Guy says:

    DTAARA is a format, not an object.
    Keyword. This oiaohm thing is beginning to rub off on me.

  2. That Exploit Guy says:

    @You Spoony Bard!
    That Exploit Guy I have not said that cobol treatment of pointers is not platform dependant.
    Then you do also realise the treatment of C data types (including pointers) is also compiler- and platform-dependent, right?
    Do you actually know anything about COBOL or C? I suppose your preposterous claim that (ILE) COBOL can facilitate multithreading should tell one plenty about the former.

    Really think how can you increase a pointer by 1 byte when you must on iserries hardware maintain a 16 bytes spacing min between pointers. AS/400 pointer is not C compatible. Yes the 16 bytes min spacing is very strange. It also not a issue if you can use offsets off pointers.
    Bhawhawh….
    Do you understand the difference between the address of a byte and a byte itself? sizeof (char*) isn’t the same thing as sizeof (char), chump, and even that’s nowhere close to understanding what comes out of the other end of the compiler. Again, put up or shut up.

    Cobol did not define a pointer as an address.
    Another statement that directly contradicts your own source. Amusing.

    So cobol can freely use a structure holding many values as a pointer. This is why cobol works on the odd ball hardware. If you read again Cobol support pointer+offset. So you can have a pointer obey rules like 16 byte fixed locations. And still access each of those bytes individually. AS/400 hardware makes C programs life hard in many ways. Yes all cobol is doing is exposing how the platform handles things straight up to the coder. Yes the hardware mandates the 16 byte spacing.
    Again, you have confused the language itself and compiler-specific details. Typical.

    The pointer alignment exception comes from the Memory management unit. C is designed for items like x86 that use virtual addressing to give an address space where you can use 1 number to define a memory space location. AS/400 and others are the buggers that are design to use 2 numbers to define a location. 2 independent numbers. Problem is one of those numbers the pointer has extra options. Like defining memory range limitations.
    The difference between x86 and AS/400 (PowerPC) is that the latter uses a construct known as an “inverted page table”, which is indexed by (physical) frame number as opposed to (virtual) page number. Typically, to facilitate a mapping, the MMU searches from the beginning of the table until an entry with the matching page is found. PowerPC uses a hashed variant (which utilises an additional hash anchor table) of this contruct to speed up the look-up process.

    There is nothing odd-ball about a well-known computer science subject. Also, of course, none of this stuff has anything to do with what you think it does.

    And that’s on top of the fact that all the operations involved are bit-wise, not byte-wise.

    The main AS/400 object I am talking about is DTAARA or plan english name Data area.
    DTAARA is a format, not an object.

    That Exploit Guy the big problem here there are a lot of large mainframe CPU types support features C is not designed for. Cobol is fine. Java in fact can be fine.
    Java is even one more abstraction away from the hardware or TIMI since the language assumes JVM as the target “machine” and uses implicit pointers rather than explicit. How is that possibly be better than the C abstract machine in any way even if your misunderstanding of everything is to apply? (That’s not a question, by the way.)

    Please remember with DS and CS under x86 you use to have to have 2 registers for a memory location. The problem here is C has merged these into one huge number.
    Again, the C abstract machine is how you understand the language, and the compiler is what dictates how that machine maps to the actual hardware. It has stuff all to do with the x86 ABI on any platform.

    So if you could make a pointer in c… On the odd ball hardware everything would be fine. C standard does not allow for pointers being a struct.
    Again, this has nothing to with want comes out at the other end of the compiler. Your argument is about as mind-numbing as it’s utterly stupid.

    C standard defines a pointer as some form of integer.
    No, it’s a compiler-specific behaviour, as your own source tells you as well as as I have already told you many, many posts before, chump.

    That Exploit Guy that is the root of the problem. A pointer in C is defined a particular thing. Cobol a pointer is not defined as a particular thing. So Cobol can change what a pointer is to suite different platforms. C cannot.
    Again, read your own source. It’s hard to convince anyone you have a job involving reading and writing when you can neither read nor write properly.

    Or produce any evidence whatsoever to support your claims.

  3. oiaohm says:

    That Exploit Guy I have not said that cobol treatment of pointers is not platform dependant.

    The problem here is C defined how pointers have to work. This makes it incompatible with particular classes of hardware. One of those example hardware is AS/400 and all their latter relations.

    All the platform with lookup tables for pointer locations where the location is turned into table address not real or virtual address as well are incompatible with C.

    Really think how can you increase a pointer by 1 byte when you must on iserries hardware maintain a 16 bytes spacing min between pointers. AS/400 pointer is not C compatible. Yes the 16 bytes min spacing is very strange. It also not a issue if you can use offsets off pointers.

    Due to the incompadible nature C on AS/400 treats AS/400 pointers like DS CS and so on registers under x86. This is not exploiting what AS/400 is designed todo.

    The simple reality on AS/400 hardware and latter forms C program for go using the AS/400 features properly.

    AS/400 uses a complete different solution to virtual memory. Yes this does appear in the iserries that are just latter generations of the AS/400.

    Cobol is one of the object languages you can use. Cobol did not define a pointer as an address. So cobol can freely use a structure holding many values as a pointer. This is why cobol works on the odd ball hardware. If you read again Cobol support pointer+offset. So you can have a pointer obey rules like 16 byte fixed locations. And still access each of those bytes individually.

    AS/400 hardware makes C programs life hard in many ways. Yes all cobol is doing is exposing how the platform handles things straight up to the coder. Yes the hardware mandates the 16 byte spacing.

    The pointer alignment exception comes from the Memory management unit.

    C is designed for items like x86 that use virtual addressing to give an address space where you can use 1 number to define a memory space location. AS/400 and others are the buggers that are design to use 2 numbers to define a location. 2 independent numbers. Problem is one of those numbers the pointer has extra options. Like defining memory range limitations. The main AS/400 object I am talking about is DTAARA or plan english name Data area.

    Yes a iSeries server is a AS/400 item.

    That Exploit Guy the big problem here there are a lot of large mainframe CPU types support features C is not designed for.

    Cobol is fine. Java in fact can be fine.

    Most of the issues come about from languages that define pointers that users are allowed to perform operations on.

    Please remember with DS and CS under x86 you use to have to have 2 registers for a memory location. The problem here is C has merged these into one huge number.

    So if you could make a pointer in c
    struct {
    pointer
    offset
    }
    On the odd ball hardware everything would be fine. C standard does not allow for pointers being a struct.

    https://www.securecoding.cert.org/confluence/display/seccode/INT11-C.+Converting+a+pointer+to+integer+or+integer+to+pointer

    C standard defines a pointer as some form of integer.

    That Exploit Guy that is the root of the problem. A pointer in C is defined a particular thing. Cobol a pointer is not defined as a particular thing. So Cobol can change what a pointer is to suite different platforms. C cannot.

    So there are platforms C cannot support properly and stay standard conforming.

    C vs Cobol is not a valid arguement. Cobol vs Java is closer to valid.

  4. That Exploit Guy says:

    @You Spoony Bard!
    There are a particular set of registers for pointers…
    No. Those are COBOL pointers, whose treatment are dependent to the platform and the compiler, as your own source points out:

    When a pointer is referenced on the iSeries server, it must be on a 16-byte storage boundary. Pointer alignment refers to the ILE COBOL compiler’s process of positioning pointer items within a group item to offsets that are multiples of 16 bytes from the beginning of the record. If a pointer item is not on a 16-byte boundary, a pointer alignment exception is sent to the ILE COBOL program. In general, pointer alignment exceptions occur in the Linkage Section, where it is up to the user to align these items.

    Hence, what you are pointing out here is a COBOL-specific issue and completely irrelevant to C.
    … reference what are called AS/400 objects.
    Good to know you can paraphrase your source material (poorly).
    Name these “objects”. I am not asking for too many – even one or two will do the job.
    There are a interesting set of asm.
    Which you have yet to show, aside from all other things I have asked of you that you have also yet to show.

  5. oiaohm says:

    That Exploit Guy I did not say GPR registers.

    There are a particular set of registers for pointers this pointers reference what are called AS/400 objects. Fun part is you set two at once. A 32 bit number. Source and destination. Or set half from a general register to the AS pointer. There are a interesting set of asm. Where bottom half of a general register can be pushed into the top half of the current objects and the bottom half not touch.

    Dealing with AS/400 object/pointers is one of the times you use the 1/2 and 1/4 register options to get from the general to pointer storage.

    That Exploit Guy all AS/400 machines contain this feature. No exception.

    AS/400 everything from CPU up take the view that everything is a object. Memory data blocks are a object. All objects have pointer value assigned that is not address based. All objects are accessed by pointers.

    Remember I said its pointer + offset.

    What appears to be memory address in a GPR on a AS/400 is in fact only a offset from what ever the current AS/400 object/pointer is.

    That Exploit Guy you might as well stop using the insulting name. AS/400 pointers are mentioned exactly what size they are. They are not 32 bit. As you said there are not 16 bit general registers on PPC.

    The thing you have missed is there are special registers for controlling the memory management unit. These are not registers to push general data into. Results of pushing random data into the registers for AS/400 pointers would a be disaster.

    Basically it what makes AS/400 hardware AS/400 hardware.

    That Exploit Guy AS/400 systems are designed for object oriented programming languages in the instruction set. This is not the only risc chip like this.

    Round peg square hole is running C on something like a AS/400.

    By the way there is a OS/400 operation system that matches the AS/400. Yes its not ibm’s general Unix either.

  6. That Exploit Guy says:

    @You Spoony Bard!
    Yes there are a set of 16 bit registers for AS/400
    You specifically mentioned RISC-based AS/400 machines. That’s PowerPC. You do realise no PowerPC chips with 16-bit GPRs are featured in the series, right?
    Here’s a chance to redeem yourself – specify a model, RISC-based, and we shall start from there. And that’s on top of producing all the proofs that I have asked of you.
    Capish?

  7. oiaohm says:

    The 16 bit pointer stunt also reduces down memory consumption. Remember Linux has x32-abi that is doing a kinda related trick but no where near as good.

    64 bit pointer takes twice the memory space as a 32 bit pointer. 16 bit pointer takes 1/4. There are many reasons for the AS/400 pointers. AS/400 pointers are not exploited effectively by C.

  8. oiaohm says:

    That Exploit Guy AS/400 pointers are not registers. AS/400 pointers are exactly 16 bits in length Or exactly 2 to the power of 16 of them per operational space. Go read the cobol page I quote before.
    On the AS/400 system, pointers are 16 bytes long.

    ILE COBOL pointer data items point to system space objects. One part of the pointer describes its attributes, such as to which AS/400 space object it is pointing. Another part of the pointer contains the offset into the AS/400 system space object

    AS/400 pointers are not 32 or 64 bit registers. The fact you are claiming registers so you did not read. That you are talking about registers shows you have completely no understanding about the feature I am talking about.

    So That Exploit Guy you are a moron here.

    AS/400 pointer has nothing todo with 32 or 64 bit registers. Yes there are a set of 16 bit registers for AS/400 pointers nothing todo with the 32 or 64 bit registers AS/400 hardware. Registers become offsets off a AS/400 pointer.

    AS/400 pointers relate to memory blocks more than registers. Fixed sizes blocks of memory.

    So how does a C program work on AS/400 hardware. All memory space of the C program is 1 AS/400 pointer. So now the NUMA transferring of required memory is no where near as effective.

    Mind you were getting somewhere on the right track saying virtual memory. This is a vastly different way of handling virtual memory. Pointer and Offset is truly different. Of course you would not have been thinking the 32 and 64 bit registers are offsets from the 16 bit pointer.

    That Exploit Guy apparently you don’t read links. Now you wish to call me insulting names.

  9. That Exploit Guy says:

    @oiaohm

    C++ strings are wrapped over yes but under it is still C style strings.
    Show me the part of the C++ specifications where this is stated.

    AS/400 hardware is PowerPC risc hardware.
    Heh, we are still talking about mainframes, right?

    They work by pointer and offset.
    Yes, those are called “registers”. There are thirty-two of them in the PowerPC ISA each at a fixed length of 32 bits or 64 bits in size depending on the chip and are all essentially general-purpose.

    What is this “sized block of memory” you speak of again? Can you show me example assembly code where this applies? No? Typical.

    If you cannot work out using AS/400 pointers is critical to performance as well. When a thread changes cpu core it running on you need to be able to transfer the memory the application requires a quick as possible.
    You mean saving the registers? Strange that you seem to have absolutely no idea what a context switch is, isn’t it?

    AS/400 pointers allow the NUMA to transfer segments of blocks in the order they are required by the application. Yes its these kinds of pointers that make the virtual addresses of memory random. Yes you can request address of a AS/400 style pointer. Cobol programs can run with consistency of address turned off.
    Nope, virtual memory address space is just another abstraction from the physical memory address space (aside from the C abstract machine) and is a solution rather than a contributor to the problem that you describe (poorly). Try again.

    That Exploit Guy you arguement about lack of COBOL command and having to use API todo it. ILE Cobol does include ABI todo it. So does Cobol on Solaris and the other remaining UNIX’s.
    By all means, then, show me that on Solaris, and that’s on top of all other things you have thorughly failed to demonstrate.

    Fool.

    C and C++ don’t have commands to thread either there threading controls are also API. Yes, it’s called POSIX threads, which are meant specifically for use with the C language. Yes modern Cobol’s today have thread management API’s so don’t require C or other programs to manage there threading. Modern Cobol is really no different to C and Pthread Library or C and Windows API to thread.
    Backtracking already, huh? What happened to your claim that “recent IBM ILE cobol supports threading directly without C programs”?

    Just remind yourself next time to read your own source first before citing it, won’t you, my dear, purported COBOL programmer?

  10. oiaohm says:

    That Exploit Guy
    http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c092540317.htm
    Read this type of pointer. This is not a C pointer.
    –When you read a C string, you point your pointer to the beginning of the sequence and increment it until the NULL character is reached. That all. Why you think this is relevant to the ISA or COBOL or the C abstract machine is completely beyond me. —
    C++ strings are wrapped over yes but under it is still C style strings.

    AS/400 hardware is PowerPC risc hardware. They work by pointer and offset. AS/400 pointer it is not possible to increment. If you have not worked out yet this form of pointer has hardware protection from buffer overflow.

    This is the reality That Exploit Guy lot of the UNIX risc archs require different programming language to C. Because they contain the concept pointer, pointer storage size and offset from a pointer at hardware level. C is design around the concept of pointers only being memory addresses. C is not designed around the idea that a pointer will be a sized block of memory.

    If you cannot work out using AS/400 pointers is critical to performance as well. When a thread changes cpu core it running on you need to be able to transfer the memory the application requires a quick as possible. AS/400 pointers allow the NUMA to transfer segments of blocks in the order they are required by the application. Yes its these kinds of pointers that make the virtual addresses of memory random. Yes you can request address of a AS/400 style pointer. Cobol programs can run with consistency of address turned off.

    That Exploit Guy you arguement about lack of COBOL command and having to use API todo it. ILE Cobol does include ABI todo it. So does Cobol on Solaris and the other remaining UNIX’s . C and C++ don’t have commands to thread either there threading controls are also API.

    That Exploit Guy this is the problem of arguing with a incompetent like you. You miss read. Yes modern Cobol’s today have thread management API’s so don’t require C or other programs to manage there threading. Modern Cobol is really no different to C and Pthread Library or C and Windows API to thread. The big difference is modern cobol’s can use hardware protections against buffer overflow more effectively.

    There are other languages other than cobol that can also use the protections the UNIX makers risc hardware provides. Just it is never C. C is in fact incompatible.

  11. That Exploit Guy says:

    That Exploit Guy there is a problem. C struts do define continuous memory appearing to the application.
    You mean “strings”? Also, again, I have absolutely no interest in reading any of your gibbered “explanation”. You either produce proof, as I have outlined, that the alleged issues do exist, or the only advice I can give you is to stop making stuff up.
    You refereed to an out of date cobol example. Recent IBM ILE cobol supports threading directly without C programs.
    Read your own source. Even disregarding the fact that ILE COBOL is not COBOL proper, your source still contradicts your above statement:

    ILE COBOL does not have a COBOL statement to support initiating or managing program threads, but COBOL programs can use APIs to do this. ILE COBOL programs can run in threads in a multithreaded environment. In other words, ILE COBOL programs can be invoked by other applications such that they are running in multiple threads within a job or as multiple program invocation instances within a thread.

    In other words, what you have actually proved is that you cannot use ILE COBOL to facilitate multithreading either. Whoops!
    Here is documentation on a ILE cobol pointer. Notice something horible. The pointer is a reference number nothing more
    Pointers in C are also just numbers, usually in the same size as an integer. What’s so “horrible” about that?
    Lets say we have a and b pointer. A is at start of string B is at end of string.
    The C concept of a string is a sequence of characters (char) terminated with a NULL. When you read a C string, you point your pointer to the beginning of the sequence and increment it until the NULL character is reached. That all. Why you think this is relevant to the ISA or COBOL or the C abstract machine is completely beyond me. Heck, it’s not even relevant to C++ strings, with all things considered.

  12. oiaohm says:

    That Exploit Guy there is a problem. C struts do define continuous memory appearing to the application. Cobol does not have this.

    So a pointer to a string in Cobol may be spread over many independent blocks.

    Removing pointer maths removes a stack of limitations what a pointer means. So a pointer can be referencing a multi independent blocks.

    C memory address idea does not hold up. People find this out when you attempt running C in Jvm. Yes its possible but the overhead you create emulating memory addresses is massive. Abstracted addresses is still a address space. That Exploit Guy abstract machine still performs better when the underlining machine matches the same model. Cobol does away with I have to emulate an address space.

    The problem here is NUMA does not in fact match C default memory model. So maintaining the memory model in the C standard has overhead. Like by default in Cobol threads there are no globals.

    Remove direct pointer maths. Make pointers a abstract in there own right. Then you have a different beast of a machine. Cobol maps into jvm very well.

    That Exploit Guy Cobol not having threading who are you trying to kid. http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c092540318.htm

    You refereed to an out of date cobol example. Recent IBM ILE cobol supports threading directly without C programs. Of course you could be a little out of date this is something that happened in 2012. Same with the other Unix Cobols.

    Just to be evil every Unix Cobol has different libraries and function names for threading. It is not drop to C. So porting from one Unix mainframe supplier to another is a complete pain.

    That Exploit Guy Cobol is in fact still evolving.

    http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c092540317.htm

    Here is documentation on a ILE cobol pointer. Notice something horible. The pointer is a reference number nothing more.
    Lets say we have a and b pointer. A is at start of string B is at end of string.
    b-a under C will equal lenth of string.
    b-a under most unix cobols will equal rand garbage. Because they are not addresses. They are reference to a structure that defines the address.

    To be correct its part kernel part hardware and part software that make mainframe cobol unique.

  13. That Exploit Guy says:

    @Pogson
    Replies with too many links go into spam.
    3 links = spam? That’s sure some inscrutable logic you have got there, isn’t it?
    Also, what is the purpose of deliberately digging up all the filtered comments that I have reposted myself already? Why not spend the time proving your “expertise” as I have outlined instead?
    You claim no one will choose cobol over C. There is a problem. Cobol scales better than C mainframes with less coding work to achieve it. Mostly because Cobol compliers are better built on those platforms.
    @oiaohm
    Again, I prefer “proof by examples”, and that means you provide sippets of code in the form of input source code and output assembly code to demonstrate the alleged difference between COBOL compilers and the rest on IBM mainframes. Outline specific optimisation features and make your demonstration reproducible.
    This is not just randomisation when the program starts. This is randomisation while the program is running
    Again, prove this using compiler inputs and outputs. Show your working.
    Its C heavy usage of pointers that make programs portable in memory space hard.
    What C describes is an abstract machine. It is meant to agnostic to the underlying platform and instruction set architecture so that code written in the language can be portable. Hence, what C pointers describes are fundamentally memory addresses of an abstract machines, not those of a platform’s address space, virtual or otherwise. This also means that how the C abstract machine maps to the target platform is strictly dependent to the compiler and the platform itself, not the language. So that’s one thing you have said that is provably wrong.
    Yes it becomes a very big problem you port to C or C++ and the program runs slower than the cobol it meant to replace because it not threading as well.
    COBOL in its proper form has nothing to facilitate multithreading. The official IBM solution to the problem is to run your COBOL-written code using POSIX threads and C code. So that’s another thing you have said that is provably wrong.
    That Exploit Guy I have told you that you did not know what my knowledge base is.
    Being familiar with something that doesn’t actually exist is quite hard, I must agree.

  14. oiaohm says:

    Cobol issue and the Unix mainframe issue where both will not just die are in fact linked.

    There is a feature missing from Linux involving application address spaces. Open Source Cobol lacks something that mainframe Cobol from the likes of IBM, Dell and others have.

    Mainframe cobol gets very fun if you start printing out the values of pointers in the same running program. Depending on what cpu the thread you did the request on depends on what value the pointer returns.

    This is Address space layout randomisation taken to a completely different level. There are limited programming languages that can be built to work in that environment. This is not just randomisation when the program starts. This is randomisation while the program is running. This is also more NUMA compatible. Since if a particular section of memory in the page tables is being used by a different application you don’t have to move that application. Instead you can move where the executable will run by updating its pointer table. Increased through put because you don’t have to attempt to maintain synced address usage.

    That Exploit Guy stuff that refuses to die sometimes has some very interesting reasons. Interesting right that C and C++ are not the be all and end all. Yes the feature I am talking about requires OS kernel support. Only OS kernels to support it are Mainframe Unix’s like AIX.

    That Exploit Guy I have told you that you did not know what my knowledge base is. Then you wonder why I said the exact opposite. Have you worked with mainframe cobol and under stand how it gets it extra performance. The answer is 100 percent no because if you had you would never made the statement you did.

    Yes it becomes a very big problem you port to C or C++ and the program runs slower than the cobol it meant to replace because it not threading as well. Its not threading as well because program cannot change its page table values while running or it risks breaking pointers with C or C++. Cobol program does not have this problem.

    Yes C and C++ compliers don’t generate pointer tables that hold the real addresses for all the pointers the program is using so they can be updated by the OS kernel in case of address space changes.

    I really don’t like cobol. I have to use cobol because that it sometimes the only way you can extract the performance out of expensive hardware.

  15. oiaohm says:

    That Exploit Guy our difference on cobol is your level of incompetence. There are still new programs turning up written in cobol and pascal.

    http://www.zdnet.com/cobol-gets-a-web-friendly-facelift-on-ibm-mainframes-7000015601/

    You claim no one will choose cobol over C. There is a problem. Cobol scales better than C mainframes with less coding work to achieve it. Mostly because Cobol compliers are better built on those platforms. Cobol can build to native code or to JVM or .Net platforms without issues.

    That Exploit Guy I am not saying Cobol alive healthy/well. Death is going to take a very long time. Cobol is not to the point that no new applications using it are being written. One day C compliers might be good enough some people will claim. Most likely not. Its C heavy usage of pointers that make programs portable in memory space hard.

    Mainframe workloads you need to be able memory position independent executables. This fair much excludes all programming languages containing pointers that you can perform direct maths on the pointer value.

    This is the problem there have been no new major-ally popular programming languages that avoid direct pointer maths completely and produce native code. So a particular set of problems is fairly much stuck in cobol.

    One day a language will appear that will get popular that will cause cobol to die completely. It was suspected at one point this would be pascal. But pascal has failed to get traction strong enough to have the complier support to nuke cobol and then latter on in pascal life they added pointer maths. So ruining it as a cobol replacement.

    That Exploit Guy there is a particular reasons why cobol is still being used for new programs of particular types. C and C++ really don’t suit particular problems.

    Java and .net ends up with too much overhead.

    Sorry to say only incompetent would say a programmer would be choosing between C and Cobol. It basically showed you did not understand why Cobol is sticking around so strong.

    You need programs to work well being relocated in memory and interrupted a lot C is not the language to use.

    There have been a lot of cases of Cobol programs being rewritten to C or C++ and companies having major failures then returning to the Cobol code base. Migrate from cobol to the wrong language you are asking for it. Lot of those companies are now once bitten twice shy. They are not going to migrate unless you can prove that there are gains.

  16. Replies with too many links go into spam. I may have missed it there and deleted it along with the spam. The current limit is 3 links, I believe.

  17. That Exploit Guy says:

    One more post for today:
    Here’s a professor with degrees in mathematics
    Discrete mathematics, to be exact; also has practicing knowledge in graph theory etc. and has taught, well, COMP2080 Analysis of Algorithms according to your link.
    Didn’t I mention COMP2080 in my previous post? Again, the challenge is there if you want to prove your worth. I am not asking you to aim for professorship – I am just asking you to put the money where your mouth is. So, do you want to take it up or do you prefer to keep making excuses about “diversity”?

  18. That Exploit Guy says:

    I have put my reply to oiaohm on pastebin.Let’s see if that works.

  19. That Exploit Guy says:

    The second half (to oiaohm) doesn’t show up. Hmmm…

  20. That Exploit Guy says:

    @oiaohm
    That Exploit Guy really you need to take a closer look there are still computer science fields using pascal.
    Take a closer look to the post you were replying – it had nothing to do with whatever you were babbling about.
    It takes a long time for a coding language to die. Dr Loser cobol still turns up inside some businesses.
    This was also the same point I raised over a week ago, though with a drastically different conclusion from yours. Perhaps the brain damage that has apparently caused your aphasis also prevents you from hiding the fact that your “knowledge” is nothing beyond parroting what other people have already said (plus plenty of fabrication), poorly?

  21. That Exploit Guy says:

    My comment wouldn’t show up properly. I figured that probably had something to do with number of links involved. Good thing I have already saved my comment in Notepad. So, here goes:
    @Pogson
    The U of M has staff who have B. Sc. (Honours) as do
    So? You do realise the U of M offers B. Sc. with “Major in CS”:http://umanitoba.ca/student/admissions/programs/computer-science.html, right?

  22. That Exploit Guy says:

    @Pogson
    The U of M has staff who have B. Sc. (Honours) as do
    So? You do realise the U of M offers B. Sc. with “Major in CS”:http://umanitoba.ca/student/admissions/programs/computer-science.html, right?
    @oiaohm
    That Exploit Guy really you need to take a closer look there are still computer science fields using pascal.
    Take a closer look to the post you were replying – it had nothing to do with whatever you were babbling about.
    It takes a long time for a coding language to die. Dr Loser cobol still turns up inside some businesses.
    This was also the same point I raised over a week ago, though with a drastically different conclusion from yours. Perhaps the brain damage that has apparently caused your aphasis also prevents you from hiding the fact that your “knowledge” is nothing beyond parroting what other people have already said (plus plenty of fabrication), poorly?

  23. That Exploit Guy says:

    I retract the part where I stated that you have apparently banned me as a result of the conversation, because that didn’t happen (WordPress ate my reply to oiaohm?)

  24. That Exploit Guy says:

    Computer Science is more diverse that TEG writes and accepting of all kinds of people with knowledge and experience related to the field
    You mean as diverse as you are apparently afraid enough to ban me for daring to challenge your claim of “expertise”?
    Note the conditions state “any topics of yours choice”. Also note that nowhere it is stated that you must actually take up the job offer – you just need to show they do offer you a position. You are retired, so what do you care about refusing it?
    I also like your claim that, because CS is apparently so diverse, even the entire Department of CS at U of M has trouble recognising your ability – it’s so ludicrous it’s almost paranormal.

  25. That Exploit Guy says:

    That Exploit Guy really you need to take a closer look
    Take a closer look. My last post had nothing whatsoever to what you are babbling about.
    It takes a long time for a coding language to die. Dr Loser cobol still turns up inside some businesses.
    I believe that has already been covered by my comment here from over a week ago. I guess the brain damage that has apparently caused your aphasia has also prevented you from hiding the fact your “knowledge” is no more than parroting whatever other people have already said, poorly.

  26. TEG wrote, ” applying for an academic position (even a paid-by-the-hour tutoring position will do the job – you have been a teacher, right?) Show them your degree in Nuclear Physics.”

    Don’t tell me what to do. I’m retired.

    The U of M has staff who have B. Sc. (Honours) as do I… see Terry Andres. OK, so he also has M.Sc. but he was accepted for M. Sc. without having B.Sc. in comp. sci. Here’s a professor with degrees in mathematics… So, Computer Science is more diverse that TEG writes and accepting of all kinds of people with knowledge and experience related to the field.

  27. oiaohm says:

    That Exploit Guy really you need to take a closer look there are still computer science fields using pascal. Introductory programming.

    Mostly because pascal makes it hard todo may bad syntax things.

    That Exploit Guy so any CS subject first year university introduction to programming knowing just pascal is still enough. Since the main objective of that subject is to teach basic program development principles.

    That Exploit Guy any topic of choice is you being foolish.

  28. That Exploit Guy says:

    There you go again.
    There you go again banning people for daring to challenge your self-“qualifications”.
    don’t have a degree in computer science but that is hardly the only means of reaching knowledge.
    You think your irrelevant work in nuclear physics can substitute genuine knowledge in computer science? Here’s a chance to prove yourself: contact the Department of Computer Science, U of M and applying for an academic position (even a paid-by-the-hour tutoring position will do the job – you have been a teacher, right?) Show them your degree in Nuclear Physics. Tell them why you are qualified to teach, say, COMP 2080 Algorithm Analysis, COMP 3030 Automata Theory and Formal Languages or COMP 3430 Operating Systems (or any CS topic of your choice) despite you have absolutely no background in any of those things (as some readers here can easily point out). Tell them about Donald Knuth etc. If they are somehow convinced that you have a point and do offer you a job in return (show evidence), then ban me as well, or else apologise to and unban Dr. Loser. Deal?

  29. oiaohm wrote, “It takes a long time for a coding language to die.”

    Many millions have been exposed to Pascal and use it today. I don’t think it will die with my generation for I taught hundreds how to use it. Here’s a guy who worked at Lockheed-Martin programming in Pascal: “After careful analysis of the system requirements, it was obvious that we needed both a stable operating system as well as a versatile and highly maintainable computer language. We chose a dedicated VAX computer running VMS, and the programming language Pascal. The applications needed to implement this system were extremely complex and diverse, ranging from database management to network interfacing with other company systems. Each application would have to be extremely maintainable to support the changing dynamics of a production shop. Of all the languages at our disposal, only Pascal and C afforded the versatility required; however, only Pascal provided the maintainability.”

    That’s exactly my observation. Code written in Pascal is much more readable than C and the fussy compiler tends to make the first draft correct. Simpler is better for making reliable software.

    Borland TurboPascal has evolved into Delphi but it’s still Pascal at its core. FreePascal does everything I need done.

  30. oiaohm says:

    http://www.freepascal.org/
    Dr Loser really do have a good read of it features. You said dead. Its not quite.

    http://wiki.freepascal.org/FPC_JVM/Language

    So to android and java vm devices possible from freepascal code base.

    It takes a long time for a coding language to die. Dr Loser cobol still turns up inside some businesses.

  31. Dr Loser wrote, “Sadly, your employers (whether in Saudi or in the Frozen Wastes) will never be able to recoup the money they wasted on your pathetic lack of expertise.”

    There you go again. I was just beginning to think you might not be a troll. I guess it’s time to ban some trolls, again.

  32. Dr Loser says:

    Sadly, your employers (whether in Saudi or in the Frozen Wastes) will never be able to recoup the money they wasted on your pathetic lack of expertise.

    No matter, Robert: you can still make amends!

    Get that thar Pascal FastCGI Ballistics site up and running, and make sure it’s feature-compatible with the original (and perfectly workable) GEBC! Including the graphics and the exports! Optionally, make sure it can be run over a Web server with 1,000 simultaneous thin clients!

    That is, after all, what you were claiming you could do, isn’t it?

    Failing that, just dump the rubbish on SourceForge.

    At least it will be FOSS in that case.

  33. Dr Loser says:

    I have taken some Computer Science courses mostly to gain access to IT as an undergraduate and to help in my number-crunching as a graduate student.

    Did these courses involve things like compiler theory? Apparently not. BNF? Apparently not. I’ll give you a pass on parallelism, because that’s pretty recent. Provability? Apparently not.

    It’s pretty hard to figure out what possible knowledge you gleaned out of these Computer Science courses, apart from an undying devotion to a dead language like Pascal. Even your understanding of numerical analysis looks a bit suspect to me. Runge-Kutta for ten yard increments in the wild? Pah. You’d have done better on an Operations Reseach course (which my father used to teach). At least that explains why you don’t waste your time on trivia that has no real-world application.

    Most of my professional life I have been either hired or paid for my expertise with computers.

    It would appear that, through most of your professional life, your employers have wasted their money on non-existent expertise, wouldn’t it?

  34. Dr Loser says:

    Do you need me to help you out with an option to control the font sizes?

    I can do that too.

    I took the trouble to learn both the original program and the fltk framework whilst you were messing around in your garden shed.

  35. Dr Loser says:

    However, and since we’re on the subject of professional fixes, rather than amateur botches, you remember your original complaint about the “Wind Drift” header? And you remember how your “solution” was to retitle it as “Windage”?

    Here’s the proper, professional solution. I’d offer it as a diff, but I’m sure you can locate the relevant eight lines. What you need, in RangeWindow.cpp, is:

    colwidths = (int*)malloc(10*sizeof(int));
    colwidths[0]=75; // Range (yds)
    colwidths[1]=75; // Drop (in)
    colwidths[2]=75; // Drop (MOA)
    colwidths[3]=75; // Vel (ft/s)
    colwidths[4]=75; // Energy (ft-lb)
    colwidths[5]=75; // Winddrift (in)
    colwidths[6]=75; // Windage (ft)
    colwidths[7]=75; // Time (s)
    colwidths[8]=0;

    Once again, you can always rely on a professional Microsoft programmer to get these things done right.

  36. Dr Loser says:

    In other words, Robert, I have contributed a fix to the problems you originally highlighted. I’ve even sent them to the author via SourceForge.

    Correct me if I am wrong here, but all you have so far managed to contribute (in three weeks’ worth of effort, on and off) is a really nasty looking GUI entitled something like “My Ballistics Table,” and an as-yet-to-be-released Pascal solution, sans graphics and the various export formats.

    I would appear to be so far ahead of you on this one that it isn’t even funny.

  37. Dr Loser says:

    Dr Loser wrote, “Explain, then, Robert, how the program stays in memory after it exits.”

    It doesn’t exit. It has an infinite loop reading and writing to a socket which it sees as the usual I/O one might access from read/write.

    Let this stand as an answer to all your recent posts.

    I know that, Robert. I highlighted that for you. I am aware that Pascal has socket-handling capabilities. I admitted that.

    But FastCGI doesn’t come for free. You have to implement the protocol within your application. That takes extra, pointless, effort.

    Typically, Web frameworks (Lazarus, Brook, etc) do this for you, and more. Furthermore, these are new and active projects. If you were actually interested in contributing to the advancement of Pascal through FOSS and the Web, you’d be using them and examining them and offering fixes and additional features, wouldn’t you?

    Absent that, it’s really difficult to see what you are contributing back to the Community.

    And I’d avoid calling somebody else “a pompous ass and a crashing bore,” Robert. I may well be both, but at least I am a professional and knowledgeable pompous ass and crashing bore.

    You? You’re an amateur know-nothing who is not contributing anything to anybody but themselves.

    The fact that you, too, are a pompous ass and a crashing bore is not that important in comparison to that small yet obvious detail.

  38. Dr Loser wrote, “Explain, then, Robert, how the program stays in memory after it exits.”

    It doesn’t exit. It has an infinite loop reading and writing to a socket which it sees as the usual I/O one might access from read/write.

  39. Dr Loser wrote, “FreePascal does not offer FastCGI out of the box.
    For that you have to use a framework: either Lazarus or Brook.”

    No, you don’t. FastCGI was developed in the mid 1990s, long before either of those frameworks. Lazarus, and Brookframework is even younger.

    FastCGI is mostly about the server. The application the server runs is almost a normal Pascal application reading on stdin and writing on stdout. The main difference is stdi/o is a socket, an ancient UNIX construct. FreePascal can do sockets out of the box and has for many years.

  40. Dr Loser wrote, “Of course, that assumes that you, Robert, have some sort of grounding in either Computer Science or Software Engineering.”

    I got my start in physics which is a huge user of IT. As a student of physics I was given an account on the IBM mainframe and started programming in my first year of university. I had employment as a programmer from about the second year and have continuously been involved in some IT project ever since. I have worked with a dozen hardware and software platforms and became conversant with current computer science topics from Day one. I have taken some Computer Science courses mostly to gain access to IT as an undergraduate and to help in my number-crunching as a graduate student. Most of my professional life I have been either hired or paid for my expertise with computers. To me science is science and computer science, physics, engineering and technology all overlap. I don’t have a degree in computer science but that is hardly the only means of reaching knowledge. There are all kinds of computer scientists who never got a degree in the subject either: RMS, Donald Knuth, James Cooley (one of the developers of the FFT), etc.

    It is not any point against me that I am not a graduate of Comp. Sci., partly because Comp. Sci. barely was off the ground when I was at university. Computer programming and IT was everywhere however. I revelled in it.

  41. Dr Loser, being a pompous ass or a crashing bore, wrote, “you’re just going to get bored with it and drop it after six months, aren’t you?”

    You will notice that my approximate/closed-form ballistics calculator has been on the web for many years. A server can just keep on running it until I die … This site has been more or less in its present form for six years. Where do you have any information that I am not persistent?

  42. Dr Loser says:

    Very simple fixes, really.

    In the interests of the FOSS community, I will publish two different fixes to your so-called “off by one” problem tomorrow.

    And, given the fact that your eyesight is not quite what it might be (neither is mine; I sympathise), I will publish a fix for your “Wind Drif” issue. Clue: it’s an actual fix, not a bodge.

    If you’re really, really nice to me, I’ll use the magic of C/C++ and fltk to add a menu option that allows you to adjust the fonts. That’s a bit more effort, maybe half a day or so.

    But then, I like investing half a day’s effort to make something better.

    You?

  43. Dr Loser says:

    Ah well, I’ve spent enough time fiddling with your borked blogging system.

    What we all want to know is, do I have the corrections to the original GEBC bugs (graphics only in the first case). And here they are!

    Index: InputWindow.cpp

    ===================================================================

    RCS file: /home/piglet/cvsroot/gebc-1.07/InputWindow.cpp,v

    retrieving revision 1.1.1.1
    diff -r1.1.1.1 InputWindow.cpp
    255,263c255,263

    ~GBCSolution(); delete gsln; gsln=NULL;}
    ~GBCSolution(); delete mem1; mem1=NULL;}
    ~GBCSolution(); delete mem2; mem2=NULL;}
    ~GBCSolution(); delete mem3; mem3=NULL;}
    ~GBCSolution(); delete mem4; mem4=NULL;}
    ~GBCSolution(); delete mem5; mem5=NULL;}
    ~GBCSolution(); delete mem6; mem6=NULL;}
    ~GBCSolution(); delete mem7; mem7=NULL;}
    ~GBCSolution(); delete mem8; mem8=NULL;}

    > if (gsln!=NULL) { delete gsln; gsln=NULL;}
    > if (mem1!=NULL) { delete mem1; mem1=NULL;}
    > if (mem2!=NULL) { delete mem2; mem2=NULL;}
    > if (mem3!=NULL) { delete mem3; mem3=NULL;}
    > if (mem4!=NULL) { delete mem4; mem4=NULL;}
    > if (mem5!=NULL) { delete mem5; mem5=NULL;}
    > if (mem6!=NULL) { delete mem6; mem6=NULL;}
    > if (mem7!=NULL) { delete mem7; mem7=NULL;}
    > if (mem8!=NULL) { delete mem8; mem8=NULL;}
    462,463c462
    < InputWindow* T = (InputWindow*)v;
    ~InputWindow();

    > exit(0);
    514,522c513,521

    gsln!=NULL) { T->gsln->~GBCSolution(); delete T->gsln; T->gsln=NULL;}
    mem1!=NULL) { T->mem1->~GBCSolution(); delete T->mem1; T->mem1=NULL;}
    mem2!=NULL) { T->mem2->~GBCSolution(); delete T->mem2; T->mem2=NULL;}
    mem3!=NULL) { T->mem3->~GBCSolution(); delete T->mem3; T->mem3=NULL;}
    mem4!=NULL) { T->mem4->~GBCSolution(); delete T->mem4; T->mem4=NULL;}
    mem5!=NULL) { T->mem5->~GBCSolution(); delete T->mem5; T->mem5=NULL;}
    mem6!=NULL) { T->mem6->~GBCSolution(); delete T->mem6; T->mem6=NULL;}
    mem7!=NULL) { T->mem7->~GBCSolution(); delete T->mem7; T->mem7=NULL;}
    mem8!=NULL) { T->mem8->~GBCSolution(); delete T->mem8; T->mem8=NULL;}

    > if (T->gsln!=NULL) { delete T->gsln; T->gsln=NULL;}
    > if (T->mem1!=NULL) { delete T->mem1; T->mem1=NULL;}
    > if (T->mem2!=NULL) { delete T->mem2; T->mem2=NULL;}
    > if (T->mem3!=NULL) { delete T->mem3; T->mem3=NULL;}
    > if (T->mem4!=NULL) { delete T->mem4; T->mem4=NULL;}
    > if (T->mem5!=NULL) { delete T->mem5; T->mem5=NULL;}
    > if (T->mem6!=NULL) { delete T->mem6; T->mem6=NULL;}
    > if (T->mem7!=NULL) { delete T->mem7; T->mem7=NULL;}
    > if (T->mem8!=NULL) { delete T->mem8; T->mem8=NULL;}
    804d802
    mem1->sln!=NULL) free (T->mem1->sln);
    805a804
    > T->mem1 = NULL;
    829d827
    mem2->sln!=NULL) free(T->mem2->sln);
    830a829
    > T->mem2 = NULL;
    855d853
    mem3->sln!=NULL) free(T->mem3->sln);
    856a855
    > T->mem3 = NULL;
    881d879
    mem4->sln!=NULL) free(T->mem4->sln);
    882a881
    > T->mem4 = NULL;
    907d905
    mem5->sln!=NULL) free(T->mem5->sln);
    908a907
    > T->mem5 = NULL;
    933d931
    mem6->sln!=NULL) free(T->mem6->sln);
    934a933
    > T->mem6 = NULL;
    959d957
    mem7->sln!=NULL) free(T->mem7->sln);
    960a959
    > T->mem7 = NULL;
    985d983
    mem8->sln!=NULL) free(T->mem8->sln);
    986a985
    > T->mem8 = NULL;

    Index: PlotWindow.cpp

    ===================================================================

    RCS file: /home/piglet/cvsroot/gebc-1.07/PlotWindow.cpp,v
    retrieving revision 1.1.1.1

    diff -r1.1.1.1 PlotWindow.cpp
    833c833
    ~PlotWindow();

    > delete T;
    Index: RangeWindow.cpp

    ===================================================================

    RCS file: /home/piglet/cvsroot/gebc-1.07/RangeWindow.cpp,v

    retrieving revision 1.1.1.1
    diff -r1.1.1.1 RangeWindow.cpp
    656c656

    ~RangeWindow();

    > delete T;

  44. Dr Loser says:

    Ah, that’s what WordPress expects, for some non-standard reason.

  45. Dr Loser says:

    What the heck. It works on my computer. One more time, and to hell with WordPress and my own incompetence:

    <img src="http://i837.photobucket.com/albums/zz298/DrLoser/Original_zps811ca3b7.png&quot; alt="GEBC"

  46. Dr Loser says:

    Ah well, ignore my incompetence. You get the picture.

  47. Dr Loser says:

    Sigh. My fault. Who needs sophistication or an edit button?

    <img src="http://i837.photobucket.com/albums/zz298/DrLoser/Original_zps811ca3b7.png&quot; alt="GEBC"

  48. Dr Loser says:

    Let me try that again, this time with the closing bit of html.

    <img src="http://i837.photobucket.com/albums/zz298/DrLoser/Original_zps811ca3b7.png&quot; alt="GEBC"

  49. Dr Loser says:

    Speaking of requirements, I’d be interested to know your ETA to something close to this:

  50. Dr Loser says:

    See, the thing here, Robert, is that I do this for a living. You do not.

    Leaving aside all this “everybody can program, except when they can’t install via a single click” nonsense, there is a significant difference here. Let me summarize it as the “Four Rs”.

    1) Requirements. These are quite important. In the case of your yet-to-be-released GEBC port to a Pascal-based FastCGI Website serving thin clients, you don’t actually have any, do you?
    2) Responsibility. If and when you get this ludicrous monstrosity up and running, you’re just going to get bored with it and drop it after six months, aren’t you? Because nobody is paying you to do otherwise.
    3) Respect. You have to respect your customers, even if they don’t pay you. They have alternatives. They can pay $9.995 for something that is infinitely better and will actually make them happy, as opposed to confused and irritated.
    4) Reliability.

    AKA, “I was going to go shooting today, but there were 999 other people clogging up Pogson’s web server, and I couldn’t get the vague details I needed.

    I know! I’ll spend $9.95 on a small, smart, web thingie app that does all that and more!

    Four Rs for the win!

  51. Dr Loser says:

    As an aside, a very good friend of mine has just pointed out the following:

    Pascal? Well, it’s not necessarily bad – medicine majors study on corpses, why not teach CS/SE majors on Pascal?

    Of course, that assumes that you, Robert, have some sort of grounding in either Computer Science or Software Engineering.

  52. Dr Loser says:

    Now, I may be wrong here, but FreePascal does not offer FastCGI out of the box.

    For that you have to use a framework: either Lazarus or Brook.

    I mentioned both of them, as you may recall: today, in fact.

  53. Dr Loser says:

    Explain, then, Robert, how the program stays in memory after it exits.

    Not relevant to CGI; relevant to FastCGI.

    And, otherwise, I’d be interested in your comments on Lazarus and Brook (even if you’ve looked and decided that they’re not for you in this particular case).

    And I’d be interested by your arguments on templates versus “very nice string-functions.” I have a personal preference for the former over the latter. You may differ on this.

    I’d also be interested in your opinions on REST.

    It’s quite an important concept when you move beyond the idea that “this is an idempotent function mapping within my program” towards “this is an idempotent function mapping between calls across HTTP,” as you know.

    In other words, I’m still waiting for your definition of “identical.”

    It doesn’t matter to me that, as with “parallelism” and “provability,” you are standing up for yourself and ignoring what every computer scientist and/or mathematician would understand by those terms.

    I’m just curious. We can’t really discuss “identical” unless you come up with yet another personal definition, can we?

    (Let’s leave bloat for another time. I believe I’ve done enough via BNF to demonstrate that your current definition of “bloat” is utterly meaningless.)

  54. Dr Loser, hammering a hammered nail, wrote, “you have to program all of that, because you insist on using Pascal. Were you to use PHP, Perl, Python, Ruby or any number of appropriate languages for the Web, you wouldn’t need to.”

    FreePascal provides units that work with FastCGI. It’s the server that needs to be set up for it. The programme doesn’t even need to know it’s using CGI or FastCGI. It works on the query string, not the protocols. The code just sits there in RAM until it’s run.

    Dr Loser wrote, “Yes, and you have to program all of that, because you insist on using Pascal.”

    “All of that” is trivial in Pascal:
    fpconnect – Open a connection to a server socket.

  55. Dr Loser says:

    You’re also assuming REST when you say

    The same numerical algorithms are used to convert inputs to outputs. e.g. for a given search query, the programme will deliver the same HTML.

    One more small Web detail that you’ll need to address. From the looks of them, both Lazarus and Brook do that for you.

    Well worth looking into, under your circumstances. Let me know if I can help.

  56. Dr Loser says:

    Dr Loser wrote, “we both understand what “identical” means in these circumstances.”

    The same numerical algorithms are used to convert inputs to outputs. e.g. for a given search query, the programme will deliver the same HTML.

    That would be “idempotent,” Robert, not “identical.” And note my qualification: in these circumstances.

    When it comes to CGI vs FastCGI, I think it’s fair to say that the circumstances are not remotely even in the same ballpark.

    So, tell me again.

    In what way is CGI, the scripting language, “identical” to FastCGI, the protocol?

    It isn’t, is it?

    But that’s presumably not what you meant. In what way is CGI, the protocol, “identical” to FastCGI, the protocol?

    It isn’t, is it?

    OK, let’s take an architectural position here. From the point of view of your Pascal application, in what way is CGI “identical” to FastCGI?

    An exercise left for the reader. I’d be interested to hear the answer.

  57. Dr Loser says:

    Now I come to think about it, have you considered using node.js?

    Node is actually very cool. It’s supported by Google. There are new modules coming out every day. It’s asynchronous by design, so you’re not limited by “parallelism” in either sense.

    It runs through a language that’s purely designed for the Web.

    JavaScript is also a functional language, which makes provability all the easier.

    Plus which, everybody understands JavaScript, which makes it ideal for sharing, caring, FOSS projects.

    Need I remind you that nobody understands, or at least can be bothered to understand, Pascal?

    I’m pretty sure there are excellent node.js graphical libraries out there, as opposed to the non-existent Pascal Web graphical libraries.

    I’ll dig out a few links if you want. I’ll even offer my (FOSS) support.

  58. Dr Loser wrote, “we both understand what “identical” means in these circumstances.”

    The same numerical algorithms are used to convert inputs to outputs. e.g. for a given search query, the programme will deliver the same HTML. It doesn’t matter what the CGI protocol is used. That’s all transparent to the user and no obstacle to using Pascal. And it does scale well enough.

  59. Dr Loser says:

    Or to put it another way:

    I equated Fast CGI with CGI because from the application’s standpoint they are identical.

    How so? I don’t wish to waste another rant until we both understand what “identical” means in these circumstances.

    We’ve already agreed to redefine “parallelism” and “provability,” so I’m quite happy to continue with your version of “identical.”

  60. Dr Loser says:

    Isn’t that rather a lot of quoted information that just replicates what I said, Robert?

    You’re confusing CGI (the protocol) with CGI (the scripting mechanism) …

    To run under FastCGI, you have to be designed to run under FastCGI. You need to build in socket-handling, which of course you can do. I know it’s possible in do inside a bare-bones Web environment.

    See? Exactly the same information, in about 1/5 of the verbiage.

    I’m doing my best to offer my professional assistance here, but as my (FOSS) client you are of course entitled to claim that I’m “ranting.”

    Seriously though, I’d look into the requirements to support the FastCGI protocol. Without a Web framework, it takes a fair bit of effort. If you reckon the effort is worthwhile, then go for it!

    Me, I’d accept that I am never in a million years going to get 1,000 shootists on thin clients using your software (which is basically GEBC rewritten in Pascal, with the graphics taken out and maybe Runge-Kutta interpolated) in parallel.

    And without that, there’s not really any point in the Web service at all, is there? These benefits you list (less CPU, less RAM, file-caching, etc etc) completely evaporate.

    The single relevant paragraph from your cite is as follows:

    The FastCGI program initializes itself, and waits for a new connection from the Web server.

    Yes, and you have to program all of that, because you insist on using Pascal. Were you to use PHP, Perl, Python, Ruby or any number of appropriate languages for the Web, you wouldn’t need to.

    Incidentally, are you still proposing to use the “very nice [Pascal] string-functions” to create the Web pages? Or are you considering the use of either the Lazarus or the Brook frameworks, complete with templates?

    I recommend templates. They are convenient and configurable and whizzy and are a useful weapon in any programmer’s arsenal.

  61. Dr Loser, ranting on, wrote, “Facebook — at least until recently, and it may have changed — uses nginx and FastCGI. Your link does not prove that it uses CGI, because it doesn’t.”

    I equated Fast CGI with CGI because from the application’s standpoint they are identical. With Fast CGI the process sits there waiting for data. Fast CGI keeps the process resident in RAM and starting involves giving it control:

    • Simplicity, with easy migration from CGI. The FastCGI application library (described on page 9) simplifies the migration of existing CGI applications. Applications built with the application library can also run as CGI programs, for backward compatibility with old Web servers.
    • Language independence. Like CGI, FastCGI applications can be written in any language, not just languages supported by the vendor API.


    FastCGI is conceptually very similar to CGI, with two major differences:

    • FastCGI processes are persistent: after finishing a request, they wait for a new request instead of exiting.
    • Instead of using operating system environment variables and pipes, the FastCGI protocol multiplexes the environment information, standard input, output and error over a single full-duplex connection. This allows FastCGI programs to run on remote machines, using TCP connections between the Web server and the FastCGI application.

    Request processing in a single-threaded FastCGI application proceeds as follows:

    • The Web server creates FastCGI application processes to handle requests. The processes may be created at startup, or created on demand.
    • The FastCGI program initializes itself, and waits for a new connection from the Web server.
    • When a client request comes in, the Web server opens a connection to the FastCGI process. The server sends the CGI environment variable information and standard input over the connection.
    • The FastCGI process sends the standard output and error information back to the server over the same connection.
    • When the FastCGI process closes the connection, the request is complete. The FastCGI process then waits for another connection from the Web server.

  62. Dr Loser says:

    Sorry to burst your bubble, but CGI does indeed have a problem with scaling. It’s why practically nobody uses it any more. The number of file images in memory is irrelevant: it’s the overhead of stopping and starting processes that hits you. (And please don’t go saying that “processes are free” on Linux. They’re not. And the CGI creation/tear-down of a socket most certainly is not.)

    Facebook — at least until recently, and it may have changed — uses nginx and FastCGI. Your link does not prove that it uses CGI, because it doesn’t. (What an astonishing waste of hardware that would be.)

    You’re confusing CGI (the protocol) with CGI (the scripting mechanism). To run 1000 instances in parallel you would definitely need FastCGI running the FastCGI modificiations to the CGI protocol. Your little <code> snippet isn’t going to cut it, I’m afraid.

    To run under FastCGI, you have to be designed to run under FastCGI. You need to build in socket-handling, which of course you can do. I know it’s possible in Pascal; I’m just warning you that it’s one more thing amongst many that you will have to do inside a bare-bones Web environment.

    I don’t expect you’ll ever create an empire either; let’s face it, nobody but you will ever use this Web service. I’m just doing my best to highlight the tons of extra work you are committing to, even if nobody outside your own family uses this, to make it work. Almost all of which would have been avoided if, in the first place, you’d used a language designed for the Web.

    And I’d still recommend forking out $9.95 for the mobile app. You get so much more useful functionality for your $9.95, and you’d have saved tens of hours of fruitless labour.

  63. Dr Loser wrote, “CGI is pretty rotten at scaling. It looks like it’s the only option on offer, though.”

    With file-caching, I don’t think CGI has much trouble scaling. There’s only one copy of the application needed in RAM. For scurity, one might do it differently but CGI will do the job. Then there’s FastCGI which causes the process to persist and serve multiple requests. Facebook is rumoured to run on Nginx which runs PHP as a CGI script. Facebook scales. I don’t expect I will ever have a scaling problem. I’m not out to create an empire.

  64. Dr Loser says:

    I stand corrected, Robert.

    Not only can you run Pascal on the Web naively through CGI, but there’s actually not one, but two, Pascal “frameworks” out there: Lazarus and Brook. (They both seem to rely on CGI.)

    This is quite impressive. Not just one raving lunatic who is prepared to put doomed effort into producing a Pascal Web framework, but two!

    Unfortunately for your current purposes (a massively parallel 1,000-user online ballistics engine) you’re going to be limited by CGI, which is the solution you’re using for your home projects/tasks. As you know, CGI is pretty rotten at scaling. It looks like it’s the only option on offer, though.

    Of the two frameworks on offer, I think Lazarus is the one I’d go for. It has a nice-looking graphical interface, which should make the job easier for you, and it’s got a reasonably minimalist feature-set of typical framework features. Foremost amongst these is the templating system, which you will find knocks the socks off mucking around with Pascal’s “very nice string functions,” as I pointed out earlier. I haven’t looked too closely, but I don’t think Brook has those.

    Assuming that this works at all (several of your other Pascal packages appear to have rotted away), you’ll now be left with a limited and not very extensible Web subsystem that is even more unlikely to be picked up for development through FOSS than the Pascal GUI as originally proposed. But hey, giving back to the FOSS Community wasn’t really the aim of all this, was it?

    Good luck with plotting the graphs and so on; I haven’t quite figured out how you’d do that. I’m sure you’ll find an elegant and minimalist solution.

  65. Dr Loser wrote, ” It doesn’t prove that you can run a Pascal application over the Web.”

    That’s just plain silly. I have all kinds of Pascal applications running on my server: search, database and such. The

    Here’s a link describing the details of how it works.

  66. Dr Loser says:

    I don’t wish to be picky, but I agree that you owe a better explanation for the following:

    That’s what I mean by overly-complex. Compilers should not think they know too much.

    FreePascal and C/C++ do not differ in this respect, as pointed out by That Exploit Guy.

    I have yet to see a compiler that doesn’t feature a boat-load of switches, specifically designed to give the user full control. You may be able to come up with an example that is acceptable to you.

    And,, finally, don’t you think that anthropomorphising a compiler, of all things, is about as silly as it is possible to get?

    A compiler is a deterministic machine. It’s about as far from “knowing anything,” let alone “too much,” as it is possible to get.

  67. Dr Loser says:

    As for your appeals to authority, I’m not even going to dignify them with a response.

    Logical fallacies are not my cup of tea.

  68. Dr Loser says:

    One of the features of a web application is that the user can use any platform to access it and it can be written in any language, including Pascal.

    Did I say otherwise? I’ve been configuring Apache for about ten years, Robert. I understand these things. I also understand that I wouldn’t go near this one with a ten foot barge pole, precisely because I have been configuring Apache for about ten years, and I know the pitfalls.

    May I gently point out that our ignorance is joint here? That ballistics website to which you linked — I don’t know it isn’t Pascal, and you don’t know it is. (I’m prepared to bet your $10 to my $100 that it isn’t, though.)

    Just linking to a ballistics website is rather pointless, isn’t it? All it proves is that you can run a ballistics application over the Web. It doesn’t prove that you can run a Pascal application over the Web.

    Luckily I’ve sorted that proof out for you with my handy link (above), and I’ll explain some of the pitfalls (below).

    Pascal has very nice string-functions, ideal for web applications.

    And here they are. A pleasant little subset of the string functions available in every other language. Half of them seem to be for AnsiStrings, half not. (This is not a limitation you will find in the typical languages used for Web programming, btw.) None of them appear to work on WideStrings, so I guess if you want internationalization, you’re SOL.

    I wouldn’t go around advocating Pascal as an ideal Web language on this basis.

    Oh, and there are a few other things to consider here:

    1) I’ve been unable to find a Pascal-based web framework (as with Zend, Catalyst, RoR, Django, etc). Still, it’s only a single app. We can worry about extensibility later.
    2) I haven’t even been able to find a Pascal templating engine, so I think you’d have to hard-code the entire page inside your (compiled) program. This is likely to be inconvenient. It will also cause you problems if you want to support different “looks” for different browsers.
    3) I don’t see any string functions for HTML escaping, or anything else you might want to do on the Web. Never mind: you can always write your own.
    4) Validation routines, cookie support, etc etc? I guess you can always write your own there, too.
    5) Fortunately you don’t need authentication methods or anything like that. Because they’re not there.

    Pascal is pretty much the worst language I can think of to write a Web application in. It turns out that even C/C++ is better — and I’ve used those, and believe me it’s no fun at all.

    So, to recap, you’ve first crippled a perfectly decent application by needlessly turning it into Pascal, and now you propose to cause yourself further grief by using what can only be described as experimental Apache bindings to put it on the Web. On top of that, by choosing Pascal, you’re needlessly throwing away just about every single advantage that Web programming might give you.

    This may not turn out to be the best programming decision you ever made.

  69. That Exploit Guy says:

    @Pogson

    I just don’t understand how anyone can write reliable software in such a language.

    These are indisputably your own word. So, the question here is:
    Is Linux reliable or not?
    Actually, don’t answer that. Anyone with half a functioning brain cell can tell right away that you have contradicted yourself within just that one little sentence. Whom are you kidding?
    That’s what I mean by overly-complex. Compilers should not think they know too much.
    Without any given specifics, my guess is that he is referring to the optimisation features in gcc. Similar features are also present in Free Pascal compiler. Perhaps it would be nice of you to clarify what you precisely mean by “too much” so as to not waste everyone’s time watching you wave your arms?

  70. Steve Yegge is a real programmer. He learned on Pascal. There’s a reason for that. It works.
    “I taught myself to program on an HP calculator using their RPN stack language when I was 17 years old. I’d tried to learn programming a few times before that but never really “got” it. The HP 28c and 48g scientific calculators were pretty powerful and had great docs. I wrote a 3D wireframe viewer for the 48g — I got a book on 3D graphics and painstakingly translated an example program in Pascal into the RPN stack language. It was pretty sweet when I got it running. After that I bought a PC and Turbo Pascal, and started studying programming in earnest. I was a decently good programmer by the time I went into the CS program in college.”

    It is well known that Linus Torvalds hates C++ and prefers C but he wrote this about C:
    “Some people seem to think that C is a real programming language, but they are sadly mistaken. It really is about writing almost-portable assembly language, and it turns out that getting good results from SHA1 really is mostly about trying to fight the compilers tendency to try to be clever.”
    That’s what I mean by overly-complex. Compilers should not think they know too much. Pascal doesn’t. It knows what is a correct programme and what to do with it. That’s all. That’s exactly what I want from a programming language.

    Linus also wrote, “So the fact is, the C language has scoping rules for a reason. Can you screw yourself by usign them badly? Sure. But that does NOT mean that the same name in different scopes is a bad thing that should be warned about.
    If I wanted a language that didn’t allow me to do anything wrong, I’d be using Pascal. As it is, it turns out that things that “look” wrong on a local level are often not wrong after all.”

    I do want a language which prevents me from doing bad things.

  71. That Exploit Guy says:

    Dr Loser writing out of ignorance…
    Really? Let’s see:

    I can’t do any of that if it stays in C. I just don’t understand how anyone can write reliable software in such a language. I can’t.

    A conundrum indeed. I’m told that the Linux kernel is highly reliable. Have you warned Mr Torvalds of his terrible mistake on this one?
    I think that same “ignorant” person has already nailed you to a tree before you even realise.

  72. Dr Loser writing out of ignorance, wrote, “is that web service written in Pascal? I’m impressed that you found such a thing.”

    One of the features of a web application is that the user can use any platform to access it and it can be written in any language, including Pascal. Pascal has very nice string-functions, ideal for web applications. There are hundreds of millions of websites serving all kinds of roles. The fact that you are ignorant of some is not surprising.

  73. Dr Loser wrote, “No, you think you can translate it. Not the same thing at all. And the “messier” it is, the more likely your translation is to be wrong.”

    The fact that I succeeded more or less quickly refutes that assertion. This is numerical analysis at which I am an expert. I can recognize familiar expressions instantly. I can recognize the data-structure and the algorithms. That’s the heart of the programme.

    The Free Pascal compiler, thanks to the concise definition of the language just about guarantees most of the programme works instantly. I think after hundreds of lines translated I had only two or three bugs to fix, some of which were in the original programme and some of which were typos. The biggest effort was just changing one symbol to another, fairly well-defined process. I used to have an application do most of that donkey-work but CtoPAS wouldn’t run so I did it manually.

  74. Dr Loser says:

    I can judge from the C what the author is trying to do and make the translation do the same.

    Please, please: never go near production software, FOSS or otherwise. Judging what something is trying to do, without understanding what it is trying to do, is a very very dangerous game.

    I couldn’t possibly fix that mess of C without learning C. I can translate it using context.

    No, you think you can translate it. Not the same thing at all. And the “messier” it is, the more likely your translation is to be wrong.

    That happens all the time in natural language.

    And things go wrong all the time in natural language. This is why they hire translators who are conversant with both the source and the target. And if the client is conversant with the original language, they don’t even bother to translate it.

    The compiler and the results give confidence that the translation is correct.

    An entirely false confidence. The only thing the compiler does is to give you confidence that what you have produced is syntactically correct; not the same thing at all.

    And once again, the results require either a reference model or a set of external data.

    For semi-formal correctness, you need a test suite.

    And once you’ve got that test suite, you can apply it to the original. I predict with some confidence that the results will be the same.

    So what’s the point?

  75. Dr Loser says:

    Dr Loser wrote, “Nobody in the whole wide world is ever, under any circumstances whatsoever, going to connect to a server, either yours or anybody else’s, in order to take advantage of this enhanced Pascal GEBC.”

    That is an absurd assertion. People do the like every day.

    Oh, is that web service written in Pascal? I’m impressed that you found such a thing.

    If you remember, Robert, way back at the beginning of this thread, I did suggest that a rewrite into a Web service (say, in PHP) made far more sense than this Pascal hobby project.

    How do you suppose that your clients are going to access your ballistics calculator?

    Via X?

    Don’t you think they’re more likely to say

    a) Sod it, I’ll use the original version written in C/C++ or
    b) I’ll stump up $9.99 for software that actually makes shooting fun with a mobile phone?

    The numbers are virtually identical out to 400 yards, so this programme is as good as Hornady’s.

    And with the minor exception of Drop for x=0, so is the original GEBC in C/C++. Are you beginning to see a pattern here?

    You could argue that it’s already been done…

    The modal “could” is not necessary. I do so argue. I will so argue. I am correct in so arguing. I have no doubt in this argument.

    … but that didn’t prevent Chevrolet from building cars, so why should it prevent me from writing software

    No reason at all, Robert. Feel free to weld a replica Chevrolet of your choice in your garage, or wherever.

    Just don’t expect anybody to want to drive it off afterwards.

  76. Dr Loser says:

    Users want software that is provably reliable.

    Actually, users want a $9.95 product with bells and whistles that does the job for them and is fun to use. There’s one already on the market. I’ve mentioned it a couple of times.

    Once again, the provability currently exists only in your head. You’d have to write a whole bunch of test programs to prove your programes accuracy, even semi-formally. You’d have to use a reference model or else get the data from somewhere. You’d have to convince users that you’ve done all this. I see no sign of you being about to do any of that.

    I can do that for them.

    You can, but are you going to? At the moment it appears to be a case of “because I say so.”

    I can explain to them how the programme works and why it is reliable.

    This is going to take a lecture tour, a set of YouTube videos, or extensive documentation. Are you sure you’re up to the challenge?

    GEBC is not in any distros I am aware of so my work may well make it easier for users to install.

    Well, for starters, rewriting it in Pascal hardly makes it viable for a downstream distro to incorporate it, does it? Think of all the extra dependencies they don’t need for any other purpose.

    And if, by install, you mean little more than “copy an executable,” well then, guess what?

    The original version in C/C++ is equally as trivial to install.

    I can’t do any of that if it stays in C. I just don’t understand how anyone can write reliable software in such a language. I can’t.

    A conundrum indeed. I’m told that the Linux kernel is highly reliable. Have you warned Mr Torvalds of his terrible mistake on this one?

    Or is it just that a 2,000 line long computational program with a bit of graphics attached is somehow more complex and inherently more likely to be unreliable than an operating system kernel?

  77. Dr Loser says:

    Going backwards for convenience, then.

    That’s not concise at all. It requires pages of documentation to explain the syntax.

    Possibly you’ve never encountered Backus-Naur Format, then. It’s the universally accepted way to define the syntax of a computer language. And the less of it there is, the more concise a language is. An elegant little mathematical way to support my point.

    You, on the other hand, are confusing “concision” with “intelligibility.” Now, I would argue that “+=” and so on are so universally intelligible as they apply to computer languages (other than Pascal) that they are completely intelligible. But that doesn’t matter.

    They may not be intelligible. They are demonstrably, mathematically, “concise.”

    It’s not only dangerous and stupid, it’s pretty useless to have that much bloat in a language.

    It’s concise. By definition, it isn’t bloat. Sometimes I think you’ve redefined the word “bloat” to suit whatever humpty-dumpty notion occurs to you at any given moment.

    It’s not dangerous. It’s not stupid. It just isn’t Pascal.

    Practically every single other language in current use has precisely the same constructs.

    And, btw, you’re not forced to use them.

    Rather than translate the whole thing into Pascal, you could just replace “x += y” with “x = x + y.” Non-existent problem solved to your satisfaction..

  78. Considering the font-size that’s not even close. Consider the assignment statement:

    “assignment_operator : ‘=’ | ‘*=’ | ‘/=’ | ‘%=’ | ‘+=’ | ‘-=’ | ‘< <=' | '>>=’ | ‘&=’ | ‘^=’ | ‘|='”

    That’s not concise at all. It requires pages of documentation to explain the syntax.

    Pascal:

    variable|function identifier := expression

    That requires just a few words. That’s much more efficient use of teachers, students and programmers’ time.

  79. Dr Loser wrote, of C, ” It certainly is not over-complex; please quote an example.”

    8 or more assignment operators. Do we really want students to spend 8 times as long to figure out what an assignment statement is? That’s just silly. The only argument I have ever read to support that is that it saves typing. Well, it doesn’t, if you consider the number of times a programmer thinks +=, writes -= and it should have been *=… That invites error and gives errors a place to hide. Check out lkml.org for “typo”… I scanned 100K lines of Linux kernel *.c files in kernel and find “+=” occurs 294 times, “-=” 73 times and “*=” occurs once. Not a lot of typing was saved. Assignment is one of the most frequently used symbol, 10181 times in this case. It’s not only dangerous and stupid, it’s pretty useless to have that much bloat in a language.

  80. Dr Loser wrote, “In no possible way are you meeting user requirements, other than your own. And since your own user requirements appear to be “it must be written in Pascal,” even those seem a little dubious to me.”

    Users want software that is provably reliable. I can do that for them. I can explain to them how the programme works and why it is reliable. Pascal helps that by being a fussy, strongly-typed language with all kinds of run-time checks. All that is useful to the user whether or not they are aware of it. GEBC is not in any distros I am aware of so my work may well make it easier for users to install. I know how to do that with static linking or virtual machines. I can also easily put it on the website as a CGI script or whatever. Heck, using splines, I could put it up as a database/webapplication interpolated for BC, muzzle-velocity, angles etc. I know how to do that. The key is having the application work well so that I can put it to use any way I want. Users will be able to use it too. I can’t do any of that if it stays in C. I just don’t understand how anyone can write reliable software in such a language. I can’t.

  81. Dr Loser wrote, “Either your translation is faulty, or you could have fixed it in C. There are no other options here, Robert.”

    Nope. I can judge from the C what the authour is trying to do and make the translation do the same. That’s all. I have no idea what double* ptr;
    ptr = (double*)malloc(10*__BCOMP_MAXRANGE__*sizeof(double)+2048);
    means but I know what pointers are and I know what malloc does so I can translate that into something sane like, type list= Array [0..10000] of double;
    Solution = ^list;
    . To me, “*” means multiplication… double could mean 8-byte reals or 8-byte words. I have no clue from the C-code. I couldn’t possibly fix that mess of C without learning C. I can translate it using context. That happens all the time in natural language. The compiler and the results give confidence that the translation is correct.

  82. Dr Loser wrote, “Nobody in the whole wide world is ever, under any circumstances whatsoever, going to connect to a server, either yours or anybody else’s, in order to take advantage of this enhanced Pascal GEBC.”

    That is an absurd assertion. People do the like every day. Here for example:
    ” Our new and improved calculator includes both basic and advanced features, allowing you to customize the shooting conditions to replicate your environment. Choose standard or metric, and enter the appropriate data to view your favorite load.

    Standard values are provided in the sight height based on the firearm type, but may be changed to match your setup. Default values are entered in the temperature and pressure spaces but can be changed. Once calculated, we offer a printable “cheat sheet” to tape to your firearm for quick reference. “

    The numbers are virtually identical out to 400 yards, so this programme is as good as Hornady’s. You could argue that it’s already been done but that didn’t prevent Chevrolet from building cars, so why should it prevent me from writing software?

  83. Dr Loser says:

    Because they may not be computer geeks and install their own software.

    Let me get this interesting proposition straight, Robert.

    Everybody can program. Everybody can program professionally. Yet not everybody is a computer geek. Not everybody can install their own software.

    That is prima facie an untenable position. Now let me proceed from the prima facie.

    Nobody in the whole wide world is ever, under any circumstances whatsoever, going to connect to a server, either yours or anybody else’s, in order to take advantage of this enhanced Pascal GEBC.

    Nobody. Never. It’s an absurd proposition.

    If packaging is an issue, you could fix that without even bothering to translate everything into Pascal. In fact, I think it would be easier in C/C++.

    And here’s the thing. The mobile phone app I mentioned (which can be used in the wild and makes use of localised information that can only be acquired via the mobile phone, not via a mythical server) costs $9.99 and has about ten times the features of anything you are going to get through a translation to Pascal followed by rigorous application of Runge-Kutta.

    Not my field, but I estimate a round of ammunition to cost about 20¢. If I use an inadequate piece of software and the result is that I waste five rounds per day of hunting/whatever, that’s a dollar. Ten hunting trips pay for the thing. After that, it’s free.

    And if you look at the features, they’re really cool features. Access to all that professional information (variable velocity etc) from the actual manufacturers? Cool! Using my accelerometer? Cool! Locating the weather through GPS? Cool!

    Fighting through a network to get the output of a FLOSS Pascal program?

    Not really cool. Distinctly off-putting, in fact.

  84. Dr Loser says:

    I can fix it in Pascal. I can’t fix it in C.

    To repeat once more: you have apparently translated the thing wholesale from C to Pascal.

    Either your translation is faulty, or you could have fixed it in C. There are no other options here, Robert.

    That result was obtained by unnecessary detail in the data-structure.

    Then lose the unnecessary detail in the data-structure. Don’t add more unnecessary detail.

    I’m afraid that’s the obvious conclusion to reach.

    When I am finished, the programme will be correct, flexible and FLOSS.

    I could rewrite the thing in Haskell and it would still be “correct, flexible and FOSS.”

    And nobody would ever use it.

    When you started, it was mostly correct (with trivial GUI issues), flexible, and FLOSS.

    The only thing you’re contributing here is to turn it into something that 99% of FLOSS advocates won’t be able to understand and will therefore discard in favour of fixing up the original.

    Which, btw, I have already done. A fifty line diff.

  85. Dr Loser says:

    And now we come to user requirements.

    Why have the programme make the entry and do it incorrectly?

    First of all, I’ve already agreed that this is a bug in the case of x=0. I’ve also given you two separate ways of dealing with that bug. And rewriting the whole thing in Pascal doesn’t achieve either one by itself. Either of my fixes amounts to a single line of C code.

    And secondly, do you think your users will really care? Do you think they’re going to sidle up to a deer, press the muzzle of the rifle next to the deer’s chest (or head, to choice), and worry that their chart shows the drop incorrectly?

    I have never hunted, nor shot targets, in my life, but this eventuality sounds extraordinarily unlikely for multiple reasons.

    GEBC is currently a nice little program that, basically, allows you to print out a handy-dandy range chart and so on for a given rifle and a given type of ammunition and the given atmospheric conditions for the day, laminate it, and go out hunting.

    All this arguing about ten yard increments and O(h) vs O(h^5) is completely besides the point. RK and splines are completely beside the point.

    In no possible way are you meeting user requirements, other than your own. And since your own user requirements appear to be “it must be written in Pascal,” even those seem a little dubious to me.

  86. Dr Loser says:

    Anyone can programme computers and they don’t have to be professional nor paid to do a great job.

    The great fallacy of our age, and I’m surprised you subscribe to it, Robert. You’re obviously an expert Pascal programmer (amongst other languages), but you’ve also got a lot of experience as a teacher.

    Are you seriously telling me that you’ve never met anyone who can’t program worth spit, or at least can’t program to a “professional” level (temporarily defined as “something that other people would want to use”)?

    Because I have. I’ve met hundreds of them. I’ve even worked with them, on platforms of all hues including most *nixes and Windows.

  87. Dr Loser says:

    My point is that no one can guarantee the correctness of C code. It’s an ill-formed, imprecise, over-complex language designed to do everything for everyone optimally, a logical impossibility. PASCAL on the other hand will get a computer to do what the computer is able to do with a very compact syntax.

    I’m going to have to take a bit of time to correct your misapprehensions here, Robert.

    0) No-one can guarantee the correctness of any code, as it pertains to the design. But that’s not what you meant (although it is important in this case), so let’s carry on.
    1) I don’t think that adding a link to Google, with a search for “upgrade to gcc broke,” is entirely relevant to the argument. We differ on this point.
    2) C has many issues, but being “ill-formed, imprecise, and over-complex” is not one of them. It certainly is not over-complex; please quote an example. It is not at all imprecise; it’s as precise as the underlying hardware architecture will allow it to be. It’s difficult to see how it’s ill-formed, but perhaps you just mean “I don’t like the look of it.” I may be putting words into your mouth. I apologise. What do you mean by this?
    3) Pascal’s syntax is no more concise than C’s. Here’s C in BNF. (I believe that’s C89, although C99 is not significantly less complex.)

    The two sole advantages of Pascal are that a) it has runtime bounds checking and b) it’s very pointer-averse. These advantages made it suitable for teaching purposes in the 1970s and 1980s, and make it suitable for very small simple programs even today. But for modern systems, they actually act as disadvantages.

    Otherwise Pascal would be the language of choice for developers everywhere. And, of course, obviously for the Linux kernel.

    I can very well judge the correctness of my programme by passing the compiler over it and comparing the output with reality and other computations.

    And now we come to “correctness,” another Computer Science concept which you miss entirely. I’m sorry, but “correctness” is not interchangeable with “works for me.” Correctness, properly stated, is a mathematical concept, and no language on Earth passes this test for anything more than a trivial (~100 lines) program.

    C is no different. In real world usage, a watered down version of “correctness” implies:

    a) A reference model. Unless I’m much mistaken, your reference model in this case is the original C/C++ code. On this assumption, your measure of correctness relies on a basis you condemn as “ill-formed, imprecise, and over-complex.” Funny sort of reference model, that.
    b) A test suite. The tests may be written against the reference model, or you may choose to write them against external expert data, which I presume would be ballistics data gathered and published by a government or other large organisation.

    I eagerly anticipate your Pascal test suite. It’s a lot more effort, but it will make the whole thing worthwhile.

    In the mean time, and absent (a) and (b), your code is not going to be “correct” in even a semi-formal sense. Chucking random write-statements wherever you guess a problem exists is not going to get around this small yet vital detail.

  88. Dr Loser wrote, “This is apparently what you get when you pay for a professional, supported, solution, rather than rely on an amateur unsupported FOSS one.”

    Anyone can programme computers and they don’t have to be professional nor paid to do a great job. The programme works. For some people that is enough. It’s not enough for me. I want more and I will get it despite your criticism. When I am finished, the programme will be correct, flexible and FLOSS.

  89. Dr Loser wrote, ” The one thing it doesn’t mean is an off-by-one error.”

    It certainly is off by one. No one needs the first row of the data-structure because it’s just initial conditions. Why have the programme make the entry and do it incorrectly? It’s all part of the problem of choosing the smallest step size being one yard for numerical accuracy instead of say, 10 yards using RK and splines. The programme calculates x as a real number, divides by 3 and truncates to get the index… so the range table entries are for random ranges in the vicinity of some 1-yard step. Instead of calculating x from t+dt etc., the programme could start from x and derive the others. The method used in gebc-1.07 is O(h). RK can be O(h5) so 1 yard steps with gebc-1.07 are ten times as accurate as 10 yard steps but RK would be 100K times more accurate, allowing much larger step-sizes. ie. With RK, 6-yard steps would give the same accuracy as 1 yards steps currently. Further, the programme should use variable length steps to allow for rapid changes in reality, eg. long-range behaviour versus mid-range behaviour where bullets are flying nearly horizontally or dropping through the sound-barrier. In any event, y/x is the wrong expression to use at x=0. The bullet is not flying at 90 degrees on launch but a known value and holdover should be precisely zero.

    So, there are multiple logical and practical errors in the table even though it describes reality roughly well enough. That result was obtained by unnecessary detail in the data-structure. There’s no guarantee at all that the programme will work properly under all circumstances given these problems. I can fix it in Pascal. I can’t fix it in C.

  90. Dr Loser wrote, ” Why complicate things by introducing parallelism, a server, network latency, error recovery, etc etc etc?”

    Because they may not be computer geeks and install their own software. They can run it on my server.

  91. Chuckle. Dr Loser wrote, “You had some degree of difficulty understanding the C/C++ code, in which case it’s difficult to see how you can guarantee the correctness of your translation.”

    My point is that no one can guarantee the correctness of C code. It’s an ill-formed, imprecise, over-complex language designed to do everything for everyone optimally, a logical impossibility. PASCAL on the other hand will get a computer to do what the computer is able to do with a very compact syntax. It can be described on just 3 pages (52 .. 54) of Niklaus Wirth’s book, The Programming Language Pascal

    Simple and elegant, isn’t it?

    I can very well judge the correctness of my programme by passing the compiler over it and comparing the output with reality and other computations.

  92. Dr Loser says:

    Wouldn’t you rather I tweaked code that I knew exactly what it was doing instead of guessing?

    Something of a false dichotomy, isn’t it?

    Either

    a) You understood the C/C++ perfectly well, in which case you could tweak the original with far less effort and to far greater benefit for the FOSS community, or

    b) You had some degree of difficulty understanding the C/C++ code, in which case it’s difficult to see how you can guarantee the correctness of your translation.

    Either case works for me; I’m indifferent to the result.

    I’ll simply comment, once more, that my four hours work and fifty line diff strikes me as a more valuable contribution to FOSS than your (impressively herculanean) efforts so far.

  93. Dr Loser says:

    One of the things I discovered this week was the pathetic state of the FreePascal IDE.

    What did you expect? Almost nobody uses it. This is akin to discovering that the world is round.

    At least now I have the code working to the point where I don’t need an IDE nor a debugger.

    Thus obviating twenty years of concerted development (apparently in all other languages bar Pascal) intended to make the programmer’s life more easy and enjoyable and efficient.

    I just run the code and check it’s output. If I want to examine the process, I insert write statements.

    A process unique to Pascal? I think not. Also an absurd waste of time compared to using a debugger.

    So, the programme has become its own development environment along with the fine tools of FLOSS, and GNU.

    No, the program has simply become a litter-filled wasteland of best-guess write-statements.

    One thing it has not become is a “development environment,” in any meaningful sense. You might just as well claim that the original program was a “development environment.”

  94. Dr Loser says:

    Processing done in parallel is parallel whether you want to define it that way or not.

    No worries. I’m amenable to using your interpretation of the term, rather than the Industry-standard one.

    There’s no reason Joe’s calculation which has nothing to do with Bill’s calculation needs that kind of parallelism.

    But there’s no reason Joe’s calculation cannot be done on Joe’s device — a small smart thingie called a smart-phone. Similarly for Bill. Why complicate things by introducing parallelism, a server, network latency, error recovery, etc etc etc?

    It can use the same application in GNU/Linux however because of file caching and shared re-entrant code. ie there’s no need for 1000 PCs to do the work one good server could do.

    And GNU/Linux is special in this regard, how?

    Are you introducing this unnecessary (and impractical — it will never happen in the real world) complication simply to highlight the (non-existent) benefits that a GNU/Linux server gives you over a Solaris server or a Windows server?

    I’m sure Joe and Bill and their 998 friends will thank you for that.

    Pascal code, unlike PHP or Java is plenty fast enough to do this.

    Impossible to say without measurement. One thing I can say is that C is plenty fast enough by comparison with Pascal.

    Another thing I can say with about 99% confidence is that Java would be equally fast enough. All the calculations in GEBC are local enough in scope that a good JITter will approximate to native code performance.

    And, in fact, will probably blow the socks off Pascal.

  95. Dr Loser says:

    What does this mean?

    I’ll step you through it, Robert.

    1) The one thing it doesn’t mean is an off-by-one error. It might conceivably mean a division-by-zero error.
    2) However, in C/C++, a floating-point division by zero is entirely permissible. (An integer division by zero is not: it causes a runtime error.) The result of this division is either INF or -INF.
    3) It’s up to the programmer to deal with this result.
    4) In the present case, the programmer fails to deal with the result. Well, it’s FOSS. It’s alpha. (The two terms are usually equivalent, though not obviously in a commutative sense.) What do you expect?

    More to the point, yes, it’s a bug. What do you do, as a programmer?

    a) You can choose to ignore it. This is not unreasonable. It’s a single point in the range table, and it’s not one — I imagine — that anybody is going to use.
    b) You can choose to fix it. One typical fix is to assign x an initial value of something like 0.000000000001, which at least approximates a reasonable result. Presumably a better fix would be to set min=1 in the constructor for RangeWindow, which will then ignore the faulty data completely. The fix rather depends upon the intentions of the design.
    c) You can choose to rewrite the whole thing in Pascal.

    It isn’t clear what option (c) gives you. Apart from the gargantuan and pointless waste of effort, you’re still left with having to deal with the bug.

    Such output would certainly be more useful on smartphones that don’t have as much memory and CPU power as legacy PCs.

    I think today’s smartphones are easily capable of running the calculation five times over for five different kinds of bullet, and representing all five results as required. Surely a spline would be overkill here?

    Besides which, if you’re aiming to put this on a smart-phone, I don’t see how rewriting it in Pascal is going to advance your aim.

    And furthermore, to repeat, a more fully-featured and sophisticated app already exists for smart-phones. It only costs $9.99. I expect 99% of hunters would happily pay that for an app that (unlike this one) has a wealth of features:

    Shooter currently has over 1,300 bullets available in the built-in library including Bryan Litz’ measured ballistic coefficients for over 175 popular bullets.

    Stepped Ballistic Coefficients Use multiple ballistic coefficients for varying velocities in your trajectory. Some bullet manufacturers provide this and it provides a more accurate solution.

    Angle Detection Use your device’s accelerometer to determine look angle (up/downhill shot). Simply turn on the angle detector and point device at target.

    Automatic Atmosphere Automatically populate Altitude, Temperature, Pressure, Humidity and Wind Speed by pulling data from the nearest weather station based off GPS location (Density Altitude may also be used instead of altitude/pressure/humidity input).

    Incidentally, it seems to cope with graphing six separate loads without much of a struggle.

    And far more. This is apparently what you get when you pay for a professional, supported, solution, rather than rely on an amateur unsupported FOSS one.

  96. Dr Loser wrote, “Modern parallelism isn’t usually considered to be the same thing as “a thousand thin clients and a server,” btw”

    Processing done in parallel is parallel whether you want to define it that way or not. There’s no reason Joe’s calculation which has nothing to do with Bill’s calculation needs that kind of parallelism. It can use the same application in GNU/Linux however because of file caching and shared re-entrant code. ie there’s no need for 1000 PCs to do the work one good server could do. Pascal code, unlike PHP or Java is plenty fast enough to do this.

  97. Dr Loser wrote, “Well, you might have a better understanding of C than I do, Robert, but I’m pretty sure it doesn’t. It’ll either crash or write nonsensical numbers all over the screen.”

    What does this mean? see gebc-1.07 in lib/ballstics/ballistics.cpp
    double x=0, y=0;
    ...
    int n=0;
    ...
    if (x/3>=n){
    ...
    ptr[10*n+2]=-RadtoMOA(atan(y/x));

    Now, what does a PC controlled by C do with that 0/0 in the argument for atan? Pascal objected… You might notice the value the C programme puts out for x=0 is drop = 5400 MOA, not zero…

    So, the C programme has some weird things in it that Pascal does not tolerate. Good. I like cleaner code.

  98. Dr Loser, not understanding FLOSS, wrote, “It will never be used by anybody but yourself.”

    GEBC was written years ago and has 74 downloads this week. It’s alive. I just want to make it better. I can’t do as much with it as C as Pascal. I can certainly improve the PBR calculation for hunters and the solution of differential equations in the engine. It may not need improvement for many purposes I see it as much more useful if it spits out interpolation splines instead of just presenting data. Then the output can be used in other calculations, like solutions for five different bullets for deer to help hunters choose the one that suits the terrain. Such output would certainly be more useful on smartphones that don’t have as much memory and CPU power as legacy PCs.

    I have been working on ballistics calculations since about 1980 and my first PC. Why should I stop now?

  99. Dr Loser wrote, “what, precisely, have you achieved in a week’s work?”

    Exactly that, produced a Pascal programme which does essentially the same as the original C code by simple translation and adding 100+ lines of my own code to replace the main programme. Now I can understand every bit of it and do what I want with it. The modification is allowed under GPL and so will my future work with it. Wouldn’t you rather I tweaked code that I knew exactly what it was doing instead of guessing? I am sure I can improve on the numerical algorithms, data-structure, and make good use of some of the exports of the programme. Winter is coming and it will get harder to find useful stuff to do outdoors. This code will give me endless hours of pleasure.

    One of the things I discovered this week was the pathetic state of the FreePascal IDE. I was annoyed by it years ago and it’s not much better today… Version 2.2.4 didn’t work for me. Current 2.6.2 didn’t either but middling 2.4.4 did until I tried to set a breakpoint… At least now I have the code working to the point where I don’t need an IDE nor a debugger. I just run the code and check it’s output. If I want to examine the process, I insert write statements. They come out under the GUI. So, the programme has become its own development environment along with the fine tools of FLOSS, and GNU.

    I have also shifted two tons of gravel by wheelbarrow, loaded many rounds of hunting ammunition for future years, blogged, read, made preparations for next year’s gardening and watched the world go to Hell more or less for lack of trying to do the right thing most times. I even got the “little woman” to get out in the yard to fuss with plants before the snow comes and she handed out treat to the goblins. She spends entirely too much time on FaceBook…

  100. Dr Loser says:

    Now, correct me if I am wrong, Robert, but your latest update is remarkably close to the range table on the SourceForge site (alpha software, btw).

    I’m all in favour of changing a few parameters in drop-boxes here and there, and saving the result in a text file, and editing the text file so that it looks a teeny bit different …

    … but what, precisely, have you achieved in a week’s work?

    Me, I started from scratch. I worked with what I was given.

    And I still have a solution that amounts to nothing more than a fifty-line diff file.

  101. Dr Loser says:

    Now, Deaf Spy, do you see why thin clients are a great idea?

    If I may answer on his behalf, no, they’re not in this case.

    It’s a simple, almost trivial, ballistics program with a neat little front-end in fltk (portable to any platform you wish) that you seem determined to wreck by means of Pascal. Who would want that?

    It will never be used by anybody but yourself. It will most certainly never be used by 1,000 notional thin clients trying to access the Beast over the Internet.

    I’m completely at a loss as to what you’re trying to achieve here, apart from the sheer enjoyment of off-by-one errors.

    And the offer of the diff which corrects the original problems is still here, should you get bored and give up.

  102. Dr Loser says:

    The engine checks out in Pascal. I was getting a division by zero due to an off-by-one error. I am not sure where that came from but I might have made an error in the looping. Perhaps C just ignores that…

    Well, you might have a better understanding of C than I do, Robert, but I’m pretty sure it doesn’t. It’ll either crash or write nonsensical numbers all over the screen.

    Speaking of which, your results so far don’t seem to be in Gtk2. Any issues there?

    See, this is exactly what I was warning you about. You might think that you can get a line-by-line translation up and working inside a day or two, but you’ll almost always be hit by off-by-one errors.

  103. Dr Loser says:

    By including latitude, longitude and compass heading on the input screen, and changing the engine, it could easily deal with Coriolis.

    And by including an appropriate model of the upper atmosphere and a set of orbitals downloaded from your friendly NASA site, it could easily deal with landing a man on the moon.

    It is what it is, Robert. Let’s just get either my (ready and waiting) C++ bug-fixes, or your port to Pascal, done before we indulge ourselves in feature creep.

    Modern parallelism isn’t usually considered to be the same thing as “a thousand thin clients and a server,” btw. It’s more to do with fairly complicated things involving work-stealing and cache-lines and so on, which are nicely abstracted away in C++ via TBB from Intel and so on. I could be wrong, but Pascal is not amenable to parallel processing in the modern (post 1980s) sense.

    However, I like a challenge. I think my next task is to split the engine from the GUI via TCP/IP sockets and to write a nice little load-tester (in C++, but I’ll let you have the source so that you can port it to Pascal) which quantifies the sort of “thin client” load we’d be talking about.

  104. Deaf Spy wrote, “Now, Mr. Pogson, do you see why thin clients are not always a great idea?”

    Properly written, this application would have no problem with 1K simultaneous users on a modern PC. Now, Deaf Spy, do you see why thin clients are a great idea?

    IDC reports that 96% of enterprise clients are thin. There are reasons for that. It’s the right way to do IT with fewer systems needing tech-support and the clients last so long. Thin clients are like telephones. I have one in my kitchen that was bought in 1987. It has a beautiful dial and the most comfortable handset for my ear. It actually has curves instead of sharp edges.

  105. Deaf Spy says:

    Pogson wrote: He forgets about scale. Imagine a server somewhere running the programme and a thousand shooters are tweaking away…

    Now, Mr. Pogson, do you see why thin clients are not always a great idea?

  106. Dr Loser wrote, ” These days, you’re extremely unlikely to see 32MB being swapped out to a specially-prepared partition on disk.”

    He forgets about scale. Imagine a server somewhere running the programme and a thousand shooters are tweaking away… That’s now 32gB of data. It matters. I think CPUs are fast enough that 1000 shooters would not bog the CPU down to calculate a few compact interpolating polynomials in a few MB.

    Dr Loser also wrote, “Are there any acknowledged parallel-processing frameworks built on top of Pascal?”

    GNU/Linux does parallel very well. This application could be running as one of hundreds or thousands of processes on a terminal server or as part of a project to locate the players in a complex crime-scene. Imagine the shooters are using machine-guns and some of the inputs are locations of shell-cases and bullet-holes and gun-camera video. There could be millions of combinations to check. Often this would be at close quarters where the application would not be useful, but imagine a field of battle or an ambush… Imagine a ship’s fire-control system with some computer needing to match an array of weapons against an array of targets. This programme could be used many times simultaneously in a “target rich” environment. It could also compute multiple aiming points to feed into another system. In the heat of battle, having a lot of information available before you need it is valuable matched against value/threat of targets.

  107. Dr Loser wrote, “where does “3-D” come into this?
    Last time I checked, ballistics basically work on a 2-D plane “

    This programme allows for windage, elevation and vertical motion. That’s 3-D. Unlike the simple 2-D model, this programme allows the shooter to shoot uphill or down with a wind from any direction: left, right, headwind, tailwind. By including latitude, longitude and compass heading on the input screen, and changing the engine, it could easily deal with Coriolis.

  108. Dr Loser says:

    One more thought on that 3-D thing.

    Ignoring Coriolis effects for the moment (which certainly involve an extra dimension), where does “3-D” come into this?

    Last time I checked, ballistics basically work on a 2-D plane …

  109. Dr Loser says:

    These days RAM may involve storage devices so that could be really slow to save/restore.

    Well, to be absolutely frank here, Robert, I think you’ve forgotten which century we’re living in, and you’re still obsessed with an obsolete computer platform that was originally designed for the PDP-8. These days, you’re extremely unlikely to see 32MB being swapped out to a specially-prepared partition on disk.

    I think the programme is fast enough…

    I haven’t measured it (have you?) but I’m fairly certain that it is.

    …but if you wanted to do parallel processing eventually, this would not scale, say you wanted to figure out a criminal shoot-out in 3D?

    Interesting.

    A few small doubts creep into my mind at this point.

    Are there any acknowledged parallel-processing frameworks built on top of Pascal? Yet again, not my area of expertise, but I was under the impression that they were all either heavily-modified bits of Fortran or else written (like GEBC) in C/C++.

    And doesn’t it strike you as a little odd that you’re now complaining that GEBC (a FOSS program that you have hitherto been praising to the skies) is not scalable to parallel architectures?

    I mean, it strikes me as odd. I can’t even imagine why anybody would assume that it was designed to be scalable in that way. It certainly doesn’t seem reasonable to extend a 2-D, non-Coriolis, non-Runge-Kutta tool in order to fulfil an as-yet unspecified 3-D requirement.

    But, such is the way with FOSS. Yesterday (or in 2008, in this case) you were everybody’s darling. Today, you’re rewriting the whole thing in Pascal. And tomorrow?

    You’re completely and provably obsolescent.

    It’s a shame, really.

  110. Dr Loser objects, “There is no possible way for a program this trivial to “squander RAM,””

    Do you really think this thing needs several MB to hold so little information? Essentially the dozen items on the input screen represent all that information. That’s some new point of fluffiness. A programme like this evolves. We should not skimp on the use of ingenuity to improve it.

    BTW, I did get the thing to compile but it gets a floating point exception. I have fired up the IDE to trace it. I downloaded the latest version of FreePascal, too, 2.6.2. Now, at least, I get line-numbers… and actual trace-back.

  111. Dr Loser says:

    And now back to my specialist field of expertise, namely computers. And specifically computers since about 1990 or so.

    There is no possible way for a program this trivial to “squander RAM,” Robert. That has not been possible since at least 1990.

    And before you object and try to trade space against time, there is no possible way to “squander” CPU cycles on such a project, either.

    Much though I am enamoured of the word “squander.”

  112. Dr Loser says:

    The 45km range is so the programme will work with artillery.

    Well, what with the Coriolis effects, it won’t even work for snipers, will it? Once again, it’s not remotely within my expertise, but I would assume that if it’s useless for a guy with a whacking great sniper slug and a high-powered rifle, and assuming he’s in position and able to wait a couple of hours to take his best shot, then it’s not much use for an M107 175 mm, is it?

    Although I’m pretty sure that the US Army has moved from standard field artillery to howitzers for other reasons than simply having to rely on some tatty piece of FOSS software that doesn’t even take Runge-Kutta into account.

    Anyway, my basic point was: if you have an issue with ranging up to 45 kilometres (quite a long range, I think you’ll agree), then the solution would be to limit the damn software to a more reasonable and applicable distance.

    Say, 800m or so.

  113. Dr Loser wrote, ” Worrying about what this particular program predicts beyond, say, 800 yards is pretty pointless, isn’t it?”

    For target-shooting, a shooter will typically fool around at 100 yards, push things to 300 yards and every now and then go to 600-1000 yards and doesn’t want to look foolish on the first shot. That’s what this programme can do, tell you how many clicks to turn the knobs on the scope so that that first shot will be close to where you want it. The longer the range, the less practical it is to walk up to the target to see where the bullets hit. A scope on the rifle and a powerful spotting scope help but it’s best to know the trajectory of the bullets to any particular range extrapolating from previous experience. It’s easy to measure the velocity of bullets too, but if you couldn’t measuring the trajectory at two or three points and using this programme could tell you the velocity. It’s all good.

    The 45km range is so the programme will work with artillery.
    this is the code that does the damage:
    #define __BCOMP_MAXRANGE__ 50001 in lib/ballistics/ballistics.h
    ...
    and in /lib/ballistics/ballistics.cpp
    double* ptr;
    ptr = (double*)malloc(10*__BCOMP_MAXRANGE__*sizeof(double)+2048);

    That’s brute force and it works but it looks ugly to me. The data-structure is indexed by the range in yard as integers. It’s not wrong but it seems to squander RAM needlessly. These days RAM may involve storage devices so that could be really slow to save/restore. I think the programme is fast enough but if you wanted to do parallel processing eventually, this would not scale, say you wanted to figure out a criminal shoot-out in 3D. Modern PCs could easily do this but not with this application. It would need to be run for each shooter, and each shot manually and the results combined somehow.

  114. Dr Loser says:

    Hunting is not about getting a deer from 1km but about getting to be where the deer are and seeing them. That takes skill. The rest is just technology.

    Indeed.

    So then. Worrying about what this particular program predicts beyond, say, 800 yards is pretty pointless, isn’t it? If you want to limit the results to something that’s useful to hunters, then I’d suggest you limit the Plot and Range windows to that effect. You could even add a pop-up dialog to explain that limitation (not difficult with fltk — I can help you there).

    Still trying to work out why you’d need Runge-Kutta or want to restrict RAM usage to < 32MB, though. And still confused about that 45km range thing.

  115. Dr Loser wrote, “once you’re out at sniper distance, you’ll still want to adjust for Coriolis effects.”

    Those effects are fixed by location and direction and mostly affect windage if you shoot north-south and elevation if you shoot east-west. That matters for the first shot of a group but target-shooters normally get one or two “warm-up” shots to zero that out. Hunters rarely care. Bullets don’t humanely kill deer much past 600 yards using usual hunting calibres. Many bullets are rated for clean kills up to 300-400 yards. Pure lead is about all that works there but it will splatter at <100 yards, so there is no universal bullet. A hunter should have two in the field but deer are camouflaged. I doubt I could see one against bush or grass beyond 300 yards. In 7mm, Sierra’s 140 grain Spitzer splatter at less than ~200 yards in the magnum. The 175 Spitzer boattail will kill deer or moose easily to 600 yards and is tougher but it still is rough inside 100 yards. The 170 grain round nose is excellent from 50-300 yards. If you are hunting with a magnum, you are crazy to shoot at most deer encounted within 100 yards. That’s why I like the 8mm Mauser. It’s good for everything I can shoot. In my whole life, only one deer escaped it and I caught it the next day. I needed a second shot and was too cold to reload… Hunting is not about getting a deer from 1km but about getting to be where the deer are and seeing them. That takes skill. The rest is just technology.

  116. Dr Loser wrote, ” I’m still stuck with the Winchester”

    That’s the way it is. In my version, I will set it to start with that frequently used combination but thereafter come up with the last-used combination. That makes more sense to me. .308 Winchester is sweet for target-shooters to 300 yards or a bit more. My son is getting tiny groups. They are hard to see at 100 yards and we often don’t have a longer range to work in. Must buy land…

    I’m not kidding. The last time out he fired a number of groups and settled on the right ammunition to use for deer in a couple of weeks, but two shots disappeared… I discovered that two of the holes were not round. The bullets had passed through the same holes at 100 yards. As long as the deer don’t shoot back they don’t have much chance out in the open with him around. I am not so fancy but I can get the job done. His eyes are perfect and he doesn’t shake. In my dreams I have a quarter-section of land with a 1000-yard range running diagonally… The rifle he was using could hit a 12 inch bull regularly at that range back in the 1970s. With today’s ammunition components and this application, it might get better. 1000 yards is a stretch for .308 though, but we have an even better rifle we can use in 7mm Rem. Mag. I would like to live long enough to see that shoot one good group.

  117. Dr Loser says:

    The current programme does that by File/Open or Save. The file-format is basically the parameters in all those input boxes, so a shooter/user can have any number of projectile/cartridge/firearm combinations.

    My version must be broken in some way, then. I can enter a new name, and adjust the characteristics, and save it.

    Unfortunately, this is not much use when I bring the app up again. I’m still stuck with the Winchester (probably not an issue if I were actually Jimmy Stewart, as opposed to being “just like Jimmy Stewart,” which two separate girlfriends have accused me of being. I blame that on my constant companion, Harvey. He likes FLOSS, too).

    Anyway, yes, it’s possible to open a file for this stuff, but it’s not really useful if you have two rifles on you, is it?

    What you need is a drop-box and a database. I think SQLite3 would do nicely.

    It may even have Pascal bindings.

  118. Dr Loser says:

    Always wishing to be helpful, btw, and I know you’ve almost certainly got this on Debian already (or can download it):

    For Runge-Kutta, you want the GNU Scientific Library.

    Lots and lot of goodies in there.

    However, I still think it only makes about 0.01% difference in your terms. And once you’re out at sniper distance, you’ll still want to adjust for Coriolis effects.

    A bit more effort, but I believe you can build that into the equations for Runge-Kutta. Not my discipline, so I’ll wish you joy of the morning, as it were.

  119. Dr Loser wrote, “no hobbyist (and certainly not me) since about 2000 has been able to figure out how this muck fits together.”

    Amen. Most of my effort the last couple of days has been spent either reading code or documentation. Often code is more informative. I knew what I wanted to do and several posts I found said to do that but no one informed me actually how to accomplish that…

    Thanks. It’s clear the code is not careful enough with memory, like allocating it and freeing it properly. I see RAM being freed when there is no need to free it… If it needs the huge array, just keep it until execution is finished. It’s pretty simple in Pascal to use a structure with meta-data about the memory allocation along with the pointer. I just find Pascal more readable because of its more compact vocabulary. With Pascal there are fewer ways to do everything so everything gets done better, IMHO. KISS

  120. Dr Loser says:

    Thank you, Dr Loser, for your constructive comments.

    You’re most welcome, Robert. Always glad to make constructive comments (see gdb debugging, below).

    I find the graphs thin as well, one-pixel trajectories almost disappear to my eyes.

    I too have presbyoptery. Once you’ve either adopted my 50-line diff, or else restructured the entire thing in Pascal, we should get back to this one. I am at your service, either way.

    That limit of two trajectories may stem from the memory requirements of the data-structure, holding up to 10 variables in up to 50000 8-byte reals… That’s ~4MB per trajectory.

    No, I think the restriction was purely arbitrary.

    I haven’t seen a desktop that can’t cope with 32MB of data in RAM for quite a while, although our circumstances may differ.

    Once you’ve admitted that your preposterous Pascal rewrite is never going to happen, I will happily restructure the code to deal with all eight trajectories. Should take me a day at the most.

    Deal, Robert?

  121. Dr Loser says:

    The code also does something strange, allocating space for 45km trajectories, one yard at a time. That works, of course, but it may waste time/memory.

    I may have missed a small detail here, and it isn’t the bizarre implicit conversion between yards and metres. (Could you give us a code reference on this, btw?)

    I’m not all that familiar with modern rifles (I went to school next to the BSA factory, so I guess I’m at least half a century out of date), but I’d be seriously impressed by a rifle that can be accurately targeted at 45km. Don’t you have to consider Coriolis effects at, say, 5% of this distance? I don’t think those effects are in the model.

    As for wasting time, I’d suggest upgrading the Beast to a modern machine. And wasting memory?

    Computers don’t go senile, Robert. They merely blow caps every now and again.

  122. Thank you, Dr Loser, for your constructive comments.

    Dr Loser wrote, ” The “name” field needs to be a drop-box. You should be able to pick an existing set of rifle characteristics, or else enter a new set with a new name.”

    The current programme does that by File/Open or Save. The file-format is basically the parameters in all those input boxes, so a shooter/user can have any number of projectile/cartridge/firearm combinations. Where there is a limitation is in the graphing. It only allows two solutions to be graphed simultaneously. That’s a bit limiting. I find the graphs thin as well, one-pixel trajectories almost disappear to my eyes. I will try to adopt some more sophisticated plotting package to make those already useful graphs more pretty. Pretty is good. That limit of two trajectories may stem from the memory requirements of the data-structure, holding up to 10 variables in up to 50000 8-byte reals… That’s ~4MB per trajectory. I can do better by producing splines to approximate the trajectories nicely so that the data could be stored in x(t),y(t) functions based on data-points much further apart, say 100 yards. The equivalent ranges would then take 500 X 6 (two cubic splines) 8-byte reals, only 24KB. It’s about swapping a tiny amount of CPU power for a whole lot of wasted RAM. Then we should be able to plot any number of curves simultaneously. Shooters love to compare calibres endlessly…

  123. Dr Loser says:

    I may adopt higher-order methods for greater accuracy.

    I believe you could do that with the original version, too, Robert. Nothing like using a mathematical model developed in 1900, is there? And who knows, there’s probably a FOSS C++ library out there that does Runge-Kutta. I’d hate to program it from scratch in Pascal, given that the operational difference is probably about 0.01%.

    The engine seems to work very well, so I don’t need to change much. I am working on an interface between the C routines and the Pascal.

    Of course, we’re all entitled to change our mind once we look deeply into the code. That’s what it’s all about, really.

    How long do you think that a pure port of the original (without your extra numerical analysis) would take?

    Do you still want that fifty line diff?

  124. Deaf Spy wrote, “Any reasonable IDE, even Delphi, would have let you do this all in 15 minutes!”

    I didn’t use a GUI IDE, just CLI in GNU/Linux, for development. A lot of that time was studying particular libraries to use and the code itself, ~1600 lines of C, a language with which I am not conversant. So the time wasn’t wasted. It was a learning experience mostly about verifying that I thought the code useful but needing fixing that I can do once it’s in Pascal. That should happen in a day or two. I translated the engine, the number-crunching stuff last night until the wee hours. I stopped when my IQ and ability to read reached 0. I didn’t want to go for < 0. The fussy Pascal compiler did most of the work, telling me what was at the top of my queue in ~600 lines in a second or so. I used sed and grep to save hours of finding and changing elements of the programme. The most work I had to do was making sure looping worked and I replaced a few IF statements and FOR loops with boolean expressions and WHILE loops, making the conditions more visible and the code more readable, for me at least. The code had several IFs at the bottom of loops containing compound boolean expressions for deciding to "break". I replaced that logic with a boolean variable tested in the WHILE statement. I did read up on the C FOR statement. I like a simple WHILE, myself. I finished as far as the last ten lines of code but couldn't think straight any longer and went to bed. I will likely have the first run of it today or tomorrow. Along with the translation, I examined the mathematical methods. They work but are not very sophisticated. I may adopt higher-order methods for greater accuracy. The programme used O(h) methods with 1-yard steps. I could do better with 10 or 25-yard steps and splines or other closed forms for interpolation. The code also does something strange, allocating space for 45km trajectories, one yard at a time. That works, of course, but it may waste time/memory. I will give some thought to allocating resources based on the input parameters. I will also do some parameter-checking for security and robustness. It’s all fun for me. I’ve been doing this kind of numerical analysis since 1968 with computers and pencil and paper earlier. Physics depends on this stuff. I was surprised that any rust I accumulated in the last few years quickly wore off. I guess it’s like riding a bicycle until Alzheimer or Death catches up…

  125. Dr Loser says:

    I am perversely drawn to the task of correcting and completing a bit of FOSS software that the original author abandoned in 2008, however.

    Ignoring the memory bugs, which incidentally are not leaks but simply an attempt to re-use memory once it’s been freed … a standard error made by most amateurs who haven’t actually used C/C++ in a professional setting, but no matter … there’s actually a requirements issue here.

    Is there such a thing as a requirements issue? Well, yes, I think there is. Note the InputWindow first screen, at “Name.”

    What happens if I don’t, for some obscure and totally irrational reason, happen to own a “308 Win Match, 168gr Sierra Match King?”

    Or maybe I own more than one rifle. I’m not an expert in the field, but I’d assume that the projectile weight, initial velocity, etc, are fairly important variables.

    So then. Here’s the challenge. The “name” field needs to be a drop-box. You should be able to pick an existing set of rifle characteristics, or else enter a new set with a new name.

    The more I think about it, the more I think this is a fundamental requirement. I mean, everything else is done, including the ballistics engine. This is just a trivial bit of database encoding.

    It would work with either the original (C/C++) version or the new (Pascal) version. It would be boffo. Any recreational shooter with a penchant for using FOSS software (and GEBC is basically very good at its job) would welcome such a feature.

    I’m thinking a nice simple database in SQLite3.

    Your thoughts, Robert?

  126. Dr Loser says:

    Step 7 was “attach PID,” btw. Inadvertently, I put PID in angle brackets.

    I’m not entirely sure it’s necessary to get a remote debugging session up and running, but in general (and no matter what platform) I prefer to let the GUI application do its own thing with minimal interference from the debugger.

  127. Dr Loser says:

    I have a debugger but couldn’t figure out how to get proper traceback.

    Actually, this took me a while too (and I’m supposed to be an expert with gdb). In the interests of the community, therefore, here are the steps required to follow my debugging activities:

    1) ./configure the code.
    2) Edit the makefile and replace all -O3 with -O0 -g. In theory the GNU toolchain does this for you, but apparently no hobbyist (and certainly not me) since about 2000 has been able to figure out how this muck fits together.
    3) make. NB: DO NOT make install. This will only confuse you (it did me, anyway) when you try to compare the debugged version against the original version.
    4) Here’s the bit of magic you need. Launch ./gebc in the background. Note the PID.
    5) Just before debugging, note down the breakpoints you want to enter. (Left as an exercise for the reader, and because it’s generally useful.)
    6) Invoke gdb.
    7) Call “attach “, which will give you a remote debugging session.
    8) Continue.
    9) You now have a debugger and an operative GUI. Follow the steps that cause the problem. When your breakpoint is hit, proceed as normal with gdb,.

    Gotta admit, this FOSS stuff is something close to magic … as long as you know what you’re doing.

  128. Dr Loser says:

    BTW: have you figured out how to port the Plot window and the Range window to GTK2 yet?

    Looks a bit too complicated for my tastes.

  129. Dr Loser says:

    If I had just translated the engine, I would be finished now.

    Good to know. You’re obviously about t0x (or more) faster than I am on this sort of thing. I can just about crank out 500 lines of C in a day, so presuming that your Pascal skills are roughly equivalent to my C skills, I make that roughly a day for the engine itself and probably two more days for the connective tissue (GBCSolution.cpp, bits of the Windows, etc).

    I generally find that testing for bugs and regressions and so on takes about twice as long as the original translation, so my estimate would have been nearer a week. Mind you, I rarely have the power of FOSS software behind me at work, so that might be a significant factor here.

    Anyway, whenever you want the fix to the original bug, just let me know. I’ve got the diff file standing by.

    It’s about fifty lines long.

  130. Deaf Spy says:

    Pogson wrote: I have all the I/O and UI done now in only 100 lines of code written by me. Thank you, FLOSS. Next, I will do the solutions so I can tabulate, and graph.

    This is really distressing, Mr. Pogson. Any reasonable IDE, even Delphi, would have let you do this all in 15 minutes! I wouldn’t have thanked anyone, if I were you. There is nothing to thank about, only to be sorry.

  131. Dr Loser wrote, “Personally, I would start with the engine (which is, after all, the hardest thing to convert from C++ to Pascal), but your approach will work as well.”

    The engine seems to work very well, so I don’t need to change much. I am working on an interface between the C routines and the Pascal. Unfortunately, I haven’t yet got the linker to cooperate… I manage to get error messages about unresolved references despite everything being installed in my system. The linker and I are having a bad day. I’ve read all the documentation on FreePascal and the linker but it’s nogo so far. I’ve tried several approaches and I either get two of the functions of GEBC not found or just about everything else in the system. I am sure it will work out. If I had just translated the engine, I would be finished now… 🙁 It’s actually quite familiar stuff so I thought I would do it the other way to avoid boredom. I’ll probably translate the thing tonight and have the new beta ready tomorrow. I still have some work to do verifying all inputs and such but the I/O routines are working well now.

  132. Dr Loser says:

    I have all the I/O and UI done now in only 100 lines of code written by me. Thank you, FLOSS. Next, I will do the solutions so I can tabulate, and graph.

    Once again, impressive. Yesterday you only had thirty-six lines of boilerplate code. Today you have a hundred.

    Possibly a few of them do not consist of either “begin” or “end.” You’re making progress.

    Now, about this tabulating and graphing thing. Personally, I would start with the engine (which is, after all, the hardest thing to convert from C++ to Pascal), but your approach will work as well.

    There’s got to be lots of really useful libraries in Pascal for tabulating and graphing, and for any given rifle, I’m pretty sure you can encapsulate the code in 100 lines or so.

    Doomed and futile, isn’t it? Plus which, the original code just needs a bit of fixing up (it’s the FOSS way, if you’re an honest FOSS contributor rather than a self-indulgent hobbyist). Plus which, there are more useful free solutions to the actual problem out there. I’ve pointed one out. I could look for others. There are probably dozens.

    Keep going. This is serious fun.

  133. Dr Loser wrote, “You’ve done the difficult bit with the GUI bindings. The rest comes naturally to somebody with fifty years of programming/computational experience.”

    I’ve redone the GUI bindings one more time to match the data-structure I’ve developed. It will be a tidy and compact programme, one that’s easier to modify/maintain.

    UPDATE I have all the I/O and UI done now in only 100 lines of code written by me. Thank you, FLOSS. Next, I will do the solutions so I can tabulate, and graph.

  134. Dr Loser says:

    Let me remind you again, Robert.

    The title of this post is “Progress Report On Translation Of GEBC To Pascal.”

    Not “I decided to give up when somebody challenged me.”

    Feel free to give up on “progress,” however. You’ve done the difficult bit with the GUI bindings. The rest comes naturally to somebody with fifty years of programming/computational experience.

  135. Dr Loser says:

    Rewriting the programme is just a tiny waste of my time instead.

    It’s a complete waste of everybody’s time, Robert. I pointed that out, at some length, below.

    Let me refresh your memory.

    1) There are perfectly good alternatives out there on the Web and in Apps already.
    2) 99.999% of the FOSS world does not understand Pascal, let alone the obscure bindings. And they have no reason to do so.
    3) All you’ve got so far is an empty GUI shell.
    4) If what you want is a fix for the memory leaks, I’ve committed to doing that.

    If you have any pride in your abilities, you will either learn C++ for yourself and fix the damn thing, or else you will complete your port to Pascal, for what it’s worth, which is precisely zero outside your own house.

    Furthermore, I’ll beat you to it.

  136. Dr Loser wrote, “Let’s see which one of us gets there first.”

    I have no doubt you could fix things first. There is no competition. I don’t need the results of the programme likely until next summer assuming we could get in some long range shooting. I have the C version working well enough and I have my own programme as well. I am not interested in how long it takes me to get a Pascal version working. I could likely finish in a few hours but I will work at it only when I have nothing else to do which is rarely. I could spend time figuring out the debugger/gcc documentation and learn C too but that would be a big waste of time. Rewriting the programme is just a tiny waste of my time instead.

  137. Dr Loser says:

    I still remember a story from the good old days… I was writing Assembler stuff for the IBM s/360…

    But these are no longer the good old days, Robert.

    You have a silly little menu skeleton with nothing behind it, and I have a completely functional C++ application.

    We both have deadlines here.

    Do you believe in your 50 years of “computational, not programming” experience?

    Good. Let’s go, then.

    Pardon me while I take time off for fun (baseball) and work (an interview).

    Let’s see which one of us gets there first.

    It’s a fair competition, I believe.

  138. Dr Loser wrote, ” Why did you hit “Solution Memory/Store to Memory 1″ twice? Isn’t that once more than strictly necessary?”

    I know how software works. One finds the bugs by pushing the limits. The programmer who knows how the thing is supposed to work and follows the manual is thinking inside the box and ships buggy code. Since the days of DOS, stuff has been crashing on me when I click on things, so I click and click and click…

    I still remember a story from the good old days… I was writing Assembler stuff for the IBM s/360. One day, a programme that I tweaked crashed. I had done nothing to change the logic in any way. I took it to the “systems analyst” who was on duty and he looked at my trivial little programme on a deck of punched cards and did the eyebrow-raising thing. Some hours later, I checked in with him and he had found the problem. It was not in my code, but the system loader. It had an “off by one” error and would crash any time a bunch of code ended exactly on a 4K page-boundary. This loader was used by every programme run all day long for months, until I won the lottery. I now check every loop for proper termination and overrun… Another time, I and every science/math/engineering geek were running the IBM Fortran H compiler and I was working on a programme supplied by another university. I was able to abort the compiler every time. Another analyst found that 4K lines of code in one module exceeded memory requirements. I think we had only ~1MB at that time… I rewrote that sucker in 1K lines of code by cutting out hundreds of GOTO statements and dead/useless code. That’s what I intend to do for GEBC. Less code means fewer bugs or opportunities to have bugs.

  139. Dr Loser says:

    can crash the application by clicking “Solve” to fill the arrays, then “Memory/Store” to “Memory 1″ twice.

    Good. Now we’re getting somewhere. The same thing happens on my end.

    I’ll make a useful FOSS contributor of you yet. (Keep taking the Pascal tablets!)

    Three things here:

    1) Why did you hit “Solution Memory/Store to Memory 1” twice? Isn’t that once more than strictly necessary?
    2) Why not just hit “Solution Memory/Store to Memory 1” once? Do you doubt the sincerity of the menu selection? Are there cosmic rays involved?
    3) Is it actually necessary to rewrite the whole thing? Remember, I’m porting this to Cygwin, which let me tell you is not easy. But the C++ bit? Helps if you can be bothered to learn C++. Trivial, however.
    4) I have a working application. You have a barebones menu. We have probably spent about the same amount of time (a couple of hours so far, I think.)

    Face it, Robert, I’m way ahead of you. If it weren’t for the fact that I have a baseball game to watch tonight and a job interview tomorrow, I’d be debugging this silly little issue right now.

    But don’t let me stop you. I’m sure you can rewrite the whole thing in Pascal by midnight tomorrow, which is about when I will have fixed the C++ segfault and sent you (and the community) the relevant diff.

  140. Dr Loser wrote, “I assume you can replicate the steps.”

    There’s mention of memory leak in the code…

    I can crash the application by clicking “Solve” to fill the arrays, then “Memory/Store” to “Memory 1” twice. Segmentation fault. That happens occasionally in normal use but that is the fastest way to crash it that I see. I think they are setting pointers to Nil all over the place when that should only be done on freeing memory. I have a debugger but couldn’t figure out how to get proper traceback.

  141. Dr Loser says:

    One small detail you want to correct whilst you’re dealing with that “About” button, Robert:

    *Built using: Mingw32 / GCC compiler”

    MingGW is a sophisticated Posix-compliant environment on TOOS.

    Which might explain why it crashes on an ancient piece of badly-supported crap like Debian Stable.

    qNextRow; qButton(‘About’, @About);

    (Text to be decided.)

  142. Dr Loser says:

    Images? OK then, let’s not stretch to fixing the PHP stuff on the blog. Here you go.

  143. Dr Loser says:

    Looking good! Nice menu, btw.

    Now, in the spirit of competition (and naturally co-operation), I’ve fought my way through downloading GEBC and fltk and some nasty PDF freebie to Cygwin. And I’ve examined the weird and wonderful configure/make/make install options along the way.

    Whaddya know? The beast builds!

    See .

    Wow, that was fun.

    Now, about this little C++ memory corruption you found? In the interests of the community, I assume you can replicate the steps.

    I’ve got gcc and gdb and ddd ready and waiting to go.

    Let’s party!

  144. Dr Loser wrote, “Have you considered using this instead?”

    I have a couple of such apps but, when I am mobile, I use a rifle, and when I am stationary, I use Beast. Generally, I know all I need to know about trajectories for hunting here. If I were in hilly country, it would be useful because long shots are more common and the path is much more critical. e.g. It’s hard to miss a deer at less than 200 yards but very easy at 600 just by being 50 yards out on range estimation. There are apps for that, too.

  145. Dr Loser says:

    I’m sincerely impressed by this effort, Robert. I’m also prepared to admit that there are, indeed, Pascal GUI bindings.

    (You’ll be pleased to learn, in the spirit of friendly competition, that I’m trying to build GEBC right now over Cygwin. I’d use a *nix distribution and save myself the problem of getting around X, but I don’t have one. Seems like a level playing ground, in a sense.)

    Now all you have to do is to port all that C++ into Pascal. One engine and a huge number of tables.

    I can’t help feeling that it would have been easier, and more useful, to do the same thing in PHP. But I’m all for hobbyist activities. Obviously: otherwise I wouldn’t waste my time on the Cygwin version (it’s taught me a lot about fltk, for example).

    Have you considered using this instead?

Leave a Reply

Your email address will not be published. Required fields are marked *