Re: [Toybox] [PATCH] more.c: More stuff, down cursor key scrolls down. Also stuff about less

[David Seikel]

On 2024-03-20 05:02:11, Oliver Webb via Toybox wrote:
> But I have to ask the question "If it's so easy, why isn't it in toybox yet?" 
> Is it just because
> other TODO items taking up time, or is it because it's harder to implement 
> than it seems.

I might be able to shine some light on that.

Long ago I wrote boxes, designed to be a starting point for a generic
editor / pager for toybox.  It included very basic implementations of
less, more, and several well known text editors, including vi.  All done
as wrappers around a common core.

Even after trimming it down to just an example shell line editor, it was
deemed too big to read.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] watch: flush the buffer each round.

[David Seikel]

On 2024-03-12 10:24:19, enh via Toybox wrote:
> On Tue, Mar 12, 2024 at 8:45 AM Rob Landley  wrote:
> >
> > Hello from Minneapolis: https://mstdn.jp/@landley/112078501045637288
> >
> > Still _really_ fried from my move, but at least chipping away at the email
> > backlog...
> 
> at least it's the same timezone :-)

I'm still recovering from my move last month, fourth one in 12 months.

This new home has four adresses, and apparently is bigger on the inside
than it is on the outside.  My new home is a TARDIS!  I can't even
guarantee being in the same year next time I open the door.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] vi.c: Backspace to merge lines when at beginning, get_endline is no more, cleanup

[David Seikel]

On 2024-03-08 10:47:10, Jarno Mäkipää wrote:
> I was not that interested on ex, and I think Rob said ex is obsolete
> and not on his roadmap. But yes some of ex commands are just vi normal
> mode commands, with special addressing. If someone needs them, I think
> first thing to do is implement better ex command parsing and
> dispatching, original version was intended only to parse write and
> quit commands. (the 90% vi user case, rest of 9% not knowing how to
> quit and 1% needing something else)

The one command I have memorised for vi and family is how to quit if I
accidently end up in it.  That command is -

killall -TERM vi

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] clear.c: Clear scrollback buffer on non-vte (gnome based) terminals

[David Seikel]

On 2024-03-06 01:57:42, Rob Landley wrote:
> Commodore did a unix for the amiga:
> 
> https://en.wikipedia.org/wiki/Amiga_Unix

Which, at least in Australia, they used for their own developer support
servers.  I know this coz I was a member of the Australian Amiga
Developers, who where owed some money when Commodare collapsed.  So
Commodore handed over one of those machines instead of money, ond it
ended up being passed onto me.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] buffer sizes

[David Seikel]

On 2024-02-28 15:41:06, Rob Landley wrote:
> I can see arguing that you might need 8k there to avoid screen flicker with 
> the
> large terminal sizes some people tend to use.

I might be one of those people, with my 256 x 140 terminal.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] deobfuscation of electricity meters

[David Seikel]

On 2024-02-27 20:29:31, Rob Landley wrote:
> On 2/27/24 19:45, David Seikel wrote:
> > On 2024-02-27 19:37:39, Rob Landley wrote:
> >> "We put all the switches together in a common fusebox, it's down in the
> >> basement. If you want to control any lights in the house, go down there 
> >> and read
> >> the labels, it's so much tidier that way."
> > 
> > Wait, your switches in the basement have labels?
> 
> Texas doesn't have a lot of basements. (Up near dallas that's because the clay
> expands and contracts significantly each time it rains, so the concrete slab 
> is
> designed to kind of float on top of that. When I lived in the Austin hill
> country it's because we were on granite and you'd need drilling and dynamite.
> Downtown we _already_ flood regularly just on the surface, and for all I know 
> we
> might have it all: ten feet of soil expansion on top of impenetrable bedrock,
> with a high water table.)
> 
> My house's circuit breakers are on an outside wall behind a large aggressive
> rosebush.

The basic problem is that the house has four addresses, on two streets,
in two suburbs, and that changes depending on which map you look at. 
There is only one actual building with the six units in it.

According to what I have found out the local city council assigns these
addresses, and while I was writing this sentence they called me back to
discuss this.  Seems I have uncovered a deeper problem that they have to
sort out now.

> > I wish the nine
> > electricity meters in my new home had labels.
> 
> I labeled them. When I moved in. It's a thing you can do yourself. (Helps to
> have two people working on it yelling stuff through a window.)

Doesn't help that there's six units here, and the occupants of two of
them don't speak English.

> > The electricity
> > distributor refused to tell me which is MY OWN meter for "privacy
> > reasons", and none of the electricity retailers know which is which.
> 
> Turn everything you can off, collect candidates, start your dryer and stove,
> collect candidates...

I came up with that idea, and so did one of the electricity companies. 
It didn't help.

Stove is gas, though my asthma would prefer electricity.  Laundry room is
shared, so the dryers and washers are on a different meter.

The meters are old style dumb meters, so the electricity companies
couldn't just look at their readings on their local computers.  Which
means you watch the big disk spin, see how fast it spins.  Some of the
meters are badly placed, can't see if the disk is spinning or not.

I wasted several days going over and over this with the electricity
companies and others.  This is why I've been trying to get to the source
of truth, since no one else knows.  Now, after speaking with the local
city council, the source of truth, even they don't know.  lol

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] deobfuscation of electricity meters

[David Seikel]

On 2024-02-27 19:37:39, Rob Landley wrote:
> "We put all the switches together in a common fusebox, it's down in the
> basement. If you want to control any lights in the house, go down there and 
> read
> the labels, it's so much tidier that way."

Wait, your switches in the basement have labels?  I wish the nine
electricity meters in my new home had labels.  The electricity
distributor refused to tell me which is MY OWN meter for "privacy
reasons", and none of the electricity retailers know which is which.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Gmail being weird again.

[David Seikel]

On 2024-02-05 17:39:33, Mouse wrote:
> > I was mostly offline over the weekend, and gmail refused pop3 this
> > morning [...]
> 
> > So I closed the tab and went to other windows, but next time I passed
> > that virtual desktop I clicked "get messages" in thunderbird out of
> > sheer habit... and it worked.  And I can send too.
> 
> I suspect gmail is made up of many, many machines, and not just because
> I can't imagine how one machine could handle the load.

I know Yahoo email is like that.  Very unreliable, and I get error
messages from a bunch of different Yahoo servers when it fails to
collect.  It's been doing this for many years.

Like I mentioned in my last email, Yahoo is like Gmail, I'm only using it
for ancient people with my old emails that rarely email me.

My favourite failure notice from Yahoo - "Failure: Success!!". 
Considering how often it fails, I can see that actually working might
count as a failure mode.  lol

> I don't normally send mail to gmail addresses because most of them
> can't mail me back.  But there are a few people who have other channels
> to reach me by, to whom I've sent from my own infrastructure, where I
> have a user agent I can stand.
> 
> Then, a little bit ago - a month? - I tried to send to one of them and
> Google rejected the mail with some babblage about it being
> insufficiently authenticated.  I tried again some hours - a day? -
> later and it worked fine.  I've been getting such failures
> intermittently since then, to the point where I've stopped trying.
> 
> But the point here is that the failures are intermittent.  I speculate
> that this happens because they're pushing a new version of their
> infrastructure code to their world-facing machines gradually, so it
> breaks when I happen to draw a machine with the new code on it.
> 
> And this would explain your own trouble, too: we just need to posit
> that you got a new-code machine "this morning", but an old-code machine
> "next time".  (Whether the new version that broke interop for me is the
> same as the one that broke interop for you is perhaps interesting to
> speculate about, but not very relevant from a pragmatic point of view,
> even if my guess is correct.)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Gmail being weird again.

[David Seikel]

On 2024-02-05 12:09:28, Rob Landley wrote:
> I was mostly offline over the weekend, and gmail refused pop3 this morning 
> with
> "web login required", and the https://mail.google.com page prompted me for my
> login/password (I log out when done with the thing I couldn't do without 
> logging
> in) and then it wanted to SMS me with a phone number it guessed was mine even
> though I've never given that account my phone number.
> 
> I refused to confirm or deny its guess (SMS as a single point of failure for
> password resets is CREEPY, as if nobody's ever stolen an account via sim
> spoofing, and broadcasting an attacker-requestable plaintext message to your
> entire city seems sub-optimal at the best of times) and instead clicked the
> "help" option, which wanted me to login _again_ with the "old password" and 
> then
> had more sms options, or I could use the next-of-kin email I gave it in case I
> died. But it was 2am and she was asleep. (And she gets spammed every time I
> login from different machine than last time, and hadn't mentioned anything in
> the household discord channel...)
> 
> So I closed the tab and went to other windows, but next time I passed that
> virtual desktop I clicked "get messages" in thunderbird out of sheer habit...
> and it worked. And I can send too.
> 
> It looks like giving my password to the webpage counts as "web login" that
> unblocked pop3 and smtp access. Only web access has the "additional
> confirmation" gating popups after the fact. (So basically
> https://ohai.social/@dcoderlt/111862395847437251 but professional.)
> 
> Anyway... was there a breach I'm not aware of? This week's seems to be
> https://tech.co/news/google-accounts-hacked-without-passwords but again I 
> don't
> stay logged in when not actively fishing false positives out of the spam 
> filter,
> and I usually "pkill -f renderer" the other tabs before doing that (on general
> principles)...
> 
> *shrug* Weird.
> 
> Rob
> 
> (Yes, gmail unsubscribed Ed Maste of the FreeBSD foundation from this list 
> again
> last week with spam filter delivery refusal, and yes now that linux-kernel 
> moved
> from vger to the new server I'm getting daily "bounce probe" emails due to
> refused email delivery there too, but that's just gmail being gmail...)

I bypassed that whole nonsense by telling gmail to forward all my emails
to an email server I control.  I really only use gmail for ancient people
that have that email address and not much need for me to update them.


Google recently decided that one of my web pages is "deceptive".  They
claim it's trying to trick people into handing over login details for
something else.  It's an account creation page for a virtual world I run
for friends.  It's not only open source, I wrote it and the source code
is available.  The only login details it asks for is the new ones for
your new account.  I sent Google an email about this, no reply.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] microcom: move from e[x]it to [q]uit.

[David Seikel]

On 2023-11-06 14:32:45, enh via Toybox wrote:
> i suspect https://github.com/tio/tio#32-key-commands is probably
> making new traditions right now. well, that and PuTTY! tbh, i only
> ever see people on youtube using gui stuff; there's even a gtkterm!

It's entirely likely that people like me that want to know how to do some
non GUI thing, much prefer a text document that you can copy & paste from. 
So videos are a hard no for that sort of thing.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] sh: pass "\" to the later app

[David Seikel]

On 2023-07-05 02:29:39, Rob Landley wrote:
> >> still matching the behavior in my devuan install. (Still devuan bronchitis,
> >> haven't updated to devuan cholera yet. Um, the web page says devuan B 
> >> matches
> >> debian "buster" and devuan C matches "bullseye", if that helps.)
> > 
> > Not at all. But charming version names.
> 
> Devuan is "debian without systemd" so 99% just a wrapper around the existing
> debian repositories intercepting the small number of packages that need to be
> diddled, and once they decided they were stable they started doing 
> alphabetical
> release names like xubuntu did, and I never remember what the names are but
> remember the letters. (The debian ones I look up because they don't have 
> letters.)

I'm what we call "the package mirror herder" for Devuan, top level admin
contact for the package mirrors that do that "serve Devuan stuff or
redirect to Debian" thing.  Though some of them are running a Debian
mirror as well, so skip the redirect step.

> I'm still using the B (ahem, "Beowulf") release. The C ("Chimaera") release 
> came
> out October 2021 but I haven't upgraded yet because B (from June 2020) is 
> still
> supported.

I keep complaining that we need to pick names that are easier to spell,
they keep picking the hard names.  I mentioned in IRC that I now have
decided that being hard to spell is a feature, so I spell them wrong
deliberately.  Though now I'm thinking just using the first letter is a
better option.  Thanks for that idea.

Now that the latest Debian has been released, Daedalus is next up for
Devuan, it's close, and quite stable.  Just gotta sort out some things
with the web site and installer.

A ("ASCII") got archived earlier this year, B is still supported until
after the next major Debian release.

> Back when I did busybox, I was replacing the Linux From Scratch packages with
> busybox, and I eventually got a system built from just 7 packages (linux,
> busybox, uclibc, gcc, binutils, make, bash) to rebuild itself under itself 
> from
> source code, and build Linux From Scratch and chunks of Beyond Linux From
> Scratch under the result. (And it cross compiled for a dozen architectures and
> ran the build under QEMU, and could call out to the cross compiler running on
> the host via distcc through the emulated network to move the heavy lifting of
> copilation outside of the emulator to speed things up...)
> 
> https://landley.net/aboriginal/about.html#design
> 
> That worked, meaning I know what success _used_ to look like. Pity it's a 
> moving
> target...

I contributed the x486 support to Aboriginal Linux, my client was using
that at the time for his device.  We managed to get it approved by the
government auditors back then.  Now he's talking about updating it to
some Pi type thing.  Easiest thing for me to do I suspect is to stick
with the version of Aboriginal Linux we used back then, but I'm open to
being persuaded otherwise.  On the other hand, the less changes the
better for the auditors. "Same code you looked at last time, we just
added some more buttons and changed the graphics."

I even put together a Debian based build environment for the auditors, so
they could rebuild it and check if it was reproducible.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Linux From Scratch build.

[David Seikel]

On 2023-04-16 18:54:04, Rob Landley wrote:
> Then I try to reproduce it in a container or vm, still with host tools. This
> pretty much means "debootstrap", but that's a known thing I've done before.

Have you looked at mmdebstrap instead of debootstrap?  From the package
description -

"Downloads, unpacks and installs Debian packages to either directly create a
directory which can be chrooted into, or a tarball of it. In contrast to
debootstrap it uses apt, supports more than one mirror, automatically uses
security and updates mirrors for Debian stable chroots, is 3-6 times faster,
produces smaller output by removing unnecessary cruft, is bit-by-bit
reproducible if $SOURCE_DATE_EPOCH is set, allows unprivileged operation using
Linux user namespaces, fakechroot or proot and can setup foreign architecture
chroots using qemu-user."

I switched to it for my last Devuan Chimaera install, I previously used
debootstrap for my installs.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] "bad xform" not very helpful

[David Seikel]

On 2022-09-01 04:35:24, Rob Landley wrote:
> On 8/30/22 03:59, David Seikel wrote:
> > I'm good at reading code, but I know you are not.
> 
> As demonstrated below.

Well I had already cobbled together something that works for me, copying
stuff from other parts of toybox, that largely did what you describe
below.  I was mostly wondering if there was some easy calltoy() type
function I had missed.

My cobbled together one still has a TODO to return the output.

