WIP - Rope: A multi-language compiler to ZASM

[itsyfox]

Alright, I've been talking about it on and off. It's about time I say something official, since I've started work.

I'm currently working on an external compiler to ZASM, programmed in Python. It will initially be available on Windows, compiled with py2exe, or to anyone on any platform who already has Python with Tkinter.

It will eventually be wrapped in C and available universally.

The original idea was, I wanted Python for ZC. Because semicolons can be frustrating. ^_~ Well, it was suggested to me I write a compiler to ZASM, so that's what I'll be doing.

I don't just want it to be Python, though. That's what I'm going to build it with and for, but I want it to be extensible so users can add their own dictionaries to interpret from. So, while at first it will only be a 'Python to ZASM' interpreter, I know eventually I'll be adding ZScript, and maybe a BASIC-type language, who knows. And hopefully anyone interested in being able to script for ZQuest in a different language will try their hand at it, too. ^_^

Right now I have the barebones interface near completion. Here's what it looks like:
http://mywebpage.netscape.com/itsyfox/images/rope-window.PNG

Kind of boring, I know. Those two combo boxes don't quite work yet, they're hand-made, each from a label, a button, and (next) a pop-up menu.

But it's in the works! It'll be prettier later. Get interface working first, then core interpretation/compilation classes, then integration, THEN making it pretty.

Here's my plans for it:

-Allow import/export to file of any available format (at first just *.pyz and *.z)

-Use a tabbed interface to work on multiple projects at once

-Make compiler bi-directional: if it can compile from a to b, it can compile from b to a

-Read dictionaries from external files and dynamically count the number of available languages to compile from

-Add user-customizable syntax-highlighting

-Use auto-indenting (a must)

-Make the program user-extensible in Python (and maybe C/C++)

-Check a wide variety of errors, warnings, and bugs, not just what ZScript or ZASM checks for by default

-Dynamicize the error-checker: allow simple warnings and 'bugs' that may get fixed to be checked, unchecked, added, and removed as needed

-(Eventually) make the program cross-compatible with Windows, Linux, and Mac, without any dependancies if possible

-(Eventually, maybe) add skins to the interface, with ini-like skin files for easy editing, and an internal interface for creating simple skins as well

-(Maybe?) somehow include a media-browser. If it's possible to make a bitmap from ZQuest exports (I read a post somewhere that fatcatfan gets info from the devs to write his MapMaker too, though), I'll bet it's possible to browse tiles, combos, enemies, items, maybe even the SFX. If they add midi control to scripting, that would hopefully be able to be added as well. Maybe you'd even be able to preview how an FFC, script-controlled Enemy, Link, or a scripted Item might look, but I'm not so sure. Overall, this one's a big maybe.

Those are the intended (some not-so-certain) main features, the rest simply falling under the categories of function, ease of use, user-control, and modularity.

[jman2050]

Nice to see you taking things into your own hands :)

I think it's time to finally to add to the scripting engine what should've been added long ago. But more on that later ;)

[itsyfox]

Oh, I've read up on you and your surprises. ^_^ I have a few guesses, but I'll wait. I'm not worried about new features/commands with my compiler, either, since the external dictionaries will allow it to be improved right alongside ZC. ^_^

[beefster09]

With the ZScript compiler part, could you add color coding, like certain things are a special color, just to make coding easier? If that were the case, I would definitely use this.

[itsyfox]

Syntax highlighting, yes!

The Tkinter text widget used hidden 'tags' in the text to format it. These tags (and the formatting) will not stay in the text when it's sent to the compiler.

I'll also allow the user to choose the colors. I'm not sure yet whether it'll be per-language, or if I'll use generic terms for all the parts 'command', 'string', 'integer', 'function', etc. for *all* languages.

I also have an idea to set up something similar to hyperlinks that show up in the buffer and do various things, but the only uses for it I currently can think of are ones I'm not sure yet I can implement.

[itsyfox]

Well, after a little playing around with my interface, I've made some new decisions. These don't effect most of how the program will function, but they do change the basic interface and how it works from the above image. I don't have a replacement image yet, when I do, this post will be edited.

