Prev: tcl/tk wish for seismic data display
Next: file unsplit?
From: dave.joubert on 15 Sep 2009 09:19
On Sep 15, 2:17 pm, "dave.joub...(a)googlemail.com"
<dave.joub...(a)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....

From: tom.rmadilo on 15 Sep 2009 10:34
On Sep 15, 6:19 am, "dave.joub...(a)googlemail.com"
<dave.joub...(a)googlemail.com> wrote:
> On Sep 15, 2:17 pm, "dave.joub...(a)googlemail.com"
>
> <dave.joub...(a)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.
From: David N. Welton on 15 Sep 2009 18:03
> > 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?
>
> 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.
From: Iain B. Findleton on 22 Sep 2009 19:52
On Sep 15, 6:03 pm, "David N. Welton" <davidnwel...(a)gmail.com> wrote:
> > > 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?
>
> > 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.

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.
From: dave.joubert on 23 Sep 2009 05:24
On Sep 23, 12:52 am, "Iain B. Findleton" <ifindle...(a)videotron.ca>
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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: tcl/tk wish for seismic data display
Next: file unsplit?