> On 8/31/22 20:33, David Seikel wrote:
> > On 2022-08-31 18:18:15, enh via Toybox wrote:
> >>it does by default. that's what i turned off as a workaround for this 
> >> bug.
> > 
> > Um how does one using toybox as the foundation for something else
> > actually call any random toy directly?  Is there a vararg calltoy()
> > function I missed?
> 
> You know how we're calling xexec() everywhere?
> 
>   $ grep -l xexec main.c lib/*.c toys/*/*.c | wc -l
>   30
> 
> That does:
> 
>   // Only recurse to builtin when we have multiplexer and !vfork context.
>   if (CFG_TOYBOX && !CFG_TOYBOX_NORECURSE)
> if (toys.stacktop && !strchr(*argv, '/')) toy_exec(argv);
>   execvp(argv[0], argv);
> 
> That first part is calling toy_exec() out of main.c, and falling back to
> execvp() if it can't (or when it fails).
> 
> There's a lot of sanity checks in toy_exec() and the things it calls, checking
> if we need to re-exec to acquire SUID privileges, and measuring stack depth 
> and
> refusing to recurse if it's gone too deep. But that's not actually required, 
> the
> actual the actual CALL to the other command is just this bit at the end, 
> lightly
> cleaned up to be usable out of context:
> 
>   // Run command
>   toy_init(toy_find(*argv), argv);
>   if (toys.which) {
> toys.which->toy_main();
> xexit();
>   }
> 
> You could also look at main() at the end of main.c to find the standalone 
> init:
> 
> // single command built standalone with no multiplexer is first list entry
> toy_singleinit(toy_list, argv);
> toy_list->toy_main();
> 
> (Using the first entry in toy_list instead of having toy_find() binary search
> for a neame...)
> 
> Or in toybox_main() there's this bit:
> 
> char *ss = basename(s);
> struct toy_list *tl = toy_find(ss);
> 
> if (tl==toy_list && s!=toys.argv[1]) unknown(ss);
> toy_exec_which(tl, toys.argv+1);
> 
> All toy_exec() does is call toy_find() and then call toy_exec_which() with the
> toy_list pointer instead of the name, but that splits them so it can add a
> special error check in between to prevent "toybox toybox toybox toybox toybox
> ls" from being recognized.
> 
> I didn't think starting at "main()" or reading the xexec() implementation in
> lib/ was an unreasonably high bar? There are other less obvious places you 
> could
> have found it.
> 
> This "which = toy_find(); toy_singleinit(which, argv); which->toy_main();" 
> trio
> is also done manually in sh.c to implement shell builtins, but I wouldn't 
> expect
> you to find that on a casual browse without knowing what you're looking for.
> 
> The xpopen()/xrun() family of functions funnel into xpopen_both(), which is 
> also
> a bit much to read (all that juggling pipes and nommu support), but it both
> calls xexec() and does:
> 
>   toy_init(toys.which, toys.argv);
>   toys.stacktop = 0;
>   toys.which->toy_main();
>   xexit();
> 
> to implement the "call ourselves again" case where argv is NULL when fork() is
> available. (No toy_find() there, it re-uses the existing toys.which to just
> recursively call the same command. The toys.stacktop is both to disable 
> further
> recursion and to signal to the re-entered command that this is not the first
> time it's been called, but that has to do with command reentry, ala this bit 
> of
> cpio.c:
> 
> if (toys.stacktop) {
>   // xpopen() doesn't return from child due to vfork(), instead restarts
>   // with !toys.stacktop
>   pid = xpopen(0, , 0);
>   afd = pipe;
> } else {
>   // child
>   toys.optflags |= FLAG_i;
>   xchdir(*toys.optargs);
> }
> 
> Or this bit of tar.c:
> 
> // Fork a copy of ourselves to handle extraction (reads from zip 
> output
> // pipe, writes to stdout).
> pipefd[0] = pipefd[1];
> pipefd[1] = 1;
> pid = xpopen_both(0, pipefd);
> close(pipefd[1]);
> 
> (This is because nommu systems can't do fork(), and vfork() requires calling
> exec() to unblock the parent, so xopen() can take a NULL argv to re-exec
> our

Re: [Toybox] Lots of libc's.

[David Seikel]

I guess the real question I want an answer to is which is the best libc?

Rob obviously has his opinions, and I'd like to hear them.  No doubt
others on this list have their useful opinions to.

For my purposes small, fast, high quality, pick three.  Working across
multiple operating systems would be great, but happy to reduce that to
Android, Linux, Windows, maybe Mac and iOS as well.  POSIXish FTW.

Assembler usually gets my nod for small and fast, anything I ever wrote
in what ever assembler was needed for a given project was always smaller
and faster.  But yeah, that means writing assembler for a bunch of CPUs. 
On the other hand, most seem to be switching to 64 bit only, so I could
cut that list down to x86_64 and ARM 64 bit.  RISC-V has my attention,
but it's not ready yet for me to poke at it.


For bonus points, a good collection of the usual algorithmic stuff. 
Currently using qlibc https://github.com/wolkykim/qlibc but open to
changing.

My big personal project is rewriting OpenSim, a 3D virtual world server,
in other words most of what this new "metaverse" thing claims is coming
in the future, but has been around for over a decade.  Rewriting it in C,
assembler, and Lua.  The problem is it's huge, and simulating worlds
involves lots of tiny details.  My proposed solution is to not write
everything, but tack on other peoples libraries.  The problem there is
that I add a dozen libraries, I get a dozen implementations of basic
things like linked lists and dictionaries.  Lua for example has it's
tables, which are a dictionary plus extendable array.  But the only way
they publish to use that in C is via their horrid stack based thingy. 
That's a pain to use from C, you have to make a function call to pass
each parameter, a function call to do the thing, then another function
call to get the results.  With potentially more function calls to get
through the C <-> Lua data conversions.  Not good for "I just want to
use a dictionary from C".

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] "bad xform" not very helpful

[David Seikel]

On 2022-08-31 18:18:15, enh via Toybox wrote:
>it does by default. that's what i turned off as a workaround for this bug.

Um how does one using toybox as the foundation for something else
actually call any random toy directly?  Is there a vararg calltoy()
function I missed?

>On Wed, Aug 31, 2022, 18:15 David Seikel 
>wrote:
> 
>  On 2022-08-31 14:55:24, enh via Toybox wrote:
>  >    On Tue, Aug 16, 2022 at 12:22 PM enh  wrote:
>  >
>  >      On Tue, Aug 16, 2022 at 10:28 AM enh  wrote:
>  >
>  >        On Tue, Aug 16, 2022 at 1:43 AM Rob Landley 
>  wrote:
>  >
>  >          On 8/15/22 18:50, enh via Toybox wrote:
>  >          > and here's their minimized repro case:
>  >          >
>  >          > echo > /tmp/foo.txt; echo /tmp/foo.txt > /tmp/find.txt
>  >          >
>  >          > cat /tmp/find.txt |
>  prebuilts/build-tools/path/linux-x86/tar czf
>  >          /tmp/out.tar.gz \
>  >          >   --absolute-names \
>  >          >   --transform 's,^/,,' -T -
>  >          >
>  >          > This fails with
>  >          >
>  >          > tar: bad xform
>  >
>  >          Hmmm...
>  >
>  >          $ echo > /tmp/foo.txt; echo /tmp/foo.txt > /tmp/find.txt
>  >          $ cat /tmp/find.txt | PATH=$PWD/sub9:$PATH ./tar czf
>  out.tar.gz \
>  >            --absolute-names --transform 's,^/,,' -T -
>  >          $ tar tvf /tmp/out.tar.gz
>  >          -rw-r--r-- landley/landley   1 2022-08-16 01:53 tmp/foo.txt
>  >
>  >          Working for me? (The sub9 bit was because I stuck toybox sed
>  in the
>  >          $PATH to
>  >          make sure that wasn't it...)
>  >
>  >        repos for me, both with their prebuilt but also with a fresh
>  clone (on
>  >        either macos or linux):
>  >
>  >        /tmp/toybox$ cat /tmp/find.txt | ./toybox tar czf
>  /tmp/out.tar.gz  
>  >        --absolute-names   --transform 's,^/,,' -T -
>  >
>  >        tar: bad xform
>  >
>  >        /tmp/toybox$ 
>  >
>  >         
>  >        a bit of printf debugging shows we're reading nothing back:
>  >
>  >        /tmp/toybox$ cat /tmp/find.txt | strace -f ./toybox tar czf
>  >        /tmp/out.tar.gz   --absolute-names   --transform 's,^/,,' -T -
>  2>
>  >        /tmp/out
>  >
>  >        argv[0]="sed"
>  >
>  >        argv[1]="-e"
>  >
>  >        argv[2]="s,^/,,"
>  >
>  >        pid=1779946
>  >
>  >        stdin="/tmp/foo.txt"
>  >
>  >          len=0 Success
>  >
>  >        total=0 result="(null)"
>  >
>  >        but strace implies we're not actually exec()ing sed at all?
>  >
>  >      and if i `CONFIG_TOYBOX_NORECURSE=y`, it calls sed and works...
>  >
>  >    ...though this might be about to come back and bite me. i'm hearing
>  as-yet
>  >    unconfirmed reports that toybox `tar czf` is a lot slower than gnu
>  tar,
>  >    and -- given that they're using --transform` while they're assuming
>  it's
>  >    tar or gzip, i'm wondering whether it's actually the fact that
>  we're
>  >    forking out to sed for every file?
>  >    i've asked for repro steps or a `perf record` i can look at...
> 
>  That reminds me...
> 
>  I've long thought it would be great if toybox toys could call other
>  toybox toys directly.  So tar wouldn't fork out to sed, we have our own
>  sed, just call it directly.  Then you avoid the fork and other overhead,
>  which will probably speed things up.
> 
>  --
>  A big old stinking pile of genius that no one wants
>  coz there are too many silver coated monkeys in the world.
>  ___
>  Toybox mailing list
>  Toybox@lists.landley.net
>  http://lists.landley.net/listinfo.cgi/toybox-landley.net

> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] "bad xform" not very helpful

[David Seikel]

On 2022-08-31 14:55:24, enh via Toybox wrote:
>On Tue, Aug 16, 2022 at 12:22 PM enh  wrote:
> 
>  On Tue, Aug 16, 2022 at 10:28 AM enh  wrote:
> 
>On Tue, Aug 16, 2022 at 1:43 AM Rob Landley  wrote:
> 
>  On 8/15/22 18:50, enh via Toybox wrote:
>  > and here's their minimized repro case:
>  >
>  > echo > /tmp/foo.txt; echo /tmp/foo.txt > /tmp/find.txt
>  >
>  > cat /tmp/find.txt | prebuilts/build-tools/path/linux-x86/tar czf
>  /tmp/out.tar.gz \
>  >   --absolute-names \
>  >   --transform 's,^/,,' -T -
>  >
>  > This fails with
>  >
>  > tar: bad xform
> 
>  Hmmm...
> 
>  $ echo > /tmp/foo.txt; echo /tmp/foo.txt > /tmp/find.txt
>  $ cat /tmp/find.txt | PATH=$PWD/sub9:$PATH ./tar czf out.tar.gz \
>    --absolute-names --transform 's,^/,,' -T -
>  $ tar tvf /tmp/out.tar.gz
>  -rw-r--r-- landley/landley   1 2022-08-16 01:53 tmp/foo.txt
> 
>  Working for me? (The sub9 bit was because I stuck toybox sed in the
>  $PATH to
>  make sure that wasn't it...)
> 
>repos for me, both with their prebuilt but also with a fresh clone (on
>either macos or linux):
> 
>/tmp/toybox$ cat /tmp/find.txt | ./toybox tar czf /tmp/out.tar.gz  
>--absolute-names   --transform 's,^/,,' -T -
> 
>tar: bad xform
> 
>/tmp/toybox$ 
> 
> 
>a bit of printf debugging shows we're reading nothing back:
> 
>/tmp/toybox$ cat /tmp/find.txt | strace -f ./toybox tar czf
>/tmp/out.tar.gz   --absolute-names   --transform 's,^/,,' -T - 2>
>/tmp/out
> 
>argv[0]="sed"
> 
>argv[1]="-e"
> 
>argv[2]="s,^/,,"
> 
>pid=1779946
> 
>stdin="/tmp/foo.txt"
> 
>  len=0 Success
> 
>total=0 result="(null)"
> 
>but strace implies we're not actually exec()ing sed at all?
> 
>  and if i `CONFIG_TOYBOX_NORECURSE=y`, it calls sed and works...
> 
>...though this might be about to come back and bite me. i'm hearing as-yet
>unconfirmed reports that toybox `tar czf` is a lot slower than gnu tar,
>and -- given that they're using --transform` while they're assuming it's
>tar or gzip, i'm wondering whether it's actually the fact that we're
>forking out to sed for every file?
>i've asked for repro steps or a `perf record` i can look at...

That reminds me...

I've long thought it would be great if toybox toys could call other
toybox toys directly.  So tar wouldn't fork out to sed, we have our own
sed, just call it directly.  Then you avoid the fork and other overhead,
which will probably speed things up.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Lots of libc's.

[David Seikel]

Oops I forgot a couple things.

It's written in C and assembler.

On 2022-08-30 18:59:37, David Seikel wrote:
> The ability to run on different OSes is coz the beginning of it is a
> polyglot hack that on Linux looks like a shell script that runs the rest
> of the binary, but on Windows looks like an executable header.  Actually
> read their description of how that works for more details.  Apparently it
> can also run from bare metal, EFI can boot straight into it.  I've not
> tested that.

At the end the put the zip file header, as you mentioned, and in between
is the actual binary code and the zip file contents.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Lots of libc's.

[David Seikel]

Justine Tunney is the main developer, perhaps our local Google people
might know her, she used to work there.

On 2022-08-28 06:35:00, Rob Landley wrote:
> On 8/27/22 20:11, David Seikel wrote:
> > On 2022-08-27 04:06:58, Rob Landley wrote:
> >> Honestly: people have already done this. A lot. What new niche is not being
> >> served here? Just "not invented here"...?
> >> 
> >> Ahem. Backing slowly away, as previously mentioned...
> > 
> > Have you stumbled across https://github.com/jart/cosmopolitan yet?
> 
> Just enough to sigh deeply, note that you can sing "Dunning Kruger" to Frere
> Jacques, and move on.

If you had spent the amount of time you had spent writing that wall of
text, instead actually reading some of the top level docs first, then
your wall of text would not have so many wrong assumptions.

If I had spent more time writing that last paragraph, it might be easier
to understand.  lol



The ability to run on different OSes is coz the beginning of it is a
polyglot hack that on Linux looks like a shell script that runs the rest
of the binary, but on Windows looks like an executable header.  Actually
read their description of how that works for more details.  Apparently it
can also run from bare metal, EFI can boot straight into it.  I've not
tested that.


I once did a similar polyglot hack that merged .ini config files and
shell scripts, calling them .shini files.  Coz .ini has # as a comment
character, so it started with the usual shell -
#! /usr/local/bin/programThatReadsThisIniFile.

They do try to write their library to be POSIX, filling in some for those
OSes that are not so much POSIX.

Lots of the libc parts are assembler.

A web server in a zip file that runs most places works for my OpenSim
replacement project, since OpenSim is mostly a bunch of badly written
from scratch web servers that fall over each others feet.  Redbean can
already run itself within itself as a separation of concerns web server. 
That and Lua support greatly interests me.

> With many years of diligent effort from a very large team, the thing you 
> pointed
> at might manage to only suck as badly as cygwin. If they're very lucky. I 
> could
> be wrong and thus pleasantly surprised, but... you know, poke me if so?

It all sounds great, so long as the quality is there.  I've only begun to
poke at it, would love some others opinions that know this stuff.  And
from those that know Justine.

The down sides I have found so far -

It's assembler bits are x86 only,  Maybe only 64 bit x86.  They mention
some sort of emulation layer for ARM that I haven't looked into.

You can't really build it from scratch without using their pre built
build tools, which they do provide the source for.  I'm reminded of
Reflections on trusting trust.  I'm hoping your airlock build thingy
might help there.

Some of the code leans more towards the unreadable clever hack end of the
spectrum.  I'm good at reading code, but I know you are not.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] Lots of libc's.

[David Seikel]

On 2022-08-27 04:06:58, Rob Landley wrote:
> On 8/26/22 18:11, enh via Toybox wrote:
> > So, nobody reads my blog ("glob") at least not yet. I spent many many
> > hours developing the world's fastest qsort() implementations, but I
> > have no way to get anyone who can get them used to look at it.
> 
> Does that have a similar writeup explaining why it's better? Elliott maintains
> Bionic (still, I think?) and Rich Felker maintains musl-libc. Personally I'd
> poke Rich first (despite Elliott having written the email I'm replying to)
> because he doesn't have to run major technical changes through multiple review
> committees with a multi-year process before getting it into the hands of end
> users, and Rich also has a math degree so is thus MUCH better at reading proof
> dialect descriptions than I am. :)
> 
> > have you tried? the llvm-libc folks are effectively starting from scratch
> > (https://github.com/llvm/llvm-project/blob/main/libc/src/stdlib/qsort.cpp), 
> > and
> Sigh. I had honestly hoped that particular https://xkcd.com/927/ had died 
> during
> the pandemic, or at least quiesced like klibc and newlib. Last I'd heard it
> mentioned was
> https://hub.packtpub.com/google-proposes-a-libc-in-llvm-rich-felker-of-musl-libc-thinks-its-a-very-bad-idea/
> .
> 
> If musl/bionic/glibc don't cover it, buildroot is still maintaining uClibc-ng
> for some reason, dietlibc inexplicably still exists. (The pandemic hasn't been
> kind to its development, but you could argue that the 2019 release happened
> because posix-2018 did and they'll do another when necessary?)
> 
> The linux kernel's "nolibc.h" WAS one header file without various #defines and
> syscall wrappers and a few inline functions but at
> https://github.com/torvalds/linux/blob/master/tools/include/nolibc/nolibc.h 
> it's
> been broken up into a dozen header files that top one #includes.
> 
> If you need a tiny embedded one better than newlib or klibc, the maintainer of
> x11 is doing "picolibc" https://keithp.com/picolibc/ which uclinux founder 
> Jeff
> Dionne had us looking at for the j-core stuff last year.
> 
> In theory the MacOS's libc is based on FreeBSD's but they've forked that so 
> far
> it's unrecognizable. There was an open source "darwin" project claiming to
> underlie OSX and iOS, but https://rixstep.com/2/20190728,00.shtml explained 
> how
> the corporation producing the serial abandonware releases lost interest.
> 
> Can we call Solaris dead yet? (There was an OpenSolaris which begat Illumos.)
> 
> If you want to go into the proprietary stuff, AIX and HP-UX still exist. Xenix
> and Unixware died after SCO committed seppuku (Well, technically Caldera 
> renamed
> itself SCO and original SCO renamed itself Tarantella and then there were so
> many lawsuits, then their unix business was bought by some private equity 
> dudes
> who renamed it UnXis then Xinuos and then in 2015 migrated the remaining
> Unixware users to a freeBSD derivative and then in 2021 restarted the SCO
> lawsuit against IBM. No really! Say hi to Cravath, Swaine & Moore for me.)
> 
> And yes I'm getting bug reports on github from the qnx guys recently because
> their libc #defines stdin in a way that makes using a local variable by that
> name break:
> 
> https://github.com/landley/toybox/issues/371
> 
> And because the recent removal of the utmpx.h compile time probe 
> inconvenienced
> them:
> 
> https://github.com/landley/toybox/issues/372
> 
> We don't need another libc... (Especially not 
> another
> C library written in C++, which is honest and truly NOT the same language...)
> 
> > i'd imagine the BSDs would be receptive to improvements, even if it's super
> > annoying that there are three BSDs that don't really share code in any
> > organized fashion? (we've never found qsort() important enough to do 
> > anything
> > but track BSD; i forget which one!)
> 
> In part it's because BSD's kernel, libc, and userspace have always been
> maintained as a single giant monolithic combined repository so if you want to
> fork any of the components you have to fork ALL of it. (Linux is modular so 
> you
> can swap parts around and then work with each other. BSD very much is not.)
> 
> But there's also SO much politics. (Links to the originals on
> https://landley.net/history/mirror but you'd be lucky to pull most them out of
> archive.org, which is why I mirror stuff.)
> 
> History of BSDi:
> https://landley.net/history/mirror/unix/special2.htm
> 
> Interview with Bill and Lynne Jolitz:
> https://landley.net/history/mirror/unix/jolitz1.html
> https://landley.net/history/mirror/unix/jolitz2.html
> 
> 1999 interview with FreeBSD founder Jordan Hubbard (shortly after Apple hired
> him away to work on their proprietary FreeBSD fork which became OSX) says he'd
> already independently ported BSD to 486 (for his own use) by the time the
> Jolitz' first release came out:
> https://landley.net/history/mirror/unix/jordanhubbard.html
> 
> NetBSD seperately-ish 

Re: [Toybox] [PATCH] Fix truncate.test for macOS.

[David Seikel]

On 2022-07-04 05:21:21, Rob Landley wrote:
> It's a pity there isn't a mac dev environment I can ssh into. I can can think 
> of
> three Linux ones off the top of my head that are still up which I probably 
> have
> credentials for. (Make that five. Probably more if I thought about it.) But 
> then
> Fabrice Bellard's jslinux run a Linux vm in a web page, so "lemme try this out
> really quick" was never a high bar for Linux.
> 
> Mac, not so much...

I used to have one available for a fellow developer on another project. 
He eventually bought his own Mac.  Then the owners of the place I was
renting kicked us all out so they could tear it down and build a huge
ugly mansion for themselves.  New place I moved to has shared WiFi, and
the owner there didn't want me to get my own Internet.  This place was
sold a couple of months ago, and the new owner is happy for me to get my
own Internet.  But there's been technical issues with doing that which I
wont go into, so not done that yet.  Also waiting on a few other shoes to
drop that might kick my arse, before I go any further with that.

On the other hand, it's a 2011 Mac Mini, which wont be getting any OS
updates, coz it's EOL, and I'm not buying a new one, as sexy as these new
M1 and M2 things look from a tech perspective.  So likely entirely
useless to you anyway.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] macOS: target 10.15.

[David Seikel]

On 2022-06-03 09:43:31, enh via Toybox wrote:
>On Fri, Jun 3, 2022 at 9:27 AM Rob Landley  wrote:
> 
>  On 6/2/22 19:41, enh wrote:
>  > Oh, yeah, I think *especially* for macOS where pretty much everyone is
>  always on
>  > the latest version anyway, unless your Mac equivalent of the seven
>  year rule is
>  > "support the oldest macOS release that still gets security backports",
>  there's
>  > no reason to do this. It's pretty rare they add anything significant
>  anyway. 
> 
>  If you think the mac AOSP prebuilts should require the latest macos
>  version to
>  run, that's your call. I don't really have a MacOS policy because I'm
>  not
>  familiar enough with MacOS: they actively exclude any developer who
>  doesn't pay
>  to play. (And sadly Darwin died in 2006, although I'll blog about that
>  rather
>  than blathering here.)
> 
>sorry, i seem to have confused everyone here...
>note that [unless we check in the "our official min is
>$lowest_version_supported_by_apple" patch] anyone who builds toybox will
>get a version that targets their builder's os version. so AOSP is actually
>getting whatever it's running on, and someone with a 10.4 machine from
>2005 would get 10.4. that was always true and hasn't changed.
>what we've done [so far] is say "our CI is now testing the latest release
>that github supports at any given time" [which, modulo a month or so, is
>Apple's current release]. so our "even if we're not paying much attention,
>github will tell us if we've screwed up" bar is set at "current". which i
>think was all we were ever trying to do with github CI anyway --- "is it
>broke?". (google's security policies also mean i can't really test on
>anything older than "current" [modulo a month or so, like github].)
>the change is that we used to _also_ ask github CI to test "oldest
>still-supported macOS release". i still don't think we've ever heard from
>a user who needs that, and i don't remember ever breaking one but not the
>other [all the breakages i can remember have been solid "linux-isms" that
>wouldn't work on any macOS release], so i don't think anything's changed
>in practice.

Just to re-iterate, for development purposes I'm NOT a current Mac user,
but I plan to be one again some time in the future, so I can port my
toybox based thing to macOS.  When I start doing that is when I'll worry
about what version of macOS I run on my Mac, and hope I wont have to buy
a new Mac.  Though the new M1 based Mac Minis look nice, and maybe a M2
or later Mac Mini might be around when I get around to it.  I'm on a
pension these days though, Apple hardware tends to be a bit expensive.

Sure I recently built a super desktop computer, but that was due to our
government at the time (may they rest in pieces) throwing my money
around.  Long story short, they let us access our superannuation for
COVID.  If you don't know how that works in Australia, I'm not about to
explain it.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] macOS: target 10.15.

[David Seikel]

On 2022-06-03 11:37:52, Rob Landley wrote:
> On 6/2/22 19:48, David Seikel wrote:
> > On 2022-06-02 17:41:09, enh via Toybox wrote:
> >>Oh, yeah, I think *especially* for macOS where pretty much everyone is
> >>always on the latest version anyway, unless your Mac equivalent of the
> >>seven year rule is "support the oldest macOS release that still gets
> >>security backports", there's no reason to do this. It's pretty rare they
> >>add anything significant anyway.
> > 
> > Um do you mean there's no one running old unsupported versions of macOS?
>
> > My ancient Mac Mini is running an old unsupported macOS.  I don't think
> > they have a supported version for it.  One of these days I'll try to
> > upgrade it, but I know the latetst version wont install, though there might
> > still be a supproted version.
> > 
> > I rarely use it these days, and got more important things keeping me busy.
> 
> Are you likely to either build AOSP on it or do toybox development on it? :)

Sort of.  I'm currently writing a big virtual world thing using toybox as
the base.  I'm doing that coz toybox does a lot of the stuff I need, and
I'm hoping I can just call toybox functions instead of shelling out to
run commands.  I'd rather use one common set of POSIX compliant things
that I know works coz I bring them with me and test them, rather than
whatever shell stuff may or may not be on the users computer.

I do want to be cross platform, so eventually I'll be building for and
testing under macOS (as well as Windewwws).  Just not right now.  When I
do I'll update my Mac to be a proper dev box for what ever is current Mac
stuff at the time.  That's what I got my Mac for in the first place,
doing virtual world development.  But that was client side, I stopped
doing that to work on server side for a while.

Development is under Devuan Linux for now.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] macOS: target 10.15.

[David Seikel]

On 2022-06-02 17:41:09, enh via Toybox wrote:
>Oh, yeah, I think *especially* for macOS where pretty much everyone is
>always on the latest version anyway, unless your Mac equivalent of the
>seven year rule is "support the oldest macOS release that still gets
>security backports", there's no reason to do this. It's pretty rare they
>add anything significant anyway.

Um do you mean there's no one running old unsupported versions of macOS?

My ancient Mac Mini is running an old unsupported macOS.  I don't think
they have a supported version for it.  One of these days I'll try to
upgrade it, but I know the latetst version wont install, though there might
still be a supproted version.

I rarely use it these days, and got more important things keeping me busy.

