[9fans] nb—search and index notes in files by keyword

[9fans] nb—search and index notes in files by keyword

[Jason Catena]

http://swtools.wordpress.com/2010/03/05/nb%E2%80%94search-and-index-notes-in-files-by-keyword/

This isn't complicated, but it hit a sweet spot with me, since I like
to break up information into smallish chunks and index it by keyword.
It collects the keywords into one file per directory, and keeps a list
of all the indexes in a file in $HOME.  It searches all the existing
indexes for the given keyword, then reconstructs the index for the
current directory, so it presents slightly older results fast.  Its
relationship with plan9 is that it's written in rc, and outputs lines
in a /path/file:line format for right-clicking with acme.  I'm posting
it here because I find it really useful, and I wish I'd come up with
it years ago.  The more you put into it the more useful it becomes,
since it's got a fine degree of granularity (the particular keywords
attached to a bit of information) and composability of keywords (just
string a few grep and grep -v after the nb command).

Jason Catena

Re: [9fans] nb—search and index notes in files by keyword

[Peter A. Cejchan]

i wiill give it a try
you might also want to check out my (ape) port of glimpse
/n/sources/contrib/pac/sys/src/ape/cmd/txt/glimpse-4.18.6.tbz
thanks,
++pac

Re: [9fans] (no subject)

[lucio]

> you might also want to check out my (ape) port of glimpse
> /n/sources/contrib/pac/sys/src/ape/cmd/txt/glimpse-4.18.6.tbz

I wonder if we can persuade Bell Labs to set up a separate, moderated
section of sources for validated ports?  We've been talking about a
group of moderators for sources in the past, maybe setting it up for
ports from Open Source would be a start?

My gripe here is that it is hard to track what has been ported and
what hasn't and repetition isn't helpful.

++L

Re: [9fans] (no subject)

[Anthony Sorace]

We have fgb's contrib, and before that just the INDEX files in /
contrib on sources. Neither is a perfect solution, but I don't think
the problem here would be addressed by the Labs providing some new
resource. Between the above and the wiki, there's plenty of
opportunity for folks to make ports known.

Re: [9fans] (no subject)

[ron minnich]

On Sat, Mar 6, 2010 at 9:05 PM, Anthony Sorace <a@9srv.net> wrote:
> We have fgb's contrib, and before that just the INDEX files in /contrib on
> sources.

we've got fgb's wonderful program and I think we're crazy if we don't
build on that.

Or we're CADT.

ron

Re: [9fans] (no subject)

[erik quanstrom]

> we've got fgb's wonderful program and I think we're crazy if we don't
> build on that.
>
> Or we're CADT.

haven't you heard?  we're not allowed to do anything
for ourselves anymore.  the mythical (and god like)
Library Writers do this for us.  our job is to glue things
together and port:

http://developers.slashdot.org/story/10/03/07/0043215/Whatever-Happened-To-Programming?art_pos=8&art_pos=9&art_pos=9

if we were to write our own, we would be guilty of
Wasting Resources.  this is a capital offense.

therefore we must port what the Library Writers have
given us.

... or maybe not.  i think contrib is pretty nice.  why
do we need "blessed" packages, away?  if you're installing
all unix->plan 9 ports, perhaps you would be happer
running unix in the first place.

- erik

Re: [9fans] (no subject)

[lucio]

> if you're installing
> all unix->plan 9 ports, perhaps you would be happer
> running unix in the first place.

That's flawed logic: I may need dot, while you need curses.  It's nice
if both have been "blessed".

++L

Re: [9fans] (no subject)

[cinap_lenrek]

> That's flawed logic: I may need dot, while you need curses.  It's nice
> if both have been "blessed".

bless a curse! jehova!

--
cinap

Re: [9fans] (no subject)

[lucio]

> We have fgb's contrib, and before that just the INDEX files in /
> contrib on sources. Neither is a perfect solution, but I don't think
> the problem here would be addressed by the Labs providing some new
> resource. Between the above and the wiki, there's plenty of
> opportunity for folks to make ports known.

