Lisp Interpreter in JavaScript

After checking out this JavaScript file, and another similar approaches, I found out that this is not exactly what I was looking for. Here's what I have in mind, for a virtual machine on the client-side:

• I need it to run code specifically designed to it. (Right now, anything must do, but I need it to be able to translate it to valid client actions - aka, use something like JavaScript, DOM, CSS, etc, etc.
• I need it to be modified from the server (i.e., to upload code changes)
• I need to have some sort of support for a set of language constructs and basic types, including continuations. So I probably need to serialize everything.
• I need to consider the drawbacks of maintaining all of the variables in the continuation's environment. One simple closure may be small, but the full environment - needed to make good use of dynamic variables - can become quite large. Note that some tests are in order to make this assert valid!

The downside of the Lisp Interpreter I checked is that everything is automatically translated to a Javascript object. That's not what I need, since I need the code to be able to travel back into the server. I only need it to be evaluated on JavaScript. (This also means I can use a portion of this code, like the tokenizer and/or parser!)



More to come...

The Law of Notepad

Taken from Continuing Intermittent Incoherency blog:

The Law of Notepad: if creative people can’t make something awesome using the lamest of production tools, your platform is gonna loose.

OpenAjax Hub

Here is a quote from Coach's blog, related to the main challanges that OpenAjax is trying to address to get interoperability:



coachwei.com :: OpenAjax Update - Addressing Key Challenges for Ajax Adoption :

• # Toolkit “loading and unloading”(the capability to load and unload more than one Ajax toolkits into one page): For example, right now a lot of toolkits overload the “onload” function, which will certainly cause collision with another toolkit;
  
  
• # Name collision (the capability to deal with variable and function name collision). For example, quite a few Ajax toolkits today use “$” as a function name. When they are all loaded onto the same page, what happens?
  
  
• # Event Hub (The capability to have interaction between different Ajax toolkits). The key requirement here is to enable some kind of “event” propagation so that an event generated from toolkit A can be processed by toolkit B. An example is that the user drags an item from Toolkit A and drops it on Toolkit B – how should this two toolkits communicate the information related to this event? The proper solution is to provide a common event hub that each Ajax toolkit can publish and subscribe events. Initially, we do not have to define the details of different event objects, which can be defined in the future.
  
  
• # Markup scanning (the capability for an Ajax toolkit to scan an HTML document to pick up the interested markup segments for processing): many Ajax toolkits allow the usage of markup to define components within an HTML page but they all have their own mechanism of scanning the document. If more than one toolkit is loaded, the HTML document maybe scanned multiple times with the danger of causing significant inefficiency and collision. Providing a common mechanism to scan an HTML document would solve this problem.
  
  
• # Network Hub (server connectivity management): most browsers allow only limited number of connections to the server (for example, Internet Explorer allows only two). If each Ajax toolkit uses its own mechanism to handle server connectivity, it is highly likely collision will happen if more than one Ajax toolkits are loaded on the same page. A proper solution is to provide a common mechanism that centrally manages server connectivity and serves all registered toolkits.;

Apart from this list, they point out other missing factors, but that shall not be addressed by OpenAJAX. They are performance issues, the multiple toolkit bloating problem, whether there are security issues with AJAX, and if so, how do they die. Other interesting problems arise with mobility and offline execution of AJAX-based code, as well as with application development and maintenance.



These last two are particularly interesting to my work. The mentioned post talks about a blog with mobility issues: SitePen Blog » mobile.

HTTP is dead. All hail Web Messaging Protocols!

It has become very clear that HTTP doesn't serve current Web needs and purposes. So why does it remains the sole winner of the communication protocol in the Web? This is simple, really. Every browser knows how to speak HTTP, and since it's a pretty simple protocol, nobody seems eager to move a multitude of users into a paradigm shift.



The tough question is related to the solution, instead of being centered on the problem space. Where do we go from HTTP? What do we need? Most aplpications today are struggling to find a proper way to communicate with the server. Comet strategies provide bi-directional messaging between a client and a server. Internet Messaging Bus goes a step further, granting the following properties to the communication protocol:

• Guaranteed message delivery
• Guaranteed order of delivery
• Once and only once delivery
• Both client pull and server push data fetching models.
  
  

This seems to be the end of the AJAX hype, as it is know. That is, the XMLHttpRequest, by itself, doesn't grant all those nice things to any WebApp. However, the word seems to be catchy, and people seem to want to stick with it for a bit longer, and the current bet is a messaging protocol.



See:

• XmlHttpRequest BAD - Messaging GOOD - Greg's blog
• Comet: Low Latency Data for the Browser
• Web 2.0 Communication Layer: from HTTP to Comet to Internet Mess
• coachwei.com :: Web 2.0 Communication Layer: from HTTP to Comet to Internet Messaging Bus
• OpenAjax Alliance White Paper

Process execution mode swapping

Another aspect that is relevant for my PhD is the exchange of information between the client(s) and the server(s). To make a pictorical description, imagine a situation where a client walks into a web application, which is running entirely on the server. The server then sends some of the computations to be executed on the client, e.g., for performance reasons. After a while, the client may take too long to execute a certain computation and transfers it, along with the already processed information, back to the server.



This situation can be compared to the Java Bytecode execution done by the Just In time compiler. The VM starts by interpreting code, then after a few iterations, it boosts up the compiler and the code that was being called is now fetched from a compiled source.



What I mean to inspect is if I can take some of these ideas and port them into a Web architecture.



In SISC - Documentation, we can see that the Scheme interpreter can also run byte-compiled Java code. I must now find out how does it swap the execution context between those two modes, and what considerations are being done.

Interpreters in JavaScript

Before discussing Termite (it deserves a post for itself), I'll post a series of links to attempts to write language interpreters in JavaScript.



First, the motivation: As I need to create a framework to build web applications with certain characteristics built-in the client-server communication infrastructure, I need to do constant experimentations with the client capabilities. Considering that the majority of clients are able to run a javascript interpreter within the browser, it seems to be the best bet, for compatibility sakes.



A list of links to different approaches follows. For some pages, The only interesting reading material is on the Javascript that is embbeded in the source html code, so you have to dig into that.

• Interactive Scheme (see http://fresh.homeunix.net/~luke/jscm/scm.js.txt)
  
  
• Lisp Interpreter in JavaScript
  
  
• A Brainfuck interpreter in JavaScript
• The Little JavaScripter and the Little Scheme
• Joe Ganley's Lisp in JavaScript
  
  

Conclusions on whether this will or will not be usefull may come up on future posts!

A Common Lisp Post

This is my first post sent via my Common Lisp Atom interface. It uses the JLinker to call the Java Google client API methods.

Termite - concurrent and parallel programming in Lisp

This is a simple tutorial for Termite, made by its author:



Bill Clementson's Blog: Update on Termite (A Lisp for Concurrent/Parallel Programming)





After reading the paper on it I'll make a proper review, but I like the side remark on a file upload procedure definition:

this program has about the same number of lines of code as a minimal "hello world" program in Java.

Google Web Toolkit experiences

I just started toying arround with GWT (Google Web Toolkit). Here's my thoughts so far:

• [GOOD THING] It makes the building and running on the development environment simple. It doesn't offer the flexibility of a running interpreter, but it provides two commands (scripts), one for compiling and another for running a box (development shell) that is an application container (tomcat based) with a small browser for a quick test.
• [GOOD THING] An application has to import only a couple of jar's to run
• [BAD THING] We have the old Template Model problem. We have two source folder structures, one "client" with the java files, and a "public" with the html templates, images, CSS, and other files to be published directly. The HTML templates should contain id's called "slot1", "slot2", and so on, for each object that is placed with Java to be attached to a certain place in the template... Is this horrible or what? The good thing is that google also lets us do (almost) everything without a template, creating defaults!
• [BAD THING] I just noticed something weird in the demo application, the KitchenSink. a page with a floating dialog box, that warns with the following:

"If you're wondering why there's a list box at the bottom, it's to demonstrate that you can drag the dialog box over it. This is noteworthy because some browsers render lists and combos in a funky way that, if GWT didn't do some magic for you, would normally cause the dialog box to appear to hover underneath the list box. Fortunately, you don't have to worry about it -- just use the GWT DialogBox class." Now this is (1) weird, as it seems we're still dealing with black-magic in order for things to appear right on the screen, and (2) wrong, as the google shell browser still shows the listbox over the dialog box, if we drag it towards the right (oddly enough, a left drag runs ok...)

powered by performancing firefox

After having some meetings about the future of my ...

After having some meetings about the future of my research in the ESW group (at INESC-ID), I've set a few goals to my PhD. I'm now a part of a project that will integrate a workflow management system into a Web Application development methodology. My contribution is centered on the following RIA features:

• Easy rich content development on a web application
• Disconnected browsing, used to enable specific parts of the workflow to be worked on without requiring a permanent Internet link.

The second point is my main goal, as the first is being more and more common every day (do a google search for 'AJAX' and check it out!). To achieve disconnected browsing, one of the biggest challanges is to find out what is going to be the persistency model - given that the information is always shared and interacted with between two possibly remote machines.

Some questions to be answered:

• What is the minimum ammount of information needed in the client for it to be able to execute operations offline?
• What are the security issued underlying such an information sharing?
• How can workflow activities be moduled so that they can be run isolated from the rest?
  

Here is a summary of the activities I fullfilled i...

Here is a summary of the activities I fullfilled in my PhD, during this year:

• Curricular Courses: I have completed the curricular component of my PhD, with the following courses:
• • Formal Software Development: Based on the B-Method, this course was about the development methodologies with the help of formal specifications;
  • Advanced Topics: I studied the Desktop applications interfaces development tools, their types and characteristics. I also read Jenifer Tidwell's "Designing Interfaces" book.
• Research:
• • I made a study on remote desktop interactions, where I calculated the required ammount of network bandwidth to enable common user interactions to be executed in remote applications, such as mouse moves and clicks, or key presses. The conclusions were satisfatory, as today it is possible to enable complex interactions over the web, even if they are mapped as a set of basic - and non-optimized - operations.
  • I analised several tools that help the development of Rich Internet Applications (or RIAs).

AJAX and Accessibility - Standards-schmandards

I read an article from March the 1st of this year, on AJAX and usability. It's a nice, simple, straight article, easy readable.It also has a few references to other articles explaining blogs (as well as a long comment list!). Here's the main points of the author on usability: "Improving accessibility of AJAX forms Fortunately there are some things we can do to increase accessbility of AJAX forms. Here are my recommendations: 1. Inform the user at the top of the form that it requires javascript or detect javascript automatically and warn the user when it isn't available. If the form has many fields you will spare your users a lot of frustration. Everyone hates filling out a form just to find out that they can't submit it. 2. Inform the user that the page is updated dynamically. This is especially important for screen reader users and will help them decide when to trigger a re-read of the page. 3. Make it possible to recieve an alert when information was updated. This may not be practically possible depending on the complexity of your form but will help a screen reader user a lot. Alert boxes are read by the screen reader and are usually displayed together with a sound. The checkbox should be displayed so it is clear that it is not part of the original form. 4. Highlight recently updated areas for a short period of time. This will help sighted users understand what just happened. The nice folks over at 37signals have dubbed this 'The Yellow Fade Technique' but you can use any colour you like. Check out Adam Michela's code for another way of providing the fade."

Morfik - the Javascript synthetizer

I've recently found an interesting, promising work, another framework for Web Applications development. So what's different in this one?

Taking Morfik's CTO's words, ?Morfik has developed a unique JavaScript Synthesis Technology (?JST?) that allows developers to use a powerful integrated design environment together with a high-level language of their choice to create reliable applications comprised purely of HTML and JavaScript?.

Since the framework isn't open-source (so far, at least) all we can checkout is the two Flash demos on using the program to develop basic applications, and a few white papers and communications they release to the public. From these, I'm able to comment on both their mission and the program itself.

Morfik's main goal is to take jobs away for "rocket-scientists" who want to develop software for well-paying companies. So far, the so-called AJAX applications have been hard to implement, given both client and server's side complexity. Morfik allows these applications to be coded in a familiar language (one of several clones of popular languages like Pascal, Basic or C#), just like a common desktop application. This code will be trans-compiled into a server side application and a set of HTML and JavaScript files to be loaded in the client's browser. Hence, no web application or AJAX knowledge would be necessary.

From the demonstrations, I've spotted that the greatest feature of Morfik it's its familiarity with common Microsoft applications to develop the application. For example, a specific Morfik component is used to setup the domain tier, using an interface almost 100% identical to Microsoft Access'. Similarly, the web pages are designed using a WYSIWYG program, just like Visual Studio's interface builder. So any application used to the Microsoft's tools should be fairly suited to use Morfik without a two year-long course!

How does this Morfik advent leaves me? Well, I was planning to do something similar for my PhD, so now I must find out exactly what they plan to do, so my work won't clash with theirs. For instance, I'd like to know how do they split the computations between the client and the server - I'd like to give some adaptability to the server.

To add up, Morfik have a pioneers program, but they haven't released any usable version of the program for us to test it (not even demo-ware...). I'll just wait for further news on their site: http://www.morfik.com/

New directions, new homepage

I've just reviewed my homepages, and it took me a while to get them
presentable... So here's my status, online-wise:

- I have http://360.yahoo.com/edy_in_carpathia - this is my personal website,
with access to photo albums, preferences and other non-interesting stuff :)
- My work homepage is http://edgargoncalves.no-ip.org - it has a set of projects I'm working on, and my professional information (like my resume)
- This site (last, but not least) will be my communication point, unless Yahoo releases a great API to post messages to it's blog. So, for now on, my PhD discoveries, researches and interesting notes will be posted here, for the world to see. Ocasionally one or other photo will invade this space, but I promise I won't have the motivation to do so (nor the time!)

So, on my next post, I promise to write about remote interfaces, my last research subject for the past weeks.

Ta-ta...

The Vitruvian Man. Leonardo's most perfect piece, imho. This is also to tell that this blog isn't dead. In fact, it's sibling MSN Space has recently entered in a inevitable coma... But bear in mind that I have my own tech blog at www.esw.inesc-id.pt/~eemg/ - so this blog will be ONLY for personal/relevant photos and thoughts. why? because I have Hello. and because It grants me unlimited picture storage and a nice interface! :) So sit back, and enjoy the show...
Posted by Hello

Emacs, Gnus and BBDB

Big day - I now have my BBDB decide where to send a mail from one of my contacts, either personal or mailling lists! My arch repository was updated accordingly (mail me if you want to know where it is).

BBDB exporting

Alex Schroeder: Comments on 2005-02-22 Software: "Comments on 2005-02-22 Software"

mozdev.org - webmail

Now THIS is handy! Finally, both Hotmail and Yahoo mails being delivered via a pop server, for free! The caveat is that the plugin only works via thunderbird - I wonder how much longer do we have to wait until a Gnus version is made? Download it now from mozdev.org - webmail: "mozdev.org"

ZipGenius: free zip unzip utility

I found a good tool: ZipGenius: free zip unzip utility. File compression is finally easy and free, with no adware, no spyware, no ads, no money. ZipGenius is free and handles many archive formats: zip, rar, arc, ace, arj, cab, tar, 7-zip, zoo, tar.gz, gz, z, bz2, iso, nrg.: "If you need a compression utility, your search ends here: now you can count on ZipGenius and you it won't cost a dime to you, just because here you can find just FREEWARE programs."

trying the current version of weblogger. if this blog entry has a title, I'll settle with it. :)