To be, or not to be: that is the question.

[ed.zo...@gmail.com]

Hi !

Tcl - is not only a programming language. It's part of our life, of light and good part of it.

The status of some things depressing, bother, destroys.

1) The first and most important - lack tcl on android. This is collapse, this is total collapse.
2) The second - a great variety of good, decent but dead projects.
for example (off the top of my head):
- Hecl
- tkhtml
- tclplugin
- tkzinc
- etcl
- tkvideo
- ctk (curses tk)
...
and more hundreds of disappointments.

Something must be done.
We must not stand aside from these processes.

If the only problem in the financing, then my suggestion is the following:

We all (fans and connoisseurs of language) have to finance their own expense.

I am willing to pay every month for $ 30.

Us are hundreds or thousands, I think $ 30,000 to start - not a bad result.

We need to discuss this issue at a conference in 2013.

Now, we must start with the funding for the development of the beautiful, useful and necessary project - Hecl created by David Welton.

P.S.
Thank you for understanding

Good luck.
----------------------
With respect, Eduard.
phone: +38067 763 86 44
email: eduard_...@mail.ru
www: http://doro.poltava.ua
ICQ: 176017203
jabber: edo...@jabber.linux.it
skype: edoroe
ekiga: sip:edo...@ekiga.net

[peter....@gmail.com]

Hi Ed,

I can't agree more!

We need financing from the community. There needs to be an incentive to proceed.
I'm prepared to donate a serious project.

If we don't proceed this will kill the future of TCL/TK.

Such a great language it is!

TCL/TK needs to be present on mobile!
I don't care what it takes!

Kind regards,

Peter

[Harald Oehlmann]

I decided for our company to purchase TclDevKit and Komodo.
As ActiveState is supporting TCL, this felt supportive to me.

Harald

[Rob]

peter....@gmail.com wrote:

> Hi Ed,
>
> I can't agree more!
>
> We need financing from the community. There needs to be an incentive to
> proceed. I'm prepared to donate a serious project.
>
> If we don't proceed this will kill the future of TCL/TK.

Not be usable to create mobile apps will not, IMO, kill the Tcl language,
but it could seriously make it a less desirable language to learn and hinder
any chance for expansion of interest among developers to even consider it as
a useful tool. It is a great language and any chance to allow it to grow in
stature again should be welcomed.

I also would be interested to financially donate to serious project, but as
far as writing code for it - no C or Java would probably limit my technical
usefulness to such project.

The end product would ideally be able to create or make possible code for
both iOS and Android platforms and be expandable (via maybe a plug-in
architecture) to cope with other future mobile platforms. I think that are
similar projects using other scripting languages which can achieve this
goal. If that's correct, then the tcl/tk community should aim for the same
sort of outcome.

Could some of the very experienced people among us please comment!

Rob.

[Gerry Snyder]

On 9/18/2013 4:53 AM, Rob wrote:
> peter....@gmail.com wrote:
>
>> Hi Ed,
>>
>> I can't agree more!
>>
>> We need financing from the community. There needs to be an incentive to
>> proceed. I'm prepared to donate a serious project.
>>
>> If we don't proceed this will kill the future of TCL/TK.
>

>...

>
> The end product would ideally be able to create or make possible code for
> both iOS and Android platforms and be expandable (via maybe a plug-in
> architecture) to cope with other future mobile platforms. I think that are
> similar projects using other scripting languages which can achieve this
> goal. If that's correct, then the tcl/tk community should aim for the same
> sort of outcome.
>
> Could some of the very experienced people among us please comment!
>
> Rob.
>

Steve Havelka has the most experience that I am aware of, but perhaps I
can contribute a little on the status of Tcl and Android.

First, eTcl runs, and is an easy way to get a complete (it includes
Tcllib) oldish Tcl going.

rkeene's Tclkits run, and are an easy way to get a new version of Tcl
running. Tcllib is not hard to install manually.

But these are Tcl-only (no Tk), and have little connection to the neat
stuff inside Androids.

Steve has done some graphics work (live wallpaper demo is available),
but Tk is still a long way off.

HTH,

Gerry Snyder

[Steve Havelka]

As Gerry mentioned, it's already possible (and not difficult) to run a
Tcl interpreter on an Android device. You can do this through one of
Roy Keene's tclkits, prebuilt for arm. This is a long way off from
actually writing an Android app (i.e. something you'd see on the app
store) in Tcl and a Tk-like gui toolkit.

I've done most of the work necessary to get a native-compiled Tcl
interpreter to run from within an distributable Android package (.apk)
file, building on Roy Keene's work. This mostly involves making sure
that the process environment for a given .APK is set up in a way that
Tcl needs (a writeable TMPDIR, etc.).