I'm merely suggesting a grouping function and I certainly am not in a
position to prescribe how it should be implemented.  As I mentioned, I
like the way NetBSD's package does it, but the price is very steep.
Fgb's contrib sounds very good, I have not had occasion to try it but
I presume it retains the scattered nature of the contrib directory.
My choice would be to add a directory wherein to store both modified
sources and binaries for Open Source projects once they have been
validated.  Of necessity, one would have the version clearly indicated
and where possible duplications as occur frequently with popular
packages such a zlib would be removed.  But there seems to me to be a
need to keep them together, although that may be just that I'm looking
at the problem from the single perspective of how it's done in NetBSD.

++L

Re: [9fans] (no subject)

[erik quanstrom]

> Fgb's contrib sounds very good, I have not had occasion to try it but
> I presume it retains the scattered nature of the contrib directory.
[...]
> I'm looking at the problem from the single perspective of how it's
> done in NetBSD.

really?  you haven't even tried it and your trying
to fit it into a whatever-netbsd-does shoebox?

- erik

Re: [9fans] (no subject)

[lucio]

> really?  you haven't even tried it and your trying
> to fit it into a whatever-netbsd-does shoebox?

Well, I do have some idea on how fgb's contrib is meant to work and,
yes, I do look at it from a biased perspective :-) Surely you don't
think that is implicitly flawed logic?

After all, how familiar are you with the NetBSD package system?  Fgb's
contrib is not too different, although it is certainly more relaxed,
in my opinion out of historical necessity.  Again in my opinion the
additional flexibility makes it harder to categorise packages and such
categorisation would be of greater benefit.  But it is just an opinion.

++L

Re: [9fans] (no subject)

[Iruata Souza]

On Sun, Mar 7, 2010 at 2:42 PM,  <lucio@proxima.alt.za> wrote:
>> We have fgb's contrib, and before that just the INDEX files in /
>> contrib on sources. Neither is a perfect solution, but I don't think
>> the problem here would be addressed by the Labs providing some new
>> resource. Between the above and the wiki, there's plenty of
>> opportunity for folks to make ports known.
>
> I'm merely suggesting a grouping function and I certainly am not in a
> position to prescribe how it should be implemented.  As I mentioned, I
> like the way NetBSD's package does it, but the price is very steep.
> Fgb's contrib sounds very good, I have not had occasion to try it but
> I presume it retains the scattered nature of the contrib directory.
> My choice would be to add a directory wherein to store both modified
> sources and binaries for Open Source projects once they have been
> validated.

who's gonna validate the beasts?

> Of necessity, one would have the version clearly indicated
> and where possible duplications as occur frequently with popular
> packages such a zlib would be removed.  But there seems to me to be a
> need to keep them together, although that may be just that I'm looking
> at the problem from the single perspective of how it's done in NetBSD.

please take 10 minutes to try fgb/contrib.
while at it, run contrib/gui. when a package is duplicated, it should
be clear from the package list on the left.

iru

Re: [9fans] (no subject)

[lucio]

> while at it, run contrib/gui. when a package is duplicated, it should
> be clear from the package list on the left.

Suppression of duplication is incidental.  What I believe is missing
from sources is a simple mechanism to see if something I'm already
somewhat familiar with has been ported successfully.  If not, then it
would be useful if there was a simple mechanism to add a successful
port to the global availability, with some moderation to discourage
malicious additions.  As for the moderation itself, the simplest form
I can think of is simply that a score be kept of successful use, reset
to zero when a new version is released.  Other options may prove more
practical.

I suspect that all the resistance I encounter is more knee-jerk
reaction to a request for a little bit of additional discipline than
real objection to the concept.  And the usual 9fans culture of wanting
code rather than discussion.  Unfortunately, this is one piece of code
that ought to be planned rather than hacked together: it's hard to
reverse the implementation if it turns out badly.

++L

Re: [9fans] (no subject)

[ron minnich]

code-code is better than talk-talk :-) (absolutely no offense
intended, I just enjoyed the phrase!)

i.e. I think a proof of concept will get your further than discussion.
It seems to me you could
even make a copy of the sources tree, set up your idea, and put it out
there for people to try.

I only strongly suggest that you put the contrib gui at the heart of
what the user sees.

thanks

ron

Re: [9fans] (no subject)

[Skip Tavakkolian]

> My gripe here is that it is hard to track what has been ported and
> what hasn't and repetition isn't helpful.

grep something /n/sources/lsr ?

Re: [9fans] (no subject)

[lucio]

>> My gripe here is that it is hard to track what has been ported and
>> what hasn't and repetition isn't helpful.
>
> grep something /n/sources/lsr ?

