OpenPoplog Files

20130415
Previous readme below.
         
Note that this file does not describe the openpoplog poplog download, but only the files
available in the Pop2011 sub-project.
                 
Changes since previous readme:
(1) This readme was edited using the pop2011 IDE. So it's sort of useable.
(2) Vertical scroll bar implemented. Clicking in the page up/down regions only scroll
one line at a time. (Because I just copied the code for the line up/down scrolling.) Fixing
this is on the todo list.
(3) Scrolling reveals that the buffer length grows in increments of about 20 lines and
never decreases. But trailing empty lines do not get written when the file is saved. They
are not the same as trailing blank lines, which do get written. How do you tell the
difference? Good question! It's not a bug, or even a feature. It's just something on the
todo list to be fixed when I get around to it.
(4) A lot of other (Windows standard) edit functions now work, like ctrl-home takes you
to the start of the file, home just takes you to the start of a line.
(5) Menu items in the File and Edit menus are grayed out unless they do something.
(6) Cut and paste work properly (with the clipboard).
(7) Stuff you type is blue - this *is* a feature (not a bug) and is intended for console
style interaction. Stuff the computer types is black. This goes away if the file is saved
and read back in. 
(8) There are two modes: console and edit. In console mode, <return> or <enter>
executes the current line (sends it to pop11), but first copies it to the bottom of the buffer
unless you are already at the bottom of the buffer. Shift-return (or shift-enter) inserts a
line break. In edit mode, nothing gets sent to pop11, and <return> or <enter> just insert
a line break.

There is still much to do, but this mostly easily becomes apparent by attempting to use
the system. So now it is time to switch back to a bit more development on the
  Compile.dll
component, making (small?) changes to the Pop2011 IDE as the need becomes
apparent.  
                                                                                   
20130408

I have finally returned to pop20xx after about a 6 week hiatus whilst being distracted by other things.

I am enclosing a zip file with 6 files:
  compile.dll  -- this is the bettapop compiler and run-time system - quite small, isn't it? :-)
  bettapop.exe  -- starts the compile.dll in an MS-DOS prompt window
  pop2011.exe -- the beginnings of a (Windows) GUI/IDE, starts compile.dll in this
  test.p         -- a pop11 test file (see below)
  trib.p          -- loaded from test.p
  trib.dll        -- linked in (at run-time) by test.p

run bettapop.exe or pop2011.exe and type: compile('test.p'); at the pop11 input prompt (after Setpop). The closing ; is
 necessary.

Note at the moment, in the GUI, <return> inserts a line break. You have to use the <enter> key to pass a line of input 
to the compiler. (I keep forgetting myself, and wonder why nothing is happening after I press <return>).

In pop2011 at the moment the GUI thread is suspended while the Compile thread is running, so it will appear to have fro
zen for about 10 seconds while the test is running (the compile thread generates output, but the GUI thread doesn't out
put anything until the whole window gets refreshed when the test run has finished). This doesn't happen in the console 
version which should give you some idea of how long to wait! I am just about to fix it (I hope) but in case it is trick
ier than it looks, I decided to send this .zip file now.

Trib.dll represents generating C++ on the fly, invoking the GNU C++ compiler and linking the result back in to bettapop
 - pop11 code can be faster than poplog pop11 generated this way, but at the moment it is "hand written/optimised" more
 as a proof of concept than anything practical (yet!).

Ideally, there will be a Linux GUI at some stage.

If either of you want to look at the source code, I'm happy for you to do so. I didn't include it because it's still qu
ite messy and in constant flux.

The compiler is written in standard C++ (without using any fancy template libraries) and the GUI is written using low-l
evel Windows API calls (without any fancy class libraries). It would probably be a good idea to do the GUI using a cros
s-platform framework of some kind, so this can be considered a design prototype rather than the beginning of a producti
on version. The Linux version should probably be the cross-platform version.

Cheers,
  Jonathan