[9fans] plan9 font service [WAS: abaco @ plan9port]
* Enrico Weigelt [EMAIL PROTECTED] wrote: now another problem: abaco expects some fonts in /usr/local/plan9/fonts. Seems we need some convenient way for relocating fonts. Maybe an even an fontserver ? ;-) I've now manually tweaked the pathes in the source, but this isn't really a good solution ;-o Maybe we should introduce some font server (maybe a little bit like X has one). This font server represents all (virtually) available raster fonts (even autogenerated or remotely fetched) in some convenient namespace, so an client only has to open one file to get an complete font. (maybe we should also invent some complete-font file format instead of splitting them into subfonts in the client's view). In the end, an client should never directly access font files, but instead query the font server. BTW: an interesting thing would be an high-level display server, which is capable of complex operations, eg. viewports, font and image rendering (maybe something between X and windows' DCs ?). The client would only have to send hi-level ops and leave the dirty work to an (maybe hw accelerated) display server. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] Announcing Vim for Plan 9
you are my hero. now do the same for firefox ;) no, seriously: thanks for the effort!
Re: [9fans] About The Codes Beyond Unicode-BMP
it would require recompiling everything, but i don't believe it would require changes to code beyond the utf routines in the c library. i do not believe there are many places (if any) that presume to know the value of UTFmax. you just pointed one out yesterday -- in devatach(). - erik
Re: [9fans] kernel panic with fresh sources
On Wed, Mar 12, 2008 at 6:54 PM, erik quanstrom [EMAIL PROTECTED] wrote:
Just for kicks, I have tried rebuilding another kernel with the fresh
sources and this modified sdiahci.c but it fails with the errors
attached in build.txt.
the build warnings are harmless. it has to do with the fact that
u32int is considerd a uint by the print format checking while
ulong is considerd a ulong.
i'll take a look at the other stuff this p.m.
assuming that you have venti or kenfs on your machine, you
can do this
cp `{yesterday ahci.h sdiahci.c} . ; mk clean ; mk 'CONF=pcf'
I have neither, but I had a backup of the sources. So yeah if I put those
two back in the fresh sources and I build the kernel it goes fine. And then
that kernel boots fine as well. So could it be possible to have the changes
you made in that driver integrated to the distribution driver? Surely it'd be
cleaner this way rather than me keeping that copy. Besides, I guess it
could happen that one day it doesn't even build anymore after a pull
because it's not compatible anymore with the distribution, right?
Now another problem is the ethernet driver, I'm still getting a mac address
of 00 with the distribution driver, which seems to be a problem
to reach the outside world depending on which LAN I'm connected to.
I guess I could also rebuild a kernel with my previous working driver (which
has the hw address hardcoded in), but it also seems like something you
had fixed I think, and which could as well be added to the sources if
it works...
Mathieu.
--
GPG key on subkeys.pgp.net:
KeyID: | Fingerprint:
683DE5F3 | 4324 5818 39AA 9545 95C6 09AF B0A4 DFEA 683D E5F3
Re: [9fans] Announcing Vim for Plan 9
On Thu, Mar 13, 2008 at 8:52 PM, [EMAIL PROTECTED] wrote: cpu% grep home crash.txt take me back home http://mirtchovski.com/screenshots/ffmpeg.gif A question in total innocence: What does Vim really buy you? it buys you a negative. I won't have to hear people whine any more about where is vi?. So it's one less complaint. One less buzzing sound in my ears. All good. Oh, and I personally like the tags stack. ron