>On Thu, Jun 2, 2022, 17:34 Rob Landley  wrote:
> 
>  On 6/2/22 12:43, enh via Toybox wrote:
>  > 10.15 is currently the oldest macOS release that's still getting
>  > security updates (probably until the end of 2022, if history is any
>  > guide). Without this, toybox built on newer versions will by default
>  > target that version.
>  >
>  > Tested by adding -v and seeing that the "sdk" in use changed from
>  > 12.0.0 by default to 11.0.0 with this flag (Apple has multiple
>  > version numbering schemes; my kernel says it's 21.5.0 already!).
> 
>  Hmmm... Switching which version github is building is one thing, but
>  switching
>  the default in scripts/portability.sh seems a bit micromanagey? (I
>  wouldn't
>  think an -mtune for Linux would belong there...)
> 
>  Rob

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] ftpget: Remove

[David Seikel]

On 2021-10-29 17:22:33, Eric Molitor wrote:
>I genuinely had trouble finding an FTP server to test until I remembered
>those two.

Devuan Linux has FTP servers for both our ISO and package repos.  My own
Devuan mirrors support FTP, and my daily logwatch says people are using
them.

https://www.devuan.org/get-devuan for ISO mirrors

https://pkgmaster.devuan.org/mirror_list.txt for package mirrors.

sledjhamr.org in those lists is my mirror.

(I'm the Devuan package mirror herder.)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] init.c ? and oneit

[David Seikel]

On 2021-05-01 10:03:27, scsijon wrote:
> 
> On 30/4/21 6:13 am, toybox-requ...@lists.landley.net wrote:
> > On 4/29/21 12:08 AM, scsijon wrote:
> > > On 20/4/21 5:19 pm, Rob Landley wrote:

> > B) what spec? Posix doesn't _mention_ init (or mount), which is one of my
> > persistent gripes about it.
> Search under mutex and pthread, makes basically the same thing with a
> different name (IEEE Std 1003.1-2001 to start from), the mutex name came
> from mainframes from memory. And then there are the posix 'semaphores' if
> you want to go that way.
> > > Includes timeslot and processor
> > > allocation configuration as well as levels assignment for logins linked to
> > > devices just to start with.
> > Um, are you referring to systemd?
> no
> > Which is not sysv init? (You can call taskset,
> > there's container infrastructure...)
> > 
> > > !NOT going there again, 3 months wasted many years
> > > ago, without any usefull code, just specs read and flowcharts created, 
> > > "^" wasn't happy.
> > Ah, I was confused because you're referring to something only you ever
> > experienced as if other people should know it.
> 
> No, there are earlier specs, that start from late last century, for init
> from unix, xenix (286/386/486), hp-ux (intel and RISC) and icon-ux
> (Motorolla) multi-processor minicomputers, all I was asked to and tried to
> do to start with was flowchart for parts that would work for the standalone
> system that we called workstations to get rid of the unneeded code to freeup
> memory, about half of it we thought, and add an auto-restart into it (didn't
> exist back then, it was all manually done unless it crashed). If you really
> want to see them, they should/maybe be on the appropriate archive sites, I
> do have a copy of a couple of the manuals in boxes somewhere in my archive
> storage room if they really need to resurface.

For what it is worth there is a LSB spec that I followed a long time ago
writing a sysv init that I vaguely recall submitting to busybox.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Phone docking stations for general purpose computing.

[David Seikel]

On 2020-05-22 00:20:06, Rob Landley wrote:
> On 5/21/20 9:49 PM, David Seikel wrote:
> > So yep, we can prototype the idea now, but I have my doubts that the
> > world is ready for it yet.  After all, why sell a cheap phone with a
> > single USB-C port that can do everything via a cheap docking station that
> > can be bought at your local supermarket next to their cheap USB
> > keyboards, when you can make more money selling more expensive phones
> > and lots of adaptors?
> 
> By that logic why would anyone sell a PC when they could have sold a
> minicomputer? Because vendors who sell what customers want to buy take market
> share from vendors who don't, and "this is more profitable for me to sell
> therefore I'll ignore everything else" has driven plenty of vendors out of
> business over the years.
> 
> Right now "lack of cheap usb-c hubs" and "android phones aren't autodetecting
> usb video adapters out of the box" seem limiting.
> 
> The hub problem is because conventional USB is still dominant for peripherals
> (no reason for mice and keybaords to have a different plug when adapters 
> exist,
> most network dongles and usb sticks still use the old interface), and there 
> are
> usb C cables to plug into a conventional hub so phones _can_ play in that
> ecosystem. I guess as long as the hub is usb3 it's all the same speed...
> 
> As for video, it looks like Google's provided solution is chromecast and 
> that's
> where they stopped trying. But at least it seems like that can cast the 
> android
> desktop to a TV:
> 
>   https://support.google.com/chromecast/answer/6059461
> 
> My wife's experience with that was it's an overengineered solution that 
> requires
> a gratuitous wireless router between the phone and the chromecast, and won't 
> get
> the volume to become cheap becuase of it. But it's available today. Somebody
> should try to prototype a usb solution with a pi zero and VNC or mp4 
> streaming...

And I found out the hard way that the security settings on the WiFI in
the local city councillors office prevented Chromecast from working.  I
didn't have a proper phone docking station working at the time either. 
So when they let me sit in their office all day during a 40 degree C hot
day, I ended up having to borrow a spare office laptop, instead of the
impressive "look, I can computer on my phone" demonstration I had
planned.

When it works Chromecast is great for the portable VR demos, I can watch
it on their big screen and tell the novice with my phone strapped to
their face, "no it's on your right, and look down a little, yes the blue
thing", coz I can see what they are seeing instead of guessing.

> > Long ago as a teenager I used to enjoy reading hard science fiction where
> > the protagonists could do wonders with modular technology that you could
> > just plug it all into each other, and it would just work.  I dreamed of
> > growing up into that world.  This isn't that world.  This is Profit, Plug
> > & Pray, toss it all into landfil, PROFIT! world.
> 
> No, you're describing immature technologies. Mature technologies are 
> thoroughly
> commoditized, immature technologies are vendor-specific.
> 
> Once upon a time the Ford Model T wasn't like other cars, you could only get
> what it offered from the one manufacturer and were then locked into a
> proprietary vendor ecosystem. These days neither the gas station nor jiffy 
> lube
> cares that much who made your car.

And now with Android for cars, you still can't plug a KVM into your
dashboard and sit in the back seat developing on the thing during a long
drive.

> And cars aren't NEARLY as mature a technology as socks or silverware or a bag 
> of
> rice. "Great spoons, who did the metalurgy" is not a question that comes up 
> much
> these days.

"That spoon isn't compatible with this soup, so you can't eat it." I
suspect is something no one ever said, but I'm not as great a scholar of
history as you.  "There is no spoon." is something someone did say, but
that was part of a movie.

> Even with LED light bulbs, I have no idea who manufactured the ones
> in my kitchen because it doesn't matter. I have no idea who made my dishwasher
> or microwave. They're amazingly high-tech by the standards of 100 years ago, 
> but
> are mature technologies today, and they just work.

I haven't managed to find an LED light bulb that was compatible with my
last two 'fridges.  It really doesn't matter, I don't leave that bulb
turned on for hours, but I have switched everything else to LED.

Light bulbs, microwave ovens, dishwashers, are becoming IoT things these
days, that want to talk to some specific companies web server.  When that
company decides 

Re: [Toybox] Phone docking stations for general purpose computing.

[David Seikel]

On 2020-05-18 23:49:49, Rob Landley wrote:
> On 5/18/20 4:47 PM, scsijon wrote:
> > Have a look for this, it may do for you.
> > 
> > Hyper HyperDrive SOLO 7-in-1 - Silver
> 
> https://www.hypershop.com/products/hyperdrive-solo-hub-for-usb-c-macbook-pc-devices
> 
> > Turns a single USB-C port into 7 ports (4K/30Hz HDMI, USB-C Power Delivery,
> > 2 x USB-A, Micro SD, SD, 3.5mm Audio Jack), works for MacBook, PC, 
> > Chromebook,> Android laptop and phones.
> 
> Also seems unlikely to be widely available thirdhand in the places the 
> planet's
> 3 billion least privileged inhabitants live. They've got phones _now_. More
> people around the world have had phones that toilets since before my 2013 
> talk:
> 
> https://www.forbes.com/sites/timworstall/2013/03/23/more-people-have-mobile-phones-than-toilets/
> 
> I've personally helped multiple homeless people buy android phones, Even in 
> the
> $USA "straight talk" phones are $40 at walmart and the prepaid data plan's
> $15/month. (Yeah it's an adware phone, but it still lets them download video 
> at
> starbucks while they're catching up on twitter and charging at an open outlet,
> then watch it that night on battery.)
> 
> > About $A99 at full price, should be able to get cheaper elsewhere.
> 
> It's a good start and it's nice to see it, but this looks like a modern 
> version
> of the samsung "usb docking station" I mentioned ten years ago:
> 
>   https://landley.net/notes-2010.html#09-10-2010
> 
> Meanwhile, food insecurity remains a thing.
> 
>   http://www.fao.org/state-of-food-security-nutrition
> 
> I'm trying to figure out how include those multiple billions of people WITHOUT
> having to solve world hunger first. And "keeping old devices out of landfills 
> by
> still being useful" seems a good start.
> 
> But sure, in a "prototype now" sense, I'm all for it. Might order one. :)
> 
> Thanks,
> 
> Rob
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net

I spent most of yesterday looking at these sorts of devices on Newegg. 

There are plenty of USB-C docking stations, that feed power into the
USB-C host device (if the host device supports USB PD "Power Delivery"
charging), and a variety of video outputs (if the host device supports DP
Alt Mode “Display Port Alternate Mode” and / or Thurderbolt 3) like HDMI,
VGA, and Display Port.  Usually including Ethernet ("for more stable
connection"), card readers, some USB power / data, and maybe audio.  Some
of them just pass through audio from your MacBook.

The great majority of them are for MacBook Pro.  Very few of them mention
using a phone as the host, but lots of them mention plugging in a phone
to charge it.  Slowly.  For some odd reason, phones with PD charging can
only accept 1.5 A through PD charging, but your laptop can accept much
higher.  At least according to those Newegg device descriptions that
bother to mention that detail.

Of those with a list of supported devices, typically they are MacBooks,
Dell laptops, Chromebook Pixels, Samsung Galaxy from about 8 up, and
several other recentish high end phones.  Alas none mention my Motorola
Z, nor Google Pixels.

Priced anywhere between AU$70 and AU$300, though most seem to be Chinese
clones.  Possibly just rebadged from a single Chinese manufacturer.

Since I already had USB-C dongles for audio and display (of the $5
variety), I also went looking for USB-C hubs, but all I could find was
USB-C to multiple USB-A hubs, but at least some of them provided for
getting power into your phone, though most had a OTG / power switch.  So
you could power your phone, or use your keyboard and mouse, but not both
at the same time.

Sadly it looks like there's no "one small device" solution for me, just
"carry around a bunch of adaptors AND the bulky Moto Mod developer box,
plus a wallwart".  At least the Moto Mod dev kit leaves me with four
usable USB ports, KVM and one of audio / Ethernet / power.  Or add one of
those USB-C to USB-A hubs.

So yep, we can prototype the idea now, but I have my doubts that the
world is ready for it yet.  After all, why sell a cheap phone with a
single USB-C port that can do everything via a cheap docking station that
can be bought at your local supermarket next to their cheap USB
keyboards, when you can make more money selling more expensive phones
and lots of adaptors?

Long ago as a teenager I used to enjoy reading hard science fiction where
the protagonists could do wonders with modular technology that you could
just plug it all into each other, and it would just work.  I dreamed of
growing up into that world.  This isn't that world.  This is Profit, Plug
& Pray, toss it all into landfil, PROFIT! world.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net

Re: [Toybox] Phone docking stations for general purpose computing.

[David Seikel]

On 2020-05-17 20:42:05, Rob Landley wrote:
> Hey Elliott, USB-C to HDMI adapters are going for $5 now. If I grabbed 
> something
> like https://www.ebay.com/i/312982429778 or 
> https://www.ebay.com/i/302957153131
> or any of the dozen others, and plugged that and my pixel 3a into the same 
> usb-c
> hub, could I get the display on my TV and if so what would I need to do?
> 
> Next question: ARE there any usb-c hubs, and if so what keyword should I be
> looking for to find them? All the hubs seem to be "USB-C to 4 USB-A" 
> splitters.
> so far. (It's like trying to find a gigabit ethernet switch in 2005: it's all
> one uplink port and the rest is 100baseT.)

The big problem vith that is that not all USB-C is created equal. 
Specifically, not all of them support video out.

For example - My Motolora Z has a USB-C, and is compatible with the
Motorola Moto Mod system (add on hardware system that clips hardware
extensions onto the back magnetically).  I can plug HDMI and USB keyboard
/ mouse into that, but not using the USB-C that is on the phone itself. 
I have to use the USB-C that is on the Moto Mod developers kit, which is
a Moto Mod with three USB ports, two USB-C and one micro B.  The HDMI
comes out of one of those extra USB-C, but only using a hacked up Moto Mod
firmware.  No video is available on the phones own USB-C, so I use that
for the keyboard / mouse.  I plug the lot into my KVM.

A powered hub that can supply power to the phone while you spend all day
developing on it would also be useful.

Another option for getting video out of a phone is Chromecast via WiFi. 
That's what I use to give Google Daydream VR demos, so I can watch what is
on the screen of the phone strapped to someone elses head.

> Anyway, it occurs to me that with the shift from 32 to 64 bit hardware (which 
> is
> why so many devices got stuck on Android-M: they were 32 bit) plus the shift 
> to
> USB-C, means I may need to draw a line in the sand.
> 
> What I probably should be targeting is "5 years from now there's gonna be a 
> lot
> of old 64 bit phone hardware with USB-C in the backs of drawers", and people
> will want to use that as hobbyist development systems the way Linux took over
> all the old 386 PCs in the 1990's but ignored the 286 systems.
> 
> Everything _older_ than 64 bits with USB-C is basically 16-bit ISA PCs at this
> point, which would be _nice_ to support but getting that to rebuild itself 
> under
> itself is less useful, because that pool of hardware is shrinking from here on
> out and the other is doing all the growing.
> 
> What's  useful is teaching new systems to have a "general purpose computing
> mode" (in a container or whatever) that can plug the phone into keyboard, 
> mouse,
> and big display, and having THAT instead of having a PC means you are not a
> second class citizen but a full-fledged developer. The "docking station" to 
> give
> a phone a real screen, keyboard, and mouse is a usb-c hub, usb mouse and
> keyboard, and a $5 hdmi adapter, which is all cheap generic and (eventually)
> ubiquitous.

There might be ubiquitous USB-C gadgets, but it'll be the return of Plug
and Pray to see if you are lucky enough to have the correct set of
gadgets that will talk to each other in the way you want.

On the plus side, once the hardware is sorted, things just work.  I
didn't have to teach my phone about external mice or keyboards.

> At some point I'd like to be able to draw a line in the sand and say "from 
> this
> system and on newer, you don't need a PC anymore, not even to do Android OS
> development". Then the PC can go the way of the mainframe and minicomputer
> before it, no longer the machine anyone sits down at to do their work, it's 
> just
> big iron at the other end of some network cable that only its priesthood ever
> needs to touch.
> 
> But what would be really nice is the ability to prototype this now. Can I put
> together such a docking station that works with a modern phone? Getting a
> terminal on the screen with a posix container that can build AOSP is just
> software at that point. (And stripping down AOSP so it doesn't take an 16x 
> cloud
> server hours to build it is also just a question of putting in the work. For 
> one
> thing, you don't "make debian", you make and install packages...)
> 
> Rob
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] vi: don't exit on ^C or ^D.

[David Seikel]

On 2020-01-23 11:40:19, Rob Landley wrote:
 
> My own todo list item for a text editor was to make a generic engine I could
> implement vi, emacs, nano/edit, and joe (wordstar) keybindings on top of (and
> MAYBE share plumbing with less and watch).

Which I did write for you, including sharing plumbing with less.  But
your inability to read code resulted in you telling me it was too big for
you to read.  That's a lot of functionality to try to cut down to
something small enough for you to read, and it couldn't be done without
turning it into a trivial blob of code that didn't actually do anything,
which I tried and was also rejected.  Possibly coz it didn't actually do
anything.

The rest of the stuff you mention below would have just made it bigger on
that first attempt, so I was doing the simple thing to keep the initial
code drop smaller.

> I was mostly worried about the
> lifetime rules for large text blocks on memory-constrained and nommu systems
> where large contiguous allocations become rapidly problematic; I was thinking
> copying data into .swp files so I wasn't depending on the original mmapped 
> file
> not to change out from under me but I also wasn't needing to keep a 2 gigabyte
> linux-kernel mbox file in memory because I was searching around for that one
> email (yeah I should use "less" instead, but it's terrible for this sort of
> thing and see above about wanting shared plumbing), and hence the "array of
> pointer+length to block-of-text" representation, but not one BIG
> array-of-pointer because just the line index tracking on my inbox mbox that 
> goes
> back to 2013 probably takes more memory than my Turtle board has (it's 1.3 
> gigs,
> wc says just under 20 million lines, so *8 and the box has 256 megs _before_ 
> you
> boot the kernel...).
> 
> It's one of those things where "what counts as pilot error" is a judgement 
> call
> and you need an analysis of usage patterns, and more to the point I needed to
> check what the kernel did for MAP_PRIVATE mappings where another process 
> changes
> a part of the file that this process hasn't faulted in yet BUT it's still
> covered by the mapping, and maybe madvise comes in here...? Yes only a 64 bit
> system could reliably map full files and 32 bit would need its own codepath, 
> and
> nommu would also need its own codepath, and maybe only 64 bit with mmu would 
> get
> properly reliable behavior and the others would just get best effort...
> 
> But I didn't get around to it in time and the decision was taken out of my
> hands, so it goes on the "dead idea" pile along with implementing screen.

It was your decision to not accept my editor code, then later someone
else wrote a vi, which you did accept.  It could have shared code with
screen as well, which I recall you dropped coz of me "bikeshedding",
where I was suggesting features that you could have just said "no" to.

> *shrug* Happens.

Yeah, shit happens, now I have to make other plans.  sigh

Though I'd happily give it another chance, spruce it up to work with
todays toybox code, merge it with the existing vi code, etc.  Just not if
you are gonna reject it again.

On the other hand, "other plans" means converting it to use Lua as the
glue layer between the C editing functions and the various editor key
bindings.  Something I'd much rather do anyway, though I recall you
dropped your initial idea to include Lua in toybox.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Finally being forced off gmail...

[David Seikel]

I didn't get that email, but I'm not using G Suite.

On 2019-12-17 15:38:30, Rob Landley wrote:
> Sometime between now and Feb 15 I need to move my email off gmail because pop3
> support is joining the Google Graveyard (at least that's how I read the 
> attached
> email). I'll probably switch it to use dreamhost's servers, but just letting 
> you
> know I may be incommunicado for a bit (and maybe lose some email in the 
> switch).

BTW, the email says "June 15, 2020" and "February 15, 2021", not Feb 15
2020, so you might not have to spend your holidays dealing with this.

They specifically mention IMAP, so my guess is they mean POP3 as well.

I've been encouraging people to move off Google email and chat systems
for some time.  I still have one set of mailing lists on gmail, the rest
I moved long ago.  I was surprised at how easy it was to move my "hates
change, is computer illiterate" girlfriend to switch to Signal, she loved
it the moment she found out how easy it was to share photos.  Google
Hangouts moving to the Graveyard encouraged her to do things my way this
time.  Now she has switched her family members to it as well.

>Note: If the app you are using does not support OAuth, you will need to
>[13]switch to an app that offers OAuth, or ask your admin to contact the
>supplier of your app and request that they add OAuth as a way of
>connecting your Google account.

I currently use fetchmail to pull things off gmail via POP3.  Alas it
doesn't seem to support OAuth, a quick grep trough the man page didn't
find it.  I've had zero problems with fetchmail, I don't really want to
go searching for an alternative.  I wont miss the regular "some one evil
tried to access your email, we blocked them" emails I get from Google coz
I'm using a "less secure access app", and then having to unblock myself.

Now I have a deadline for fully moving off gmail.

I'm part way through moving all my stuff to my own server, off other
peoples computers, coz other people keep pulling this crap on me.  I
never liked "The Cloud" for exactly this reason.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Fwd: hexedit uses VT-420 scroll ctrl sequences which dont work on tty1

[David Seikel]

On Thu, 26 Sep 2019 08:49:10 -0500 Rob Landley said :
> On 9/25/19 12:59 PM, David Seikel wrote:
> > On Wed, 25 Sep 2019 12:24:13 -0500 Rob Landley said :  
> >> On 9/24/19 1:18 AM, Jarno Mäkipää wrote:  
> >>> Hi
> >>>
> >>> I now tested to run hexedit in tmux: downscroll works but upscroll
> >>> does not... Well we might say its tmux fault, but lots of people
> >>> use tmux nowadays. And this behavior seemed to be same in
> >>> framebuffer console and xterms...
> >>
> >> I have a todo item to write a screen for toybox. I'll make sure
> >> this works there. If you want to submit a bug report to the old
> >> one, have at.  
> > 
> > Would writing a tmux be a better option than a screen?  I prefer it
> > for several reasons, the major one being that I can script reading
> > and writing text to what ever command is running inside tmux (in my
> > case OpenSim consoles for cron'ed backups).  Mouse support is handy
> > to.  
> 
> I started using screen on the sunos workstations at Rutgers in 1992.
> I've never used tmux. This is the first I've heard they're different?

Admittedly it's been some time since I switched from screen to tmux.
I've just done some reading now, and it looks as if they are now a bit
more similar in features.  When I switched some of the differences
where important enough to me that I did switch.

https://wtanaka.com/node/8136?utm_source=linuxnewssite.com is the best
I found after a quick search, that shows the basic differences.

I mentioned above that tmux allows scripting.  Robert Thompson pointed
out -

> That all works in screen, at least to some extent. Years ago I
> discovered I could write a script and connect its stdin to the stdout
> of whatever was in the screen, and vice versa.

Which isn't really the same thing.  The scripting I was talking about
is where you can run a tmux command from outside the tmux session that
feeds text into a running tmux session, and reads text coming from that
session, but still have that session being interactive.  In Opensim
there are several console sessions, each is interactive, and I run a
cron job that feeds commands into them, and waits for certain text to
say the command has finished before doing something else.  This wasn't
possible with screen when I first switched to tmux, but apparently now
it is possible with screen.

I've not been able to find out much about modern screen mouse support,
except that it supports mouse wheel scrolling the contents.  I remember
years ago I showed tmux to a manager of mine and he was very excited
about how much you could do with the mouse in tmux that wasn't possible
in screen.  Resizing panes by dragging the border had him shouting in
sheer happiness.  I use the mouse support all the time.

There are naturally lots of little differences, tmux is the same sort
of thing as screen, not a clone of screen.  First thing I did with tmux
was to configure it to be a bit more screen like, so it would be more
comfortable for my screen using co-admins.  The major obvious
difference is the prefix character, simple to change that.

The one thing that truly annoys me about tmux is they keep changing the
format of the mouse options in the config files.  Only slightly less
annoying is that sessions shared with others use the smallest terminal
size, which only annoys me coz I use a huge terminal with tiny font, so
when I share it becomes smaller to match the terminal of who ever I'm
sharing with.  Screen doesn't do that.  According to what I have been
reading today, there's a way around that in tmux now.

The above web page mentions automatic renaming of windows.  I dunno if
screen can do that, but you can also name the windows using tmux
commands.  Very handy for my OpenSim usage, as all but one window uses
the same command, so I need to rename them so I can tell them apart.

BTW OpenSim is a 3D virtual world, an open source fork of Second Life.
The usage I'm talking about here is the running of the server consoles,
which are terminal based things.  One of them is the base server, the
others are per "sim", a 256 x 256 meter area of virtual land.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Fwd: hexedit uses VT-420 scroll ctrl sequences which dont work on tty1

[David Seikel]

On Wed, 25 Sep 2019 12:24:13 -0500 Rob Landley said :
> On 9/24/19 1:18 AM, Jarno Mäkipää wrote:
> > Hi
> > 
> > I now tested to run hexedit in tmux: downscroll works but upscroll
> > does not... Well we might say its tmux fault, but lots of people
> > use tmux nowadays. And this behavior seemed to be same in
> > framebuffer console and xterms...  
> 
> I have a todo item to write a screen for toybox. I'll make sure this
> works there. If you want to submit a bug report to the old one, have
> at.

Would writing a tmux be a better option than a screen?  I prefer it for
several reasons, the major one being that I can script reading and
writing text to what ever command is running inside tmux (in my case
OpenSim consoles for cron'ed backups).  Mouse support is handy to.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Editor for toybox?

[David Seikel]

On Tue, 24 Sep 2019 12:50:12 +1000 scsijon said :
> Do I remember you considering adding a multi-purpose editor into 
> toybox?

I had written a very basic generic editor for toybox long ago, with
plans to add more advanced features to it.  Rob didn't like it, so it
never made it in.  That's been on hold since then, but soon I'll be
reusing the code for another project.  It supported all the usual editor
varieties, and some more - emacs (microemacs), joe (Wordstar), less,
mcedit/cooledit (part of Midnight Commander), more, nano/pico, vi.

While it is on github, I moved all my stuff to my own server -

https://sledjhamr.org/cgit/boxes/

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] vi: small fixes.

[David Seikel]

On Sun, 8 Sep 2019 03:03:52 -0500 Rob Landley said :
> On 9/8/19 2:08 AM, Jarno Mäkipää wrote:
> > Mailinglist didint send me Rob:s message and I feel like I am
> > missing sometimes other messages too. But I saw robs message on
> > archive so wanted to reply anyway so i copy pasted it here...  
> 
> Check gmail's spam filter. I just had to fish all of scsijon's
> messages out of it.
> 
> And I got unsubscribed from my own list again yesterday by a
> gratuitous gmail delivery refusal (of my own message sent back to me
> by the list), and missed the start of the vi thread because of it. (I
> had to apply Elliott's patch by downloading it form the web archive.)
> 
> These days, gmail is bordering on unusable. I'm only still washing my
> email through it due to historical inertia...

I guess it's time for the semi-regular, all together now - 

Stop using gmail for mailing lists everyone!

Your friendly, no longer using gmail for mailing lists, correspondent.


P.S.  OK, still using it for one collection of mailing lists I haven't
gotten around to changing yet, but they have half a dozen lists and at
least one web site I have to change.  It's on the TODO!  And not
particularly important anymore, so low priority.  Even the developers
on that project rarely use their lists.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] I merged mkroot.

[David Seikel]

On Sat, 24 Aug 2019 11:56:12 -0500 Rob Landley said :
> So if you "make root" it'll build a simple toybox based root
> filesystem, and if you have $LINUX pointing to a linux source
> directory, it'll build it based on whatever architecture your cross
> compiler points to.

Cool.

I'd love to eventually move that i486 device to this, but it's been
through government labs for auditing, and that's a lengthy and
expensive process the client doesn't want to repeat unless he has to.
So that device is stuck on what ever versions of things it had at the
time.  He keeps dropping the ball on starting the new project that'll
reuse the same code, so I doubt that's happening any time soon either.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Toybox in Devuan / Debian. Was: [PATCH] losetup: fix the race.

[David Seikel]

On Thu, 8 Aug 2019 21:55:02 -0500 Rob Landley said :
> On 8/8/19 9:00 AM, David Seikel wrote:
> > Now that you mention it Devuan has a busybox package, via Debian,
> > but no toybox package.  If we want to do something about that the
> > question becomes - do we push it into Debian, or push it into
> > Devuan?  I might be able to help with the later.  
> 
> Devuan is a fairly light reskin of debian, if it goes into one it'll
> presumably go into the other before too long.

The correct thing to do would be to push it into Debian.  Devuan
package mirrors serve the Devuan versions of those few packages that are
different for Devuan, then redirect everything else to Debians package
mirrors.  Some Devuan mirrors also mirror Debian, so they handle the
lot.  So if a new package gets added to Debian, Devuan picks it up
automatically.  Though obviously if the new package depends on systemd,
then hopefully the Devuan folks will notice and attempt to do something
about that.  That wont be a problem for toybox.

> A .deb packaging of toybox has been on my todo list for a while, if
> you want to take a stab at that I'm happy to support you however I
> can. :)

I mentioned above that I might be able to help with a Devuan package
since I'm one of the Devuan devs (I help maintain the mirror system).
So my "help" to push it into Devuan mostly would have been me waving
toybox around and asking "anyone wanna package this".

Like yourself my TODO lists runneth over.  I not only have a TODO list
that lists the other TODO lists, I've recently installed MantisBT to
help track some of them.  I'm semi retired, gotta have something to do
with my time.

I've been writing a new mirror testing script for Devuan, and one of the
plans is to make it generic, so other .deb based distros could use it
to.  Then I get to package it up and push it into Debian.  That will be
my first attempt at getting something into Debian, though I have in the
past been responsible for some .rpm packages in Yellow Dog Linux.  So
I'll add "get toybox pushed into Debian" onto my TODO, and let's see
which one of us gets around to it first.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] Toybox in Devuan / Debian. Was: [PATCH] losetup: fix the race.

[David Seikel]

On Thu, 8 Aug 2019 08:10:12 -0500 Rob Landley said :
> On 8/7/19 10:59 AM, enh wrote:
> > and if the next stage in your personal "surely this can't be true?"
> > journey is the same as mine, the answer i got from our init
> > maintainer for the "why?" is that the kernel doesn't want to have
> > an opinion on permissions etc. (they pointed out that Android's
> > setup actually reduces the size of the window compared to the
> > desktop.)  
> 
> I remember the lwn.net argument, but I thought they _did_ merge
> default permissions in? (I remember the argument but not the
> resolution...)
> 
> Looks like permissions went in: https://lwn.net/Articles/353849/
> 
> Ah, I see what happened to ownership:
> 
> https://lwn.net/Articles/546464/
> 
> It was submitted to the kernel by a bad messenger:
> 
> https://www.theregister.co.uk/2014/04/05/torvalds_sievers_dust_up/
> 
> (Who of course went on to become one of the core devs of systemd.
> Which is why I'm using devuan.)

Now that you mention it Devuan has a busybox package, via Debian, but
no toybox package.  If we want to do something about that the question
becomes - do we push it into Debian, or push it into Devuan?  I might
be able to help with the later.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] scan_key: support more terminals.

[David Seikel]

I presume you meant to send this to the list.

On Fri, 12 Apr 2019 15:52:10 -0500 Rob Landley  wrote:

> On 4/11/19 9:46 PM, David Seikel wrote:
> >>> luckily i suspect in 2019 we mainly want function keys just so we
> >>> can throw them away and get on to the next meaningful keypress!
> >>> but i can easily put this back to one constant per key if you
> >>> prefer.
> >>
> >> Unfortunately a command line utility doesn't get to _see_ the
> >> function keys, so yeah probably.  
> > 
> > Users of mc and mcedit need functioning function keys, though they
> > do have a backup of Esc $DIGIT, which helps when a lot of X
> > terminals use F10 for their menus.  I know I long ago tried to get
> > mcedit into toybox.  
> 
> I googled, the first page is entirey about a world editor for
> minecraft?

mcedit is the text editor that comes with midnight commander, it can
be used stand alone.  Dunno about minecraft.

> (I never used midnight commander but I used to use xtreegold back
> under DOS, which is presumably what it cloned.)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] scan_key: support more terminals.

