Tcl/Tk 8.4.3 for WinCE ARM binaries available
Jeff Hobbs
ftp://ftp.tcl.tk/pub/incoming/tcltk843ce-arm.zip
It includes the full Tcl/Tk + celib binaries needed for operation.
There is a README on how to install it (you will need to set a few
registry settings on your PocketPC device). In addition to Tcl/Tk,
you will find tcllib1.4 and bwidget1.6, which both work out of the
box (pure Tcl), and tktable2.8 as a proof-positive TEA ported
library (works like a charm).
Known issues:
* [X] in the corner doesn't close app
* Menus don't work correctly
* Scrollbar always scrolls to end
* exec not supported
* Too slow ... (for my taste)
I was hoping to get the sources available, but 8.4.3 and other things
distracted me. The sources are set up in such that they coexist in
the regular win/ subdir, you just configure like so:
$ /cygdrive/z/cvs/tcl/tcl8.4ce/win/configure \
--prefix=C:/build/inst/tclce \
--enable-wince=300,ARM \
--with-celib=/cygdrive/z/src/celib-palm-3.0
Also, they require changes to the default celib devel stuff from
Rainer Keuchel (http://www.rainer-keuchel.de/software.html - thanks
for the porting library Rainer!), in order to be more WinCE3.0
compliant. I also want to fix the known issues (at least the first
two) before creating a mega-patch for others to test from source.
The changes necessary for TEA extensions are already commited to the
sampleextension source base. I've compiled and tested the
sampleextension and tktable successfully. Porting of extensions to
WinCE3.0 should be rather easy.
Hopefully others will find at least these binaries useful.
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Ryan Casey
I have been following your progress on this and am very excited that
you have provided a mostly-working current Tcl/Tk for CE. I installed
it this morning, and have noticed a couple things:
Backspace (for instance, in Tclsh) does not seem to work for me. I
get one of those empty rectangle boxes.
Regarding the X in the corner:
The Start Bar X never works
The X on the titlebar of the app seems to work sporadically.
Playing with the Widget Demo, it seems to work unless I try to bring
up one of the demos. On a side note, none of the demos I have tried
have worked. They start a new process in the list under Running
Programs, but even if I activate it from there, I get nothing.
Man, that scrollbar thing is annoying though :-)
I know this is early, considering you are still working on bugs in the
current port, but are there any plans for a CE Starkit?
Thanks again, Jeff!
Ryan P. Casey
Jeffrey Hobbs
> I have been following your progress on this and am very excited that
> you have provided a mostly-working current Tcl/Tk for CE. I installed
> Backspace (for instance, in Tclsh) does not seem to work for me. I
> get one of those empty rectangle boxes.
That's the console written by someone else, and it never supported
backspace. It also doesn't wrap. This isn't really part of the
core Tcl stuff at all and I likely won't ever look into it. I use
tkcon instead.
> Regarding the X in the corner:
> The Start Bar X never works
> The X on the titlebar of the app seems to work sporadically.
Yes ... I did say that in Known Issues.
> Playing with the Widget Demo, it seems to work unless I try to bring
> up one of the demos. On a side note, none of the demos I have tried
> have worked. They start a new process in the list under Running
> Programs, but even if I activate it from there, I get nothing.
That may have something to do with exec, but I'd have to see what it
is doing. The window might be hidden behind another, and the control
of stacking isn't correct. I've never actually tried the widget demo
because I figured it wouldn't adapt to QVGA well without lots of work.
> Man, that scrollbar thing is annoying though :-)
Yes ...
> I know this is early, considering you are still working on bugs in the
> current port, but are there any plans for a CE Starkit?
Talk to Jean-Claude. It wouldn't be so hard if he wasn't so stubborn
about sticking with C++ and libtool for metakit <hint hint jcw>. As
I said, I've ported the TEA base over already.
--
Ryan Casey
> I use tkcon instead.
Simple enough. I will do that.
> > Regarding the X in the corner:
> > The Start Bar X never works
> > The X on the titlebar of the app seems to work sporadically.
>
> Yes ... I did say that in Known Issues.
The Known Issues stated that the X didn't work. It didn't specify
between the two, and I mentioning that the titlebar one does seem to
work most of the time for me.
> I've never actually tried the widget demo
> because I figured it wouldn't adapt to QVGA well without lots of work.
Ah. Seems strange to have the default install contain all the Widget
demo stuff if it won't work (just a little annoying because of
transfer time). However, if it is not expected to work, that's ok
then.
> > I know this is early, considering you are still working on bugs in the
> > current port, but are there any plans for a CE Starkit?
>
> Talk to Jean-Claude. It wouldn't be so hard if he wasn't so stubborn
> about sticking with C++ and libtool for metakit <hint hint jcw>. As
> I said, I've ported the TEA base over already.
:-) ok.
Thank you Jeff
Ryan
Jean-Claude Wippler
> > > I know this is early, considering you are still working on bugs in the
> > > current port, but are there any plans for a CE Starkit?
> >
> > Talk to Jean-Claude. It wouldn't be so hard if he wasn't so stubborn
> > about sticking with C++ and libtool for metakit <hint hint jcw>. As
> > I said, I've ported the TEA base over already.
Ehm, Jeff... that's kind of a cheap shot, don't you think?
1) My position on C++ is well-known, it isn't what you are suggesting
2) MK has been working on WinCE for months, it's not the bottleneck
3) I'll throw libtool out the *second* someone gives me a patch for it
I don't mind you saying things. Just don't drag me into it over and
over again. I've responded to your comments several times, also on
the chat. It's a bit tedious to have to repeat it ... :(
So where's that mega source-patch you offered, so I can have a go at a
build for WinCE again? <hint, hint, hint, jh>
For everyone else's information: I worked on a tclkit build for WinCE
a while back (and got me a PDA to test it on), but had to postpone it
because the version at the time (8.4a2, i.e. Rainer Keuchel's great
port) predates the new VFS logic in the core, on which tclkit and
starkits rely.
FWIW, having starkits/packs and tclkit on WinCE ought to make it a
*lot* easier to develop and deploy applications for that platform! I
really want to help make it happen.
-jcw
Jeffrey Hobbs
>>>>I know this is early, considering you are still working on bugs in the
>>>>current port, but are there any plans for a CE Starkit?
>>>
>>>Talk to Jean-Claude. It wouldn't be so hard if he wasn't so stubborn
>>>about sticking with C++ and libtool for metakit <hint hint jcw>. As
>>>I said, I've ported the TEA base over already.
>
> Ehm, Jeff... that's kind of a cheap shot, don't you think?
You are right, but you have to allow me the rare cheap thrill in
my drab developer life. ;)
> 1) My position on C++ is well-known, it isn't what you are suggesting
> 2) MK has been working on WinCE for months, it's not the bottleneck
> 3) I'll throw libtool out the *second* someone gives me a patch for it
Oooo ... you may get a taker on pt3. It is one of the harder
components to deal with. My point about though was that in the
base kit building toolchain, metakit is the only real outlier
in terms of code (C++ vs. ANSI C) and build tool (it's the only
part to use libtool, although I know that some VC++ driving
magic is used on Windows).
OTOH, the changes that I have made (and yes, I'm guilty for
still sitting on them) are all part of the TEA "standard"
configure/make setup (even though we are talking Windows stuff
here). Thus, it's the unknown that I fear!
> So where's that mega source-patch you offered, so I can have a go at a
> build for WinCE again? <hint, hint, hint, jh>
I will rerelease the ARM binaries this weekend, with the full
patches to tcl/tk attached. They aren't ready for commiting to
the core just yet, but are ready for others to play with. On
some advice, I switched to using the internal Tcl memory alloc
routines and found that it sped up the functionality noticably.
Andreas Kupries
> > 1) My position on C++ is well-known, it isn't what you are suggesting
> > 2) MK has been working on WinCE for months, it's not the bottleneck
> > 3) I'll throw libtool out the *second* someone gives me a patch for it
>
> Oooo ... you may get a taker on pt3. It is one of the harder
> components to deal with. My point about though was that in the
> base kit building toolchain, metakit is the only real outlier
> in terms of code (C++ vs. ANSI C) and build tool
> (it's the only part to use libtool
Not quite true. Both the libxml2 libraries and the ogg/vorbis
libraries for snack also use libtool. However these libraries are
written in C and required only a bit of hand-holding in our build
system. IOW it seems that libtool for C is relatively well-behaved,
but not nearly so for C++.
>, although I know that some VC++ driving magic is used on Windows).
--
Sincerely,
Andreas Kupries <akup...@shaw.ca>
Developer @ <http://www.activestate.com/>
Private <http://www.purl.org/NET/akupries/>
Join us at the Tenth Annual Tcl/Tk Conference <URL: http://wiki.tcl.tk/6274>
-------------------------------------------------------------------------------
}
Jeffrey Hobbs
> Jeffrey Hobbs writes:
>>>1) My position on C++ is well-known, it isn't what you are suggesting
>>>2) MK has been working on WinCE for months, it's not the bottleneck
>>>3) I'll throw libtool out the *second* someone gives me a patch for it
>>
>>Oooo ... you may get a taker on pt3. It is one of the harder
>>components to deal with. My point about though was that in the
>>base kit building toolchain, metakit is the only real outlier
>>in terms of code (C++ vs. ANSI C) and build tool
>>(it's the only part to use libtool
> Not quite true. Both the libxml2 libraries and the ogg/vorbis
> libraries for snack also use libtool. However these libraries are
> written in C and required only a bit of hand-holding in our build
> system. IOW it seems that libtool for C is relatively well-behaved,
> but not nearly so for C++.
Note that I was referring just to the creation of a base kit for
WinCE specifically, so it would be the only libtool part. Yes, I
know it isn't the only libtool part in ActiveTcl.
Steve Cassidy
> ... Both the libxml2 libraries and the ogg/vorbis
> libraries for snack ...
Ooh Ooh, how about throwing these at the arm compiler, snack
at least is on my list of targets for porting to wince but
the trauma of dealing with windows IDEs wasn't making it an
attractive proposition.
Are the TEA mods to snack publicly available? Sorry but I
haven't looked at the sources for a month or two but last
time I checked it needed the IDE to build on Windows.
Steve
Jeffrey Hobbs
I have no idea exactly what the limitations are, as it is outside
my expertise, but I understand that things like audio libraries
will not be easy to port due to the ARM hardware limitations (the
ARM chip perhaps has no FPU?) Anyway, it could be tried, but do
not expect much. The TEA mods are already part of the sample
extension in CVS, so you can apply those changes to snack and
see if that works.