LC for Raspberry Pi

[Richard Gaskin]

In another thread  Mark Rauterkus wrote:

 > The other HUGE area where I think LiveCode could shine is with the
 > Raspberry Pi community. But, sadly, the mothership is not putting
 > support there for confidence to take root, IMHO. So, that remains
 > only a dream. An annual release for Pi would be most welcomed.

I agree, an RPi update would be great.  But I'm not sure this needs to 
be a company effort, and to be honest we've seen only a few in our 
community actually interested in participating to maintain it.

But we do have some, and the team made some updates to the Github repo 
to help that along.

I set up a thread for this project in the forums:
http://forums.livecode.com/viewtopic.php?f=76&t=27912

At this point we're down to just a few specific questions we need some 
guidance on, and I've seen a note on the LC Gitter feed from someone who 
successfully made an RPi build from the 8.1.3 code base, so we know it's 
possible.

Let me take a moment to outline near-term and long-term goals for the 
Raspberry Pi project, and encourage anyone here interested in helping to 
move this forward to jump into the forums at the link above.

Near-Term
---------
The last RPi build was v7.0.4, which is generally good with one critical 
issue:  a bug in the menu handling routine causes a crash when clicking 
in a menubar.

This currently prevents the IDE from being run on the RPi itself, which 
of course we'll want to see for EDU adoption (with some caveats noted 
below in "Long-Term").

But for any GUI that doesn't use menus that doesn't stop RPi from being 
a deployment platform.  Check out the 7-pages-and-growing thread by -hh 
chock full o' stacks designed specifically for the RPi:
<http://forums.livecode.com/viewtopic.php?f=76&t=19248>

It also doesn't prevent what is to me the most interesting use of RPi: 
IoT.  Such devices will not usually need a UI of their own, and LC 
Server v7.0.4 runs great on RPi, as do standalones run facelessely with -ui.

With GUI control of the device handled from a desktop app or a mobile 
app on your Android or iOS device, the range of interesting things that 
can be done with LC on RPi are vast, even with the limitations of the 
v7.0.4 engine.

Once we get the build process set up for 8.x and 9.x, we should be in 
very good shape to handle any remaining issue (though I suspect with all 
the good work done for the Linux engine since v7 we may find the menu 
issue has already been resolved).


Long-Term
---------
RPi is great.  And RPi also sucks.  :)

It's great because it's small and cheap.  And it sucks for the same 
reasons:  little RAM, and very slow.

In fact, while I do keep an SD card loaded with a GUI OS just for 
playing around, I find any GUI on RPi (including the bundled browser and 
even the desktop manager) to abysmally slow to be satisfying.

So for me, if I had to deliver a GUI for RPi I'd much rather use a 
workflow similar to what we do with mobile:  develop on a fully-spec'd 
desktop machine, and deploy to the device.

And as long as that's what you're doing, LC is a great experience.

But then we consider classrooms in which the RPi is the only device the 
kids work with.  There, developing on a full-featured desktop machine 
won't be an option.

The LC IDE is a rich system, but requires a lot of RAM and a rather huge 
amount of disk space (> 1 GB in recent versions).

These resource requirements cause LC to strain the RPi, esp. RAM but 
also CPU (instruction sets matter; 1.2 GHz on x86 doesn't necessarily 
equate to the same clockspeed on ARM, though compiler options may be 
able to help with some of that).

So even when we update LC's RPi engine to v9, it'll run robustly but 
slowly.  Painfully slowly.

So at some point, if there's enough interest in using an LC-based IDE 
directly on the RPi, we may want to consider making a lightweight IDE 
for that.

That might seem daunting, and it's certainly not a trivial task.  But 
the MC IDE reminds us that it's doable.

Given that the MC IDE is available under MIT license, it may be a 
tempting starting point.

But it's quite old; it doesn't support many newer features the engine 
provides, and uses a very different means of building standalones 
(indeed I doubt MC's standalone builder even works at all in newer 
versions).

Perhaps the best path would be a fresh start, taking advantage of newer 
language features and a better understanding of workflow needs to create 
a fresh approach designed specifically for low-end systems.

And maybe it doesn't need to include a standalone builder, at least not 
at first.  A runner app that plays stacks would be more than fine for 
EDU settings.

In fact, in some ways it might even be better. One of my back-burner 
projects is an EDU-focused toolkit that, among other things, has network 
stack-sharing built in.

Imagine a world of students using any computer, all sharing stacks 
easily with one another....

The runner could be built now.  That part's relatively easy.

Harder is on-device authoring.  The current IDE is unlikely to be 
satisfying given resource constraints, so any widespread adoption will 
benefit from a lightweight IDE.

If that sounds daunting, it isn't.  More tedious than difficult.  And if 
well-factored at the core, any one of us can work on just one corner of 
it, and the parts can interoperate gracefully.

If the Linux world can churn out any number of entire desktop 
environments for the OS, certainly we can craft an IDE or two for LiveCode.

-- 
  Richard Gaskin
  LiveCode Community Liaison
  richard at livecode.org