[David Seikel]

> > luckily i suspect in 2019 we mainly want function keys just so we
> > can throw them away and get on to the next meaningful keypress! but
> > i can easily put this back to one constant per key if you prefer.  
> 
> Unfortunately a command line utility doesn't get to _see_ the
> function keys, so yeah probably.

Users of mc and mcedit need functioning function keys, though they do
have a backup of Esc $DIGIT, which helps when a lot of X terminals use
F10 for their menus.  I know I long ago tried to get mcedit into toybox.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] alias tar="tar --restrict"

[David Seikel]

For what it is worth, OpenSim (the open source Second Life clone I do a
lot of work in) has .iar and .oar files, which are just .tar.gz files
with a specific restriction in the order of files in them.  These
files are archives of a users in world inventory, or parts of their
inventory (.iar files), and an archive of a "sim" or "region" (.oar
files).  "Sim" / "region" is the basic unit of land and 3D contents,
being 256 x 256 x Z meters.  Initially Z was 4096 meters of height,
later extended to 16384 meters, possibly higher now.  Though due to the
floating point nature of of the coordinate system, anything above 16 km
gets the jitters.

I generally just rename them to .tar.gz and use the usual tar and
friends on these files.  I just have to be careful when creating them
to put the files in the correct order.

Likely the above is more FYI than actually any issue with what you
propose.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] gmail unsubscribed everyone from the list again.

[David Seikel]

> I fixed it all up via the web gui when gmail did this last week, and
> I just fixed it up again after yesterday's mass-bouncing, but I'm
> kind of tired of it.
> 
> As far as I can tell, other mailing lists are coming to a "gmail is
> too dysfunctional to use with mailing lists" consensus:

I've been saying that here for some time.  Everybody just move off gmail
and be done with it.  My non gmail address wasn't bounced off the list.
Gmail is bad, m'kay.  Protonmail.com works OK if you want a web based
alternative.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Alternatives to github?

[David Seikel]

> (I've been thinking of putting it on landley.net but dreamhost's docs
> about putting anything there are all "you can store your website in
> a .git repo, and then mirror your website repo to github!" That's not
> what I'm trying to do, thanks. Can I get a cgit instance running on
> landley.net/git/toybox or similar? Sigh, I may have to host my own
> server at some point. Really dowanna do that, but I miss the control
> of back when I _did_ do that and the "send us a raspbery pi" folks
> don't seem too crazy...)

I have a TODO item for finding an alternative to github, and I have my
own server in Europe.  Among other things it's one of the mirrors for
Devuan packages and ISOs.  I've not played with cgit before, and I note
it's in the Devuan package repo, so I might install it and give it a go.

I'm happy to share Rob.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Of course gmail unsubscribed me for that.

[David Seikel]

> If you also didn't get the big long "how patch works" email I sent
> because gmail, it's at
> http://lists.landley.net/pipermail/toybox-landley.net/2019-January/010049.html
> 
> (It went OUT through gmail's smtp server, and was then bounced as
> spam when the mailing list delivered a copy back to gmail. And not
> "filed in the spam folder" but "delivery refused, repeatedly, until
> the retries triggered an unsubscribe". Bravo. Magnifique.)

I've had zero problems with missing emails, bounces, or being
unsubscribed since moving my mailing list subscriptions off gmail.  I
highly recommend it.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Tired of gmails nonsense.

[David Seikel]

Rob Landley wrote:
> On 12/4/18 1:30 PM, Ivo van Poorten wrote:
> > On Tue, 4 Dec 2018 13:54:10 +1000 David Seikel
> >  wrote:  
> >> I'm not sure if it's gmails fault entirely, but I've only been
> >> seeing about half of the posts to this list.  Mostly those from
> >> enh of late.  
> > 
> > The same is happening here. I only see enh's replies and none of
> > Rob.  
> 
> Did you ever start seeing my replies?

I think you are asking Ivo instead of me.

For the record my non-gmail address is now getting every message from
this list.  I've started switching over on all my other mailing lists.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] mktemp: fix the tests and the logic.

[David Seikel]

> Sorry for the delay replying, gmail unsubscribed everybody from the
> list again and I had to do the web gui dance.

I had left my read only gmail account on this list as a comparison to
my account on my own email server.  As expected, the gmail one did the
bouncy spam thing, mine didn't.  So I'll go and properly remove my
gmail one now, should not be any of my gmail accounts left in your
mailing lists anymore.  That's one less to dance for next time.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] macOS: move getmountlist.c functions into portability.c.

[David Seikel]

> What ever it is, this isn't the first mailman driven mailing list I'm
> having that problem with.  I wonder if there is a simple to use
> "convert base64 encoded ASCII emails to just plain damn ASCII emails"
> utility I can bolt onto my mail filtering pipeline and be done with
> it?

I logged onto the mailman options page, changed "Get MIME or Plain Text
Digests?" from "Plain Text" to "MIME", which the descriptive text
strongly implies it only changes how digests of bundled posts get sent,
not individual posts.  I don't have digests turned on.  Now I'm getting

Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

instead of 

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

But my email program still can't quote it.  Something odd at my end.

Still, progress.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] macOS: move getmountlist.c functions into portability.c.

[David Seikel]

Given the subject of this port of the discussion, apologies for the
lack of attribution in the quotes below.

> > Though now I'm getting annoyed at mailman sending plain ASCII text
> > as base64 encoding.  My email proggy can't handle quoting that.  It
> > didn't used to.  
> 
> I wonder if that's related to me enabling the "header rewrite" option
> to avoid triggering gmail's spam filtering when a mail server has
> that funky sender verification thing that breaks mailing lists?

You would expect something called "header rewrite" would only rewrite
headers, not body, but mailman is proudly a GNU project.

What ever it is, this isn't the first mailman driven mailing list I'm
having that problem with.  I wonder if there is a simple to use
"convert base64 encoded ASCII emails to just plain damn ASCII emails"
utility I can bolt onto my mail filtering pipeline and be done with it?

Or pull my finger out on my "switch email clients" TODO item, and find
one that can cope?  It's gonna take time to evaluate the contenders.

> Apparently it's gotten so bad some open source projects are
> abandoning mailing lists:
> 
>   https://lwn.net/Articles/768483/

That was an interesting read.  I've long been of the opinion that
mailing lists, web forums, bug trackers, and even chat room software,
is all basically conversation based.  There could be a base
conversation system that all the above would just be UI front ends to.
Let each user choose which to use.

Especially bug trackers, users have a tendency to just make bug reports
and support requests with whatever they are using at the time, not the
actual official bug tracker.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] macOS: move getmountlist.c functions into portability.c.

[David Seikel]

> There's something strange about gmail and this mailing list.  I still
> can read your messages only from Elliot Hughes' replies (And of
> course I saw that message since you Cc'ed me). I can't even find your
> messages in the "Spam" folder in Thunderbird!

Switching to no longer using gmail seems to have worked for me.

Though now I'm getting annoyed at mailman sending plain ASCII text as
base64 encoding.  My email proggy can't handle quoting that.  It didn't
used to.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Tired of gmails nonsense.

[David Seikel]

> What are you using for spam filtering?

On my mail server I don't have any spam filtering, but at my client
end I use a mailfilter black / gray / white list which also sorts
things into my local IMAP folders.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] Tired of gmails nonsense.

[David Seikel]

I'm not sure if it's gmails fault entirely, but I've only been seeing
about half of the posts to this list.  Mostly those from enh of late.
I know others post, I ran see their replies in things enh quotes.  Last
month it was mostly just Robs posts.  And yet another "membership in
the mailing list Toybox has been disabled due to excessive bounces".

On top of that, due to a gmail "feature" I had to have a read only and
a write only subscription.  It's considered a feature by Google, there
have been bug reports about it closed for many years.

So now I'm trying my own email server.  I'm slowly weening myself off
Google everything anyway.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH 1/2] macOS: use getconf rather than nproc for portability.

[David Seikel]

On Wed, 28 Nov 2018 17:11:03 -0800 enh via Toybox
 wrote:

