Tcl on Google Android phones
dave.j...@googlemail.com
, and Tcl is unfortunately not on there. Is there any 'official'
project aimed at Tcl on Android ?
Dave Joubert
bs
<dave.joub...@googlemail.com> wrote:
> I recently saw an Android scripting website,http://code.google.com/p/android-scripting/
> , and Tcl is unfortunately not on there. Is there any 'official'
> project aimed at Tcl on Android ?
>
> Dave Joubert
I would love to see Tcl on Android. If only I had the time :(
I know it's not a direct answer to your question, but there is the
Hecl project, which is an implementation of a Tcl-like scripting
language written in Java, and is geared towards mobile phones. It is
spearheaded by David Welton, who has a lot of Tcl history.
I'd still like to see Tcl ported to Android though!
dave.j...@googlemail.com
>
> http://www.hecl.org
>
> I'd still like to see Tcl ported to Android though!
I have seen Hecl before, and again recently.
There are certain things I did not like:
1) Hecl is not Tcl, nor does it claim to be.
Specifically, it does not have vwait , expr etc etc.
2) It does not seem to be a standalone interpreter. The website for
example says:
java -jar ./hecl/jars/AndroidBuilder.jar -android /opt/android-sdk_m5-
rc15_linux-x86/ -class Hello -label Hello -package hello.world -script
hello.hcl
and to run the app on the emulator
/opt/android-sdk_m5-rc15_linux-x86/tools/adb install Hello.apk
I suppose what I am looking for in the long run is the equivalent of
tclkit which runs on Android; if such an animal was available, I would
be quite happy to pay for it via the Android marketplace. I would even
be happy to pay twice to be able to run it on the emulator and the
phone.
Dave
terryowen
<dave.joub...@googlemail.com> wrote:
> I recently saw an Android scripting website,http://code.google.com/p/android-scripting/
> , and Tcl is unfortunately not on there. Is there any 'official'
> project aimed at Tcl on Android ?
>
> Dave Joubert
I added a request in the ASE issue tracker a while back for TCL but
the last time I was there it hadn't been accepted or assigned.
Back in January, there was an Evolane announcement that they had
compiled eTcl for Android's specific ARM architecture but I downloaded
the archive file and wasn't quite sure what to do with it... I have a
rooted phone (CM rom 4.1.5) but am still somewhat clueless about
native Linux apps. There are things you can do in certain terminals
and not others and I can't seem to make the etcl files executable.
Terry
David N. Welton
<dave.joub...@googlemail.com> wrote:
> >http://www.hecl.org
>
> > I'd still like to see Tcl ported to Android though!
>
> I have seen Hecl before, and again recently.
>
> There are certain things I did not like:
>
> 1) Hecl is not Tcl, nor does it claim to be.
Right. Tcl is too big to run in older J2ME environments, and I don't
think that Jacl would run even in modern ones because it uses too much
of Java, and J2ME is quite limited. It might be possible to port it
to Android, though.
It's also about the freedom to tinker with something. That makes it
much more fun for me. Also, not mentioning Tcl is a good way of
avoiding the stigma associated with the language.
> Specifically, it does not have vwait , expr etc etc.
It has a similar mechanism to vwait.
It doesn't have expr because it's a big ugly parser in an environment
that was designed to be small.
> 2) It does not seem to be a standalone interpreter. The website for
> example says:
> java -jar ./hecl/jars/AndroidBuilder.jar -android /opt/android-sdk_m5-
> rc15_linux-x86/ -class Hello -label Hello -package hello.world -script
> hello.hcl
That packages up your script into an application.
> and to run the app on the emulator
> /opt/android-sdk_m5-rc15_linux-x86/tools/adb install Hello.apk
Yep, you have to install it. Just like anything else.
> I suppose what I am looking for in the long run is the equivalent of
> tclkit which runs on Android; if such an animal was available, I would
> be quite happy to pay for it via the Android marketplace. I would even
> be happy to pay twice to be able to run it on the emulator and the
> phone.
I'm not sure what you mean, but the files that are generated by the
above commands are standalone applications. Are you looking for
something that can share scripts?
Hecl, like Tcl, is free software. You can "pay" for it by
contributing to it, something that is very welcome, and, I think, fun,
because there's more room to hack the language than there ever will be
on anything but a complete fork of Tcl.
John Seal
news:7a912c85-ee89-4ccb...@q7g2000yqi.googlegroups.com...
> Also, not mentioning Tcl is a good way of
> avoiding the stigma associated with the language.
Ouch!
I played with Hecl a while back (last year?) and got a lot of things
working, but I'm on OS X and certain parts of Hecl seem to assume you're on
Linux. Anyway, I liked what I saw, and I like recent developments I've seen
on the Hecl mailing list. Maybe it's time to take a second look? Is anyone
else developing with Hecl on OS X?
David N. Welton
> "David N. Welton" <davidnwel...@gmail.com> wrote in messagenews:7a912c85-ee89-4ccb...@q7g2000yqi.googlegroups.com...
>
> > Also, not mentioning Tcl is a good way of
> > avoiding the stigma associated with the language.
>
> Ouch!
I figure that anyone familiar with Tcl will see the resemblance and
hopefully be happy with what they see and only mildly annoyed that
it's not really Tcl. Other people, I hope, will judge it on its
merits rather than that "their friend talked to this other guy on IRC
who said that he used it 10 years ago and, like it sucks and stuff".
> I played with Hecl a while back (last year?) and got a lot of things
> working, but I'm on OS X and certain parts of Hecl seem to assume you're on
> Linux. Anyway, I liked what I saw, and I like recent developments I've seen
> on the Hecl mailing list. Maybe it's time to take a second look? Is anyone
> else developing with Hecl on OS X?
Be sure to post any problems; preferably to the mailing list (which
will actually soon be a Google Group), but an email to me is better
than nothing. It bugs me if stuff is broken, but I won't fix what I
don't know is broken!
Speaking of which, I have a sponsor who is paying for a lot of work to
make Hecl nice on Blackberry devices. Right now it's in the "do lots
of stuff" phase, which will be followed by the "put it in order and
document it and make it nice" phase.
Gerard Sookahet
Hello,
There is a tiny command line interpreter.
- Download and install Hecl.jar and Hecl.jad at:
- Download and install Commandline.jar and Commandline.jad at:
http://lauri.ojansivu.googlepages.com/heclcommandlineapp
HTH,
GS
Gerry Snyder
> ....
>
> Speaking of which, I have a sponsor who is paying for a lot of work to
> make Hecl nice on Blackberry devices. Right now it's in the "do lots
> of stuff" phase, which will be followed by the "put it in order and
> document it and make it nice" phase.
David,
Thanks for the update. I had seen your earlier statement about an
official port to BB, and was very interested, having just become a BB
Tour owner.
Any predicts on when things might be in shape for public trial?
Keep us posted.
Gerry
dave.j...@googlemail.com
Several people have said that Tcl will be too big to run on an Android
handset, although I have not seen any hard figures along the lines of
'The Jacl executable is 200 MB big, and Android has a executable
restriction of 32MB'.
Having been told in my youth that infinite bandwidth is a good
substitute for infinite memory or CPU cycles, would the following be
feasible:
Write a small component in Java that runs on the handset (more detail
below)
Launch a 'almost standard' Tcl shell on a server, that:
1) Connects Stdin , Stdout and Stderr to sockets
2) breaks the filesystem IO into 2 pieces, one piece that reads and
writes to file storage on the server, and another piece that reads and
writes the user's files via a socket based mechanism.
The Java component on the handset then minimises to code that has to
handle the sockets:
connect the keyboard to socket 1
connect socket 2 to the screen
read socket 3 for filesystem requests
send filesystem results back along socket 4
I can see several benefits to such a distributed plan9 type approach,
including being able to fully distribute one's data; for example your
email can stay on a POP3/IMAP server. Another benefit would be that
the libraries stay on the server, making everything much more
maintainable.
This should also be buildable / testable using pure Tcl and components
such as Tcl's VFS
This seems so doable. Has anyone already done it ?
Dave Joubert
tom.rmadilo
32Megs is pretty big, unless that if for all executables combined. My
tclsh usually takes up about 11Megs.
The android scripting "interface" is very simple: it uses a json-rpc
proxy to the scripting executable. (At least this is what I have
figured out so far. The Tcl API would need to make JSON-RPC calls to
the Android API.
This caused me to look into JSON on Tcl. There is a module in tcllib
which can parse a json text, but it looks like it isn't too good at
serializing back to json. It also requires Tcl > 8.5 because of the
use of dict.
Unfortunately, the use of dict may be part of the serialization
problem.
Anyway, I decided to write a new parser which solves these issues and
so far it seems to work.
Anyone have more info on getting Tcl working with android scripting?
dave.j...@googlemail.com
> On Sep 11, 9:18 am, "dave.joub...@googlemail.com"
> > handset, although I have not seen any hard figures along the lines of
> > 'The Jacl executable is 200 MB big, and Android has a executable
> > restriction of 32MB'.
>
> 32Megs is pretty big, unless that if for all executables combined. My
> tclsh usually takes up about 11Megs.
>
32MB was just a figure I sucked out of my thumb!! Not sure what the
actual figure is...
>
> Anyone have more info on getting Tcl working with android scripting?
No, but I will be setting up a Android toolchain on one my machines
over the weekend. My first experiment will be just to take the jar
files from Jacl and try to produce the required Android files.
Hopefully if it coughs and dies it will give me some useful info (such
as size limits).
As far as JSON is concerned, you only need dicts if you are doing
something complicated, like building a JSON structure incrementally
and then converting it to string just before sending it; JSON itself
is simple enough that one can just build/parse the strings directly.
http://www.json.org/example.html
http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal
Dave
tom.rmadilo
<dave.joub...@googlemail.com> wrote:
> On Sep 11, 10:30 pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
> > Anyone have more info on getting Tcl working with android scripting?
>
> No, but I will be setting up a Android toolchain on one my machines
> over the weekend. My first experiment will be just to take the jar
> files from Jacl and try to produce the required Android files.
> Hopefully if it coughs and dies it will give me some useful info (such
> as size limits).
>
I really can't imagine that it could be so low as to be unable to hold
10-15 megs, but a full tclkit might be too big (I've never looked at
the size). Hopefully you can run a reasonable sized app.
> As far as JSON is concerned, you only need dicts if you are doing
> something complicated, like building a JSON structure incrementally
> and then converting it to string just before sending it; JSON itself
> is simple enough that one can just build/parse the strings directly.
>
> http://www.json.org/example.html
> http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal
I'm probably going to use my TWiST API and just add a different reader
(for input) and printer to replace XML. I use tDOM's toList as input,
so I just have to remove the attributes feature.
I put up a JSON text to Tcl list converter for my own testing, if
anyone wants to see what the Tcl format looks like:
http://junom.com/json/json.tcl
It also prints out debugging info on a char-by-char basis.
The parser only performs structural validation as I plan on using
TWiST for more complete validation. What is missing is that any one
word literal value passes through the parser. I may tighten this up to
reject the literals 'object' and 'array', since I use those as
metadata.
Assuming I get this working, it would provide a Tcl only JSON-RPC
server.
David N. Welton
Hecl on BB does run, but it's still in a state of flux. I bought a BB
code signing key, and am working on multiple API's, so that Hecl will
be able to take advantage of all the platform has to offer. I'm
guessing in October, more or less, but the more people chip in (which
can be as much as saying "look, it's not building right in this
situation"), the faster that will be.
Pat Thoyts
Tcl 8.6 can be compiled for arm-eabi- using the Android NDK if you
tweak the makefile a little. Adding in the vfs package and this gives
enough to run a zip based starpack file. I imagine this means that
hooking it into the ASE stuff will not be too hard.
However, ASE doesn't provide much access to the Android device at the
moment. You can't create a GUI for instance. Hecl however lets you
hook into Android quite completely as it has access to the java
classes. You can create a GUI in Hecl and call up any other Java
provided objects too. Its also lighter weight than ASE at the
moment. The Hecl Android demo application is 1.68 MB which is the
runtime plus a live interpter and some demo scripts. The ASE runtime
is 6MB with the scripts on the sdcard separately. This might be
because I have Python rather than Lua.
--
Pat Thoyts http://www.patthoyts.tk/
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
dave.j...@googlemail.com
>
> Yep, you have to install it. Just like anything else.
>
> above commands are standalone applications. Are you looking for
> something that can share scripts?
>
One of the reasons I prefer Tcl is that there is no compile/install
phase, but given the fact that the Android marketplace relies on the
developer delivering an apk file (and Hecl does this), I might have to
change my mind.
My focus is on getting the project done, and the language is mostly a
secondary issue (expect that I dislike certain languages (Perl, C++)
and would rather abandon the project than use them).
Does Hecl on the Android deliver the full Android programming model ?
ie Intents, IntentFilter, contentProvider, Broadcast receivers, access
to SQLite etc etc ?
Because the Android environment would be difficult to implement in the
client/server model I looked at, I have decided to put this on hold. I
experimented with this and while it is very doable, one would miss out
on the Android specific features.
My focus is on getting the project done, and the language is mostly a
secondary issue (except that I dislike certain languages (Perl, C++)
and would rather abandon the project that use them).
Dave
dave.j...@googlemail.com
<dave.joub...@googlemail.com> wrote:
>
> My focus is on getting the project done, and the language is mostly a
> secondary issue (except that I dislike certain languages (Perl, C++)
> and would rather abandon the project that use them).
>
> Dave
Sorry about the repeat para; copy and paste trouble....
tom.rmadilo
<dave.joub...@googlemail.com> wrote:
> On Sep 15, 2:17 pm, "dave.joub...@googlemail.com"
>
> <dave.joub...@googlemail.com> wrote:
>
> > My focus is on getting the project done, and the language is mostly a
> > secondary issue (except that I dislike certain languages (Perl, C++)
> > and would rather abandon the project that use them).
> Sorry about the repeat para; copy and paste trouble....
Some things deserve repeating! This would make a good tagline,
although if you look at the sources for incrTcl, you might rethink the
C++ part.
David N. Welton
> > above commands are standalone applications. Are you looking for
> > something that can share scripts?
>
> One of the reasons I prefer Tcl is that there is no compile/install
> phase, but given the fact that the Android marketplace relies on the
> developer delivering an apk file (and Hecl does this), I might have to
> change my mind.
Yes, there is pretty much no way around that: you have to create the
apk files.
Included with Hecl is an AndroidBuilder.jar that tries to automate
that process to some degree, although it's definitely more than a bit
of a hack.
> My focus is on getting the project done, and the language is mostly a
> secondary issue (expect that I dislike certain languages (Perl, C++)
> and would rather abandon the project than use them).
>
> Does Hecl on the Android deliver the full Android programming model ?
> ie Intents, IntentFilter, contentProvider, Broadcast receivers, access
> to SQLite etc etc ?
The blunt answer is: no. The more nuanced answer is that when I sat
down and started work on the port, I realized that covering the whole
API was 1) not something I had time for, and 2) might make the
application a bit bloated in any case. So what I settled for was to
add Hecl commands to do reflection, so that it's possible to access
most API's you need. Of course, in Android, we have reflection, but
not code generation, so things like listeners, where you need to
subclass something in order to make it work, still need to be done 'by
hand'. There are a number of examples of how to do this in the
sources, though.
I'd be more than happy to work with you (as time permits) to address
any issues you run into, or make improvements in Hecl's Android port
that help you out (do join the mailing list if you choose to use it,
though).
I am really excited about Android as a platform - it's open source and
generally treats application developers very well.
Iain B. Findleton
You can get my Tcl/Fltk package and a Tk package compiled for arm-eabi
from the SF project by the same name. Have not tried it on Android,
but it may work.
dave.j...@googlemail.com
wrote:
>
> You can get my Tcl/Fltk package and a Tk package compiled for arm-eabi
> from the SF project by the same name. Have not tried it on Android,
> but it may work.
The sticking point now is what happens after one gets a dynamic
language like Tcl running on the Android platform, and the more I read
about the this the worse it gets.
When the Android app starts the system looks at the manifest file
(XML), and from that the system can work out what contracts the app
honours; services provided, events it wants etc etc.
At the moment I see no public way of doing this at runtime, only at
load time, and therefore ultimately at compile time. While I can
understand the reasons for doing this, it is not the way I like to
work on personal projects, esp while the project is in its organic
phase.
Dave
David N. Welton
> from the SF project by the same name. Have not tried it on Android,
> but it may work.
Android doesn't use X - it uses its own graphics system. Pretty much
the only way to get at it is to go through their Dalvik runtime.
res...@gmail.com
> 32Megs is pretty big, unless that if for all executables combined. My
> tclsh usually takes up about 11Megs.