Prev: tcl/tk wish for seismic data display
Next: file unsplit?
From: John Seal on 10 Sep 2009 13:41
"David N. Welton" <davidnwelton(a)gmail.com> wrote in message
news:7a912c85-ee89-4ccb-b669-0a6d51fa8aea(a)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?


From: David N. Welton on 10 Sep 2009 15:00
On Sep 10, 7:41 pm, "John Seal" <john_j_s...(a)raytheon.com> wrote:
> "David N. Welton" <davidnwel...(a)gmail.com> wrote in messagenews:7a912c85-ee89-4ccb-b669-0a6d51fa8aea(a)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.
From: Gerry Snyder on 11 Sep 2009 10:37
David N. Welton wrote:
> ....
>
> 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
From: dave.joubert on 11 Sep 2009 12:18

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

From: tom.rmadilo on 11 Sep 2009 17:30
On Sep 11, 9:18 am, "dave.joub...(a)googlemail.com"
<dave.joub...(a)googlemail.com> wrote:
> 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 ?

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?



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: tcl/tk wish for seismic data display
Next: file unsplit?