headers
Rudolf Sykora | 9 Feb 13:07
Picon

ligatures in troff

Hello,

when I try to use any ligature in troff (on p9p, but if I remember
correctly also on p9) , such as \(fi, I don't get it. Instead I see:

tr2post: <stdin>:6735 :WARNING: cannot find glyph, rune=0x66
stoken=<fi> troff font R

Is there any (preferrably simple) way to use the ligatures (they are,
I believe appropriate in the Times Roman font).
Do you also experience such behaviour?

Thank you!
Ruda
Permalink | Reply | 0 comments |
headers
Anthony Sorace | 9 Feb 04:20
Gravatar

Cocoa devdraw in 9vx/drawterm?

Has anyone started work on taking the (very nice) Cocoa
devdraw stuff and making it work with 9vx or drawterm?
Permalink | Reply | 0 comments |
headers
Nemo | 7 Feb 19:55
Favicon

poll: files

I'm working on a file system that will keep most of the tree in memory
at all times (in fact, the "active" tree is only in memory). It archives frozen
temporary copies to a disk partition until it gets full (in which case the oldest
is discarded) and an external program is going to make permanent archives
in venti.

I'd like to know how many files do you have in /active and how big is your
/active tree in the machines you are using (even though they might not
run plan 9, I don't care about that).

thanks for the info.

PS: send it directly to me, I'll summarize here if people wants to know.
Permalink | Reply | 0 comments |
headers
Jeff Sickel | 7 Feb 17:27
Favicon
Gravatar

ape under arm

Just a quick question for other users of ARM based machines:

Should the ape/lib/openssl be ignored for ARM, or is there a decent alternative for objtype=arm when
trying to 
build it?  The current build fails as /sys/include/ape/openssl/opensslconf.h errors out with 'unknown objtype'.

Otherwise, I can get ape/lib/openssl to build (though not necessarily be viable) by the subtle change below:

term% cd /sys/include/ape/openssl
term% diffy opensslconf.h
85c85,86
< #if defined(PLAN9) && defined(T386)
---
> #if defined(PLAN9)
> #if defined(T386)
86a88,89
> #elif defined(Tarm)
> #define ARM_ONLY
89a93,94
> #endif
> 

This small change has made it a lot easier to populate my arm tree.
Permalink | Reply | 7 comments |
headers
Rudolf Sykora | 6 Feb 11:17
Picon

refer for plan9port

Hello,

does anybody know about a 'refer' version for plan9port?

(I know there is a version for plan9 in the contrib, but I generally run p9p...)
(Also: I can't directly use the GNU refer, since it stumbles over
unicode characters in my texts.)

Until now I have been using the Heirloom version. But it seems to have
unexpectedly stopped working for some reason.

Thank you!
Ruda
Permalink | Reply | 2 comments |
headers
bsder | 5 Feb 19:08
Gravatar

using memory stick

I am trying to figure out whether a memory stick can be used 
in a usb port on an IBM T23 laptop to transfer files to and
from the memory stick, and if so, how to mount the stick
and copy files to and from it.

The Plan 9 installation I have is from November 2009.
/dev/usb shows a ctl file and three directories,
ep1.0, ep2.0, and ep3.0.  
The T23 has only two usb interfaces on the back.

Robert

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Permalink | Reply | 1 comment |
headers
erik quanstrom | 3 Feb 03:33
Favicon

encode(2)

as it turns out, encode(2) inaccurately describes the code.
dec64, enc64, dec16 and enc16 truncate rather than returning
errors.

does anybody have any reasons why truncated encodings should
be allowed?  i think this only allows for interesting attacks based
on truncated encodings, rather than being useful.  but i could
be wrong.

i'm currently testing these changes (there are a few calls to enc/dec64
that need correcting).

- erik
Permalink | Reply | 0 comments |
headers
tlaronde | 2 Feb 14:34

[RFC] How to install without

Since it seems that Iruatã Souza, who had accepted to give a second look
at what I wrote, is as short on time as I am, here is for review an
explanation about "how to do [an install] without". [Still TODO: fix
disk/fdisk.]

       Installing Plan9 without a CD reader or a PXE boot.

                            Abstract

The Plan9 distribution is available for installation by the mean of a
bootable ISO image supposed to be burnt on a CDROM. But this image has
indeed all the pieces needed to realize an installation, without a CD
reader, or without a PXE boot.

What follows is an illustration of "how to do without".

0. What was first? The egg or the goose? Well: the egg, that is some
BIOS.

In the following, the names will match the pc world; but, more or less,
there is a mapping between pc idiosynchrasies and something else
idiosynchrasies.

When a pc starts, it first initializes its hardware before giving the
hand to an user provided program---generally an operating system. But to
be able to hand over to something else, it has to know the rendez-vous
point. This BIOS entry point is a 512 bytes sector, that is a program,
and that is (for disks and like) the very first sector of the device.

On disks, it is called: MBR. It is a program with a signature (for basic
(Continue reading)

Permalink | Reply | 0 comments |
headers
erik quanstrom | 2 Feb 13:49

Re: [kenfs] the mercurial repo problem

On Thu Feb  2 06:57:40 EST 2012, akumar <at> mail.nanosouffle.net wrote:
> This is a problem perhaps two of us
> have on Plan 9 (hi Erik): mercurial
> repositories contain files with long
> names and/or spaces.

coraid run's ken's file server.  so a fair percentage
of plan 9 users run on that rather than fossil.

- erik
Permalink | Reply | 0 comments |
headers
Akshat Kumar | 2 Feb 12:56

[kenfs] the mercurial repo problem

This is a problem perhaps two of us
have on Plan 9 (hi Erik): mercurial
repositories contain files with long
names and/or spaces.

I realised that `lnfs' is a neat solution
to this problem (though you have to
remember to run it each time you're
in the repo) for the time-being. In
particular, it doesn't hog up ram (the
way ramfs does... :), and it doesn't
rely on the repo .hg dir already being
there (the way hgfs does), which is
what usually contains the long names.
And we can use `unlnfs' to export.

Just for future reference -- I noticed that
this didn't come up when we last discussed
this issue.

As always -

BUGS
          This exists only to shame us into getting a real long name
          file server working.
(Yeah, yeah - fossilheads can SUCK EGGS :-)

Best,
ak
(Continue reading)

Permalink | Reply | 1 comment |
headers
erik quanstrom | 2 Feb 06:03
Favicon

9atom unicode 6.1 support

steaming 💩 (u+01f4a9) and all.  if you're using plan 9 to
view this (or even most browsers), you probablly see a couple
of screen droppings where the steaming pile should be.
(no laughing, now.)

well, the unicode committee might not have the best taste, but
for better or worse, it's the character set we've got.

yeah! 😑 (u+01f611)

upgrade from 6.0 was trivial since all the tables for is*rune() and
to*rune() are generated, as is /lib/unicode.

- erik

(btw, the font symbolta does display both the wierd codepoints i
used.)
Permalink | Reply | 0 comments |

Gmane