How to Design Programs. Lisp CMUCL: a high-performance, free Common Lisp implementation Association of Lisp Users An Introduction and Tutorial for Common Lisp LISP prehistory - Summer 1956 through Summer 1958 Common Lisp: A Gentle Introduction to Symbolic Computation Practical Common Lisp CLISP CLiki: The Common Lisp Wiki The Common Lisp Cookbook Planet Lisp
A program to fabricate and articulate a plausible interlude Using Lisp (or another language) to generate fictional characters Clean Slate Annotated objects which drive behavior The annotated cellar: an experiment A Lisp thinktank to explore nonstatic programs Lisp Is King What kind of library would you like to have, if at all? Enjoying books... Arc: interesting; strives to put power and beauty at your fingertips
CLIPS-like language mutating/evolving Lisp code Silly/fun/cool Lisp code snippets!!
SLIME: The Superior Lisp Interaction Mode for Emacs The Music 220b Programming Environment
So I've been sick since Sunday. Being congested in 80F degree weather isn't great.
I've finished book three of the Hitchhiker's series. Bizarre stuff. I might be losing my steam with it though.
I just remembered to check on Stewie, and realized that I'd not responded to a nice gentleman who took a screenshot for me (and evidently hosted it.)
As I've just begun a workshop to cover some network programming basics and OpenGL programming for the ACM chapter of which I am an officer, I should get around to putting up a real page for it. At least the source and some direction as there has been some interest in seeing the code from a few developers.
I'm still looking for a nice basic intro/tutorial on getting something like cl-sdl up and running in one of the big Linux Lisp versions. The website is about as informative as this journal. In the meantime I have sdl working well in Corman Lisp but that's a Windows only solution which doesn't work for me very well.
The textbox currently displayed will turn into the listbox, with the actual textbox differing largely only in that font colors will be supported and the selection will be specific to the character.
The fps is so low due to a number of issues primarily including my old laptop video card and immature passes at certain functionality (it doesn't go too fast with just about nothing on the screen so...). I'll need to profile and refactor at some point. Drawing text seems to be very slow with glut for some reason. I've not used it much outside of my encounter with it this year in Python so I really can't comment on that just yet. I may try to integrate the pyGame font handling code.
Hmmm. At fullscreen it runs at ~80fps. I believe I've read that SDL (the underbelly of pyGame) is relatively slow when windowed so perhaps that is one aspect of this issue.
So Seemant was railing off on use flags again... I couldn't help but laugh at the comments on the bug report... specifically the ...SO FAST... ones, even though they must be common at this point. Sadly, those (use flags) are the sort of things I encounter with school mates as well...
Anywho, I'm off for the weekend but I intend on finishing up the GUI (well, making it functional) and integrating it with the base network layer over the next week or so. Realistically, it'll take longer as I'm moving, program on and off anyway and yadda yadda.
Well, updates and such set my sound in a great mess. Now pygame.init( ) fails due to pygame.mixer.init( ) failing.
Update: Well, after 2 days of beating my head against the desk and bugging my coworker who happens to be on the board of Gentoo developers or somesuch, I fixed it.
Evidently compiling ALSA into the kernel or as a module doesn't work (even though it always did... save one consistent issue), but emerging alsa-driver on its own and configuring that jazz works perfectly.
So I spent a few hours a few days ago and again last night making a "good enough" pyGame GUI. It's largely what you'd expect, the main window holds "frame" widgets which then contain widgets that may contain widgets and so forth. Completed currently are Frames (with or without a titlebar), Edit Field (single line text box), Button, Radio Button and Label. In the works are a multiline non-input run TextArea, Picture and Scroll Bar.
I figure that that should be enough for my purposes. The current way they are displayed is rather ugly, but its functional and I can worry about prettying it up when it matters. I've made a bit of headway with the network code (fixed an issue) and will probably (try to) merge the two bases tonight.
As was predicted, progress is rather slow. My work term is over in 4 weeks (most unfortunately) so my impending 3 day school schedule should leave time to get some more code done on this.
However, I have been able to experiment and get a few things done. Most importantly, the foundation of the prototype networking protocol is largely completed.
I know find myself looking for a way to handle the UI so that I can merge the networked console client with the graphical one. I've at least run an example and read some docs on PyGTK, wxWindows and pyUI.
My primary concern with the first two is that while they afford an OpenGL context, their look and feel aren't great, and they're rather large for what I need. I'm still considering wxPython, though I'm no fan of anything with a layout manager.
pyUI is a slight mess. It would seem that the author has taken off or somesuch, though someone has built upon it with the Vierstein project. That looks quite promising.
My issues with this are that handling key and mouse events outside of a widget seemingly requires a sort of hack and that, like the rest of these, pyUI drives my application, not the other way around.
The last option is a custom built UI, which may be a case of reinventing the wheel. This sort of defeats the purpose of using Python to begin with, but on the other hand, as I've helped build a more comprehensive UI with straight pyOpenGL in a small amount of time, a workable, if ugly, UI could be up after a few hours work.
A custom UI means no questions as to how something works, and I don't have to "make do" with what a 3rd party system provides.
I have to inventory my books so I figured I'd do my technical books as well just to see what's laying around (not to mention that it seems a little addition when compared to the amount of the rest of them). This is the bulk of these books, and I should be done with the catalog as well as this list when I return to Boston tomorrow. I expect to add less than 10 books to this list to finalize it then. Some of these books I can't explain and others I'm embarassed to own (read: the ethical hacking book - the result of a research paper that served really to just mock, well, everyone, myself included, for a class led by a know-nothing hack who was later removed. Ah, memories.). Anyway, here's the list:
Ah, I can't forget Learning Perl and Perl which this will serve as reminder for me to pick up from the Professor's office Friday morning.
Also, though many books have been lost to me, I have yet to give up on Out of Control. You'll get yours yet, Ian. Well, or I'll get mine.
So I've finally gotten around to py2exe (at the end of a long, exhausting day). Well, after prevailing against numerous PIL, numarray and OpenGL package issues, I have a python "executable" up and running.
That sounds well and good until you realize that 78.3KB of code and images (.png's) turn into a 15.3MB distributable directory. I should be able to thin it out, but that's quite a large demo.
[ Moments pass. ]
Well, after (partially) arbitrarily deleting .dlls I've brought it down to 11.0MB. I'll have to build this deletion into the script. For some reason all of the SDL*.dll's have reared their ugly heads. Perhaps PIL utilizes them?
I think 10.0MB is a somewhat more reasonable download (though that's before any media we add as well as Glut's 232KB), with a source option for those with python installed.
I clearly already have a habit of appending an ellipsis to my journal subjects.
At work today I had to interface to a 3D application's COM server. My co-worker mentioned using C++ and MFC to do it. I decided that I didn't enjoy the equivalent of repeatedly beating myself with a shovel so...
I'd like to thank whomever was responsible for this.
Python > C++ + MFC in any context. Ever. Even when it comes to COM. ::shudder::
Concerning the PMPG, I've contacted a resident sprite artist to see about replacing the proof of concept sprites and to see about possible future work should this take off very well.
Well, someone from these boards has decided to join in on my low-key project, which is good news for it's completion likelihood!
I'm doing a little bit of work on the client/server branch. I'm sure that a select() server (also in Python) should be more than fast enough for this. More importantly, I feel it's the most friendly networking method to beginners (which is a good part in my decision to do this).
If I decide to get really motivated I'll merge the branches tonight, as I don't see myself working on this much in the next few days.
If at any point, anyone wants source for whatever reason, let me know. If it gets moving I'll probably set up a page for it (maybe sourceforge?).
I decided to kill some time tonight and whipped up this.
Unfortunately those were converted once too many times so they don't look very nice, but I've written up quick and dirty sprite functionality with Python/OpenGL. I'll probably make a light text-based protocol client/server app out of it when I next have some time to kill. It's largely already written, it's just a matter of integration.
Well, that and some sort of focus.
My main issue with Python is that is seems rather daunting to release anything with considerable dependencies as an executable with py2exe. I have yet to even try it so it's really lazy/idle conjecture at this point. More importantly, it's impetus for me to just release everything in the public domain.
Also, pertaining to Python, it's nice to be able to crank something like this (and a few other things) in a night and have it be either reusable or easily tossed away. I wish I could say that about my C++ implementation of a "Program to Evolutionarily Generate Articulate Motion." *sigh*
So, after just over a month, work has turned out to be pretty awesome. If nothing else, learning Python alone has made it worthwhile. It's really nice to have all co-workers whom you respect and like.
What I'm particularly happy about is that unlike so many of my classmates on co-op, my position is one of design and creation, not maintenance. As my first time in this sort of setting, I must admit it's a strange feeling having your code be that which is shown to the Board of Directors, when you've only been around for a handful of weeks.
Oh, it's Valentine's Day. I received this massive package from my girlfriend... I'll wait until I get home to open it methinks. Life is good.
I'm pretty surprised that no one has really shown any interest in my offer to work on an MRPG. I guess a realistic, fun project isn't what beginners/intermediates are looking for nowadays.
I would like to thank a particular mod for his show of support and offer of aid. The Mods are a good balanced bunch here.
It's probably for the better that no one is interested anyway, as I've decided to give real thought to joining an acquaintance (from here no less) in a serious venture. I'll still have some time to work on the MRPG, but I'd rather commit myself to something more worthwhile.
Also, if anyone else is interested in the source to my Assembly Game then I'll probably get around to setting up a page with a source download along with a FAQ. Or, more likely, explanations to the questions about the source that I've been asked by others who've downloaded it. (The answer to most of which: "It was a hack so it would be finished in time.")