If you wanted to talk about using Tcl to create fully-usable GUI
applications, there are basically two routes I think you could go,
either wrapping the Android native widgets in a Tk-like language, or
using the Android's canvas-like widget as a full-screen "blank slate"
and drawing your own widgets to that. Going the first route, you're
looking at a certain amount of effort to write a lot of wrapper code.
Going the second route, you're still looking at a lot of effort, and
then your applications will always "look funny" (i.e. not native).


Quick aside--it's important to understand about an environment like the
Android runtime is that it's divided into two parts:
* the Java VM that most people write to, that gives you access to the
widget toolkit, platform services, hardware and so on,
* and the native code environment, where you can call from the Java VM
into compiled C libraries and, with a bit more work, call back into the
Java VM from those C libraries.

(If you have any experience with the Java Native Interface (JNI), then
you probably already know how tedious it is to write C-level code that
calls back into the JVM.)

I've learned enough about writing code to bridge the C<->Java gap to be
able to say that, it's definitely within the realm of possibility to
write C code that can, say, instantiate Java objects (like GUI widgets)
and react when those Java objects' methods are called (like touch events
sent to a given GUI widget).


I personally would love to see steps taken toward making GUI option #1 a
reality--that is, writing a Tk-like wrapper at the C level around the
native widgets. Once that much was in place, it'd be easy to adapt my
code and scripts into making a turnkey "pack up your Tcl into an .APK"
build system. It might even be possible to do much of the hard work
automatically, by writing some sort of mechanical wrapper-generation
script. Any Java experts, can you speak up with any thoughts on this?

Another aside: it'd be possible to do nearly the same thing for iOS
support. Some time ago I embedded a Tcl interpreter into an iOS
project, which ran without problem on an iPad. It'd be a different
widget set, of course, though, and trying to develop a common set of
widgets between the two platforms might be tricky (i.e. more trouble
than it's worth).

And one last thing--I like your ideas about financial incentives. I'd
definitely submit a proposal or two for these sorts of projects if there
were some financial backing available.


cheers,

Steve

[Ted Nolan <tednolan>]

In article <l1cvib$7kt$1...@dont-email.me>,

So...

Wouldn't the natural thing to do to build Tcl apps for Android be to
use Jtcl?
--
------
columbiaclosings.com
What's not in Columbia anymore..

[escargo]

Is it possible to use SWIG to generate the wrapper code to access the underlying C widgets?

[Steve Havelka]

Would it? Or rather, let me instead ask...what are the advantages and
disadvantages of going either route (Jtcl or native-built Tcl)?

Here's my take on that question:
* native-built Tcl is up to version 8.6, JTcl is at 8.4 + some
commands from 8.5
* native-built Tcl has no method to create or manipulate Java objects,
while JTcl does
* both require a certain amount of legwork to integrate into an
Android .APK
* neither one, as far as I know, actually presents a Tk-like language
for creating/manipulating Android widgets


What are your thoughts?


thanks,

Steve

[Ted Nolan <tednolan>]

In article <l1d5d5$b62$1...@dont-email.me>,

Well, this is fairly off the cuff since I've not used Jtcl, and don't
really have any plans to do android apps, but..

It seems to me the ability to easily use the standard android java classes
would be pretty compelling. As for no Tk -- years ago I had to use
a X11/Motif binding for Tcl for some reason instead of Tk. It was certainly
different, but I was doing the basic (and admittedly fairly ugly) GUI stuff
I needed to to in a week or so.

[tcl....@gmail.com]

Rildo Pragana had the Android version of Tcl (including the Android API) working in 2010. No one paid attention to it at the time and the project is outdated now. The Android API part no longer works.

In my opinion, creating a Tk wrapper to the Android API is an unnecessary waste of effort and time and creates needles complexity. Just use the API, forget the wrapper.

I don't know if Rildo reads CLT anymore, but his website is still up and here are two files that might be of help to someone who knows what he is doing:

http://ww1.pragana.net/Android/TclForAndroid.apk

http://ww1.pragana.net/Android/TclForAndroid.tar.gz

And some additional help about scripting on Android is here (I think you need to install the SL4A package from there before you install the above .apk package):

https://code.google.com/p/android-scripting/

Latest SL4A .apk package:

https://code.google.com/p/android-scripting/downloads/detail?name=sl4a_r6.apk&can=2&q=

[Steve Havelka]

I'm not sure that writing a generalized C<->Java bridge would be
particularly tricky. Obviously, the code that's already written
certainly has the benefit of existing, but that feature alone, I'm not
convinced is a decisive factor.

Going either route, though, I still think that, if you tried to build a
layout just out of Java objects, without some sort of wrapper layer to
make it more Tk-like, it wouldn't be very pleasant. That, I think, is
probably the hardest part, and that'd have to be written no matter how
you were embedding Tcl into an Android app.


thanks!

Steve

[tcl....@gmail.com]

I would really prefer to have the API working first and then create the wrapper. I just have a feeling that the wrapper will take a long long time to create. Tcl just doesn't have enough exposure to attract the manpower to do it fast and now.

[ed.zo...@gmail.com]

среда, 18 сентября 2013 г., 9:07:26 UTC+3 пользователь ed.zo...@gmail.com написал:
> Hi !

> 1) The first and most important - lack tcl on android. This is collapse, this is total collapse.
>