> yeah, bitrot is my big fear too. i really don't want to have to
> actually get a mac. (even if i'm not paying for it, this current
> macbook pro genuinely is the most awful laptop i've ever used.)
> 
> but i suspect i could always just update the mac toybox prebuilt "on
> demand", which i assume would work out to "once every couple of years
> or so". obviously i'll admit that to the build folks up front though
> :-)
> On Wed, Nov 28, 2018 at 4:43 PM Rob Landley  wrote:
> >
> > On 11/28/18 5:18 PM, enh wrote:  
> > > yeah, sed seems to work okay. right now (with a bunch of source
> > > hacks that i'll try to clean up and send to you) i have the
> > > following subset of the AOSP build tools building:
> > >
> > > basename cat chmod cmp comm cut dirname dos2unix du echo egrep
> > > false fgrep file grep head help hostname id ln md5sum mkdir
> > > mktemp od paste patch pwd readlink realpath rm rmdir sed setsid
> > > sha1sum sleep sort tee timeout true uname uniq unix2dos wc whoami
> > > xargs xxd
> > >
> > > (note that i say "building". hostname at least doesn't work
> > > yet.)  
> >
> > I wonder if anybody has a macosx dev environment I could ssh into
> > to test stuff out?

Alas I used to.  I have a Mac Mini I bought specifically to do cross
platform development, mostly of virtual world stuff.  A fellow
developer used remote desktop to that Mac, to develop and test his bits
of the software.  Until a few months ago I had fibre to the bedroom, my
own custom built router, enough IPv6 for every ant within two blocks,
and permission from my ISP to run servers.  So I just punched the
correct sized holes in the firewall, and it all worked.

I had to move, the owners of the building tossed us all out so they
could knock it down to build a luxury mansion for them to live in.

So now I have ADSL2+ shared to half a dozen units via WiFi that I have
no control over, and the new ISP doesn't do IPv6 or allow servers.

Luckily my fellow developer bought his own Mac before the move.

I could bounce a ssh port through my European server, that I always
have my own ssh session open to.  A bit clunky, and no bandwidth
guarantees if every one else in the building is watching Netflix that
evening / weekend.

The other problem, we are in the middle of an "extreme heatwave" right
now.  I turn my Mac off when it gets above 32 C, which it will more
often than not for the next week.  It got over 34 C today, still 34
inside my home.  I just got home, I should open the window.  My main
Linux desktop I built specifically for these sorts of conditions, I
don't have to turn it off when it gets hot.  Apple doesn't build for
the tropics.

> >
> > I tried to boot Darwin under qemu rather a lot, but as with BSD:
> >
> > https://landley.net/notes-2007.html#28-11-2007
> > https://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00443.html
> >
> > I eventually lost interest...
> >
> > Rob  
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


pgpSrwRAaaowv.pgp
Description: OpenPGP digital signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Fun with the android NDK.

[David Seikel]

On Sat, 8 Sep 2018 18:43:17 -0500 Rob Landley  wrote:

> The big driver for both memory and storage consumption since the DOS
> days has been increasing display resolution and video, but a 4k
> display is the same resolution as digital cinema blown up on the wall
> of a theatre https://en.wikipedia.org/wiki/Digital_cinema and the
> point of a "retina display" is it's at the limits of human
> perception, and frame rate increases have been kinda meh too (movies
> have been at at 24 frames and TV at 30-ish for most of a century,
> https://www.youtube.com/watch?v=EM16aiSSpFk ), we've _already_
> doubled that today, so that's near endgame too...
> 
> I'm sure we'll come up with new stuff over the next 20 years but

My Motorola Moto Z phone is basically a "retina display", even taking my
glasses off and squinting at it with my horribly short sighted vision,
I can't see pixels.  Strapping it to my head in a Google Daydream is a
whole other story though, rather low res, not enough resolution to be a
monitor replacement.  Oculus and friends insist on 90 Hz frame rates, to
stop people feeling ill, but lower rates work fine for "never gets ill"
me, YMMV.  4k per eye at 90 Hz frame rate for augmented / virtual
reality headsets is likely coming soonish.  Then again, tricks like
foveated rendering will reduce the amount of high res pixels needed
(tracking what part of the display your eyeball is actually focused on,
and only rendering that bit in high res).  That's driving things a bit
for now.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


pgpVwRr_g0GSl.pgp
Description: OpenPGP digital signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Release fiddling, need another day or two.

[David Seikel]

On Fri, 6 Oct 2017 19:16:45 -0500 Rob Landley  wrote:

> None of these messages have shown up in the web archive since
> dreamhost "fixed" it. There's nothing for the month of October yet.
> 
> Dreamhost is really, really, really bad a this.

Is it time to move to someone other than Dreamhost?

> Rob
> 
> On 10/05/2017 04:11 AM, scsijon wrote:
> > OK, my apologies, I must have missed the android link anouncement by
> > Rob. However my other premise still stands.
> > 
> > regards to all
> > scsijon
> > 
> > On 10/05/2017 04:54 PM, enh wrote:
> >> On Wed, Oct 4, 2017 at 2:25 PM, scsijon 
> >> wrote:
> >>>
> >>>
> >>> On 10/05/2017 07:14 AM, toybox-requ...@lists.landley.net wrote:
> >>>
> 
>  Message: 1
>  Date: Wed, 4 Oct 2017 04:14:47 -0500
>  From: Rob Landley 
>  To: toybox@lists.landley.net
>  Subject: [Toybox] Release fiddling, need another day or two.
>  Message-ID: <758ba73a-ff30-2ed7-229c-d912571b2...@landley.net>
>  Content-Type: text/plain; charset=utf-8
> 
>  I wrote up release notes yesterday, but am reluctant to do a
>  second release with no new commands, especially since I have
>  pending changes in
>  my tree for dd, ping, lsof, iconv, cut, sysconf, gzip... In any
>  normal dev cycle I'd have gotten at least half those finished
>  and checked in, but this year's been a bit distracting.
> 
>  So I'm taking a little extra time to finish off at least one,
>  hopefully two. Stalling on the way to 1.0 is not cool and I'd
>  like to get unblocked.
> 
>  Rob
> 
> >>> Instead, think of it as a "getting most of the bugs out and
> >>> having a working
> >>> base point" release. Well worth having from time to time
> >>> Especially if later
> >>> problems cause things suddenly turn to quicksand, you can check
> >>> if the problem cause was in code before or after this point, and
> >>> that shortens rework cycles to get up and running again.
> >>>
> >>> Anyway, keep up the good work, I DO like toybox.
> >>>
> >>> regards
> >>> scsijon
> >>> ps I wonder if android could make use of it?
> >>
> >> pay attention at the back there!
> >>
> >> https://android.googlesource.com/platform/system/core/+/master/shell_and_utilities/
> >>
> >>
> >> :-)
> >>
> >>> ___
> >>> Toybox mailing list
> >>> Toybox@lists.landley.net
> >>> http://lists.landley.net/listinfo.cgi/toybox-landley.net
> >>
> >>
> >>
> > ___
> > Toybox mailing list
> > Toybox@lists.landley.net
> > http://lists.landley.net/listinfo.cgi/toybox-landley.net
> > 
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


pgpiYVgjjalDr.pgp
Description: OpenPGP digital signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] Add "microcom" to pending.

[David Seikel]

On Mon, 23 Jan 2017 13:25:47 -0600 Rob Landley  wrote:

> P.S. How is spider-man _not_ an Australian superhero?

Bojack Horseman is more our style, coz Australia's deadliest animal is
now ... horses.

http://www.abc.net.au/news/2017-01-17/horse-more-likely-to-kill-you-than-bees-wasps-snakes-spiders/8188842

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] awk seen in the wild

[David Seikel]

On Mon, 18 Jul 2016 17:03:18 -0400 dmccunney
 wrote:

> On Mon, Jul 18, 2016 at 3:17 PM, Rob Landley  wrote:
> 



> > The lua thing fell apart trying to write mount, ifconfig, netcat,
> > losetup, nsenter, ionice, chroot, swapon, setsid, insmod, taskset,
> > dmesg... The language just didn't have the bindings.
> 
> I rather like Lua, but I bear in mind the domain it addresses.  It's
> intended to be an embedded scripting language you can call from within
> your application.  You can't write stand alone Lua code because it
> lacks the infrastructure.  It assumes the application it's embedded in
> will handle that, and it doesn't need to. It's gotten a fair amount of
> pick up as the script engine for games, and there are a couple of IDEs
> intended for writing Lua used in games.
> 
> It's also popping up as the script language in editors.  One of the
> things I'm poking at the TextAdept, an extensible text editor.  It
> uses the Scintilla  edit control, and Lua for scripting.  The C code
> is under 2,000 lines and will remain so (and is basically the
> framework to embed Scintilla and Lua.)  The actual editing functions
> are written in Lua, and you can extend it all over the map by writing
> Lua code, in a manner akin to extending Gnu Emacs in eLisp.  The Lua
> code is currently about 4,000 lines.

This is the sort of thing I might do to boxes, the editor I was trying
to get into toybox.  Implementing a bunch of editors needed some sort
of internal language that wraps editing primitives, and I'm a fan of
Lua.  The original wasn't going to use Lua, since Lua isn't in toybox
for the reasons Rob gives above.

I'm still not sure what direction I should take boxes, now that it's
not going into toybox, and it's currently waiting on someone else to
right some code anyway.



> > It would be nice if there were some youtube clips on "an
> > introduction to sed", "an introduction to awk", and so on. I might
> > wind up doing them someday if nobody else beats me to it.
> 
> Oh, crap.  Sorry, but one of my pet peeves these days is the
> increasing use of video as documentation.  Video has a place, but I
> can *read* much faster than I can *watch*.  Give me a bleeping written
> tutorial, that I can have open in one window while I experiment in
> another.

This I fully agree with.  You can't copy paste text from a video,
making them useless for teaching shell stuff.  It's a lot easier and
quicker to back your eyes up and re read a sentence you didn't grok the
first time, than it is to rewind the video, and deal with the
inaccuracy of the rewind process.  Try searching a two hour video for a
bit of text, grep's gonna find it a hell of a lot quicker in a written
tutorial.

You can slow down or speed up your reading depending on your ability to
keep up, but that's just not possible in a video, the thing will drone
on at it's fixed pace.

They say a picture is worth a thousand words, but it's worth way more
than that in bandwidth requirements, and videos even more so. My
bandwidth is precious to me, I don't have a lot.  It's expensive here
in Oz.  Consider that an entire average novel would fill an entire
average floppy disk back in the day, and how big the average digital
photo is, you're not gonna squeeze an entire novel into a photo.

Having that trouble now, the gubermit has enrolled me in an online
course, I calculate that downloading all the videos for that course
will fully soak up five months of my bandwidth for the six month course.
I want to do other things with my bandwidth.  I'm trying to negotiate
this video silliness away, but they aren't talking.  The crazy thing is
that after poking around their web site, I have stumbled across what
looks like a written version of their first video, carefully hidden
away.  I'm not sure yet if it actually matches the videos in subject
matter that is to be tested, they wont tell me.  I'll have to watch the
first video and compare I guess.  There may be more of these text
versions.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] How do I tell cyanogenmod they're wrong?

[David Seikel]

On Sun, 29 May 2016 22:33:32 -0500 Rob Landley  wrote:

> Browsing through the cyanogenmod repository. Since they never
> submitted patches to me I'm not going to copy their stuff verbatim
> (technically it could be under a different license), but I'd like to
> address their issues in mainline (modulo the pending stuff), and I
> get to this:
> 
>   http://review.cyanogenmod.org/#/c/131295/
> 
> commit b90823e298988ff365cdf8e6d7c17687c3897d55
> Author: Scott Mertz 
> Date:   Tue Feb 2 14:40:31 2016 -0800
> 
> Don't exit with failure code when cp ownership preservation fails
> 
> POSIX spec states that it is unspecified whether '-p' prints
> errors to stderr when preserving ownership fails. GNU coreutils
> implementation does not write anything to stderr when this fails.
> Additionally, '-a' is only specified in GNU coreutils & specifies
> nothing is to be written to stderr in the case of failure. Switch the
> implementation to align with GNU coreutils while still satisfying
> POSIX.
> 
> OPO-358
> Change-Id: Ibb7c94fbf553a178b3f88a724ef6f737275a4205
> 
> I tried to pull up the OPO-358 thing to see what the original bug
> report was, but it requires a login to view it:
> 
>   https://jira.cyngn.com/browse/OPO-358
> 
> So I tested it myself, and they're _wrong_:
> 
>   dd if=/dev/zero of=vfat.img bs=1M count=1
>   mkfs.vfat vfat.img
>   mkdir vfat
>   sudo /bin/bash
>   toybox mount vfat.img vfat
> 
> And then when I go:
> 
> # cp -a todo vfat/
> cp: failed to preserve ownership for ‘vfat/todo/attachment.bin.4’:
> Operation not permitted cp: failed to preserve ownership for
> ‘vfat/todo/attachment-0002.bin’: Operation not permitted cp: failed
> to preserve ownership for ‘vfat/todo/netstat.patch’: Operation not
> permitted cp: failed to preserve ownership for
> ‘vfat/todo/githash.patch’: Operation not permitted cp: failed to
> preserve ownership for ‘vfat/todo/expr.patch’: Operation not
> permitted ...
> 
> The stock ubuntu 14.04 vesion is giving warnings about
> inability to preserve ownership...?

Is that like throwing an error when trying to delete a non existent
file?  The end result is what you want, it's only complaining coz it
can't do that, not that what you want done is already done.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] What should I do with my boxes generic editor code?

[David Seikel]

Well, the evening I had said I was gonna reply got eaten up by four
unexpected visitors in a row.  Time to do so now.

On Tue, 26 May 2015 15:31:57 -0500 Rob Landley r...@landley.net wrote:

 On Tue, May 26, 2015 at 12:08 AM, David Seikel onef...@gmail.com
 wrote:
  This has been most frustrating.
 
  tl,dr - Getting boxes into toybox has entirely failed for four
  years, which has blocked the progress of both.  Let's do something
  about that.
 
 I suspect the best thing to do is just release it as an independent
 package. I've been consistently overwhelmed with stuff, merging as
 fast as I can.

Yep, looking like that's gonna be the way to do so.  Perhaps if I can
get some decent progress doing things that way, we might be able to
merge some parts between the two projects.

Most of the rest of your reply, that I have read now, is just showing
that I'll need to clean it up a lot to make it Rob friendly.  Now that
I have your initial comments, that will be easier to do.  B-)

 Hand #defining FLAG_ macros even though the infrastructure's done
 this for us for at least a year.

To be fair, this was written four years ago, before that infrastructure
existed.  Needs an update.

 The edit line is basically a movable readline... not really, no.
 For command history I've been pondering how to handle I scrolled up
 and got a long multiline command history thing and then scrolled past
 that to get a shorter one, so even if I scroll back down it's now
 several lines _up_ from the bottom of the screen because the
 transient long line moved everything. Lines that wrap can vary in
 size, they're no more _one_ vertical line than horizontal characters
 are one character with utf-8. Speaking of which, searching this file
 for mbr or wcwidth didn't find any hits? I added the basic
 fontmetrics dance to hexedit's filename display in commit
 5ea14bd1c246 a couple weeks ago, not because it's important for a hex
 editor but because I'm using a simple command to work out the
 infrastructure I want to genericize. Your version has a lot of very
 complicated behavior but doesn't address fundamental issues I'm
 interested in getting right, ones which aren't necessarily easier to
 retrofit on _top_ of all that complexity.

The code only does long lines scroll left and right for now.  Dealing
with shells use multiple lines to edit long lines and UTF-8 is extra
complexity in something that's already overly complex as a starting
position just to get it in.  Yes, I intended to add that stuff later,
but trying to get this cut down yet still functional first.

 At line 2400 there's two screens full of what looks like a man page
 cut and pasted into the middle of the code? (Why not just reference
 the man page?)

Ah, just notes to myself about which of those terminal settings I
wanted to use.  Not just copy pasta, it has a sprinkling of oregano as
well.

 Ok, backwards search for main( and... it's got a multiplexer for
 mode, with emacs, joe, less, mcedit, more, nano, and vi. But you
 can't submit one at a time, because this code cannot be broken up
 into smaller pieces. Right.

I wrote it as a generic editor, that is table driven.  So it includes
tables for the stuff toybox is interested in.  Vi is in fact the only
one with extra code besides the tables.  I could have submitted it as
just the vi toy, that would only have left out the extra tables.  It
might have been my next step, if handlekeys had got in.

 Ok, let's look at vi, which is the editor required by posix. Case
 insensitive search for vi  from the top of the file... help text,
 help text, comment, comment... ok, the eleventh hit is still in yet
 another comment (right after yet another TODO) but it's right in
 front of simpleEditCommands which sounds like fun, and which seems
 to have built-in help text? Back space last character. Ok, let's
 see what displays this help text. Forward searching from
 simpleEditCommands it's in simpleLess (is there a non-simple less?)
 and in simpleMore and in simpleMcedit... ok, simple here seems to
 be an assertion rather than actually informative.

During my research I had split editing functions into groups, the first
one is simple, which is anything that's needed to be able to just
barely be able to edit things.  Load a file, cursor around, insert,
delete, overwrite, save the result.  This group has been implemented.

The next group of commands adds the usual basic tools that most editors
have, and is called basic.  That group would be what I start on next
once simple has been bedded down.  The other two groups are
advanced and code, advanced editing tools, and stuff that's
specific to source code editing.  These last two may or may not be
suitable for toybox, though might end up cherry picking some of that.

 What are the _other_ files here? README.md: Please don't actually
 include this in toybox. BOXES.txt: a series of disconnected
 notes-to-self apparently not meant to be read by anybody other than
 its author.

Yep, BOXES.txt is just

Re: [Toybox] What should I do with my boxes generic editor code?

[David Seikel]

I have to go to work soon, but I can quickly reply to this bit, then
answer the rest later, after work, or during a break in work.

On Tue, 26 May 2015 15:31:57 -0500 Rob Landley r...@landley.net wrote:

 I remember at one point I asked if there was a way to chip off a
 hundred or so self-contained lines to add as a first step, I believe
 I suggested the escape key sequence parsing (ala the stuff I
 eventually implemented myself for hexedit) might be self-containable?
 I do not remember a patch to toybox lib/ forthcoming in response, but
 maybe I missed it.

Yep, you missed that, I split that part out into the handlekeys.c, plus
an example of how to use it called dumbsh.c.  I did that about a year
and a half ago, posted it to the mailing list.

I'll read and reply to your reply later today (my time, I'm on the
opposite side of the planet from you, unless you are in Japan again).

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] What should I do with my boxes generic editor code?

[David Seikel]

This has been most frustrating.

tl,dr - Getting boxes into toybox has entirely failed for four years,
which has blocked the progress of both.  Let's do something about that.



I've been trying for years (since 2011) to get my generic editor code
(boxes) into toybox, so far with zero movement on that front.  Now Rob
has added two editors he wrote himself, and from what I can tell wants
to just write it all himself.  Not to mention a few other things that my
generic code covers, where written by others, and have been included
already.  Boxes covers emacs, joe (Wordstar), less, mcedit (the editor
I actually use), more, nano, and vi.  It also covers the ed style
modes of those things that include one.  It could cover a few other
things as well, for instance I wrote an example shell that just
demonstrates how it could be used in toysh.  It could share code with
sed, and now hexedit.

It's time for me to make a decision about what to do with boxes.  Four
years with no movement is ridiculous.  People keep wanting me to finish
it, Rob wont put it into toybox just isn't an acceptable response for
me to give after four years.  I'm putting this on the public mailing
list so that those who are actually interested can provide some
feedback to help inform my decision.  Some actual useful feedback from
Rob that progresses this instead of just sitting on it forever would be
great to.

So far the only actual objection you have given to me Rob is that it's
too big a blob for you to grok.  So I cut out a bit of it, to see if you
could at least handle a small part of it, even though it was too small
to be actually useful.  You ignored that to.  That's a problem, a
generic editor is just too big, even if it's cut down to barely usable
editor.  Sure it can be cut down into bite size bits, but none of
those bits will be useful at all.  So this has been the big blocker,
Rob wants bite sized bits, this doesn't break down into bite sized
bits, and Rob aint putting it in, not even to pending, unless it's
bite sized bits.  Me completing it by fleshing out the missing editing
functions wont make it any more bite sized, that has to wait until
it's in toybox.  Once it is in, fleshing it out CAN be done in bite
sized bits.

Every now and then Rob you say I want to write this, and I usually
reply I've written this for you already, sometimes you respond with
we'll talk about it later, then later never comes.  Mostly you just
ignore it.  Despite the fact that it covers a lot of things that you
keep saying you want to add.



So, what are my choices?

0) Try to convince Rob to just dump it into pending.  Then we can all
work on it to make it great.

1) Keep waiting another four years in the forlorn hope that Rob
actually does something with it.

2) Fork toybox and just add it myself.

3) Write it as a drop in module for toybox.

4) Rewrite it to be entirely separate from toybox.

5) Just forget about it, and wait four or more years for Rob to write
his versions of a bunch of things.

6) Insert choices I haven't thought of here.



Choice 0) is what I have been trying to do for four years.  I'm a
computer programmer, not a marketing droid, I can't sell for shit.
Obviously this isn't working.  Time to move on, reluctantly.

Choice 1) doesn't cut it for me, coz one of the reasons I was motivated
to write this in the beginning is that I want to use it myself.  In
four years I could have actually completed enough of this to actually
be useful to a large number of people, including myself.  Time to move
on.

Choice 2) is something I really don't want to do.  That's way more work
for me, and creates competition where I wanted to cooperate.  Just as
Rob didn't want to compete against busybox at one point, I don't want
to compete against toybox editors, for basically the same reasons.

Choice 3) might work, I'm not sure yet if such a thing is possible.
Though then Rob will still write his own versions, coz mine will only
get bigger as I flesh it out to full editing functions, so he wont be
able to grok it.  The big problem here is that there's lots of code that
could be shared between boxes and other parts of toybox.  Rob might not
accept patches to deal with this, if the history of boxes is anything
to go by.

Choice 4) is workable, as the toybox library stuff I use isn't that hard
to replace, and I could even just use those parts directly, as I would
use a similar license to the toybox one, which allows that.  This would
be just another implementation of a bunch of editors, so likely I'd be
the only one using it.  This wont help toybox at all.

Choice 5) isn't really an option for me, but is likely what will happen
judging by how things have gone so far.

Choice 6) - this is where you people can lend a hand if you can come up
with other choices for me.  Maybe someone else could convince Rob where
I cant.  Maybe sending push requests from the boxes github to the toybox
github would help get it in.  I dunno what else will work, make
suggestions.

Re: [Toybox] [Aboriginal] notcurses

[David Seikel]

