JSMeta on Android

We were at Old Chicago last night with friends and one of them had an Android phone, so I asked him to try out JSMeta, and he did. It didn't quite work properly, so I set up LiveAndroid 0.2 in a VM today to see for myself...

See the screenshot below. :) Something's not right... but it's more functional than I expected. Perhaps there's a JS engine bug I could report to Google...

LiveAndroid 0.2 network eth0 in VMWare Workstation

To enable LiveAndroid 0.2 networking in VMWare Workstation 6.5:

  1. Boot the LiveAndroid VM

  2. Hit Alt-F1 to switch to the root console.

  3. mkdir /data/misc/dhcp

  4. Stop the VM, and "Close" the VM in VMWare Workstation (or Exit VMWare Workstation)

  5. Edit your VM's .vmx file so the "ethernet0.virtualDev" line reads: ethernet0.virtualDev = "vlance"

  6. Open the .vmx file (launch the VM in VMWare)

  7. Set the VM to have at least 384MB RAM

  8. Start the VM; you're networked.


new JSMeta revision - 0.3 or something?

Sorry, I was distracted from JSMeta by the .NET world for a week while I ported JSMeta to C#/Silverlight as an experiment slash proof-of-concept, which was more than sufficiently successful, btw.

Now MGraph projections are recognized, but they don't do anything yet. :) Toggleable XAML and M code output to be added tomorrow.

syntax Main
= something:any+ => id(something)[or => valuesof(other)];

Here's the full change/commitlog:

- added MGraph (projections) recognition (but they're still noops, just like the
variable/symbol assignments/bindings)
- lots of performance/responsiveness improvements, such as canceling the current
parse attempt if another key is pressed in the input or grammar window (kinda
difficult in single-threaded, async-emulated JS), and added lots of "fastfail"
error() combinators in the DynamicParser generator.
- fixed bug with required-interleave accepting only one interleave character
- added new shortcut combinators UseFirst & UseSecond
- added smarter error location reporting for the die/error combinators
- added some more parser tests as a result of working on JSMetaSheet (online
spreadsheet workalike, don't try it though, yet. Goals: minimal computation,
maximally responsive UI.) :) The columns resize and cells edit/navigate
generally as expected, but formulas don't evaluate at the moment in most
browsers. :) Yes, as usual I spent way too long on the details of the UI.
Please, no one let me do UI development; I'm sorta (comparatively) slow at it.
- fixed an off-by-one error (wait, TWO off-by-one errors; ha) in the left-
recursion handling (finally discovered after an all-day debugging/diagnosis
session while working on JSMetaSheet. That kinda burned me out for a few
days... As someone commented, "that's part of the price of doing meta-meta-


JavaScripty C#, Part 1 of Some

I've spent the last week porting JSMeta and JSMetaPad to C# 3.0 on Silverlight 2.0. My approach to this has been the same as that of all my implementation designs lately: direct. To port JSMeta to C#, I literally copied and pasted the JavaScript code into Visual Studio 2010 beta 1 and set to work creating abstractions in C# to support the JavaScriptisms in JSMeta. Luckily, there weren't actually very many.

Lambda Expressions, Deeply

It took me a few days to realize I was actually creating a runtime that would support JavaScript's language features. I implemented JavaScript's scope [chain] as a Dictionary, accessed through a couple of layers of wrapper objects through indexer getters. It ends up being an invisibly-inherited "expando object", with members accessed by name. Those indexer getters treat their results differently depending on their type (whether they match one of several particular delegate type signatures).

I overloaded the indexer by arity: public Activation this [ string memberName, object [] ] { get {...} } , which allows the runtime "code" (actually lambda expressions; no strings/eval/CodeDom involved; pun intended) generator to "call" or "apply" the scope's member by passing in an array of arguments, if necessary.

Here's some code from the Context class demonstrating the mechanics... Sorry I'm not posting all of the code yet; I will at some point soon (this week).


More explanation later...