> We all (fans and connoisseurs of language) have to finance their own expense.
>

> We need to discuss this issue at a conference in 2013.
>
> Now, we must start with the funding for the development of the beautiful, useful and necessary project - Hecl created by David Welton.

Thank you all for participating in the discussion of this important issue.

But, even so, we may come to nothing !

I propose to discuss the issue on the tcl android at a conference in 2013: http://www.tcl.tk/community/tcl2013/cfp.html

And not only discuss but also to make a decision. To build strategic and tactical plans. Assign responsibility for implementing the plans of people. Organize the principle of accepting donations from foreign people.

We must take a sequence of actions to address the lack tcl on android soon.


Best regards.

[Steve Havelka]

[Steve Havelka]

On 09/22/2013 02:21 AM, ed.zo...@gmail.com wrote:

I'd like to be involved in any discussions you have about this. I've
already done a bit of the work, and I can help contribute to these goals
further.


Here's my take on where we are:

You can already run Tcl programs on an Android device, as long as you're
a developer who knows how to use a command line, and as long as you
don't care about interacting with the device.

There are two problems there, and I and others have worked toward
solving the first one (packaging Tcl into a program that non-developers
could try to install). The second one--interacting with the device--is
a bigger question for me.

What does it mean to interact with the device? Access the GPS, get
accelerometer data, display something on the screen, etc? A goal like
"get Tcl/Tk on Android" is vague. What kind of specifics do you have in
mind?

And, for me, also important to know--once the code is written, what kind
of plans would you want to have for getting the word out, i.e. plans for
marketing and promotion?


Looking forward to your thoughts,

Steve

[peter.r...@gmail.com]

What makes Tcl/Tk so special and easy to use for me?

This is easy crossplatform gui and event based socket handling.
If this could be ported to android, it would be a big start.


Client/server is a breese in tcl. No AJAX,SOAP,CORBA,....
Just 2 interpreters with the comm extension and you are done

I see a lot of anger when collegues of me try to design a web gui.
Webapplications are becomming hell (browser campatibility!). This could be TK's strength.

It's all app's now. Tcl/Tk in a starkit for android can be made an app.
So maybe customers will shift again to apps on desktop also when they are fed up with again a not working webgui.

This is where we have to put TK back in the spotlights and make it also mobile.
With more focus on multimedia TK. Like a sound/video player.
Or focus on the ability to embed a gui application in a TK container in a multiplatform way.


Hopefully it get's some attention on the TCL conference.

Peter

[Tim Wallace]

Google lists tcl on their android-scripting page
https://code.google.com/p/android-scripting/ but if you go to the
downloads link, there are perl, lua, and python but no tcl downloads.
This has some pretty good hooks to the android device APIs, so maybe
someone would like to investigate helping make it work for tcl.

--Tim

[David N. Welton]

On Wednesday, September 18, 2013 8:07:26 AM UTC+2, ed.zo...@gmail.com wrote:

> Now, we must start with the funding for the development of the beautiful, useful and necessary project - Hecl created by David Welton.

Sorry for the slow reply, but I've been on vacation in Oregon.

That's a very kind thought on your part, but more than money, I would love to see someone step forward and donate their time and code to Hecl, which I still think could play a role in the world of mobile scripting.

When I wrote Hecl I was a single guy with a lot of spare time; now I am married with two kids, a busy consulting job, and a side business that is steadily growing ( www.liberwriter.com ).

I'd be happy to help someone with the technical ability to jump in and really drive the development of Hecl.

[ivani...@gmail.com]

For my mobile development I am using a cross platform sdk called MoSync (http://www.mosync.com/) which provides common C/C++ api. In the past, they had a version of lua ported. I feel some version of tcl (perhaps jim) could be easily ported.

Unfortunately, on top of Mosync, I am knee deep in HTML5 which uses javascript as the core scripting language. I haven't really found a case for tcl on the client side.

The server side application is another story :)

[crt...@gmail.com]

