This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Nano using PDCurses for eCos

Steven Clugston wrote:
> Sergei Gavrikov wrote:
> > If you just want to edit config files, it's better to implement own
> > editor, call it `femto' then :-)
> >
> > It seems for me that nano is enough bloat stuff for eCos targets.
> Nano does far more than I realised and I agree that most of it is
> bloat for what I need like calls to external programs for spell checking
> and wide character and NLS support etc, but it's a choice between writing
> an editor from scratch or hacking nano to work by disabling the bloat
> using its existing config mechanism. I think the latter should take less
> time/effort. It's a shame there's not a #define NANO_FEMTO mode to strip
> off even more than NANY_TINY does.


> Sergei Gavrikov wrote:


> > When I will get a far progress with Nano/PDCurses I wil let you know.

Hello Steven,

Let moderators excuse this post. At first, I thought to write you
personally, but, then I thought, Why not here? More that one guy did
share own eCos shell here:

And it seemed for me that our thread is a shell-related thread. You told
about your needs to edit config files and yesterday I thought, Why do
not write and send e-mails using SMTP with nano like pine does it using
pico :-) A hundred of kb is not issue for PC target, for example.  What
curses program does at all? The curses program the mostly sleeps.  IMHO,
curses is not bad thing for eCos. So, why do not benefit our experience
with other eCosers? IMHO, TCL shell or PDCurses shell is more powerful
thing than just "while(1) cyg_io_read(...);" It is a portable way to
get the shells.

I have got some results on "femto". Today I put nano-2.0.9 under local
mercurial repository and cleaned up all my tweks.

(1) My "femto" config.h version and my tweaks let me build the nano
    without eCos POSIX package. Instead I add CYGPKG_LINUX_COMPAT (just
    to get headers). AFAIK, some eCos FS packages depend on it (e.g,
    it's possible to add FS_FAT, FS_JFFS2 without bloat CYGPKG_POSIX).
    My config.h let me build nano without Unix stuff at all
    arm-eabi-nm src/nano | grep -E "T (wait|fork|exec)"
    (no output)

    For my config I have got only 5 stubs: getpwuid(), getpwent(),
    endpwent(), umask() and mkstemp().

(2) About POSIX signals. There were exactly two functions in nano.c:
    signal_init() and do_suspend() for my config. Both of the functions
    depend on TOGGLE_SUSPEND_KEY and NANO_SUSPEND_KEY. But what is "^Z"
    for the eCos World? We can quite ignore those handlers.

(3) My eCos config was

    Template: default

    and it did let me get "The GNU nano" for ARM target as

   text	   data	    bss	    dec	    hex	filename
 123384	   1408	  24256	 149048	  24638	src/nano

(4) I add getopt.[ch] under compat directory. And the nano the above
    contains it. I think you are right: it would not bad to prepare
    something like CYGPKG_SERVICES_GNU_GETOPT. It seems for me that
    today's eCos license let us do it. And, perhaps, you are right when
    said about CDL against getopt.

(5) My tweaks of nano/src seem itself the very minimal (only nano.h,
    and nano.c were tweaked), look at an attached nano.diff.  It was
    surprise for me. But, now I do not know what will happen if someone
    will turn on an external spell checkeri, for example, in my config.h 

I attach all stuff (including used getopt) to get "femto" under eCos. I
will put all on bitbucked then. If anyone is interested in any CLI under
eCos, he/she can use our experience.



Attachment: nano-ecos-hack.tar.gz
Description: Binary data

Before posting, please read the FAQ:
and search the list archive:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]