On Fri, 15 May 2015 17:24:03 -0500 Rob Landley r...@landley.net wrote:

 On 05/15/2015 01:40 PM, Kartik Agaram wrote:
  Rob, I just had your post from the 27th pop up on my RSS reader:
  http://www.landley.net/notes-2015.html#27-04-2015
 
 Technically this is a toybox question. :)
 
  Are you aware of https://github.com/nsf/termbox? A few weeks ago I
  replaced ncurses with it in my project
  (http://github.com/akkartik/mu#readme), and the version I've inlined
  there is even smaller and even more self-contained (no waf-fling).
 
 I've looked at a few, but basically the hard part is the keyboard
 scanning function:
 
 https://github.com/landley/toybox/blob/master/lib/interestingtimes.c#L89
 
 Which still isn't actually that hard, especially since I had to
 rewrite busybox's implementation way back when because they did it
 wrong, ala these two commits:
 
 http://git.busybox.net/busybox/commit/?id=988dd5549bc7
 http://git.busybox.net/busybox/commit/?id=5e38cd910aca
 
 Already had rather extensive learning experiences here, so I might as
 well just implement the result. Once you understand it, it's _really_
 not that hard, the sequences are documented and everything:
 
 http://man7.org/linux/man-pages/man4/console_codes.4.html
 
 (There's also xterm's
 http://invisible-island.net/xterm/ctlseqs/ctlseqs.html and the ANSI
 x3.64 standard http://sydney.edu.au/engineering/it/~tapted/ansi.html
 and so on, but the console_codes is mostly a common subset.)
 
 Also, back in that bulletin board system I mentioned (written back in
 1990), I implemented my own ansi handler that maintained a screen
 write buffer so I could essentially do virtual terminals in dos. Mine
 could show you ~3 lines of each (cursor and two lines above it,
 unless that goes above top of screen in which case top 3 lines).
 Meaning I got very familiar with the dos version ansi escape
 sequences at one point because I wrote my own driver for it, and my
 limiting factor is it's been so long I don't necessarily remember the
 details and have to look them up again.
 
 Rob
 ___
 Aboriginal mailing list
 aborigi...@lists.landley.net
 http://lists.landley.net/listinfo.cgi/aboriginal-landley.net


Boxes has this already, naturally.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Did I mention the release?

[David Seikel]

On Sat, 21 Mar 2015 14:16:00 -0500 Rob Landley r...@landley.net wrote:

 I need to reread this thread after my california trip and update the
 roadmap. Quite POSSIBLY what I need is a slushpile.html where instead
 of why this command should go in I have a list of commands and notes
 about what I plan to do with each command. (Brief implementation
 details like the above, why this is hard, what's blocking it,
 remember to handle these cases...)

That might help me get my editing stuff into toybox.  Seeing what your
thoughts are, coding it accordingly.

Though I'm hoping that after your reread, you might at least respond to
my previous rant.  lol

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Did I mention the release?

[David Seikel]

On Thu, 19 Mar 2015 20:52:46 -0500 Rob Landley r...@landley.net wrote:

 The other thing is that top does terminal control similar to less.
 And watch should do the same, and ps does a _little_ of the same.
 (They query the terminal size and truncate output at screen width and
 screen height.) So my plan was to genericize _that_ code, in a way
 that works with shell command line history editing and vi.

Well, you could start with the boxes / handlekeys code I keep sending
you every couple of years for inclusion.  Which does exactly that,
including basic working examples for less, shell, vi, and others.

I keep worrying that you'll write this stuff yourself, making my work
useless and wasted.  Especially since you keep saying it's your plan to
write it.  I'm happy to write this stuff, I'm not happy it's taking
years to get any of it into toybox, with zero progress so far.

I'm considering just making boxes a separate project from toybox, since
it's otherwise not going anywhere.  People are asking me for fixes,
more advanced editing, and to help out.  Hell, I want to add more
advanced editing stuff, so that I can use it myself.  I keep having to
tell them frozen, coz Rob.  B-(

I don't want to make it separate though, it will be a pain, especially
if I need to patch toybox to suit boxes.  Fork and diverge is not
something I want to do to toybox.

I should probably take your sed code and pull out the generic editing
bits, then convert boxes to use that.  At the very least that might make
it easier for you to read, coz some of it will be your code.  I'm not
particularly tied to my line handling and basic editing functions code.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Mail list service

[David Seikel]

On Sat, 24 Jan 2015 19:55:01 -0500 stephen Turner
stephen.n.tur...@gmail.com wrote:

 Im setting up my project resources and didnt see a mail list service
 on sourceforge. Anyone reccomend a free service that wont spam the
 users or sell thier email address?

Sourceforge has mailing list services, though they do add adverts to
the end of each email.  For any given project go to the Admin page -
Tools - Discussion.  It's Mailman 2.1.9 based mailing lists.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] Don't check whether . or .. are RTCs.

[David Seikel]

On Fri, 23 Jan 2015 20:18:45 -0600 Rob Landley r...@landley.net wrote:

 On 01/22/15 23:11, enh wrote:
  This probably only seems worthwhile to those of us who spend a large
  part of every day staring at strace output, but in case you're
  interested...
  
  Before (on a device with only one RTC):
 ...
  diff --git a/toys/pending/hwclock.c b/toys/pending/hwclock.c
  index 003174f..04f4770 100644
  --- a/toys/pending/hwclock.c
  +++ b/toys/pending/hwclock.c
  @@ -35,6 +35,7 @@ static int check_hctosys(struct dirtree* node)
 FILE *fp;
  
 if (!node-parent) return DIRTREE_RECURSE;
  +  if (!dirtree_notdotdot(node)) return 0;
  
 snprintf(toybuf, sizeof(toybuf), /sys/class/rtc/%s/hctosys,
  node-name); fp = fopen(toybuf, r);
 
 
 I'd actually like to follow your suggestion do the counting based
 version, if I can assume that the rtcs aren't sparse (I.E. if
 /sys/class/rtc/rtc3 doesn't exist, then there isn't an rtc4 or higher
 either, so I can stop at the first one that isn't there).
 
 Do we have hot-unpluggable realtime clocks?

This might count.  It's entirely possible to have a bunch of them
plugged in.  I may even get one some day.  I don't intend to actually
hot plug it though.  I do intend to have it on a device with another
realtime clock, coz they designers neglected to provide so much as a
place to hook up a battery to the other real time clock.  This one has a
battery, it will keep time when the other one doesn't have power.

https://www.olimex.com/Products/Modules/Time/MOD-RTC/open-source-hardware

So in theory, yes we can have multiple hot-unplugabble realtime clocks,
in practice, I doubt it will ever be an issue.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] optional fatter cat(1)

[David Seikel]

On Sat, 3 Jan 2015 23:31:38 -0500 Rich Felker dal...@libc.org wrote:

 On Sun, Jan 04, 2015 at 02:24:19PM +1000, David Seikel wrote:
  On Sat, 3 Jan 2015 23:07:55 -0500 Rich Felker dal...@libc.org
  wrote:
  
If vi/uemacs/joe/nano are trivial extensions of the same basic
infrastructure (sort of true modulo vi command mode), I have no
problem implementing lots of sets of keybindings. But the first
target is vi because it's the only one actually in posix.  
   
   My guess is that this is not so easy, and that attempting to do it
   this way would have a lot of subtle failures that would just annoy
   users. But it might be a lot less annoying than being stuck with
   nothing but vi...
  
  It was actually quite easy once I had done my homework.  I don't see
  how it would have a lot of subtle failures that would just annoy
  users.
 
 The how/why is just past experience, e.g. joe -- jmacs feels nothing
 like emacs and it's frustrating because your brain has to be in emacs
 mode to use it, but then nothing actually works like emacs. The only
 emacs workalike I've seen that actually fits my emacs workflow is mg,
 and even then only until I have a non-ASCII file, in which case it
 breaks horribly...

We, my research didn't include how does this feel to experienced
users of these editors.  Not actually being an emacs user these days,
I'll have to rely on people like you to report how you think the feel
might need adjusting.

Rob has mentioned a few times about Linus Torvalds maintaining his own
emacs fork, and how it would be great if the toybox emacs could convert
Linus.  Certainly feedback from him be welcome as also.

  Though my design wasn't start with vi and bend it to look
  like other editors, it was research all the targeted editors /
  pagers, figure out what's common and what's not, then come up with a
  generic infrastructure that can handle them all.
 
 That might work a lot better. I'd love to see it work out. I'm just
 not holding my breath.. :-)

I stopped holding my breath two years ago.  Though with this fresh
discussion, there might be some movement on this soonish.  In fact I
just had an idea I'll rush off to add to the boxes TODO right now.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] service

[David Seikel]

On Thu, 1 Jan 2015 10:22:46 -0800 Isaac Dunham ibid...@gmail.com
wrote:

 On Thu, Jan 01, 2015 at 09:35:31AM -0500, stephen Turner wrote:
  while doing some searches on scripting i was reminded about
  service and noticed it wasn't in toybox. Is this a oversight or
  not in intended feature/possible post 1.0.
 
 service(8) is part of the rc scripts, of which there are more variants
 than there are of init(8).
 It makes little sense to include it in toybox when the only init we
 have is oneit; even when init gets out of pending, implementing
 service in toybox would be hard-coding a requirement about how the rc
 scripts work. We certainly couldn't implement the rc scripts in
 toybox, since they are scripts.

That's not entirely true.  Many years ago I wrote an implementation of
runlevel/init.d/SYS V init applets for busybox, aiming for LSB
compliance.  It included the ability for the actual scripts
themselves to be written in any language, and included several ones
written in C as busybox applets.  These init scripts would just be
symlinks to busybox.  This is in fact compliant with the LSB
specification.

If I remember correctly, it includes most of the good stuff systemd
claims, fast boot if all/most of the scripts are written in C,
dependency tracking, parallel script running, etc.

Rob hasn't decided yet how to tackle this sort of thing, other than his
oneit toy, which is a very basic init system.  I hope that when he
does tackle it, scripts written in C as part of toybox would be
supported.

It's likely bit rotted horribly, but for the curious -

https://sourceforge.net/projects/urunlevel/

I'd be happy to port it to toybox.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] toybox in Android status

[David Seikel]

So if Android is switching to toybox, is my unfinished project to
create a toybox installing app now obsolete?

I was stuck on what to do if busybox is already installed and has
symlinks plastered all over the file system.  I'm still thinking about
how to deal with that.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] optional fatter cat(1)

[David Seikel]

On Thu, 1 Jan 2015 14:04:41 -0500 dmccunney dennis.mccun...@gmail.com
wrote:

 On Thu, Jan 1, 2015 at 1:39 AM, David Seikel onef...@gmail.com
 wrote:
 
  I have a simple test to decide if I like an editor as a result of
  these decades of random editor usage.  If I can't sit down with the
  editor and figure out how to do basic editing and saving in less
  than a minute (sans documentation), then in my opinion it's a crap
  editor. Both TECO and vi fail this test miserably, though oddly
  enough I have a soft spot for TECO.
 
 These days, the general assumption is that you can open a file in an
 editor with editor filename, and that once up, cursor keys can
 be used to move around in the file and that text can be added where
 desired by typing it at the cursor location and deleted with Backspace
 or Delete keys.
 
 Vi originated in the days when some of those assumptions might not be
 true.  Some early terminals on Unix systems didn't *have* cursor keys
 or F-keys.  The vi command set and separation between input and
 command modes was a result.
 
 Given where Toybox will be used, it's a reasonable assumption folks
 running the included editor will already know enough of the basics to
 deal with vi, even if they may prefer something else, so Can they
 figure out basic editing and saving without docs is a non-issue.

Boxes already has other editors in it that do pass my test.  So having
to deal with vi is a non-issue.  Choice is a good thing, we have it.
B-)

  killall -KILL vi
 
  OK, yes I know about :qa as well, killall is much more satisfying.
  B-)
 
 You *could* simply remove vi from your system. :-)

While that's true, I can't do that to clients systems.  I think one of
them actually likes vi.

  Out of all the editors that I have implemented in boxes, I have used
  them all professionally, including the line editors buried inside
  emacs and vi.  These days I prefer to use mc and mcedit for
  everything though, which is why boxes includes mcedit.  So I'll
  dogfood mcedit, the rest I'll have to rely on others to tell me
  what I get wrong.
 
 We will.  The big issue I can see is preserving moded editing in vi
 and dispensing with it in the others.

Actually, other editors have modes to.  So also not an issue, and
already solved.

  I have no plans to implement TECO in boxes, vi and ed are already
  there.
 
 C source is available for a port of TECO if anyone wants to build it,
 but I don't see a need in Toybox.  Stallman used ITS TECO as the
 implementation language for Editing MACroS, the lineal ancestor of Gnu
 Emacs, because it was what was available.  It was a language in which
 he could implement an editor.  It took over as the standard editor at
 MIT's AI labs, and he realized how successful his efforts had been
 when he no longer remembered how to do things in raw TECO. We have
 other languages in which you can write editors now.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] optional fatter cat(1)

[David Seikel]

On Mon, 29 Dec 2014 16:10:07 -0500 dmccunney
dennis.mccun...@gmail.com wrote:

 On Mon, Dec 29, 2014 at 1:00 PM, Rich Felker dal...@libc.org wrote:
  On Mon, Dec 22, 2014 at 10:21:26PM -0600, Rob Landley wrote:
  I plan to implement vi over the next year, but it's one of the four
  realy big commands required by posix (sed, awk, sh, vi) and I've
  been debugging sed against real-world data for _weeks_ now. (It's
  easy to knock out a simple 90% implementation. It's really hard to
  make something do everything right in all the cases people are
  going to throw at it.)
 
  It would be awesome to have mg too or a similar mg-like emacs clone
  but with working unicode support.

Mg is one I haven't heard of.  Got a URL?

 You might look at Albrecht Kliene's e3.  e3 is that Linux rarity -
 code written mostly in Assembler.  (There is also a C version for
 other systems.)
 
 By default, e3 implements a subset of the WordStar command set, but
 can emulate emacs, ne, pico and vi.  It's the same executable -
 symlink it under the desired name and it assumes the desired
 personality.  Puppy Linux bundled e3 as vi.  See
 http://texteditors.org/cgi-bin/wiki.pl?E3
 
 (There is also a Puppy build of Traditional vi, built from source
 released by Caldera, which I prefer under Puppy.  See
 http://ex-vi.sourceforge.net/ for source. It's under a BSD license.)

E3 was my inspiration for boxes.  Though I do have a soft spot for
assembler, I'd prefer using C for this sort of thing.  Or perhaps C +
Lua, but Rob decided a while ago to not use Lua.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Screen vs. tmux (was: optional fatter cat(1))

[David Seikel]

On Mon, 29 Dec 2014 03:12:03 + (UTC) Jason Spiro
jasonspi...@gmail.com wrote:

 Rob Landley rob@... wrote:
  
  I plan to implement vi over the next year, but it's one of the four
  realy big commands required by posix (sed, awk, sh, vi) and I've
  been debugging sed against real-world data for _weeks_ now. [...]
  
  There are some others (the kernel build requires bc now, if I'm
  doing less and vi I should be able to do screen, and rsync
  is really useful...) but right now I'm focused on the list for 1.0,
  and there are a lot of smaller commands (and the giant backlog of
  pending cleanups) that could get knocked off the list faster...
 
 In this message, I will tell you why I think toybox should emulate
 tmux instead of GNU Screen.

Well, if I can go ahead with my plans for boxes for toybox, which will
eventually include a screen / tmux type system, then no one has to
convince me to make it more like tmux than screen.  I fully agree with
you, tmux is much better, it's what I use.  I've configured tmux to be
friendly to screen users in the past, and convinced one of my clients
to switch to it.  Actually, he convinced himself with the phrase
h, you can resize the window panes with your mouse.  Mind you,
he was resizing MY window panes from another computer at the time,
which annoyed me watching from the other side of the city.  lol

 Let me begin.
 
 GNU Screen, a terminal multiplexer, is very useful.  Still, I've
 since switched to tmux.  It's a newer terminal multiplexer, and is
 BSD-licensed. It is true that GNU Screen has now started making
 releases again for the first time in half a decade.  Still, I like
 tmux so much that I don't plan to switch back to Screen.

From my point of view tmux seems to be better designed.

 tmux makes certain operations easier.[1]  For example:  It ships with 
 preconfigured keybindings (C-b 0, C-b 1, ..., C-b 9) which let
 you jump to low-numbered windows in just a few keystrokes.  Another
 example:  To renumber a window, you need only hit five keys (C-b .
 9 RET), instead of nine (C-a : n u TAB 9 RET).
 
 tmux is also easier to learn.  For example:  It shows a status line
 (tab bar) by default, instead of forcing users to mess with complex
 configuration options just to get a status line.  See screenshot[2].
 
 tmux is included in the software repositories of Ubuntu, Debian
 stable, and other distros.
 
 tmux's basic keybindings are fairly similar to Screen's.  But,
 instead of Ctrl+A, tmux's default prefix is Ctrl+B.  (This is
 reconfigurable.)

I do generally configure the hot key and a few others for screen
compatibility.  So that if I ever have to use screen, then I know what
to do, and others used to screen can still use my tmux installs.

Tmux is also built for scripting, which is hard for screen.  I have a
script that, for instance, connects to a tmux session, switches through
particular windows in that session, issuing commands to each window, to
automate some backups, running from a cron job.  The other sysadmin for
that server had originally used screen, coz she didn't know about tmux,
and completely failed to get screen to be able to do anything like that.

 You can find a tmux reference card[3] on the Web.
 
 Dear Rob:  I know you mention Screen in your todo.txt file[4].  But
 please consider instead mentioning tmux.  Those who are familiar only
 with good old Screen can either adapt to the nicer user interface
 that tmux provides, or can download and install Screen themselves.


In the end, I'll likely do what I did for the boxes based editors, make
it generic, and allow people to build their own variations easily.  So
screen and tmux users will both be happy.  After all, the boxes based
editors already support all the editors / pagers on the toybox roadmap
(except sed), and a couple more.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] optional fatter cat(1)

[David Seikel]

On Mon, 22 Dec 2014 22:21:26 -0600 Rob Landley r...@landley.net wrote:

 
 
 On 12/21/14 17:42, enh wrote:
  On Sun, Dec 21, 2014 at 1:07 PM, James McMechan
  james_mcmec...@hotmail.com wrote:
  On 12/20/2014 05:55:45 PM, David Seikel wrote:
 
  On Sat, 20 Dec 2014 19:30:01 -0600 Rob Landley r...@landley.net
  wrote:
 
 
 
  On 12/19/14 18:52, David Seikel wrote:

No idea how the quoting in your reply got built, nothing I actually said
is quoted.

  On Fri, 19 Dec 2014 16:43:51 -0800 enh e...@google.com wrote:
 
  i was thinking about writing a trivial termcap implementation
  that just returns the xterm-color answers and using the BSD
  less, but i didn't realize that even the BSDs use the GNU less.
 
 
  fortunately n-curses devolves tremendously when you don't try to
  support every terminal type under the sun efficiently...
  
  (very off-topic at this point, but vim doesn't use ncurses under any
  circumstances. moreover, it turns out that vim actually has all
  kinds of different fallbacks and as long as you don't misconfigure
  it like i did, it builds and runs fine out of the box on Android.
  it has a minimal tgetstr/tgoto/tputs implementation *and* a few
  built-in termcap subsets, including xterm. it's an 8.3MiB binary
  unstripped or 2.1MiB stripped for aarch64, though, so probably not
  of much interest to you guys :-) )
 
 I plan to implement vi over the next year, but it's one of the four
 realy big commands required by posix (sed, awk, sh, vi) and I've been
 debugging sed against real-world data for _weeks_ now. (It's easy to
 knock out a simple 90% implementation. It's really hard to make
 something do everything right in all the cases people are going to
 throw at it.)
 
 There are some others (the kernel build requires bc now, if I'm doing
 less and vi I should be able to do screen, and rsync is really
 useful...) but right now I'm focused on the list for 1.0, and there
 are a lot of smaller commands (and the giant backlog of pending
 cleanups) that could get knocked off the list faster...


Rsync isn't in my scope, but I agree, it being in toybox would be
very useful, I hope someone works on that.

 By the way, the generic line editing infrastructure is useful not just
 for shell command line editing, and obvious stuff like less, screen,
 and vi, but even watch needs it to work quite right. (And if you're
 supporting unicode, the difference between doing more and less
 _right_ isn't as big as you'd think...)
 
 If less is a priority, that actually helps prioritize the rest of
 them. Once I've written the basic navigate a line infrastructure
 (with querying screen size via ansi probe fallback, and reassembling
 escape sequences that got decoupled going over serial line; I fixed
 both of these in busybox several years ago), then stacking them isn't
 quite as big a deal.

Even less of a big deal since I've already done a lot of these things
for toybox, and hanging out for things to filter through Robs TODO list
of DOOM so that we can complete them.  Screen / tmux (I prefer tmux
at this stage) is something my boxes infrastructure could handle as
well, so it's on my TODO to look at.

I've done the no need for curses / termcap thing.  I've done the
basic navigate a line infrastructure.  I've done the figure out
screen size with fallbacks thing.  I've done the generic line and
screen editing thing.  I've tied it all together.  I've done the basic
emacs, less, joe, less, mcedit, more, nano, vi thing.  I've done a
brian dead sh to show how my infrastructure would fit that use case.
I've done the research for the non basic editing stuff that I've not
implemented yet.  I've even implemented a few non basic editing
commands.

It's been going on for a long time now (over two years) can you at least
put the boxes stuff into pending please, so that we can all work on it?
Then people wont keep bringing up less, vi, and all those others that I
have a basic working implementation of, as if there's been no work done
on them.  Would be nice if we all worked on one implementation, instead
of investigating them / working on them separately.

Boxes is good enough for pending means we can move on.  Boxes is
shit means I can give up and find other things to do, someone else
can work on them.  Boxes is not quite good enough for pending and Rob's
not been telling me what needs to be fixed for years means it's in
limbo for two years and I'm getting frustrated with that lack of
progress.  I know others where waiting on some progress here two years
ago.  They might have given up waiting.

