In integer world:

(3 / 2) * 2 == 2

- this is because (3 / 2) == 1.

Ah, sorry, yes I was forgetting that everything would be an integer. I'm now not sure whether I've forgotten something or I've never come across all-integer arithmetic before. I've a feeling it's the latter which shows my lack of programming experience and comp-sci education.

Let's say the font is 1/4 tall, or four lines per vertical inch. (Internally, that is stored as 360 twips -- a twip being 1/20th of a point, a common measurement among traditional typesetters; there are 72 points per inch, and thus 1440 twips per inch.) And let's say the space available on the screen for the text box is 5-1/8 inches (7380 twips). That will give us 20 full lines and half of a line at the bottom. Ugly. So we take the box's height, 5-1/8 inches (7380 twips), and divide it by the font's height, 1/4 inch (360 twips) and -- throwing away the remainder -- we get 20; ie, 20 full lines. Then we multiply that figure by the font height (1/4 inch or 360 twips) and we end up with a nice round 5 inches (7200 twips) for the box's height.

Again, it would have been clearer had we just said:

Round the box's height down to the nearest multiple of the font's height.

Or perhaps something like:

Make sure the box won't cut off the font at the bottom.

That's an assumption. Strictly speaking, from a compiler-design perspective, there are what are known as semi-compilers, versus full-compilers. Semi-compilers only do part of the job of compiling. They typically spit out an intermediate language, which is then processed by other programs. But full-compilers can do the full job of compiling. In a technical discipline, assumptions should be avoided as if they were Ebola.

Correct me if I'm wrong, but I glanced at your ZIP file, and it looks like most of what needs to be done is to replace the "intel" constructs with the corresponding code for the Linux system, and the various dlls that are called directly. A quick scan shows them to be:They are, as far as I (and grep) could tell almost all in "the noodle."

Doing that might be much easier using a higher level language or, perhaps, using a Earley parser to create gcc preprocessed intermediate code for the gcc compiler. (Going that route would open the noodle to using any of the thousands of Linux library routines for anyone who wanted a non-standard noodle.)

Have you tried your code under the wine system? Does it work there? If so, that might be a simple preliminary "port" to Linux.

All the calls to Windows DLLs are in the Noodle, yes. Intel instructions appear in both the Noodle and the Compiler units. A few things (like file names formatted for Windows) appear elsewhere.

Understood. But we prefer to go directly from English to machine code without any intermediate steps for a variety of reasons (eg, teaching programming basics through compiler design to newbies; speed; simplicity; avoiding bloat; etc).

Don't have Linux (yet) so haven't tried Wine. Still trying to get a feel for the kind of reception and support we can expect from the Linux community before taking the leap. And again, our goal is to keep the thing simple, small, and direct. Right now (on Windows) all the user needs is the .exe and the Noodle to write new programs; we want it to be equally simple on Linux.

Thanks for the thoughts.

Is this currently 32 bit? Do you have any feelings about word size, 32 bit versus 64, etc?

Do you foresee any difficulty with larger programs, any possible need to compile multiple source modules?

Did you read my post to the very end ? Did you see:

?

Yes, it's currently 32 bit. I think keeping it that way will make it compatible with more machines.

Regarding large programs, it depends on what you mean by "large". Niklaus Wirth's elegant Oberon system -- a complete OS and compiler -- is only 26,000 lines of code; while Windows XP is estimated at about 40 million lines. We tend to think Old Nick is closer to the mark. (Our program is 20,000 lines in 6 source files; but a lot of that is because of Windows and Adobe's PDF, etc: lines that would disappear if we had something better underneath.)

Regarding large programs -- like a HAL-9000-style "Apparent Intelligence" -- we have plans as well; but first we have to get this thing converted to Linux.

I'm not sure that it's valid to use lines of code as a metric of size comparison between projects, where one project has lines of code written in a very high level language, and another project has plenty of lines of assembly language code, as well as lines of codes in other disparate languages. But my purpose was to understand whether or not it was felt that there would be any need for a range of output options on Linux, in order to try understand the scope of the conversion to Linux. If I understand correctly, it seems you want only single source file input, single "32-bit" executable file output.

True, it's a ballpark kind of evaluation. But surely, when two systems are more-or-less functionally equivalent, it's surprising to find that one is, source-code-wise, over a thousand times larger than the other. Exactly what are we getting for that increase in size and (presumably) complexity?

What we're looking for is a Linux program that looks and feels and runs just like the Windows version. The same thing we've got now, only with lovely Linux stuff underneath, instead of convoluted Window's crap.