I wasn't aware of an "lsr", but I don't think that's it, really.  One
needs more than a file name in many instances.  If I had infinite free
resources at my disposal, I'd use the NetBSD packages DESCR files in
some guise or other.

Of course, one would then be tempted (as I have been) to look more
seriously at porting the NetBSD package system to Plan 9.  That's not
out of the question, in fact it's probably not too difficult, but the
residual pain of autoconf for each individual package has already
frightened people with a stronger stomach than mine away.  That is why
I cannot suggest we catch up, but it may be nice to be ready when
eventually the autoconf edifice falls down and something mildly
intelligent takes its place!

Ironically, Plan 9 may be the platform on which a replacement for
autoconf could be designed and implemented.  But that's too close to a
pipedream to be given serious consideration.

++L

[9fans] Contrib indexes

[Lyndon Nerenberg]

> grep something /n/sources/lsr ?

You can also grab /n/sources/contrib/lyndon/contribindex which generates a
pretty-printed listing of people's contrib/*/INDEX files.

Re: [9fans] Contrib indexes

[lucio]

> You can also grab /n/sources/contrib/lyndon/contribindex which generates a
> pretty-printed listing of people's contrib/*/INDEX files.

<grin>

Just goes to show why I'm asking for some consolidation :-)

++L

Re: [9fans] Contrib indexes

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> Just goes to show why I'm asking for some consolidation :-)

Mines better!!! :-)

Re: [9fans] Contrib indexes

[Anthony Sorace]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

Lyndon said:

> You can also grab /n/sources/contrib/lyndon/contribindex which
> generates a pretty-printed listing of people's contrib/*/INDEX files.

There's been several of these. Note that I run one to update the
contrib index on the wiki more or less daily. That version includes
both things from INDEX files and a listing of packages using fgb's
contrib program.
	http://www.plan9.bell-labs.com/wiki/plan9/Contrib_index/index.html
	/n/sources/contrib/anothy/bin/rc/contrindx

Lucio said:

> What I believe is missing from sources is a simple mechanism to see
> if something I'm already somewhat familiar with has been ported
> successfully.

I think the "resistance" you're encountering is really just people
telling you you're mistaken. fgb's contrib (I do wish it didn't share
the name with the section of sources) isn't perfect by any means, but
it does an excellent job of solving the problem of "where do i find
what's been ported". So do the INDEX files. Those are currently
extant. I can't find any way what you're proposing would solve that
better.

Anthony


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [9fans] Contrib indexes

[Federico G. Benavento]

you can grep http://www.plan9.bell-labs.com/sources/contrib/rminnich/pkgs.ls
which is what contrib/gui uses to get a fast listing



On Sun, Mar 7, 2010 at 5:51 PM, Anthony Sorace <a@9srv.net> wrote:
> Lyndon said:
>
>> You can also grab /n/sources/contrib/lyndon/contribindex which generates a
>> pretty-printed listing of people's contrib/*/INDEX files.
>
> There's been several of these. Note that I run one to update the contrib
> index on the wiki more or less daily. That version includes both things from
> INDEX files and a listing of packages using fgb's contrib program.
>        http://www.plan9.bell-labs.com/wiki/plan9/Contrib_index/index.html
>        /n/sources/contrib/anothy/bin/rc/contrindx
>
> Lucio said:
>
>> What I believe is missing from sources is a simple mechanism to see if
>> something I'm already somewhat familiar with has been ported successfully.
>
> I think the "resistance" you're encountering is really just people telling
> you you're mistaken. fgb's contrib (I do wish it didn't share the name with
> the section of sources) isn't perfect by any means, but it does an excellent
> job of solving the problem of "where do i find what's been ported". So do
> the INDEX files. Those are currently extant. I can't find any way what
> you're proposing would solve that better.
>
> Anthony
>
>



-- 
Federico G. Benavento

Re: [9fans] Contrib indexes

[ron minnich]

On Mon, Mar 8, 2010 at 1:36 PM, Federico G. Benavento
<benavento@gmail.com> wrote:
> you can grep http://www.plan9.bell-labs.com/sources/contrib/rminnich/pkgs.ls
> which is what contrib/gui uses to get a fast listing

oopsie. I'm supposed to set up a cron job to keep that up to date.
Somebody wants to send me the command I'll set up the job. I'm so lazy
:-)

ron