Log in

Dec. 9th, 2007 @ 02:47 pm (no subject)
About this Entry
I've been working hard on the Sleep 2.1 manual. My promise to the world has essentially been finish the code, redo the docs on the language, and then write a short primer on integration. Following those actions Sleep 2.1 will be completed.

One of the challenging aspects of writing this documentation is writing good examples. When writing this documentation I realize I'm not just capturing the syntax and basic use cases within the language. I'm also trying to capture the paradigms and ways of thinking in the language. This is important because it is the difference between an academic example and something people can use.

One example is fork. Fork is Sleep's abstraction for asynchronous computing. I say this because I don't want to call them threads. For the most part, Sleep's forks are completely isolated from each other. Of course they can share explicitly specified variables and then we get into locks and all that ugly mucky muck. But in any case I was trying to capture--how do I write an example of a multi-threaded tcp/ip client app? Something that users can cut and paste and begin using right away.

I learned Java in this cut and paste and begin using right away mentality. (Thanks Mr. David Flanagan for your Java Examples in a Nutshell Book--I'm quoting your name and book from memory, that shows what I really think of you).

Fortunately Sleep has had a strong ally in this type of development. I have a few coworkers and the incredibly, ah, vocal jIRCii user community who use Sleep. There feedback, endless support requests, and hunger for a solution have really driven the project. They have helped me identify holes in my functionality, real problems to solve, and of course what to document.

Case in point with fork. This weekend someone was trying to write a connection bouncer in Sleep. I think he actually is close to finishing it. He keeps adding a lot of stuff to it. But in any case he was trying to wrap his brain around fork and how to do computing in an asynchronous manner.

I managed an example that made it into the Sleep manual. If it weren't for him the technique I documented probably would not have been documented. Meaning ever user with a situation similar to his would be stuck trying to figure something out.

So I'm thankful for the users. They are really helping this come together.

The documentation is almost in a distributable state. So Sleep 2.1 should be coming soon. I will probably be ready to call it official in January 2008.
Nov. 26th, 2007 @ 02:23 am (no subject)
About this Entry
Sheesh, I am exhausted. I have to leave for Boston in 2 hours. Spent the whole night hacking code.

On the bright side I finally have a jIRCii website up. The hick.org crash wiped out the old site. For awhile I had nothing but a placeholder page up. Not really fair to jIRCii or to its user community.

On the even brighter side of things, I put out a jIRCii release today. I think I managed to fix some things that were really annoying folks. It took a little bit of persistent prodding for me to get the release out.

Ok, i'm gonna go pack and then hop on the road or something.
Nov. 12th, 2007 @ 11:32 pm (no subject)
About this Entry
During a google search for jIRCii, I found a link to the JavaPosse. A regular podcast on Java.

Anyways these guys were talking about IRC and jIRCii in particular. There was a little debate on how to pronounce it. They settled on jerky like beef jerky. Actually it is jay-eye-are-cee-two, a play on ircii the classic UNIX IRC client. It looks like I'll have to update the FAQ.
Oct. 18th, 2007 @ 01:19 am callcc and clever sleep hacks
About this Entry
I've been MIA for awhile. I tend to go through high/low phases with my open source coding. A sure-fire trigger for a low phase is a "hard" problem for me.

The latest hard problem was how to implement continuations and inline functions into Sleep. This combination of features is necessary to really make the callcc construct useful. (FYI--I figured it out and both features are now implemented and checked into the subversion repository).

I've gotten a lot of mileage out of Sleep's yield command. Yield causes the current function state to be saved while simultaneously returning a value. This ability to save the current state of a function has been very useful to me. I was using this capability to support strong mobility of Sleep functions. http://www.jroller.com/sleepsnip/entry/mobile_agents_in_sleep

The problem is yielding an IP address was a cumbersome way to represent a go or move command. In my opinion the language shouldn't be clunky like that.

Enter callcc. callcc works like yield except it immediately passes control flow to a specified function. The specified function receives the saved state of the caller as a parameter. Interestingly enough, this specified function ends up owning the control flow for the caller and it can choose to return a value that will be returned to the caller of the caller. (confusing yet?)

The problem with callcc is it can be cumbersome to type callcc and some function over and over again. Just like having yield for my move abstraction was cumbersome. Enter inline functions. Sleep is not lisp or scheme. If it was, I'd support full on macros. Since its not I wanted to come up with a way to hide the details of callcc behind a function like entity. In Sleep an inline function call looks like a normal function call. Except inline functions execute inline within the current scope. Return, yield, callcc, etc.. within an inline function all affect the parent closure. So in a way, inline functions are like poor man's macros in Sleep.

I am excited as this will enable fun stuff like:

inline move{
  callcc let({
     $handle = connect($host, 8888);
     writeObject($handle, $1);
  }, $host => $1);

*pHEAR*. The middleware for this kind of asynchronous, mobile entity:

global('$server $agent');

while (1)
   $server = listen(8888, 0);
   $agent = readObject($server);


It does not get much simpler than this. Oh, the mobile entity itself. Lets talk about a file copying mobile entity:

# assume $local_ip, $remote_ip are defined to two ip addresses running the middleware above

sub copyFile
   local('$handle $data');
   $handle = openf("database.dat");
   $data = readb($handle, lof("database.dat"));

   $handle = $null;


   $handle = openf(">database.dat");
   writeb($handle, $data);

   ($handle, $data) = $null;



As you can see callcc and inline functions will be quite a formidable combination. What type of flow control you want to abstract will be entirely up to your imagination. I'm excited for it.
Jun. 15th, 2007 @ 07:21 pm (no subject)
About this Entry
Ok, this is a momentous occasion. I have only 4 open reports in the Sleep issue tracker right now. I've been down this low before but I plan to stay there this time, really really. :)

This next Sleep beta is going to be pretty good. Each beta usually focuses on one or two sets of features/areas to fix bugs in. This one focuses on adding support for Java class literals i.e. ^String to resolve in place to java.lang.String.class. This feature is useful for stuff like: if ($exception isa ^IOException) { ... } no more need for crazy [Class forName: "..."] calls throughout script code. The other advantage to this new literal is several functions in Sleep's library use a kludge where a string is specified and later turned into a Class. The &use function for loading a bridge into the current script environment is a good example of this. Life sucks for the scripters as they can't take advantage of any checking done by Sleep at compile time. Now this has been remedied.

For example, to use Andreas' JDBC bridge with this new enhancement:

import JDBCBridge from: "jdbc.jar";

This next beta also adds a bunch of nit picky features and fixes some nit picky bugs. I also spent some time and fixed the bugs I found in Sleep's try/catch mode. I've been doing a decent sized project and I've found using try/catch to handle all errors (debug mode 34) is really nice. However I've also found some corner cases that resulted in bugs with try/catch and I managed to fix those.

So that is what I've got going on in the Sleep world.
May. 18th, 2007 @ 08:33 pm Documentation Hacking
About this Entry
I'm happy, making some good progress on the Sleep 2.1 Manual. I've opted to treat the tutorial portion of the manual as a place to explain the constructs of the language and how things work overall. Explanations of abstractions and how to do certain things (like calculate the MD5 digest of a file) are left to the function reference.

This philosophical change has helped a lot. Now the manual is merely a reference and a quick start guide for scripters. This is leaving the door wide open for a real book on Sleep when there is enough interest in such a thing.

I wrote some scripts to help me out with the documentation. Namely my function reference pages are all generated from some simple text files. This keeps things consistent and greatly speeds up my ability to write pages. I'm one of those writers that tends to get caught up in how things are formatted. This was really slowing me down.

I still have two chapters to finish. I'm going to rewrite the chapter on interfacing with Java and the debugging chapter has to be done practically from scratch as well.

I now have pages for nearly all of the functions. About half of them are generated from my scripts, the other half have yet to be converted. Once these are done I have to start writing examples that show off how each function works.

I'm excited though. Writing new documentation is like writing new code. It is a slow process and it takes awhile before progress is visible. However as with code there is a point where so much is done that all work is just building on something that is already good. Doing development on something that is already good is a lot of fun. The Sleep documentation is almost at this point. Once the function files are all converted to my script system then I'll feel comfortable with where it is at.

Once the Sleep manual is done, I plan to go through the Sleep developers guide and try to distill and paste a lot of the good stuff from it into the Sleep javadoc. After that I will write a short pamphlet on integrating Sleep into an application. This process has changed considerably since the Sleep developers guide was written.

My aim is for the new developer's guide to be less than 10 pages total.

Apr. 16th, 2007 @ 01:09 pm (no subject)
About this Entry
I hope no one is expecting anything from me for the next few days. I've been on a little bit of a traveling binge. This is definitely helping.

I find as a developer it helps to get away from my work from time to time. Namely when I get caught up in my work I start to get more and more ambitious. Each bug fix starts to require grander rewrites that supposedly introduce more elegance. Suddenly some far off idea becomes a must have feature. Really, my getting caught up in my work is dangerous to it. So a break is good.
Apr. 8th, 2007 @ 11:43 pm There is a madness to the method... resolution
About this Entry
There is a guy named Kurt who is an advocate of jIRCii. After I released b41 I quickly uploaded a small fix as I noticed a problem when running one of blue-elf's scripts with +trace enabled. Upon announcing this quick update he stated "this is why I use jIRCii whenever I want a GUI... you're #@&(&*($@&* ANAL!"

I've never thought of myself as an anal person. But I guess when it comes to code I may be. Tonight I've been working on how Sleep converts Scalars to arrays. Converting one dimensional types is easy, you resolve the best fit and convert it. With arrays there is the quirky question, how to convert the rest of the values and what to do if they don't convert, and how should the common denominator for the whole array be determined.

At the moment Sleep has array conversion code in place. It isn't bad but there are a few tweaks that can be made. Tonight is the first time I created an extensive series of test cases to cover this array conversion and it is revealing a few small problems (nothing cast() can't fix for scripters). But in any case, I don't want scripters to say "oh yeah, Sleep is horrible at converting arrays, if you decide to trust its array conversion... good luck". This may be the case but I'd like to do everything I can to at least make it work in a semi-logical and consistent manner.

Not going so well at the moment. I'll be happy so long as I fix a few things, avoid breaking backwards compatibility, and provide good error messages if necessary.

So that is whats happening on this side. I'll try to release 2.1-b15 tomorrow night.
Apr. 7th, 2007 @ 01:52 am (no subject)
About this Entry
Progress on Sleep 2.1-b15 is going well. I've managed to fix a lot of bugs and I took the time to search for some potential outstanding bugs as well. I've also added an assert command to the language as well.

So I'm down to one more bug fix before my list of open bugs is exhausted. That is a good place to be.

So now I'm trying to figure out the rest of the roadmap for Sleep 2.1. I have two features I'd like to implement (even though we're supposed to be feature complete right now), namely an optimizer and ||, && for use within expressions. The optimizer is more of an experiment I want to do. It doesn't have to make it into this version of Sleep but I'd like to be able to modify the Block/Step APIs to at least accept a visitor type object before Sleep 2.1 is out.

I may do the visitor thing this weekend and fixing my last bug. Beyond that I'll probably finish my Sleep bridge based on Dunamis (a java.net project, allows one to generate instances of classes with methods back by an invoke method). These things I'll release as part of Sleep 2.1-b15.

The &&, || thing I will try to do but unless it goes 100% smoothly, I'll probably defer it to a future development cycle. As for the optimizer same thing. I'll do an experiment to see how it goes trying to optimize a few things but I won't put that kind of heavy pressure on myself to finish an optimizer in such a short amount of time. Sleep 2.2 anyone?

Bare with me here, I'm merely thinking aloud and figuring out what comes next.

Of course all my release candidate versions of Sleep have to go into jIRCii for some good "field testing". Some of the bugs I just fixed were filed when jIRCii scripters came to me with questions about odd behaviors.

So ideally this weekend I'll make the compiled Sleep code traversable with a visitor object, fix my one last little bug, finish my dunamis bridge, and post a jIRCii update as well.

Tall order but definitely doable. Then of course I have to continue working on the Sleep 2.1 Manual. (: Sheesh, so much work to do yet.
Mar. 30th, 2007 @ 12:45 am Working with Dynamic Delegation
About this Entry
After spending hours writing that little Java 2D Sleep snippet, I was thinking to myself "self, there has to be a better way". Then I hit google and found other Java scripting lang devs had the clever idea long to implement subclassing by dynamically generating class files with the minimum amount of byte code to call back into their interpreter.

This idea appealed to me. The thought of embedding a 500kb byte code tweaking framework does not appeal to me, but whatever.

So the journey started with "Discover New Dimensions of Scripted Java", an article by David Weiss from 2003. http://www.javaworld.com/javaworld/jw-10-2003/jw-1003-beanshell.html

I decided I would investigate some of the byte code / classfile tweaking libraries out there and see what is what. First off, I have to ask, what is up with all of these fancy build processes people require now a days? Is it too much to ask to be able to download a .tgz file and type ant once the files are extracted? People want me to use maven or build extra ant utilities before I can compile their stuff. Really annoying. Also why can't folks generate one or two jar files, what is up with this multitude of functionality options?

Oh well, whatever.

So anyways I looked at Serp, Objectweb ASM, and BCEL. Objectweb ASM is the most appealing to me at the moment due to the fact the runtime for it is ~33KB. Size is important to me, especially if I am going to distribute their stuff with Sleep.

One really nice feature of BCEL and Objectweb ASM is the ability to load a Java class file against their tools and have Java code generated that shows how to generate the same class file with their libraries. I found this to be really useful.

With that said I eventually got kind of bored of it and decided to back off. Then I found Dunamis: https://dunamis.dev.java.net/

Dunamis is pretty cool. It works like the java.lang.reflect.Proxy class except it lets you specify a sort of invocation handler class with methods to trap and stop an invocation before it happens. If you allow it there are also methods for after and for when an exception is thrown. Kind of useful I suppose.

Whats more interesting seems to be the approach. You specify a Java object and it creates a class file implementing the same methods/interfaces of this class file except the body of each is set to go to the invoker interface first and foremost. A reference to the original object is kept on hand for calling into its methods if need be.

Not a bad approach and not too complicated.

I'm working on a Sleep bridge right now based on dunamis. I plan to play with it and release it on the Sleep homepage. If it turns out to be a technology I (or others) can't live without, then I may consider writing this type of functionality with ObjectWeb ASM and including it in Sleep's core. Dunamis uses BCEL and the two together create a runtime that is ~500KB. Not really going to fly for inclusion into the core Sleep library.

In the meantime, if you're curious as to what I'm planning to do, it is *really* simple:

$component = [new java.awt.Component];
$delegate = delegate($component);
intercept($delegate, "paint", { ... some closure to handle painting ops here ... });

Thats pretty much it. I plan to have access to the original delegated object through $super (maybe $self would be more appropriate). So one could do [$super paint: $1]; if they so desired.

I'd have to look at how well abstract classes and such are handled but I don't think it'll be a problem.

So anyways that is something I'm looking at right now.