Re: Truecolor on OSX?

Even though the Mac OS X version is using the true color (colour  
might be the more appropriate form of the word) X11 source, I've  
never been able to get it to actually display in 24 or 32 bit color  
modes.

jas

On Jul 28, 2005, at 10:20 PM, Jack Johnson wrote:

> I recall Inferno having truecolor support, but I tried various -C
> options with no (good) success.
>
> Is it not supported on OSX?
>
> -Jack
>
>

inferno newbie

Re: inferno newbie

>  But first of all, i need to know how to read/send email. I read  acme(1)
> and i can't get it working with Mailpop3 module.
I don't use this anymore, but this worked on my comcast account without SSL.

In your /lib/ndb/local set the smtp and pop3 variables for you site, e.g.,
infernosite=
  pop3=mail.comcast.net
  smtp=smtp.comcast.net

Log into inferno as the user you want to connect to your mail account.
Set the DOMAIN environment variable for example
  DOMAIN=comcast.net

Download the attached Mailpop3.b and compile and run within acme. You
should just need to type in your pop password, and then you can read
and send email from within acme.

This won't work for gmail pop because of ssl support is not in Mailpop3.b.

>  Anyway a wiki like the plan9 one would be helpful to this kind of tasks.
I ported the plan9 wikifs to inferno. It is running here
http://canto.hopto.org/wiki/1

-Caerwyn

building under macosx

two quick tips for users trying to rebuild inferno from src under
macosx:

1) I found that I needed to replace the dependence on libtool with
plain old ar in mkfiles/mkfile-MacOSX-power:

	#AR=            libtool
	#ARFLAGS=       -static -o
	AR=             ar
	ARFLAGS=        crvs

this was to get around to fact that every other time mk touched
lib9, libtool would be run with only one input file and clobber the
output file, leaving you with a busted lib:

	$ mk all
	libtool -static -o /Users/Shared/Inferno-20050720/MacOSX/power/lib/lib9.a convD2M.o convM2D.o
convM2S.o convS2M.o fcallfmt.o qsort.o runestrlen.o strtoll.o rune.o argv0.o charstod.o cistrcmp.o
cistrncmp.o cistrstr.o cleanname.o create.o dirwstat.o dofmt.o dorfmt.o errfmt.o exits.o fmt.o
fmtfd.o fmtlock.o fmtprint.o fmtquote.o fmtrune.o fmtstr.o fmtvprint.o fprint.o getfields.o
nulldir.o pow10.o print.o readn.o rerrstr.o seek.o seprint.o smprint.o snprint.o sprint.o strdup.o
strecpy.o sysfatal.o tokenize.o u16.o u32.o u64.o utflen.o utfnlen.o utfrrune.o utfrune.o utfecpy.o
vfprint.o vseprint.o vsmprint.o vsnprint.o dirstat-posix.o errstr-posix.o getuser-posix.o
getcallerpc-MacOSX-power.o getwd-posix.o
	$ mk all
	libtool -static -o /Users/Shared/Inferno-20050720/MacOSX/power/lib/lib9.a getcallerpc-MacOSX-power.o

huh??!  I'm not sure if mk is doing something wrong there or not,
but at least when I switched to ar it didn't clobber the output
file.  this problem was most apparent during an interruped 'mk all',
for example.  ymmv but this definitely helped on my system.

2) there seems to be a problem with compiling appl/cmd/units.b with the
native limbo compiler:

	limbo -I/Users/Shared/Inferno-20050720/module -gw units.b
	fatal limbo compiler error: no file specified for       movw    $1,4(48(fp))
	mk: limbo -I/Users/Shared/Inferno-20050720/module -gw units.b  : exit status=exit(1)

since mk exits there, many of the remaining files you need in order
for emu to run don't get installed.  invoking 'mk install' as 'mk
-k install' lets you get around this.  you can then do a 'mk install'
from within emu to reinstall units.dis.  I'm not sure what the
underlying problem with the native limbo is there, but I noticed
that it happens under linux too.