OK Rob, you told me one thing that was wrong, it was too big for you to
grok in one sitting.  It has to be, it covers a lot of ground.  I broke
of the smallest stand alone part I could and submitted that, and still
no movement with it.

Please put boxes (or at least that bite sized handlekeys bit) in
pending, or put it out of it's misery.  We can help you write this
stuff if you let us Rob.  Delegate responsibility to me if you

Re: [Toybox] [PATCH] optional fatter cat(1)

[David Seikel]

On Sun, 21 Dec 2014 15:42:01 -0800 enh e...@google.com wrote:

 On Sun, Dec 21, 2014 at 1:07 PM, James McMechan
 james_mcmec...@hotmail.com wrote:
  On 12/20/2014 05:55:45 PM, David Seikel wrote:  
 
  On Sat, 20 Dec 2014 19:30:01 -0600 Rob Landley r...@landley.net
  wrote: 
  
  
   On 12/19/14 18:52, David Seikel wrote:  
On Fri, 19 Dec 2014 16:43:51 -0800 enh e...@google.com wrote:
 
i was thinking about writing a trivial termcap implementation
that just returns the xterm-color answers and using the BSD
less, but i didn't realize that even the BSDs use the GNU
less.  
 
 
  fortunately n-curses devolves tremendously when you don't try to
  support every terminal type under the sun efficiently...  
 
 (very off-topic at this point, but vim doesn't use ncurses under any
 circumstances. moreover, it turns out that vim actually has all kinds
 of different fallbacks and as long as you don't misconfigure it like i
 did, it builds and runs fine out of the box on Android. it has a
 minimal tgetstr/tgoto/tputs implementation *and* a few built-in
 termcap subsets, including xterm. it's an 8.3MiB binary unstripped or
 2.1MiB stripped for aarch64, though, so probably not of much interest
 to you guys :-) )
 
i switched Android over to the toybox more from the mksh shell
function, but people still complain they really want less.
(afaict, mostly for the ability to go backwards and
search.)  
 
 
  Thinking about it, an old school more without ncurses could have
  the last few bits of less tacked on top: searching, backwards
  movement, any other bits of interest?
  If we yield on fine cursor control and efficiency we could just
  print the screen...
  It is not like we are trying to be efficient on a ADM-3 or a
  teletype over a slow serial connection...

This is what boxes does.  In theory most things still in use today use
some basic and ordinary ANSI escape sequences, so the complexity of
ncurses and friends is not really needed.  Boxes is a generic editor
frame work, with the simple stuff of editing / paging generalised and
wrappers around it for emacs, less, more, vi, WordStar, and a few
others.  And yes, it does just print the entire screen when stuff
changes, though Rob mentioned more intelligent redraws might be a good
addition.  I left it out for simplicities sake for now, better to get
the basic infrastructure in place first.  Apparently Rob has had to
deal with slow serial ports recently.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] optional fatter cat(1)

[David Seikel]

On Sat, 20 Dec 2014 19:30:01 -0600 Rob Landley r...@landley.net wrote:

 
 
 On 12/19/14 18:52, David Seikel wrote:
  On Fri, 19 Dec 2014 16:43:51 -0800 enh e...@google.com wrote:
  
  i was thinking about writing a trivial termcap implementation that
  just returns the xterm-color answers and using the BSD less, but i
  didn't realize that even the BSDs use the GNU less.
 
  i switched Android over to the toybox more from the mksh shell
  function, but people still complain they really want less. (afaict,
  mostly for the ability to go backwards and search.)
 
  On Fri, Dec 19, 2014 at 4:30 PM, David Seikel onef...@gmail.com
  wrote:
  On Fri, 19 Dec 2014 11:54:55 -0800 enh e...@google.com wrote:
 
  (sadly the most common request seems to be ooh, does this mean
  we can have less now?.)
 
  Actually I made a start on less, and more, and a bunch of editors,
  and got them working at a basic level.  Robs just been too busy to
  get my generic editor infrastructure in.  So that stalled.
  
  https://github.com/onefang/boxes if you want to look at it.  It may
  have bit rotted though.
 
 I'm working on it. Your infrastructure required some adaptation to do
 what I want it to do in toybox.

You can always tell me what those adaptations are, and I can see if I
can make them.

 I'm trying to clean up pending as fast as I can but I'm worried that
 people using pending and relying on stuff in there might get broken
 when I do the cleanup and promotion...
 
 Speaking of promotion, I think I may get sed promoted today! (Yay!
 Implementing 'l' now and the testing pass has made it to the kernel
 build of the aboriginal native build. I've still got to run it
 through a linux from scratch build, but it hasn't glitched in a
 while...)

Your new sed implementation would have some infrastructure that might
be shared by boxes.  Lots of the editing stuff in a few of the editors
is essentially identical to sed, using the same commands.  Any editor
will have similar infrastructure for dealing with files, lines, actual
editing, and such.

So maybe during the Christmas break (new $DAYJOB means I get paid
holidays for a change), I'll go over toybox sed and see what I can
reuse for boxes.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] optional fatter cat(1)

[David Seikel]

On Fri, 19 Dec 2014 11:54:55 -0800 enh e...@google.com wrote:

 (sadly the most common request seems to be ooh, does this mean we can
 have less now?.)

Actually I made a start on less, and more, and a bunch of editors, and
got them working at a basic level.  Robs just been too busy to get my
generic editor infrastructure in.  So that stalled.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] optional fatter cat(1)

[David Seikel]

On Fri, 19 Dec 2014 16:43:51 -0800 enh e...@google.com wrote:

 i was thinking about writing a trivial termcap implementation that
 just returns the xterm-color answers and using the BSD less, but i
 didn't realize that even the BSDs use the GNU less.
 
 i switched Android over to the toybox more from the mksh shell
 function, but people still complain they really want less. (afaict,
 mostly for the ability to go backwards and search.)
 
 On Fri, Dec 19, 2014 at 4:30 PM, David Seikel onef...@gmail.com
 wrote:
  On Fri, 19 Dec 2014 11:54:55 -0800 enh e...@google.com wrote:
 
  (sadly the most common request seems to be ooh, does this mean we
  can have less now?.)
 
  Actually I made a start on less, and more, and a bunch of editors,
  and got them working at a basic level.  Robs just been too busy to
  get my generic editor infrastructure in.  So that stalled.

https://github.com/onefang/boxes if you want to look at it.  It may
have bit rotted though.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] archivers, read-write loops

[David Seikel]

On Wed, 17 Dec 2014 13:45:19 -0600 Rob Landley r...@landley.net wrote:

  Dear thunderbird, genericization is so a word. Oh good grief it's
  got a squiggle under thunderbird. I am not capitalizing the t.
  Deal with it.
 
  Ok, if the above two are separate sentences, full of squiggles.
  Together as a paragraph: no squiggles. But Ok has a squiggle.
  I'm going to give up trying to understand this email client now.  
  
  Yeah, I gave up on spill chuckers years ago.  
 
 Chuckers has a squiggly underline.

Try a New Zealand dictionary.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] ?from left field

[David Seikel]

On Mon, 20 Oct 2014 13:17:44 +1100 scsijon scsi...@lamiaworks.com.au
wrote:

 I was wondering if toybox 'could / would be able to' have an auto
 tool built into it. I'm not a coder, so can't do it, but
 
 Along the line of:
 --
 If toybox had the command 'siliswap' built into it, but it's inbuilt 
 siliswap was a subset of the full 'siliswap' command and it's
 complete set of switches, as for most people and programs it doesn't
 need the others.
 
 If at a later stage, the user needs to install the full 'siliswap' 
 package because they need to use switches that are not built into 
 toybox's 'siliswap' then toybox's 'siliswap' knows to pass the
 request onto the full siliswap instead of dealing with it itself.
 --
 Not sure if it could be added without a shell file though and i'd
 prefer not to add to the default set. ?or could these be created
 automatically when toybox is first run, against all inbuilt packages,
 or manually with a toybox -cfg command).
 
 And of course, toybox doesn't have or needs siliswap (it's a very old 
 IBM Mainframe silo interface command), i'm not sure it is even used
 anymore.
 
 ...Just a thought...

Normally toybox just has symlinks of the command names that point to
the toybox binary file.  If you actually install packages with commands
that are in toybox then, depending on your package manager or whatever,
it's likely to overwrite the symlink with the proper binary file for
that command.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [Patches] - Some more static analysis fixes

[David Seikel]

On Thu, 09 Oct 2014 23:43:25 -0500 Rob Landley r...@landley.net wrote:

 --- getty.c.patch:
 
 I actually have a pending cleanup to getty I haven't checked in for
 ages because I haven't got a serial port setup lying around to test.
 It redoes the speed calculatons to look like:

Er, serial port console on a VM isn't good enough to test with?

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Gonna have to do the release in the morning.

[David Seikel]

On Wed, 01 Oct 2014 22:05:44 -0500 Rob Landley r...@landley.net wrote:

 Finishing the release notes, test building LFS under aboriginal, the
 two musl patches so I can do the static binaries against musl...
 
 Not quite gonna get this done tonight. (Close. Working on it...)

One of two Xeno code releases gets closer. B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] getty questions.

[David Seikel]

On Sun, 29 Jun 2014 09:19:45 -0500 Rob Landley r...@landley.net wrote:

 Looking at getty, it has a lot of modem support, including
 autodetecting the rate of incoming modem connections from the
 CONNECT message.
 
 Do you actually have a use case for this? Are there still modems in
 live use in 2014, where they're hooked up to a unix system that's
 waiting for you to dial in at an unknown serial port rate? (Not
 internet, not a statically configured serial connection set by the
 bootloader or the console= command line argument?)
 
 Or is this there because that's what you expect getty to do, not
 because you personally know anybody who's still using that
 functionality?

Just quickly off the top of my head before I go to bed, the Open Gear
company might be doing something like that in their enterprise network
equipment.  They have some sort of backup admin interface using GSM
modems or something that I've not looked into.  Could also be a fixed
serial speed.

There's also things like serial parity, word length, etc.  And a huge
array of serial terminal parameters that likely no one uses any more.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Hello world.

[David Seikel]

On Tue, 17 Jun 2014 19:47:58 -0500 Rob Landley r...@landley.net wrote:

 Sorry for the radio silence, I took friday off to prepare my talk for
 Texas linuxfest and instead managed to give myself heatstroke (missed
 my bus stop going to the convention center, the walk from where the
 bus dropped me off was farther than I realized in 90 degree weather,
 when i got there I rehydrated by guzzling an energy drink, and when
 it wore off I crashed hard enough my fingernails turned blue.
 Learning experience: don't rehydrate with strong caffeine, you feel
 _fine_ until it suddenly wears off and your blood pressure drops.)

Word of wisdom from someone that lives in the tropics - don't EVER
rehydrate with anything that contains alcohol, sugar or caffeine, they
are all diuretics that will just dehydrate you quicker in the end,
hence your sudden drop.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] Fw: [Aboriginal] Aboriginal Linux on Google play.

[David Seikel]

There you go Rob.  Now I gotta pull my finger out and actually make the
app.


Begin forwarded message:

Date: Thu, 29 May 2014 11:30:03 -0600
From: Bruce Gardner
To: David Seikel onef...@gmail.com
Subject: Re: [Aboriginal] Aboriginal Linux on Google play.


Absolutely.  Thanks David.

-Bruce



On Wed, May 28, 2014 at 7:57 PM, David Seikel onef...@gmail.com wrote:

 On Wed, 28 May 2014 11:57:55 -0600 Bruce Gardner bgar...@gmail.com
 wrote:

  Hi David,
 
  Very cool!   I'm in the software business, too.  I don't think any
  of my images are 'toy-boxy' but you're welcome to use my image for
  you logo. Would you please include an attribution for the image
  somewhere in the distribution?

 Thank you Bruce.  Yes we would be happy to attribute the image to you.
 May I forward these emails to the mailing list?

  On Mon, May 26, 2014 at 8:43 PM, David Seikel onef...@gmail.com
  wrote:
 
   G'day Mr Gardner.
  
   I've volunteered to create or find a logo for the open source
   toybox project, you can see the details of the project at -
  
   http://landley.net/code/toybox/
  
   Rob Landley, the head toybox developer, suggested one of your
   dorodango photos would be perfect, in the email I have forwarded
   below.  I wasn't able to find any licensing details on your web
   site, so I am contacting you to find out what your thoughts on
   this subject are?
  
   Thanks for your time.
  
  
   Begin forwarded message:
  
   Date: Mon, 26 May 2014 21:07:46 -0500
   From: Rob Landley
   To: David Seikel onef...@gmail.com, aborigi...@lists.landley.net
   Subject: Re: [Aboriginal] Aboriginal Linux on Google play.
  
  
   On 05/26/14 19:53, David Seikel wrote:
I'm thinking a kids toybox, but over flowing with high tech
tools and stuffed pengiuns.  If I can find decent images to bolt
together.
  
   I've seen that logo elsewhere. There's already a busybox and
   android toolbox. Can't say I'm hugely enthused at the concept.
  
   To be honest, if I could get the rights to the image on
   http://www.dorodango.com/about.html it'd be perfect. Failing that,
   something abstract would be nice.
  
   Still, this isn't an issue I've cared enough to do anything about
   in years, so...
  
   Rob
   ___
   Aboriginal mailing list
   aborigi...@lists.landley.net
   http://lists.landley.net/listinfo.cgi/aboriginal-landley.net
  
  
   --
   A big old stinking pile of genius that no one wants
   coz there are too many silver coated monkeys in the world.
  
 
 
 


 --
 A big old stinking pile of genius that no one wants
 coz there are too many silver coated monkeys in the world.




-- 
Bruce Gardner
dorodango.com   http://www.dorodango.com


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
Absolutely.  Thanks David.-BruceOn Wed, May 28, 2014 at 7:57 PM, David Seikel onef...@gmail.com wrote:
On Wed, 28 May 2014 11:57:55 -0600 Bruce Gardner bgar...@gmail.com
wrote:

 Hi David,

 Very cool!   Im in the software business, too.  I dont think any of
 my images are toy-boxy but youre welcome to use my image for you
 logo. Would you please include an attribution for the image somewhere
 in the distribution?

Thank you Bruce.  Yes we would be happy to attribute the image to you.
May I forward these emails to the mailing list?

 On Mon, May 26, 2014 at 8:43 PM, David Seikel onef...@gmail.com
 wrote:

  Gday Mr Gardner.
 
  Ive volunteered to create or find a logo for the open source
  toybox project, you can see the details of the project at -
 
  http://landley.net/code/toybox/
 
  Rob Landley, the head toybox developer, suggested one of your
  dorodango photos would be perfect, in the email I have forwarded
  below.  I wasnt able to find any licensing details on your web
  site, so I am contacting you to find out what your thoughts on this
  subject are?
 
  Thanks for your time.
 
 
  Begin forwarded message:
 
  Date: Mon, 26 May 2014 21:07:46 -0500
  From: Rob Landley
  To: David Seikel onef...@gmail.com, aborigi...@lists.landley.net
  Subject: Re: [Aboriginal] Aboriginal Linux on Google play.
 
 
  On 05/26/14 19:53, David Seikel wrote:
   Im thinking a kids toybox, but over flowing with high tech tools
   and stuffed pengiuns.  If I can find decent images to bolt
   together.
 
  Ive seen that logo elsewhere. Theres already a busybox and android
  toolbox. Cant say Im hugely enthused at the concept.
 
  To be honest, if I could get the rights to the image on
  http://www.dorodango.com/about.html itd be perfect. Failing that,
  something abstract would be nice.
 
  Still, this isnt an issue Ive cared enough to do anything about in
  years, so...
 
  Rob
  ___
  Aboriginal mailing list
  aborigi...@lists.landley.net
  http://lists.landley.net/listinfo.cgi/aboriginal-landley.net
 
 
  --
  A big old stinking pile of genius that no one wants
  coz there are too many

Re: [Toybox] Fw: [Aboriginal] Aboriginal Linux on Google play.

[David Seikel]

I have no idea why that got duplicated.  shrugs

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Toybox - size, what's in it and command overlays!

[David Seikel]

On Fri, 16 May 2014 13:15:19 +1000 scsijon scsi...@lamiaworks.com.au
wrote:

 Considering what is now within toybox and the increase and spread of 
 command content range it has and is being added.
 
 I was wondering if it's time to think about splitting some of it's 
 content out into a number of smaller group command overlay sets with
 the primary command set being able to load and unload the others on a
 need or as-used basis.
 
 I think it would have to be considered soon / now, otherwise like 
 busybox has become, it would become unreasonable to do because of the 
 rewrite and redesign work required.
 
 If anyone needs / wants more expansion. I'll add on request. I will
 add that i'm not a programmer, so what you get will need to be
 tempered by that.

One of the design goals is to have just one file to upload to give you
a known set of useful commands.  If you statically link toybox (I think
that's the default) then that's what you get, a single file with no
dependencies (other than a reasonable kernel).

It's also possible (or at least is planned) to compile individual
commands.  Nothing stops you from compiling several sets of commands,
each under a different name.  There is minimal overhead on both of
these options, so I don't see what the gain is in doing what you
suggest.

Unlike busybox, I would think that Rob can keep a tight lid on the
spread of commands being added to toybox.  Another of his design goals.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] license.html page update.

[David Seikel]

On Wed, 16 Apr 2014 20:00:32 -0500 Rob Landley r...@landley.net wrote:

 I'm planning to check in the attached www/license.html update after
 the 0.4.8 release. Any comments?

I have no problem with it.

 This doesn't change the actual LICENSE file, it just adds some
 explanatory text at the end of the HTML page to go This permission
 grant is functionally equivalent to placing the code in the public
 domain, it's just disguised as a BSD license to make people more
 comfortable, so you can still use it even if you're afraid of the
 public domain due to the 30 year FUD campaign against it. Although if
 you don't believe in public domain code why the heck are you using
 things like dropbear that's built around the public domain libtommath
 and libtomcrypt libraries? The source code in dropbear _says_ it's
 public domain in those two subdirectories, but if a random third
 party takes public domain code and relicenses it _then_ it's ok?
 What's wrong with you...
 
 Only, you know, more professionaly phrased.
 
 Rob
 
 (I might still be a slight bit grumpy at Bradley and
 http://gondwanaland.com/mlog/2014/04/11/commons-patents/ and such
 going but public domain, that's SPOOKY at every darn opportunity...)


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Generic editor. Was: fold implementation

[David Seikel]

On Tue, 08 Apr 2014 19:41:11 -0500 Rob Landley r...@landley.net wrote:

 I'd be interested to know which terminal programs sent which keys.

I've created a showkey toy for just that purpose.

 But mostly what I was thinking is that either escape, followed by the
 rest of the sequence, is unique except for the fact you have R and
 S defined for 0x9b twice (but both times, for 0x9b).

I left them in and commented that they conflict.

 I'm not trying for perfect, I'm trying for mostly works. If some
 term program is crazy, it's crazy. Wait for the bug reports from
 people actually trying to use it.

Exactly what I'm trying to do, something that works but is not perfect.

I've made changes now after your comments, do you want it sent to the
list again, or can you pull it out of my git repo?

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Generic editor. Was: fold implementation

[David Seikel]

On Sun, 13 Apr 2014 17:20:13 -0500 Robert Thompson
robertt.thomp...@gmail.com wrote:

 If we're lucky, simply hardwiring the terminal and key codes that
 overlap between the screen terminal, the linux console, and the
 documented xterm codes should give us a subset that is very widely
 supported even on other VT100-derived terminal emulators.

That's pretty much what I did already.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Generic editor. Was: fold implementation

[David Seikel]

On Sat, 12 Apr 2014 21:00:37 -0500 Rob Landley r...@landley.net wrote:

 I'm strongly tempted to just treat both escape sequences as we saw an
 escape sequence and then the things after that translate the same
 whether they were after the two char or the one char version.

That's what I do.

 Except that the 8 bit one doesn't seem compatible with UTF-8, and I
 want the code to deal with UTF-8 properly.

I'm also checking for the UTF8 version of CSI.

Shortly after getting the buffer, I check for ESC [ and the UTF8 
version of CSI (C29B), then reduce them to the single byte CSI
character.  Then check if it's the single byte CSI character in that big
table.  This keeps the table small.

Keeping it UTF8 compatible means a bit of extra testing, but you told
me to send bite size chunks, and you said you don't care if they are
broken bite sized chunks.  I tried to keep this chunk, while still
providing something that can do something.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Generic editor. Was: fold implementation

[David Seikel]

On Tue, 8 Apr 2014 18:57:24 +0200 Hadrian Węgrzynowski
hadr...@hawski.com wrote:

 Dnia 2014-04-09, o godz. 02:45:55
 David Seikel onef...@gmail.com napisał(a):
 
  Advanced editors allow arbitrary mappings between keystrokes and
  commands.  In this case having strings would be the way to do it.
  Perhaps we wont ever get as far as supporting such advanced editing
  features, perhaps not.  My study of the commands that are on the
  toybox roadmap that might use this broke things down into dead
  simple commands that get something barely usable, basic commands,
  advanced commands, and code editor specific stuff.  My intention
  is to implement things in that order.  At some point along that
  progression we might decide this is where we stop.  As you keep
  saying, a stopping point is good.  So far, other than lets not
  write an entire operating system like Emacs, no stopping point has
  been decided. Dead simple commands was my stopping point for my
  first code drop.
 
 Hello.
 
 It's my first message to this mailing list so pardon me if it's
 generally known. Could this be used as basis for implementation of
 less?

That's exactly what it's for.  I had sent a much bigger bunch of code
to the list some time ago that used this to implement really basic
versions of less, more, emacs, vi, joe, mcedit, and nano.  Also
intended to use this for a shell and mc, but those where not done
then.  Hence the generic editor subject.  Rob wanted me to send it
all in smaller bite sized bits though, so this is the first bite sized
bit.

https://github.com/onefang/boxes includes this bit, and the rest if you
are interested.

My plan is to implement fuller version of those things as toybox toys.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] fold implementation

[David Seikel]

On Thu, 03 Apr 2014 21:32:02 -0500 Rob Landley r...@landley.net wrote:

 On 04/03/14 19:29, Samuel Holland wrote:
  On Apr 3, 2014, at 5:56 PM, Rob Landley r...@landley.net wrote:
  The -u option to fold isn't currently being used...
 
  Could you describe a little more how unfold would work?
  
  Generally, I write papers and such in a text editor with hard
  wrapping, like nano, and then transfer them to LibreOffice for
  formatting. So I go from newline after X columns and a blank line
  between paragraphs to long lines with a single newline between
  paragraphs. The simplest algorithm would be to remove all newlines
  except double newlines (and convert those to single). If -s was
  specified, we would only remove newlines after spaces and tabs (or
  unless there was no space in that line). Finally, if -w was
  specified, we would re-wrap at that width.
 
 *shrug* sounds good to me. I note that when we implement our toybox's
 editor, it'll probably need something like this.

Seems like a good time to remind you about the generic editor code
thread that has my first instalment that's been sitting there for
months with no comment.  Well, one private comment from someone that's
itching to use the more advanced editor, but I'm waiting for you to
deal with the bite sized chunks you asked me for.

The other type of folding is planned as an advanced editing feature.
That's where you fold source code on the screen so that only the top
line of any block of code is visible, the rest get hidden.  That would
either work based on parsing the source code (also needed for syntax
highlighting) or a more simple version based on indentation only.
Either way, that's a bite sized chunk for much later, I hadn't even put
it in the original editor yet.

This sort of folding/unfolding could be added to, especially since
Samuel has written the code already.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] generic editor code