32-bit executables are fine. But I'm not sure what you mean by "single source file input". The Windows version itself consists of six separate source files (see page 4 of the instructions) and compiles/links multiple source files for the programmer -- specifically, any and all source files in a project's directory (see page 56 of the instructions).

Apparently then, you and I were each having a different discussion, when we were discussing whether or not there was a need for any special consideration for compiling large files. :-)

Ultimately, I was just trying to urge you to consider various alternatives for output formats under Linux. Since you've instead re-iterated:

you are apparently very certain of what you want.

Are you expecting a commitment as to time frame, for anyone undertaking the project of porting your work to Linux?

My apologies for the confusion.

Actually, we're more certain of what we DON'T want lost in translation. Improvements -- especially the kind that do more with less -- are always welcome. But we want to keep both our immediate and ultimate goals in sight at all times. You can get a pretty good idea of what those goals are from the three "release notes" that we eventually share with all who contact us directly:

(1) The system is NOT intended for isolated self-study. Both the program and the documentation are designed to provoke questions and engender discussion. So when anything strikes you as unusual, strange, or just plain stupid, ask. We have at least three good reasons for everything that we put in (and left out), and we're more than happy to tell you what they are.

(2) The product is intentionally different -- iconoclastic is the term we use. It is designed to make the programmer question almost every preconceived notion a modern practitioner might have. Are installation programs necessary? Can a high-level language like English be used to conveniently write low-level programs like compilers? Can a workable interface be designed without icons, scroll bars, radio buttons, and a wide variety of other widgets? Can complex programs be clearly and concisely written without nested ifs and loops? Can a polymorphic drawing program be effectively programmed without objects? And so forth.

(3) The product is serious stuff, in spite of our tongue-in-cheek presentation. We really believe in our unique and deceptively simple approach to natural language parsing. And we really do think this approach will provide a firm foundation for computers like the infamous HAL 9000 sometime in the not-too-distant future. Our next step is to install the compiler on a dedicated machine where all previously compiled code will be resident at all times. We will then extend that machine's compiler to accept and rank additional (and even alternative) definitions and routines submitted by a group of dedicated Plain English programmers -- programmers who will continue to "teach" this machine new things over a period of several years. Our hope is to recruit 100 such teachers who will each agree to explain at least 10 things to the machine every day, in Plain English, so that at the end of just three years, our "Apparently Intelligent" PAL 3000 (tm) will understand and properly respond to more than a million practical natural language sentences. Not unlike a three-year-old human (hence the 3000 in the name). There's more to it, of course, but that's the gist. And yes, it's a bit of a brute force approach. But not unlike the one we all use with our children. And, we think, the only truly workable approach in a natural language environment where everything not directly perceptible to the senses must, by definition, be treated metaphorically (and more often than not, idiomatically).

By the way, here's an interesting article on the subject by Stephen Wolfram:

http://blog.wolfram.com/2010/11/16/p...going-to-work/

Seems he's arrived at similar vision of the future. And let's not forget Apple's first steps with SIRI. The difference between us and these better-funded guys is that we're starting with Plain English, and simply extending it; they feel compelled to more-or-less "simulate" Plain English using tools of a more traditional and mathematical nature.

In any case, part of what I'm doing on this forum, right now, is gathering the data we need decide which operating system we want undergirding our PAL 3000 -- and thus which community of programmers we want teaching the little guy. You can't let your kid play with just anybody, you know...

I suspect it is becoming apparent now why I included the "Open Minded" qualifier in the title of this thread

Not at this time; but as things progress and we discover whether we're looking at a marriage made in heaven -- or the converse -- the usual topics (ownership, remuneration, etc) will undoubtedly arise and be fairly dealt with.

I had a look at your zip.

what is that exe file? Where's the code for it then? Is it a trojan?

I think (to paraphrase) calling windows something like a "whore of a kluge" etc and "taking over the screen" shows a lack of humility.
I personally hate having my screen taken over. (No I don't use windows incidentally)

I have been programming for 20+ years, I am willing to help as soon as I have finished my current project:
turning base metal into gold, nearly there.

I agree with a previous poster that this whole discussion is a bit too negative. Especially for a thread where the threadstarter actually did not even ask for opinions.

I think big things can be created only if someone goes ahead and does something which nobody else thinks can be done. Very nice work Gerry, I am especially fascinated by the idea that you get to the point where you can actually hand this over to a couple of people and have them "teach" it new things in plain english.

Do you think that at some point this teaching could be taken to the next level where you'd actually have it spider the web to teach itself stuff?

As much as I would like to help you with the Linux port, I am afraid I wouldn't have much to bring to the table other than being openminded. I could imagine being one of the 100 "teachers" you mentioned, though.