On Wednesday, October 2, 2013 5:32:34 PM UTC+8, ivani...@gmail.com wrote:
> Unfortunately, on top of Mosync, I am knee deep in HTML5 which uses javascript as the core scripting language. I haven't really found a case for tcl on the client side.

Tcl to JS compiler?

[Kevin Walzer]

On 9/18/13 2:07 AM, ed.zo...@gmail.com wrote:
> 1) The first and most important - lack tcl on android. This is collapse, this is total collapse.
> 2) The second - a great variety of good, decent but dead projects.
> for example (off the top of my head):
> - Hecl
> - tkhtml
> - tclplugin
> - tkzinc
> - etcl
> - tkvideo
> - ctk (curses tk)
> ...
> and more hundreds of disappointments.

Each of these projects was written by someone hoping to achieve
something specific--they needed it for a product, were interested in the
problem domain, or some other reason. Regardless of the driving force,
they had a personal stake in the development of the project. When that
stake ended, they moved on.

Absent that motivation, it's very hard to entice someone to focus on an
open-source project full-time or even part-time. Money helps, but a
community as small as Tcl isn't likely to be able to raise those funds.
The only instance I can think of where a major Tcl/Tk open-source
project was sponsored/financed to the level where a Tcl developer could
work on it full time was Apple's sponsoring of Tk's port to the Cocoa
frameworks. Apple decided to make Tk its core cross-platform GUI
library, and paid Daniel Steffen to port it to Cocoa--a nine-month
project that ended a few months later with him joining Apple full-time.

The best way to help one of these projects move forward will probably
require you to roll your sleeves up and get your hands dirty learning
Tcl/Tk's low-level internals, C-API, etc. I was concerned about Tk's
status on the Mac--apart from Daniel Steffen, no one was working on
it--so I spent a number of years learning C programming, Objective-C
programming, and the relevant Mac frameworks so that I could contribute
to the development of Tk itself. (Tcl/Tk is the basis of my commercial
apps so I have a vested interested in keeping it strong.) After
releasing several successful open-source projects involving Tk and the
Mac, I volunteered to take over as Mac maintainer of Tk as Daniel
Steffen was no longer able to do the work. I lack Daniel's expertise,
but I know enough to fix bugs, review patches, and so on--the basic work
of a maintainer.

That's not why I got into developing with Tcl/Tk--its appeal was that,
as a high-level language and framework, I wouldn't have to muck at the
low level of C. Ironic that I've spent as much time learning C as I have
Tcl. But that is what's necessary to keep Tcl/Tk going on my platform of
choice; if no one fixes bugs or make any enhancements, Tcl/Tk may suffer
from bit-rot.

If one of these projects, such as Hecl or some other form of Tcl/Tk on
Android is very important to you, then I would get busy hacking on the
code. You may have a steep learning curve. But I see no other way for
you to achieve what you want. When I look at these projects, their
learning curve exceeds what I am willing to invest; I'd rather use a
well-supported, commercially funded framework like PhoneGap and JS/HTML5
for a mobile app than start at ground zero with Tcl/Tk. That's my
evaluation of Tcl/Tk in the mobile space. That's also the evaluation of
many people about Tcl/Tk on the Mac, which is why very few people have
contributed code to the Mac port in recent years; this means that if I
want anything done on Tk on the Mac, I have to do it myself.

I wish you the best!

--Kevin



--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

[Lawrence Woodman]

On Wednesday, 2 October 2013 11:49:29 UTC+1, crt...@gmail.com wrote:

> Tcl to JS compiler?


While reading this thread, I couldn't help but feel that a Tcl to JS compiler would be a more realistic option.

One way of creating the compiler would be to do what Danny Yoo did with Whalesong (http://hashcollision.org/whalesong/) for Racket. Whalesong takes the bytecode that Racket creates and uses this for conversion to Javascript. The resulting Javascript then has all the unused functions stripped using Googles clojure compiler.

Because Tcl is a mix of C and Tcl this may also need to use something like emscripten (https://github.com/kripken/emscripten) to compile c to js.

This route has many advantages:
* It would be easy to interact with the phone's gps, camera, etc.
* You could use phonegap to create apps for multiple platforms.
* I would assume the resulting packages would be much smaller.
* You could create an online Tcl Repl to show off/promote/demonstrate Tcl.
* You could easily access a wealth of Javascript libraries.
* You could run Tcl via node.js, giving further access to a vibrant active community.

Best wishes


Lorry

--
vLife Systems Ltd
Registered Office: The Apex, 2 Sheriffs Orchard, Coventry, CV1 3PP
Registered in England and Wales No. 06477649
http://vlifesystems.com