Tao of the MachineProgramming, Python, my projects, card games, books, music, Zoids, bettas, manga, cool stuff, and whatever comes to mind.
Last 10 archives
:: About me
:: Oasis Digital
To generate or not to generateYesterday's "generator puzzle" prompted several people to send in solutions, none of which worked. ;-) This problem is trickier than it seems.
In the meantime, I came up with a far-fetched solution myself. Let's recap: I want to write a portable application, that works in Python 2.1, 2.2 and 2.3. One object could benefit from the use of generators, so I want to include these generator methods if generators are present (in 2.2 and up), and exclude/ignore them in earlier versions.
Sounds easy, right? Not really. The code presented yesterday doesn't work, because the __future__ import must be the first line of the file. What about inspecting sys.version?
The solution I came up with is:
More SwingMore Swing hacking today. This time I tried a more complex example, ListDialog. Conversion to Jython went without much trouble. Jython maps very well to Java, and the Swing documentation is excellent.
In spite of that, I will probably stick with wxPython as my main GUI for Firedrop... for now at least. Getting a Swing implementation to work will probably take too much time. However, once I got a rudimentary version working, I will consider adding a second GUI in Swing. In other words, Firedrop may have multiple front-ends, one in wxPython, one in Swing, maybe even more.
This led to an interesting puzzle, aside... the FDB had two methods using generators, which are Python 2.2+. Jython, however, covers Python 2.1 (without generators). Problem: find a portable way to include the generator methods if generators are available, and exclude them if not.
Obvious solutions like
A fling with SwingAfter peeking at some example code in the Jython book, I decided to try my hand at converting the first example from a Swing tutorial. It was shockingly easy to convert the Java code! Granted, the example isn't very convoluted, but it speaks for the power of Jython that this can be so easy. As expected, the Python code is a bit more readable too, mostly because of events that can be methods rather than something wrapped in an ActionListener.
For those who are interested, here's the code. It works, although it may not be perfect. (For example, you have to call main() after creating the class, to make everything visible. Shouldn't that have been in __init__?)
Ooey GUIIn my search for a suitable GUI for Firedrop, we have the following contenders:
Which makes me wonder, maybe I can write multiple GUI front-ends... but I digress.
I don't want a really complex GUI. In spite of that, Tkinter as-is doesn't really look up to the job; maybe with Pmw. wxPython would be a better candidate, but will it work on the Mac? That may be very important because I might want to develop parts of the app there. Delphi is cool, but restricts the app to Windows. Jython and Swing is looking better and better. I don't know much about Java, but using some simple Swing classes doesn't seem too difficult. Of course I may be wrong, so some experimentation is required. Jython would actually have some cool benefits... you can compile the eventual "product"... and it will/should work on any system that has a recent Java VM. The Jython examples work flawlessly on my Mac. ^_^
So, I will need to do some more experimentation first... also, the GUI design isn't quite done yet. More later.
The new frameMagic the Gathering card frames will change. As expected, many people protested, and as expected, Mark Rosewater explains why the new frames are a good idea. Curiously, he repeatedly brings up that the new font is more readable "from a distance". Yes, I always put Magic cards a few feet away and then try to read them, I'm sure others do too. Also, one alleged reason is that the textures of the frames don't always match the "flavor of the colors". "Look at a white card, for example. The background is a lace doily. What does a doily have to with white's flavor? I have no idea." Maybe you should have thought of that earlier. This "lace doily" has been the hallmark of white for ten years, and has appeared on more than a thousand different cards.
Then there's this:
"Probably the biggest aesthetic change with the new card frames is that the focus is now more clearly on the art. For starters the art box is larger, but more importantly the card frames now focus the eye to the art. This is why, by the way, I don't agree with the assessment that the new frames are less "fantasy" than the old ones. I believe that the fantasy focus is merely different. The old frames added fantasy elements all over the card. The new frames instead draw the focus to the one card element that I believe is the most effective in capturing the fantasy flavor: the art."Yes, except that the art all too often is *not* fantasy-related. At least with the original font, cards always had a fantasy flavor, even if the art did not. It was a consistent fantasy element on the card. That is gone now.
The new design isn't bad. One could wonder if it was necessary though.
It's onIntroducing: FDB, the Firedrop Database. This is a (very) simple OO database system, that will be used in Firedrop (and maybe in Kaa, although Firedrop will probably make Kaa obsolete).
FDB uses the underlying file system to store files. Files are stored in subdirectories ("sections") under the root directory. Files whose names match the regular expression "^\d\d\d\d\d$" (five digits, basically, like "00001" or "82934") are considered to be "entries" (or "nodes", in FDB-speak), and are seen by the database if you loop over all entries, or over all entries in a section. Files with other names are not seen directly, but can be retrieved on demand. This allows us to store all kinds of things in a section directory without corrupting the database.
You "connect" by simply creating an FDB object with a root directory. You must also specify an encoder and decoder. By default, these are a pickler and an unpickler (yes, from the pickle module). FDB stores and retrieves Python objects, and it does so by serializing them. Currently (and by default) pickle is used, but Firedrop may use a custom serializer that is less powerful but more readable (and editable).
Some trivial example code:
This system is unorthodox, but I wanted a database that was as open as possible, in many ways. You can inspect and even edit files (nodes) directly, drop new stuff in a directory to add a node, add a section by creating a subdir, etc. Also, from within Firedrop (and its embedded code, templates, etc) it will be easy to access any entry you want. Thus, writing embedded code will be easier.
The system is not super fast, nor is database integrity high on its agenda. It's easy to mess up a database if you don't know what you're doing (but meddle around anyway). So don't do that, then. :-) But if you do know what you're doing, you're not stopped by obscure file formats.
I have interesting plans for Firedrop. But it will take a while to design it and write it. I haven't even decided on the GUI yet. If any (!). ;-)