Hi,
You need to sort your index file. Looks like dict(7) is doing binary
search on it. After sorted, it works fine.
fhs
On Tue, Jan 6, 2009 at 12:34 AM, Akshat Kumar
aku...@sounine.nanosouffle.net wrote:
Regarding the dict index files, what I understand is that dict(7)
receives a pattern (may
...
You need to sort your index file.
Aha! This was exactly the problem!
Looks like dict(7) is doing binary
search on it. After sorted, it works fine.
Indeed.
fhs
Thanks,
ak
I'm still trying to figure out what kind of approximation of the
above
would be possible with fossil/venti.
how about making a copy? venti will coalesce duplicate blocks.
But wouldn't you still need to send these blocks over the wire (thus
consuming bandwidth and time)?
key word
And just to be completely clear: the #X notation doesn't
bother me when #X can be thought of as a weird cousin
of '/srv/#X'. Both are simply channels that need to be
not really. #X references a device directly. (hence the
attach you were complaining about.) there is no channel.
we could
i'm using zfs right now for a project storing a few terabytes worth of
data and vm images. i have two zfs servers and about 10 pools of
different sizes with several hundred different zfs filesystems and
volumes of raw disk exported via iscsi. clones play a vital part in
the whole set up (they
very interesting post.
this is an example of the design decision difference between
fossil/venti and zfs: venti commits storage permanently and everything
becomes a snapshot, while the designers of zfs decided to create a
two-stage process introducing a read-only intermediary between the
Where should I look for the format of Plan 9 objects as created by the
compiler(s) and ready for linking? I'm hoping there is a place other
than the compiler sources that documents this intermediate format,
which I presume is not totally unlike a.out.
Also, while I'm asking, there must be more
Suject: scuzz(8) man bug
man -P, man or the magicman html versions
all have a similar bug. the .IR macro appends a
a spurious .}f.
SEE ALSO
sd(3)
Small Computer System Interface - 2 (X3T9.2/86-109), .}f
shortening the italic portion by 4 characters makes the
.[8kvq965] ... files are unrelated to a.out.
as ken thompson's paper says
The object files are binary forms of assembly language,
similar to what might be passed between
the first and second passes of an assembler.
they contain target-dependent code but not precise
one nice thing about the scheme is that in the compiler suite
only the loader knows or needs to know
the bit patterns and peculiar properties of the actual machine.
Thank you for reminding me, I thought I'd seen the details somewhere.
Now to actually absorb them, given that if I were to read
It would be a shame (but no disaster) if Binutil's nm and other
tools could not at least display native Plan 9 intermediate files. I
need to know or decide how far to take this exercise.
why would that be advantagous on plan 9? if you teach
gcc to output, e.g., 8.out, then what is gained by
I am having trouble getting Plan 9 to recognize my ethernet card in my
embarrassingly old Dell laptop. The card is a Farallon Enet, which to the
best of my knowledge would be a 3C589 type for the purposes of plan9.ini.
I have tried some variations in plan9.ini, such as ether0=type=3C589 or
This just means that these services need to be mounted at the canonical
there is no point binding #a or #D into the name space.
they can be used only locally and might as well
be accessed directly. they might be considered similar to
push in streams. #s has a similar difficulty to #a and #D
Now to actually absorb them, given that if I were to read your
comments literally, I'd assume that the intermediate code would be
machine independent.
not if you're reading my comments literally. i'd already observed
that they contain target-dependent code but not precise machine instructions,
I used a December 2007 installation CD, so I'll download the latest version
and try again.
Thanks for the help!
Cheers,
jed
On Tue, Jan 6, 2009 at 3:09 PM, blstu...@bellsouth.net wrote:
I am having trouble getting Plan 9 to recognize my ethernet card in my
embarrassingly old Dell laptop.
I used a December 2007 installation CD, so I'll download the latest version
and try again.
The particular patch I mentioned made it into the source tree in
the fall, I think. So any relatively recent one should include it.
But I should point out that it only made it possible for the driver
to
On Tue, 2009-01-06 at 15:09 -0500, erik quanstrom wrote:
It would be a shame (but no disaster) if Binutil's nm and other
tools could not at least display native Plan 9 intermediate files. I
need to know or decide how far to take this exercise.
why would that be advantagous on plan 9?
On Tue, 2009-01-06 at 15:09 -0500, erik quanstrom wrote:
It would be a shame (but no disaster) if Binutil's nm and other
tools could not at least display native Plan 9 intermediate files. I
need to know or decide how far to take this exercise.
why would that be advantagous on plan 9?
On Tue, 2009-01-06 at 17:54 -0500, erik quanstrom wrote:
On Tue, 2009-01-06 at 15:09 -0500, erik quanstrom wrote:
It would be a shame (but no disaster) if Binutil's nm and other
tools could not at least display native Plan 9 intermediate files. I
need to know or decide how far to take
On Tue, 2009-01-06 at 20:37 +, Charles Forsyth wrote:
This just means that these services need to be mounted at the canonical
there is no point binding #a or #D into the name space.
they can be used only locally and might as well
be accessed directly. they might be considered similar to
Although in the alternative universe I can see how implementing #X
as *channels* capable of 9P messages, could enable things like mounting
them on external hosts and letting these hosts manipulate physical
devices attached to yours (I agree that remote mounting of the kernel
services, which
On Tue, 2009-01-06 at 11:19 -0500, erik quanstrom wrote:
very interesting post.
indeed. I actually need some time to digest it ;-)
this is an example of the design decision difference between
fossil/venti and zfs: venti commits storage permanently and everything
becomes a snapshot, while
a big difference between the decisions is in data integrety.
it's much easier to break a fs that rewrites than it is a
worm-based fs.
True. But there's a grey area here: an FS that *never* rewrites
live blocks, but can reclaim dead ones. That's essentially
what ZFS does.
unfortunately, i
Not *on* Plan9, but *for* Plan9: think cross-environment.
I thought about that, but dismissed it because Plan 9 objects exist
only in a Plan 9 environment in the scenario Erik envisages. But,
funny enough, I am currently using NetBSD as my GCC platform, so your
point is not entirely irrelevant.
Well, that's what I meant: binutils on Linux (or any other UNIX
for that matter) understood Plan9's *.out files you can set up
a cross-environment *on Linux* and deploy on Plan9. I'm not sure
its a killer application, but its a use case.
It's also a necessity in order to bootstrap the GCC
mounting
them on external hosts and letting these hosts manipulate physical
devices attached to yours
That's the function of import/export and is one of Plan 9's strong
suits. Surely I cannot have been fooled all these years?
++L
RFNOMNT, like everything in Plan 9, was put in because
someone needed to use it, not as a purely academic
exercise in adding features.
Here is something which either I've misunderstood or is
harder than I'd like.
I have a machine which runs two private (password-protected)
web servers on
27 matches
Mail list logo
