Download Latest Version (203.5 kB) Get Updates
Name Modified Size InfoDownloads / Week
openpoplog-win 2004-01-27
readme.txt 2013-04-15 4.6 kB 2013-04-15 203.5 kB
Totals: 3 Items   208.0 kB 0
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
Source: readme.txt, updated 2013-04-15