First of all, for first seeing if I could create my interface to match my drawings of it, I hard-coded everything in a single file. Now that I'm working on the combobox, I've found it much easier to work with classes, and so have started creating a 'tkeditors' Python module (basically a library) to store a whole bunch of different new widgets I'm making in classes for modularity and re-usability (which was the plan from the beginning).

Second, the image in my first post above shows two buffers: One for the 'From:' language, the other for the 'To:' language. But I thought about the function of 'Import' and 'Export', and how there's only one 'Compile!' button. There really is no need for two editable buffers. It's nice, at first, but the use of the second buffer is trivial. It might mean you could edit both buffers' code simultaneously, but that really doesn't have any use in any case: If you have errors you need to fix, it shouldn't fill the second buffer. If you just want to make changes, it's much easier to make the changes to one language only and compile. And when you hit the 'Compile!' button to error-check, it only works on the top buffer. I was going to have 'export' also run the error-checker, but then that was redundant, and the bottom 'Export' could just be replaced by 'Compile!' and the extra button removed entirely.

In the end, I decided to reduce it to one buffer, and instead reduce the size of the bottom text window, making it a multiline label instead of an editable buffer, and make that the error-check buffer instead of opening a separate window for it.

I'll also remove 'Import' and 'Export' since Open/Save do the same thing. Ctrl+S and Ctrl+O will be able to open those dialogs quickly, too. And Ctrl+N can add a new project (open a new tab with a blank buffer).

Maybe, as well as the 'Compile' button, there'll be an 'Uncompile' to act in reverse (Compile from To: to From: instead of the normal way). But of course, you could also with only slightly more work, simply change the From: and To: to set the app to recompile to your original language. There will also be an Undo/Redo option in the Edit menu, for which Ctrl+Z and Ctrl+Y should work as well. Maybe I'll have the From: language automatically change when you compile to the compiled language, and clear the To: language (Or set it to the original From: language?)

I'll also allow Compiling from a language to itself, so you can simply error-check (and possibly optimize) your code in any language.

On a completely different topic, I'm going to start playing with Tkinter's Canvas widget, at first not using any special graphics, but just creating a Window Canvas Item, and placing existing widgets inside it. I'm going to see if this gives me any additional positioning and altering control. If so, I'll start designing EVERYTHING through the canvas widget so skins are possible.

If this works out, skins will be very simple. In the Options menu will be the program configuration dialog ('Configure...'). One of the tabs in this dialog will be 'Skins'. You will be able to select either '<none>' or a few existing Skins, or Add/Edit/Remove your own.

Below that section of options will be the skin design section. This will be disabled (grayed-out) for the default skins, but usable for any custom ones.

There will be a combobox (drop-down) for different widgets, from larger ones such as 'default' (what any unset widget uses), 'application', and 'frame' to 'button', 'menu', 'label', and 'buffer'. There'll also probably be a 'titlebar' option, which is simply a custom widget built off of canvases to cover the existing titlebar.

Then it will contain on the left nine buttons arranged in a square, and on the right a preview.

The default graphics will be from one of the default skins. Only 3 of the buttons will have graphics, and this is the minimum you need set. Any one of the four corners, any one of the four sides, and the center (background). If you add more, they will simply be used separately for the sides they represent. For instance, if you use both a horizontal and a vertical side set which are different, the horizontal one will be used on both right and left (of course flipped), and the vertical one used on top and bottom. The more images you set, the more unique the sides can be.

When you click one of the buttons, a small dialog will pop up allowing you to choose an image, color, and/or a shape (a standard drawing shape with fill and outline colors, and any rectangular section of the shape can be used for the actual graphic). The center button, for the widget background, will also have font settings (Face, Style, and Color). You have the option of setting gif frames to use for different events (normal, mouse-over, and click), or choosing additional images, colors, and/or shapes for this purpose. For gif animations, you can set it to play once (ending on the last frame), loop, loop and rewind, or play once and reset (to the first frame). You could potentially have a very colorful and animated interface this way. ^_^ When the widget is entered at all, any of these segments with animations will play as set, at the same time. They can be longer/shorter than each other, so you can make really dynamic animations, but have to make sure they're all the same length if you want them all to end at the same time. There will probably be a 'delay' setting available too, so you could make the animation 'roll across' your widget in any desired direction. ^_^ You don't have to set any of these, however. Also, if you use an animated gif and don't use any of it's settings, it will stay on the first frame normally, and 'play once and reset' the whole animation whenever the mouse enters or clicks on the widget.

