On Fri, 13 Sep 2013 14:30:37 +0200
Jens Staal wrote:
> Now nano builds on APE with PDCurses and sort of "works" : can open
> text files and fast commands work.
> what does not work:
> - line change by enter
> - saving a file (related to my mkstemp hack?)
scratch that... everything works. Just a
On Thu, 12 Sep 2013 11:16:31 -0400
erik quanstrom wrote:
> > On 9atom 1 out of two type signature conflicts got resolved when I
> > tried to build GNU nano (using FGB's PDcurses, rebuilt on 9atom to
> > avoid that character width or something might be an issue).
> >
> > The resolved issue was so
> On 9atom 1 out of two type signature conflicts got resolved when I tried to
> build GNU nano (using FGB's PDcurses, rebuilt on 9atom to avoid that
> character
> width or something might be an issue).
>
> The resolved issue was some sort of internal conflict in libbsd bind. The
> remaining is
On Thu Sep 12 02:27:31 EDT 2013, lu...@proxima.alt.za wrote:
> > it appears that there are mistakes in ntohl and ntohs.
>
> The problem with _sock_findrock() is that in
>
> /sys/src/ape/lib/bsd/connect.c
>
> the
>
> #include
>
> is missing. Took me a while to figure that
On Thursday 12 September 2013 01:21:38 erik quanstrom wrote:
>
> i believe all the type signature problems in 9atom's ape have been sorted
> out. if you find something that does not work, it will be fixed.
>
> - erik
On 9atom 1 out of two type signature conflicts got resolved when I tried to
b
> it appears that there are mistakes in ntohl and ntohs.
The problem with _sock_findrock() is that in
/sys/src/ape/lib/bsd/connect.c
the
#include
is missing. Took me a while to figure that one out.
I rearranged the #includes to match socket.c, now that the entries ar
> I presumed I missed the obvious errors because I didn't know what to
> look for. I'll see if I can internalise this for future use. With
> the CVS sources, turning on "T" creates an avalanche of errors. I
> suspect the same goes for OpenLDAP.
it's surprising how many large projects rely on vi
> it appears that there are mistakes in ntohl and ntohs.
> for obvious reasons int is valid for both "unsigned long" and
> "unsigned short" due to the usual conversions (and the local,
> temporary conventions on amd64), but remember, type
> signatures are based on C types, and may differ from the
>
attached. sorry for the violence to the 9fans standard of no attachments.
- erik#!/bin/rc
# 9fs filesystem [mountpoint] - srv & mount filesystem, usually from plan 9
rfork e
nflag=-n
if(~ $1 -a){
shift
nflag=()
}
switch($1){
case ''
echo usage: 9fs service '[mountpoint]'
> i believe all the type signature problems in 9atom's ape have been sorted out.
> if you find something that does not work, it will be fixed.
I'll see if I can sync my APE libraries and headers with 9atom's, this
is getting beyond annoying. Off the cuff, do you have a 9-mountable
link for 9atom,
it appears that there are mistakes in ntohl and ntohs.
for obvious reasons int is valid for both "unsigned long" and
"unsigned short" due to the usual conversions (and the local,
temporary conventions on amd64), but remember, type
signatures are based on C types, and may differ from the
implementat
> I'm going to start from the man page: 8c(1)
>
> -T Pass type signatures on all external and global enti-
> ties. The signature is based on the C signof opera-
> tor. See dynld(2).
>
> There is no dynld(2), I do wish the reference could be to som
I'm going to start from the man page: 8c(1)
-T Pass type signatures on all external and global enti-
ties. The signature is based on the C signof opera-
tor. See dynld(2).
There is no dynld(2), I do wish the reference could be to some useful
docum
13 matches
Mail list logo