good luck...

	-Chad

Re: building under macosx

>>from within emu to reinstall units.dis.  I'm not sure what the
>>underlying problem with the native limbo is there, but I noticed
>>that it happens under linux too.

i don't know.  when you first mentioned it, i tried to reproduce it on all the linux
systems i've got, but i haven't yet succeeded (or do i mean, failed?).
i understand what the diagnostic might mean, but
not how it gets into that state, or just why that particular file
(presumably because it was built using yacc, but there are several others like that).

i hadn't noticed the libtool problem apparently because i tend to remove
all the libraries before each build (partly because i sometimes change the
library structures, and partly to ensure they can be built from scratch).
i'm happy to change back to ar, though.

Re: inferno newbie

Re: building under macosx

On Thu, Aug 04, 2005 at 08:12:15AM +0100, Charles Forsyth wrote:
> >>from within emu to reinstall units.dis.  I'm not sure what the
> >>underlying problem with the native limbo is there, but I noticed
> >>that it happens under linux too.
> 
> i don't know.  when you first mentioned it, i tried to reproduce it on all the linux
> systems i've got, but i haven't yet succeeded (or do i mean, failed?).
> i understand what the diagnostic might mean, but
> not how it gets into that state, or just why that particular file

the relevant specs for the systems that generate the error:

$ uname -a
Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power Macintosh powerpc
$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1666)

$ uname -a
Linux ubuntu 2.6.10-5-386 #1 Tue Apr 5 12:12:40 UTC 2005 i686 GNU/Linux
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls
--without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)

if there are any other bits of information or tests that would help,
let me know.

> (presumably because it was built using yacc, but there are several others like that).
> 

yeah, it had crossed my mind that it might be a yacc-induced error
but I don't know enough to say for sure.

	-Chad

Re: building under macosx

>yeah, it had crossed my mind that it might be a yacc-induced error
>but I don't know enough to say for sure.

Check your $PATH.  I've had problems with different versions of yacc in the past, too.  When in doubt, use the
Inferno yacc, rather than the MacOSX-supplied yacc.  Make sure that your
/usr/inferno/MacOSX/power/bin (or wherever else you've installed Inferno) shows up before all your
other stuff...  I've even had conflicts between plan9port and the Inferno environment, despite the fact
that they ought to be 100% compatible...

Good luck!!

-Ben

Re: building under macosx

On Thu, Aug 04, 2005 at 08:52:36AM -0700, Ben Huntsman wrote:
> >yeah, it had crossed my mind that it might be a yacc-induced error
> >but I don't know enough to say for sure.
> 
> Check your $PATH.  I've had problems with different versions of yacc in the past, too.  When in doubt, use the
Inferno yacc, rather than the MacOSX-supplied yacc.  Make sure that your
/usr/inferno/MacOSX/power/bin (or wherever else you've installed Inferno) shows up before all your
other stuff...  I've even had conflicts between plan9port and the Inferno environment, despite the fact
that they ought to be 100% compatible...
> 

yeah, I did all of that beforehand.  in the 'units' case, the limbo
src is already included and doesn't get run through yacc at build
time as far as I can tell.  the fact that was generated by yacc at
some point in the past is what I was referring to though.

	-Chad

Re: inferno newbie

>  It would be nice to add a -u $user option or read $user variable or
> something like that to Mailpop3.

Ideally, I think a port of upas/fs is needed.

>  I will take a look to the wiki, i hope to have time to collaborate :)

If anyone would like to post to the Inferno Programmer's Notebook
(http://caerwyn.com/ipn) with the story of whatever they're working on
in inferno, then send me a note and I'll send you an invite to the
blog. (I'm afraid you'll need to register with blogger. An inferno
blogfs is on my wish list bug i've no plans to actually write it.) I'd
love to hear what others are working on.

-Caerwyn