Below the nine buttons will be the background display settings.

First there will be a combobox for background orientation: N, S, E, W, NW, NE, SW, SE, and CENTER.

Then there will be some radiobuttons for the fill type: 'Normal', 'Tile', 'Stretch', and 'Stretch and Tile'. 'Normal' just fills in a background color around the image, depending on its orientation. The next two work just like the options for a desktop image: tiling it at its current size or stretching it to fill the whole window. The final option is kind of special: It will always make sure only whole images are tiled. For instance, if your image is 512x512 pixels, it will shrink the image when the window is anywhere below that (which it can't be anyways, but could with larger images), and will stretch it at any larger size, until the window's width or height (or both) become(s) larger than 1024. Then it will tile the image in that direction, and continue stretching both evenly until another 512 pixels is passed. So your tiled image will never be cut off in the middle.

Finally, there will be a combobox and a 'Change...' button for all the standard application graphics. Depending on how well I can control Canvas space, this could include the window icon, minimize/iconify, window/maximize, and close, and it will always include things like the info, warning, and error graphics, radiobutton and checkbox graphics (for each both checked and unchecked), scrollbar and combobox graphics, new, open, save, cut, copy, paste, undo, and redo, and probably a few other program-specific ones.

All this will be saved to something like a 'skins.ini' file, and read at start-up. The different options will be categorized under '[Type]' headers, and options will simply be in the format 'option_name = value'. The options chosen from a list will use numbers or constants (commented at the top of the file), whereas the images will always be in 'path/file.ext' format.

There will be super-headers for each custom skin made, containing all the settings for that skin. The default skins will not be included in this file, nor will the file exist until a custom skin is made.

At this point, I'm going to have skins no matter what, the only question is whether they can leave the window or not. If they can, you can design your entire window look (the real window will never be visible). If not, they will sit inside the window's border and 'decorations' (basically the titlebar).

Tkinter doesn't support partial transparency as far as I can currently tell. However, besides bitmaps it also supports gifs with a transparent color set, so you can create rounded borders, etc. I'll try to include some other image handlers, and if I can find some support for partial window transparency that's multiplatform, I'll try to include it.

As I work on all this, I'll get more screenshots up. The first one will be a skinless view of the new interface, however. Skins will come after I get my widgets all moved to Canvas Items (and the methods of creating widgets in Canvases simplified).

This'll still take a while as I create my custom widget classes, but it'll be done soon enough. I also have a new job to work around though, so most of my work will get done on the weekends. I'll only have a few hours each day during the week to work on it, otherwise, and I really need larger blocks of time to accomplish much.

[Fire Wizzrobe]

It's been two months. Any more progress on this? :)

[itsyfox]

Ah, someone mentioned it. ^_^ I was holding off the mentioning, because progress has been slow.

It *has* been, though. I've been gradually converting everything to classes. I've run into a few annoying bugs along the way (some of which I think are inherent to tkinter, and not my fault), but that happens. Maybe I'll post more pics soon.

As a complete sidenote, I've been learning more C and might want a practice project for it - if nobody would mind a command-line interpreter as a start, I could do that. It would also be easier for the devs to integrate it directly into ZQuest if they chose to, and I could certainly just write all the functions and references to them for allegro to call upon as needed.

I'm actually finding more minor irritating bugs (that may not bother anyone else too much, but I'm picky) in the GUI part that are keeping me from the meat of the project, the interpreter and translator. So if I were to focus my efforts on that and drop the GUI for now, it may get done sooner.

Again, sorry for my silence. I've been busy, and didn't feel I'd made enough progress worthy of posting. Snapshots would look barely different from the last, and in my opinion worse (such as the combo-box, which I have working but have tried to make look *just* like a windows one does, and that broke it).

I'm still working on it though. And I haven't given up on a GUI either. I may not even postpone the GUI, but like I said, that may speed up release of at least the tool in its most primitive form.

[bigjoe]

This would be a cool learning tool. I'm trying to get into the scripting bit and it's proving to be a bit of a pain. Something that compiles directly to Zasm would be a great way to dissect the outcome and learn what Im doing wrong.