On Tue, Mar 28, 2017 at 12:00:22AM -0700, Michael Forney wrote:
> On Mon, Mar 27, 2017 at 2:44 PM, Marc André Tanner <mat_AT_brain-dump.org> wrote:
> > Hi Michael,
> >
> > Overall I like your package selection, but I also have a few questions:
> >
> > * Did you consider using netbsd-curses[1] instead of ncurses?
> >
> > This probably won't work as is, because libtermkey as required by
> > vis depends on the ncurses terminfo library. It might be worth
> > investigating how much work it would be to either port libtermkey
> > or provide the necessary terminfo symbols in netbsd-curses.
>
> I have not. I actually was originally very hesitant to include any
> curses library at all, since it seems to me like the wrong layer to
> implement a graphical UI (instead going the route of acme + 9term).
In principle I agree. Unfortunately I often have to deal with systems
where I'm stuck with a tty.
> If you find a way to use netbsd-curses
That might be more easily possible.
> (or maybe no curses at all; I
> saw you added a vt100 UI to vis), I'd be interested.
The vt100 UI stuff cuts out the middle man (trades it for a fixed
set of escape sequences and probably a lot of display flickering),
but is ultimately still based on the same flawed terminal abstraction.
Speaking of curses alternatives there is also
http://www.leonerd.org.uk/code/libtickit/
which is advertised as the "successor" of libtermkey (currently
it still depends on it though). I haven't actually looked at it in
detail, partly because it uses bzr as SCM and launchpad as issue
tracking system. Apparently a first version was released recently.
Not sure whether it would be an improvement.
> > * Did you try how much of the system can be built using a C only
> > toolchain like cparser+libfirm?
>
> I did try cparser/libfirm at one point in the project's infancy and I
> was surprised at the amount of stuff that built no problem. I have
> since added more packages though, so can't give you a recent answer.
It was a long time ago when I last played around with it, but it is
supposedly able to build musl. Hence I thought the rest of the core
system should also be doable. But maybe I'm a bit too optimistic. Also
just being able to compile something isn't that interesting in itself,
the result should also work as expected.
I just tried to build vis, but cparser doesn't currently support multiple
source files on the same command line. This of course doesn't concern
oasis where you completely replaced the build system.
> I also spent a week or so a while ago fixing some bugs in scc to try to
> get it to build sbase. I think it would be really cool to be able to
> build the core system (or more!) with a lighter toolchain.
I strongly agree. I wonder whether an organization participating in GSoC
would be willing to accept/mentor such a project (working on cparser+firm).
Maybe OpenWRT/LEDE? Seeing that they are using musl as their libc.
I'm probably a bit late to the party though ...
> > * Why did you settle for perp instead of s6[2]? Again I'm not really
> > familiar with either of them (besides reading their respective
> > websites etc.). Just curious, it would be interesting to get your
> > reasoning behind the package selection process.
>
> I tried both a couple of years ago, and liked perp more. It seemed
> simpler and smaller in scope than s6. s6 has its own scripting
> language and quite a lot of extra tools. Although, I have to admit,
> one contributing factor is that the s6 tool names are just a pain to
> type.
Yeah, I'm not yet sure what I should think of stuff like execline.
I haven't actually used either system for a sufficient amount of time
to draw any meaningful conclusions.
Received on Tue Mar 28 2017 - 15:33:40 CEST