RE: [Hecl-devel] some initial thoughts

[David B. <dav...@ak...>]

>
> > 1) Added "!=" and "ne" commands to the comparison operators. This
> > is for convenience when writing scripts to avoid either having to
> > invert the result or use only the else branch. Both are ugly.
> >  Its a cheap addition as it doesn't add any more classes. 400 bytes
> > really hurts !
>
> Sure, those work.
>
>
> Good one.  Can you send me your patch and I'll integrate these two?

 I will try and work out how to get cvs access to make sure I am at top
of tree then will send the patches.


>
> > 3) Added a hack into puts code to write to a GUI text box. I am no
> > java expert but I guess the correct thing to do here is to have
> > a defined interface (or use the System.out one), but it could be
> > a heavyweight solution.
>
> This one requires a bit more thought.  Tcl has a fairly complex channel
> system that you can do really neat things with, like stacking channels,
> so one compresses, one encrypts, and so on.  However, that's going to
> blow out the size limitations.  Some ideas:
>
> *) Have puts (rename it to echo or print?) just go to whatever sort of
> console (including a GUI if the device only has that) is available, and
> develop a file/channel system separately that uses other commands and is
> a bit more complex, but that is a modular add-on so as not to encumber
> the core.
>
> *) Simply leave puts alone and tell people to override it as needs be,
> providing a few defaults for different platforms.

 I agree, its a slippery path.

 One thing I would love though is file access, via puts and gets would work.
The
j2me file system is frankly weird.



>
> *) Work on a minimal channel system that puts uses to send text to
> whatever device the channel refers to.
>
> > On a related note about size. Anyone have any experience of using a
> > gzip library to inflate a hecl script at runtime. Zipping a typical
> > tcl file takes it from 18k to 6k, a big saving. If the expansion
> > code is less than 12k and fast enough it could be a good win.
>
> Offhand it doesn't look like they provide that API as part of J2ME,
> which is a pity... it would be useful to a lot of people I think.
>
> It's worth looking around to see if some minimalistic compression code
> is available for J2ME (it can't utilize API's available only to regular
> Java, in other words) under a suitable license.



 I believe there is something called zlib for java. It supports the various
different formats that zip can produce in. However it would make sense to
strip it right down to only support one format and a single file. That
should
make it a lot smaller. Then the code can be de-OOed (my name for making java
code small to fit on a mobile :-) IE removing unnecessary classes and
merging
other classes together.
 I have no idea how much work this would be. My concern is also performance,
would the expansion be fast enough and frugal enough in memory to be useful.



Another note. What are your feelings about using #defines, #ifdef etc in
java code.
I am using netbeans which integrates them pretty well, though they are not
standard in
Java.
They are very useful though, different phones have wildly different run time
environments
so being able to customize things in the source is good. This could be a way
to deal with
the different "puts" requirements.



David



>
> --
> David N. Welton
> - http://www.dedasys.com/davidw/
>
> Apache, Linux, Tcl Consulting
> - http://www.dedasys.com/
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Hecl-devel mailing list
> Hec...@li...
> https://lists.sourceforge.net/lists/listinfo/hecl-devel
>