Wednesday, November 15. 2006
Version 0.3 of the MySQL FFI for Gambit released
Another version of the MySQL FFI is finished and ready for takeoff. Some big changes in this version. First of all, MySQL connection pooling has been implemented, and should be mostly thread-safe. I've also done up some higher-level functions for retrieving data from the database. Again, this release is not perfect, but it is getting much closer.
Click here to download the tar file
Here is the documentation
I am currently working on a set of macros as a sort of object-relational layer between the DB and scheme. Obviously this not a true object relational... anything, because there are no real (native) objects in scheme. More info forthcoming.
Click here to download the tar file
Here is the documentation
I am currently working on a set of macros as a sort of object-relational layer between the DB and scheme. Obviously this not a true object relational... anything, because there are no real (native) objects in scheme. More info forthcoming.
Monday, November 13. 2006
Its like a whole new world of the source is opening up...
I've been playing around with Gambit lately. Just recently I posed a question to the Gambit list, because I wanted access to the default exception handler. the response I got was... Mind-blowing.
Where I got directed was something a little different. Gambit defines the primitives ##cmd-b, ##cmd-e, ##cmd-y, etc. Each of these primitive procedures are equivalent to the interpreter commands prefixed with a comma. So just like in the GSI interpreter ,b will shoot you a backtrace, ##cmd-b will do the same.
If you are at all interested in becoming a Gambit hacker, these routines are a MUST-LOOK-AT. For instance, dynamic inspection of the current environment now becomes possible. On top of that, there seem to be a host of interesting functions like:
Where I got directed was something a little different. Gambit defines the primitives ##cmd-b, ##cmd-e, ##cmd-y, etc. Each of these primitive procedures are equivalent to the interpreter commands prefixed with a comma. So just like in the GSI interpreter ,b will shoot you a backtrace, ##cmd-b will do the same.
If you are at all interested in becoming a Gambit hacker, these routines are a MUST-LOOK-AT. For instance, dynamic inspection of the current environment now becomes possible. On top of that, there seem to be a host of interesting functions like:
- ##continuation-count-interesting [continuation]
- ##continuation-creator [continuation]
- ##procedure-name [continuation-creator]
- ##continuation locat [continuation]
- ##decomp [interpreted-continuation-code]
- ##dynamic-env->list [macro-continuation-denv]
- ##decompile [obj]
- ##exception->kind [exc]
- ##exception->procedure [exc] [cont]
- ##exception->locat [exc] [cont]
- display-exception [exc]
I think it is time to transfer the Gambit source to my PDA for long-time bus related browsing.
And the code? Damn readable.
Wednesday, October 25. 2006
Imagine a webserver...
Imagine a webserver that is completely dis-entangled from the filesystem. Where requests are handled as they should be: as requests for representations of resources. Imagine a webserver based on very simple rules that can be composed into more complex rules (url is foo, host is bar, accept-language is baz, method is blarg). Imagine a webserver where typical HTTP headers and methods are understood, but extensions can be easily dealt with. Thats right, a server that could respond to the new FROBNICATE method is possible.
This server, is called zen-garden. zen-garden is my pet project. It is my tilting at a windmill, and it is rapidly approaching a 0.1 release. The fundamental difference between zen-garden and most other webservers is that zen-garden is built, and based around simple rules. You want to log every request to a database table? Write a rule that acts on every request, and writes the request info to the table. You want to run all of your HTML files through Tidy and or gzip to compress them? Write a rule to act on every response that doesn't already have gzip encoding, and has a content-type of text/html. As you can see, the rule-based webserver is a very powerful concept indeed.
Now you might be asking "How do you handle a request for a single page, a single CSS file?" The answer is simple: a rule to output the page or CSS file when the request method is GET, and the URI is /path/to/your/file. But imagine this, instead of making the webserver find the file, load it, and send it across the network, what if you told the webserver it should compile the serving of that file into itself on deploy time? What if part of the deploy is taking a source file in XML and doing some transformations on it, and then compiling the transformations into itself before deploying? But what if all this was developer friendly so that when working in a development environment, you don't have to deal with the daily grind of compile-test-debug, you could make a change to your file, and test it on the spot? zen-gardens host language is Scheme on Gambit, so it is interpreted for a really fast development cycle, but Gambit can also be compiled to C (which of course can be compiled to native code) so when it is time to deploy, your server will be fast.
The crux to zen-garden is the request-chains and request-handlers. A request-handler is a data structure, with 2 important parts: a predicate stating whether or not the handler should execute, and the handler itself. Both of these are functions that return booleans. A request-chain is really just a series of request handlers that are executed in a particular order, split out into 4 convenient phases: initialization, handling, fallback and finalization. A request-handler can be bound to any one of these 4 phases. If a request is not handled during the 'handling' phase, the fallback phase is executed, otherwise it is skipped.
The real interesting thing about this structure is that a request-handler can spawn a new request-chain. So you can have a request-handler that executes when the 'Host' header is set to 'my.foo.domain.com' that spawns a new request-chain. On top of that, there is nothing stopping you from dealing with requests in other ways, in fact, any way you see fit. Don't like my method of predicates and request chains and what have you? Write your own method of doing things. zen-garden is modular in design. Pull out the routine that I use to handle requests, and install your own.
What is in the future of zen-garden? Well, ZSP's, or Zen-Server-Pages, which is a JSP/PHP method of page generation. Unlike these other technologies, I plan on getting the separation of business logic and display logic right. No top-heavy tag libraries with presentational logic getting confused with document structure, yes JSP and the entire J2EE stack, I am looking at you. No business logic tied up with your presentation, dirty, nasty PHP! What else is in the future? My(and other)SQL connection pooling, GD integration, regular expressions, optional continuation based web programming, RESTful resources, specialized preprocessing of CSS and Javascript files (only send the browser the CSS it needs, and you want it to have).
Oh, and it is all under a BSD License.
For now, everything is available in a subversion repository, svn://panda-ba.sanriowasteland.net/zengarden/trunk . You will need the Gambit-C compiler and interpreter as well.
This server, is called zen-garden. zen-garden is my pet project. It is my tilting at a windmill, and it is rapidly approaching a 0.1 release. The fundamental difference between zen-garden and most other webservers is that zen-garden is built, and based around simple rules. You want to log every request to a database table? Write a rule that acts on every request, and writes the request info to the table. You want to run all of your HTML files through Tidy and or gzip to compress them? Write a rule to act on every response that doesn't already have gzip encoding, and has a content-type of text/html. As you can see, the rule-based webserver is a very powerful concept indeed.
Now you might be asking "How do you handle a request for a single page, a single CSS file?" The answer is simple: a rule to output the page or CSS file when the request method is GET, and the URI is /path/to/your/file. But imagine this, instead of making the webserver find the file, load it, and send it across the network, what if you told the webserver it should compile the serving of that file into itself on deploy time? What if part of the deploy is taking a source file in XML and doing some transformations on it, and then compiling the transformations into itself before deploying? But what if all this was developer friendly so that when working in a development environment, you don't have to deal with the daily grind of compile-test-debug, you could make a change to your file, and test it on the spot? zen-gardens host language is Scheme on Gambit, so it is interpreted for a really fast development cycle, but Gambit can also be compiled to C (which of course can be compiled to native code) so when it is time to deploy, your server will be fast.
The crux to zen-garden is the request-chains and request-handlers. A request-handler is a data structure, with 2 important parts: a predicate stating whether or not the handler should execute, and the handler itself. Both of these are functions that return booleans. A request-chain is really just a series of request handlers that are executed in a particular order, split out into 4 convenient phases: initialization, handling, fallback and finalization. A request-handler can be bound to any one of these 4 phases. If a request is not handled during the 'handling' phase, the fallback phase is executed, otherwise it is skipped.
The real interesting thing about this structure is that a request-handler can spawn a new request-chain. So you can have a request-handler that executes when the 'Host' header is set to 'my.foo.domain.com' that spawns a new request-chain. On top of that, there is nothing stopping you from dealing with requests in other ways, in fact, any way you see fit. Don't like my method of predicates and request chains and what have you? Write your own method of doing things. zen-garden is modular in design. Pull out the routine that I use to handle requests, and install your own.
What is in the future of zen-garden? Well, ZSP's, or Zen-Server-Pages, which is a JSP/PHP method of page generation. Unlike these other technologies, I plan on getting the separation of business logic and display logic right. No top-heavy tag libraries with presentational logic getting confused with document structure, yes JSP and the entire J2EE stack, I am looking at you. No business logic tied up with your presentation, dirty, nasty PHP! What else is in the future? My(and other)SQL connection pooling, GD integration, regular expressions, optional continuation based web programming, RESTful resources, specialized preprocessing of CSS and Javascript files (only send the browser the CSS it needs, and you want it to have).
Oh, and it is all under a BSD License.
For now, everything is available in a subversion repository, svn://panda-ba.sanriowasteland.net/zengarden/trunk . You will need the Gambit-C compiler and interpreter as well.
Monday, October 23. 2006
Lambda is my memento mori
It is easy (easy by Unix, not Apple/Microsoft standards) to configure a Linux machine so that it will go directly into a GUI when you boot it up. This way, you never see a tty screen at all. I still have mine boot into the white-on-black teletype screen however, as a computational memento mori. It used to be fashionable for a writer to keep a human skull on his desk as a reminder that he was mortal, that all about him was vanity. The tty screen reminds me that the same thing is true of slick user interfaces.—Neil Stephenson, In the Beginning... was the Commandline
Greg asked me on IRC the other day why I tend to write functions in scheme as
(define foo (lambda (bar) ... )) instead of
(define (foo bar) ... )?
It was then that I realized it was my Memento Mori. It is my way of saying to myself "functions are just values that can be bound to names like anything else".
Thursday, September 21. 2006
On Scheme, OSX and Editors
I am trying to find the perfect editor for OSX. Actually, I have been trying to find the perfect scheme editor for OSX.
On my windows machine at home i use UltraEdit, which at one point was the ultimate in text editors. At work, I use jEdit, which is excellent , and has a lot of potential. Both of these programs are good at editing source code for PHP, JSP, HTML and PL/B. But in my heart, I knew that when it came to programming Scheme, both of these solutions fell short.
So when I was faced with trying to find an editor I liked for OSX, I immediately jumped to jEdit (being cross platform and all) and I rapidly jumped back. jEdit, while good, just isn't great at editing scheme. Sure there is an R4RS implementation of scheme that hooks into its console, but lets face it, it isn't really that useful. On top of it, its console plugin does NOT like to play nice with the Gambit scheme interpreter. To make matters worse, working with jEdit on OS X didn't feel like working with it on WinXP.
Now let me take a little diversion here. Ever since I have gotten my new PowerBook, I have been sitting in this weird little zone. It is equal parts "Oh Ess Ex? More like Oh! Eh! Sex!" and sitting, quite firmly in the suck threshold. On one hand I am opening terminal windows and hacking like a power user, but on the other, I am running to my more seasoned mac friends to ask how I can use the tab key to switch focus to a button. The overall effect here is that for me to get the simplest jobs done (sometimes) involves a lot of pain and work; this being said, I can imagine switching from OS X to WinXP would be an even worse experience.
So I narrowed my choice down to either TextMate, or Emacs. Now TextMate is the ultimate in slick editors for OS X. It is slick, very OS X in its interface, easy to use... and an absolute pain to work with if you are editing Scheme. Basicly, TextMate has an active community of Ruby, Python and PHP developers doing Ruby, Python and PHP things for TextMate, not Scheme things.
With Emacs, it is quite the opposite. Emacs is de rigeur amongst Scheme developers, so obviously more effort has been made to make it scheme friendly (even allowing for the fact that there are many different implementaitons). The differences don't stop there. While TextMate is flashy, user friendly and OS X like, Emacs, even the latest build for OSX, is not.
So I was faced with inferior editing, in a comfortable (but yet new) OS X style with TextMate; or far superior editing with emacs, but faced with the prospect of not only sucking in OSX, but sucking in a completely different method of editing source code.
Now you might be asking yourself "How different can editing source-code be? Even across WinXP and OS X, its Control (or Command) U for undo, C for copy, X for cut, and V for paste. Right? Right?" Well. No. In Emacs, Undo is done with a Control-/. There is no redo. Instead, undo's are un-done by performing an action (like hitting space-bar), and undoing that, which forces the undo of the undo actions. Essentially every action (hitting a character, deleting a line, or even undoing) puts that action upon a stack, so every action is saved, even actions that were undone. This is a very powerful and slightly confusing concept, but it exactly illustrates emacs. Powerful and Confusing.
Overall my experience thus-far has been good. It is hard work, I still suck at editing Scheme in emacs, but the biggest thing here is that I am the one that is sucking, not my editor. Surely emacs could be built better, perhaps the Headrush folk could build an equally powerful but yet friendlier emacs. But emacs has already given me enough bones to keep slogging away at it. Knowing that I will stop sucking soon also helps.
On my windows machine at home i use UltraEdit, which at one point was the ultimate in text editors. At work, I use jEdit, which is excellent , and has a lot of potential. Both of these programs are good at editing source code for PHP, JSP, HTML and PL/B. But in my heart, I knew that when it came to programming Scheme, both of these solutions fell short.
So when I was faced with trying to find an editor I liked for OSX, I immediately jumped to jEdit (being cross platform and all) and I rapidly jumped back. jEdit, while good, just isn't great at editing scheme. Sure there is an R4RS implementation of scheme that hooks into its console, but lets face it, it isn't really that useful. On top of it, its console plugin does NOT like to play nice with the Gambit scheme interpreter. To make matters worse, working with jEdit on OS X didn't feel like working with it on WinXP.
Now let me take a little diversion here. Ever since I have gotten my new PowerBook, I have been sitting in this weird little zone. It is equal parts "Oh Ess Ex? More like Oh! Eh! Sex!" and sitting, quite firmly in the suck threshold. On one hand I am opening terminal windows and hacking like a power user, but on the other, I am running to my more seasoned mac friends to ask how I can use the tab key to switch focus to a button. The overall effect here is that for me to get the simplest jobs done (sometimes) involves a lot of pain and work; this being said, I can imagine switching from OS X to WinXP would be an even worse experience.
So I narrowed my choice down to either TextMate, or Emacs. Now TextMate is the ultimate in slick editors for OS X. It is slick, very OS X in its interface, easy to use... and an absolute pain to work with if you are editing Scheme. Basicly, TextMate has an active community of Ruby, Python and PHP developers doing Ruby, Python and PHP things for TextMate, not Scheme things.
With Emacs, it is quite the opposite. Emacs is de rigeur amongst Scheme developers, so obviously more effort has been made to make it scheme friendly (even allowing for the fact that there are many different implementaitons). The differences don't stop there. While TextMate is flashy, user friendly and OS X like, Emacs, even the latest build for OSX, is not.
So I was faced with inferior editing, in a comfortable (but yet new) OS X style with TextMate; or far superior editing with emacs, but faced with the prospect of not only sucking in OSX, but sucking in a completely different method of editing source code.
Now you might be asking yourself "How different can editing source-code be? Even across WinXP and OS X, its Control (or Command) U for undo, C for copy, X for cut, and V for paste. Right? Right?" Well. No. In Emacs, Undo is done with a Control-/. There is no redo. Instead, undo's are un-done by performing an action (like hitting space-bar), and undoing that, which forces the undo of the undo actions. Essentially every action (hitting a character, deleting a line, or even undoing) puts that action upon a stack, so every action is saved, even actions that were undone. This is a very powerful and slightly confusing concept, but it exactly illustrates emacs. Powerful and Confusing.
Overall my experience thus-far has been good. It is hard work, I still suck at editing Scheme in emacs, but the biggest thing here is that I am the one that is sucking, not my editor. Surely emacs could be built better, perhaps the Headrush folk could build an equally powerful but yet friendlier emacs. But emacs has already given me enough bones to keep slogging away at it. Knowing that I will stop sucking soon also helps.
Wednesday, August 2. 2006
A simple build of Gambit
In my mounds of spare time (ha ha ha) I've been playing with Scheme again. I've been seriously trying scheme-48 (very nice and elegant) and Gambit (very usable). Right now I am in the midst of working with a webserver written entirely out of scheme, to play with my own web-application ideas. I want to focus on the idea of a webserver that deals strictly in resources, something very RESTful and elegant.
We'll see how it goes.
Anyway, I needed a cygwin compatible speedy build, and because I couldn't do one at home, I thought, why not at work? And if I am going this far, why not post it so that someone else can use it?
Here ya go: gambit v4.0 beta 17 with --enable-single-host
We'll see how it goes.
Anyway, I needed a cygwin compatible speedy build, and because I couldn't do one at home, I thought, why not at work? And if I am going this far, why not post it so that someone else can use it?
Here ya go: gambit v4.0 beta 17 with --enable-single-host
Wednesday, January 18. 2006
PHP Scheme (!!!)
PHP is like my old waffle shirt in the closet. It is comfortable, well worn, I love it, but it certainly has some holes.
Scheme is like a nice suit—with a batman utility belt—made out of waffle material. It is pleasing to look at, fits well, it is super comfortable, and is abso-fuckin-lutely amazing.
So what happens if you mix the two together? Marko Riedel's Scheme interpreter written in PHP.
The Code isn't the most well factored code I've seen (lots of global abuse), but it seems mostly functional (haha). While his interpreter doesn't implement a macro system, such sucks because macros are dead sexXxy, it does implement another sexy feature of Scheme... "call-with-current-continuation" ("call/cc" for short).
If Marko is open to the idea, I am going to wrap the interpreter inside of an object, so that one can plug this thing into a PHP application easily. I have no idea what kind of licence it is under, the source code is available however. The next time you decide that you need some kind of configuration language, pay a little visit over here, instead of building your own custom solution.
Update: I wrote Marko and asked about the possibilities of updating his code, and this is what he had to say:
Update 2: Fixed the broken link. Sorry 'bout that.
Scheme is like a nice suit—with a batman utility belt—made out of waffle material. It is pleasing to look at, fits well, it is super comfortable, and is abso-fuckin-lutely amazing.
So what happens if you mix the two together? Marko Riedel's Scheme interpreter written in PHP.
The Code isn't the most well factored code I've seen (lots of global abuse), but it seems mostly functional (haha). While his interpreter doesn't implement a macro system, such sucks because macros are dead sexXxy, it does implement another sexy feature of Scheme... "call-with-current-continuation" ("call/cc" for short).
If Marko is open to the idea, I am going to wrap the interpreter inside of an object, so that one can plug this thing into a PHP application easily. I have no idea what kind of licence it is under, the source code is available however. The next time you decide that you need some kind of configuration language, pay a little visit over here, instead of building your own custom solution.
Update: I wrote Marko and asked about the possibilities of updating his code, and this is what he had to say:
thank you for your interest. It's been quite some time since I wrote PHPScheme. I remember it as a rather trying and frustrating experience (I don't like those globals either -- but there was no way around them at the time). PHP has evolved and improved since. I think making PHPScheme into a proper object seems like a cool idea and I encourage you to try it. Feel free to use the code any way you like as long as you indicate where you got it and what parts of it are yours. Then again there already is an embeddable Scheme interpreter that is vastly superior to anything I could write. It's called Guile and definitely worth checking out.So, I did have a look at GNUStep. It looks hella interesting, and is truely cross platform, so you get get it for win32, mac, linux (of all sorts of distros). I don't have the time right now to go installing and playing with yet more software... (the last thing I nee right now is ANOTHER project), but if go check out Markos Interesting software projects.
Can I interest you in GNUstep by the way? It can use all the exposure it can get, and it's a rather marvellous software development environment to discover. How about a plug for my programs GMastermind.app (GNUstep) and Mastermind.app (Mac OS X version) on your blog? ;-) I also have a Scheme interpreter, a mine sweeper and a jigsaw puzzle.
Update 2: Fixed the broken link. Sorry 'bout that.
(Page 1 of 4, totaling 25 entries)
» next page