[David Seikel]

In another thread you recently said -

 Feel free to remind me about stuff that got buried.

So I guess it's time to remind you about this again.  A couple of posts
up is where I put the code.

On Thu, 27 Feb 2014 16:15:22 +1000 David Seikel onef...@gmail.com
wrote:

 On Sat, 1 Feb 2014 20:56:53 +1000 David Seikel onef...@gmail.com
 wrote:
 
  On Sat, 1 Feb 2014 12:21:29 +1000 David Seikel onef...@gmail.com
  wrote:
  
   Oops, found a small design fault.  I'm fixing that now, and will
   send an update later today.
  
  This time for sure.  Fixed up the bottom of terminal bug in dumbsh,
  the resizing, and made the keystrokes / ordinary characters
  determination more sane.  Did a lot of debugging and hopefully
  solved all know bugs except for one in the editor that I'll get to
  some other time.
 
 Rob, I would guess you are still too busy with everything else to get
 to this, perhaps I should just keep maintaining it and working on it
 at https://github.com/onefang/boxes until you can get around to it?

People are wanting to use this editor of mine, but are waiting on me to
implement more of the basic editing stuff like search and replace.  But
I'm waiting to see if this time around, I've supplied you with a small
enough chunk for you to digest, so I can feed you more small chunks in
the future.  Eventually building up to the big slab of code I sent last
time, and then I can continue with adding features like search and
replace.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] generic editor code

[David Seikel]

On Sat, 1 Feb 2014 20:56:53 +1000 David Seikel onef...@gmail.com
wrote:

 On Sat, 1 Feb 2014 12:21:29 +1000 David Seikel onef...@gmail.com
 wrote:
 
  Oops, found a small design fault.  I'm fixing that now, and will
  send an update later today.
 
 This time for sure.  Fixed up the bottom of terminal bug in dumbsh,
 the resizing, and made the keystrokes / ordinary characters
 determination more sane.  Did a lot of debugging and hopefully solved
 all know bugs except for one in the editor that I'll get to some other
 time.

Rob, I would guess you are still too busy with everything else to get
to this, perhaps I should just keep maintaining it and working on it at
https://github.com/onefang/boxes until you can get around to it?

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] generic editor code

[David Seikel]

Oops, found a small design fault.  I'm fixing that now, and will send
an update later today.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] generic editor code

[David Seikel]

On Mon, 27 Jan 2014 11:26:16 +1000 David Seikel onef...@gmail.com
wrote:

 I'm finally getting back to working on my editor.  At least for the
 next week.  I broke this out of the other thread, it should have it's
 own.

snip

I've fixed up the bit rot, and got joe / wordstar stuff to work.  As
well as ^C and other keys usually swallowed by the terminal.

 Squeezing it down to manageable by Rob bits might be tricky due to -
 
 On Thu, 27 Dec 2012 06:06:53 -0600 Rob Landley r...@landley.net
 wrote:
  Basically what I'd like is a self-contained line reader. More or
  less a getline variant that can handle cursoring left and right to
  insert stuff, handle backspace past a wordwrap (which on unix
  requires knowing the screen width and your current cursor
  position), and one that lets up/down escape sequences be hooked for
  less/more screen scrolling, vi line movement, shell command
  history, and so on.  
 
 Which is most of the editor already.

Nearing the end of the week, and I hopefully have a first bit to put
into toybox.  The generic input handler, including SIGWINCH and
terminal size probing.  Hopefully it's Rob friendly enough this time
around, and can be added to toysh.  If it's still too big to digest, I
can leave out the terminal size probe, and send that again later.  The
CSI parser to handle that is a big lump of code in the middle.

The terminal size stuff could be integrated into the existing
terminal_size(), but I wanted this first code drop to be just stand
alone files.

First is handlekeys.c and handlekeys.h, both to be put into lib.  Docs
on what it is and how to use it are in handlekeys.h.  Should be usable
for all your keyboard input and screen sizing needs.  Can be extended to
deal with mouse input to, but that's for another day.  Error handling
leaves a lot to be desired, but is more suitable for testing at the
moment.

Second is dumbsh.c, to be put into pending.  It's really just an
example for how to use handle_keys(), but it could be fleshed out into a
real toysh a little bit at a time.

Referring to Rob's comment above -

It's sorta self contained, but since it's up to the application to deal
with what to do with keystrokes and CSI commands, I made the input
handler the self contained blob.  It translates things to something
easily digested by user code, and tries to deal with the gotchas.  Using
that to make a getline variant doesn't take much, as the dumbsh example
shows.

The dumbsh.c file is a brain dead and stupid shell example.  It uses
Emacs style keys (trivial to change to vi or something else) to do
cursor left, right, home, end, backspace, and delete.  It reads the bash
history file and lets you up and down arrow through it.  It handles
terminal resizes, even in the middle of typing commands.

Dumbsh doesn't do multi line editing, so no backspace past a wrap,
should be doable easily enough.  It doesn't add stuff to the history,
should be trivial.  It doesn't actually execute commands, I'm still
thinking about how to deal with ^C and friends for that.

Dumbsh has a bug or three.  First time you get to the bottom of the
terminal it will swallow the next line, and resizing quickly gets crap
on the screen. Perhaps other bugs.

I'll likely work on fixing the dumbsh bugs more during the weekend.
Next week I'll be working on something else for a while.  Likely there
will be a week of effort on the editor during February, but I can deal
with any small issues in the mean time.

The editor stuff is still on https://github.com/onefang/boxes , but will
leave putting that into toybox until much later.  It still needs lots of
cleaning up.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
/* dumbsh.c - A really dumb shell, to demonstrate handle_keys usage.
 *
 * Copyright 2014 David Seikel won_f...@yahoo.com.au
 *
 * Not a real shell, so doesn't follow any standards,
 * coz it wont implement them anyway.

USE_DUMBSH(NEWTOY(dumbsh, , TOYFLAG_USR|TOYFLAG_BIN))

config DUMBSH
  bool dumbsh
  default n
  help
usage: dumbsh

A really dumb shell.
*/

#include toys.h
#include lib/handlekeys.h

typedef void (*eventHandler) (void);

struct keyCommand
{
  char *key;
  eventHandler handler;
};

GLOBALS(
  unsigned h, w;
  int x, y;
  struct double_list *history;
)

#define TT this.dumbsh

// Sanity check cursor location and update the current line.
static void updateLine()
{
  if (0  TT.x)  TT.x = 0;
  if (strlen(toybuf) = TT.x)  TT.x = strlen(toybuf);
  if (TT.w  TT.x)  TT.x = TT.w;
  if (0  TT.y)  TT.y = 0;
  if (TT.h  TT.y)
  {
printf(\x1B[%d;0H\n, TT.y + 1);
fflush(stdout);
TT.y = TT.h;
  }
  printf(\x1B[%d;0H%-*s\x1B[%d;%dH,
TT.y + 1, TT.w, toybuf, TT.y + 1, TT.x + 1);
  fflush(stdout);
}

// Callback for incoming CSI commands from the terminal.
static void handleCSI(long extra, char *command, int *params, int count)
{
  // Is it a cursor location report?
  if (strcmp(R, command) == 0

[Toybox] generic editor code

[David Seikel]

I'm finally getting back to working on my editor.  At least for the
next week.  I broke this out of the other thread, it should have it's
own.

On Tue, 24 Dec 2013 10:41:39 -0800 ibid...@gmail.com wrote:

 On Tue, Dec 24, 2013 at 01:18:46PM +1000, David Seikel wrote:
   
   I note that patch does something really similar to this.
   Maintaining these kind of line buffers is something we've got
   code and there might be some opportunities for code sharing. I'll
   have to look...
  
  This is why I wanted to include sed as one of the various editors I
  wanted to support in my generic editor code.  Less, grep, sed, vi,
  emacs, etc. all need to deal with line buffers.  s/foo/bar/g works
  in most of the editors, including sed.  Lots and lots of common code
  there.  Still on my TODO list to cut it down into easier to digest
  bits for you, which is like your TODO, it runneth over, several
  times.
  
 FYI, there are a few small build fixes I needed:
 
 diff --git a/boxes.c b/boxes.c
 index 5945308..2eb1308 100644
 --- a/boxes.c
 +++ b/boxes.c
 @@ -35,11 +35,11 @@ config BOXES
  */
  
  #include toys.h
 -#include toynet.h
  
 -DEFINE_GLOBALS(
 +GLOBALS(
   char *mode;
 - long h, w;
 + long h;
 + long w;
   // TODO - actually, these should be globals in the library,
 and leave this buffer alone. int stillRunning;
   int overWriteMode;

Yes, it bit rotted a little.  Splitting the long deceleration didn't
seem to be needed.  Unless it's a style thing, I think there was a
toybox style change since I first wrote this.  I'll be going over the
entire thing and making it pretty and clean soon.

 But for reasons unknown to myself, boxes does not seem to ever exit
 (apart from Ctrl-C; tested with joe and vi modes), I get the
 impression it doesn't save,

Saves and exits fine in the default mcedit / cooledit mode.  Joe mode
seems to be broken currently, thought I had it working.  For vi and
other editors that can deal with shortcuts for their commands, the
shortcuts are not implemented yet.  So the ex mode :write and :quit
commands work fine, just not :q or similar.

 and vi never clears the : once you run
 a command of that sort.  I'd suspect it got stuck in ex mode, but
 since none of the commands have an effect I can't tell...
 Is that expected behavior at this point?

There's various methods of escaping from ex mode.  You can just
backspace out of it, or use Ctrl-[.  Ctrl-C should escape, but I'm not
catching that at the moment.  It also should escape after a command,
but that's not implemented yet.  There are actually two ex modes, but
they are currently treated the same.  The temporary one is invoked
by :, that's the one you can backspace out of, or returns to visual
mode on command completion.  The other one is invoked by Q, it's not
supposed to back out on backspace or command, only the control keys
mentioned above.

Treating the : and Q ex modes differently is a complication.  Catching
Ctrl-C is a complication.  Command shortcuts is a complication.  All
such complications I'll deal with later, but first I need to simplify
it enough so that Rob can accept an initial version.  Fixing joe mode
may or may not be a complication, some debugging needed there.

Squeezing it down to manageable by Rob bits might be tricky due to -

On Thu, 27 Dec 2012 06:06:53 -0600 Rob Landley r...@landley.net wrote:
 Basically what I'd like is a self-contained line reader. More or less
 a getline variant that can handle cursoring left and right to insert  
 stuff, handle backspace past a wordwrap (which on unix requires
 knowing the screen width and your current cursor position), and one
 that lets up/down escape sequences be hooked for less/more screen
 scrolling, vi line movement, shell command history, and so on.  

Which is most of the editor already.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Some questions re: init...

[David Seikel]

On Mon, 06 Jan 2014 00:07:51 -0600 Rob Landley r...@landley.net wrote:

 On 01/05/14 20:31, ibid...@gmail.com wrote:
  On Sun, Jan 05, 2014 at 11:49:31AM -0600, Rob Landley wrote:

  I'm pretty happy just hardwiring in TERM=linux if it's not already
  set. (Although possibly this is the shell's job and not init's? Sad
  there's no spec for init...)
 
  The shell doesn't set TERM; it reads it.
  It's the job of whatever provides a tty, which in this case means
  init is on the hook.
 
 I was recently looking at login, which can also set it. And getty can 
 set it too. (I wonder what upstart, openrc, and android's init do?)
 
 These days termio is all software talking to other software, we
 emulate terminals so terminal emulators can parse the data, they just
 have to agree on it. There aren't anymore vt100 tn3270 or ASR33
 teletypes lying around anymore. It's possible that minicom is brain
 damaged and hardwired, but the microcom in busybox just dumps I/O to
 the terminal it's running in. Same for netcat in toybox. Those can
 handle TERM=linux on a serial line. And qemu's -nographic mode
 connecting /dev/console to stdin and stdout works with TERM=linux on
 the (emulated) serial line.
 
 So I don't see a big reason not to hardwire TERM=linux and if
 somebody does need to set it to vt102, gettty or login can do that...

My editor code just ignores TERM, and uses a few very common escape
sequences to drive what ever pretend terminal you are using.  I doubt
if anything else inside toybox cares either.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Finally removed the python requirement.

[David Seikel]

On Fri, 03 Jan 2014 19:04:37 -0600 Rob Landley r...@landley.net wrote:

 Now generated/help.h is made by a C file, every build, and I don't
 have to treat that file specially during clean or cutting release
 tarballs, and no weird python2 version probing. Yay!

Cool.  I always enjoy when people make Python go away, but then I have
an unreasonable hatred of any programming language that starts with the
letter P.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] FTP commands

[David Seikel]

First of all, could every one stop CCing me, I'm actually on the list
and I'm getting this entire conversation twice.  It seems every one
just copies the CC list from the one they are replying to, then adds
one.  The CC list has been steadily growing here.  lol

On Thu, 12 Dec 2013 17:39:56 -0800 ibid...@gmail.com wrote:

 On Thu, Dec 12, 2013 at 02:25:38PM +0530, Ashwini Sharma wrote:
  Hi,
  
  The input parameter port was kept as string, so that the
   user can also give service name like ftp instead of numeric PORT.
  
  Which will be resolved by getaddrinfo() using /etc/services.
  
  regards,
  Ashwini
  
 Thanks for the explanation.
 Unfortunately it doesn't always work that way:
 
 //TT.port is initialized to ftp if not set
 static void get_sockaddr(char *host)
 {
   struct addrinfo hints, *result;
   char *ptr;
   int status, port;
 
   errno = 0;
   port = strtoul(TT.port, ptr, 10); // - may set errno if
 non-numeric port if (errno || port  65535) error_exit(Invalid port,
 Range is [0-65535]); // - we hit this by default on musl
 
   memset(hints, 0 , sizeof(struct addrinfo));
   hints.ai_family = AF_UNSPEC;
   hints.ai_socktype = SOCK_STREAM;
 
   status = getaddrinfo(host, TT.port, hints,
 result);
   if (status) error_exit(bad address '%s' : %s,
 host, gai_strerror(status));
 
   memcpy(TT.buf, result-ai_addr, result-ai_addrlen);
   freeaddrinfo(result);
 }
 
 I'm thinking that should be 
 -  port = strtoul(TT.port, ptr, 10);
 +  if (isdigit(TT.port[0])) port = strtoul(TT.port, ptr, 10);
 
 and initialize port to 0, if we want to keep support for -P ftp.
 (I don't imagine anyone using -P ssh or any non-numeric port other
 than ftp.)

Yes keep support for -P.  I use it, and I think Aboriginal Linux uses
it.  At least from the busybox version, and I think we both want to
move to the toybox version.  I think we both use numeric ports for what
it's worth.

 OK, yes that works...
 
 Attaching my full diff, which also addresses a couple nitpicks:
 
 -Rob adds new applets to toys/pending/, default n. 
 They get default y when he thinks they're ready.
 -Any user-supplied value is all-caps in the help messages, so
 we have -u USER -p PASSWORD -P PORT
 
 Thanks,
 Isaac Dunham
 


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] FTP commands

[David Seikel]

On Tue, 5 Nov 2013 20:06:10 -0800 ibid...@gmail.com wrote:

 On Fri, Oct 18, 2013 at 01:05:50AM +0200, Bertold Van den Bergh wrote:
  
  Can commands be accepted that are not on the roadmap? I will
  certainly need 'ntpdate' which for embedded systems is better than
  a full blown ntpd.
 
 That would be a question for Rob.
 
 That said, I'd be in favor of it. Having *not* examined NTP in
 detail, I get the impression that it might be possible to have ntpd
 and ntpdate share much of their code.

Aboriginal Linux uses rdate, which is also not on the toybox roadmap.
I would have thought that rdate or ntpdate would have been.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Fwd: [New Toy - patch] add ps watch

[David Seikel]

On Wed, 21 Aug 2013 11:52:25 -0500 Rob Landley r...@landley.net wrote:

 On 08/21/2013 06:47:34 AM, David Seikel wrote:
  On Wed, 21 Aug 2013 02:11:39 -0500 Rob Landley r...@landley.net  
  wrote:
  
   On 08/20/2013 11:15:42 PM, David Seikel wrote:
On Tue, 20 Aug 2013 15:55:24 -0500 Rob Landley r...@landley.net
wrote:
   
 On 08/20/2013 04:46:20 AM, Ashwini Sharma wrote:
  Hi Rob,
 
Attached are the patches for _watch_  and _ps_ command.
 
  Sent _ps_ again, just in case you lost the last one. This
  one also have a
  copyright update.

 I planned to do watch.c after doing less.c because both have
 the similar printing a chunk of a larger screen logic. If
 your command output produces too many lines, it shouldn't
 scroll off, but given that it can wrap around to produce more
 lines, you can't just count lines. For example:

watch 'python -c print
 100*\abcdefghijklmnopqrstuvwxyz\'

 This version just scrolls off. It doesn't capture the output
 and make an attempt to format it. But toybox needs that logic
 for less, more, vi, editing command line history...
   
I've been thinking about what you said before about my large
editor and
screen handling blob.  I think I have found a way to at least
make one or two much smaller blobs to help ease it into
toybox.   
  Finding
the time to get to it is a problem we are all too familiar with.
I'll get there, I want to actually use it myself.
  
   I note that busybox gets this wrong (their watch shows all
   output each time, scrolling the screen at length for watch ls
   -lR /), so it's an easy mistake to make. But I want to be
   _better_ than  
  busybox.
  
  Busybox's less also just dumps it all in one go if I remember.
 
 Yeah, less needs to do progressive disclosure, which means a select  
 loop responding to new lines of output _and_ user keyboard input at
 the same time...
 
   Also, this is one of them damn fiddly bits whith asynchronous
   ascii probing of screen size as part of interactive input,  
  responding
   to dynamic window resizing (keeping in mind that sigwinch won't
   propogate over a serial port), fixing it so the shell notices when
   it's not starting at the left edge (in bash echo -n walrus
   screws up editing of the following line; at one point busybox ash
   got that right because I complained),
  
  That's the first thing I want to do as a single smaller patch,
  sorting out the various terminal size fiddly bits.  I had noticed
  when I was looking at it last time that I've not completely sorted
  that out anyway, but I was close.
  
   that fun bit about collating escape sequence input while also
   allowing escape by itself to put vi into command mode (I used 1/3
   of a second timeout)...
  
  That bit I got solved, also with a time out.  Seems the only way.
 
 That's what I implemented in busybox. :)
 
 Where's your current code for this? Maybe I have time to look at it  
 now...

https://github.com/onefang/boxes with lots of under construction,
excuse the mess warnings in the readme.  No idea if it has bit rotted
since last I looked.  I hope to get time in the near future to clean it
up and split it up as I mentioned.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net