Re: [9fans] off topic - a good Git reference

2015-09-30 Thread lucio 
> it would be useful, to access git repositories directly. unfortunately, git
> is a C program, so it's not very portable.

Hey, it could be C++ and even less portable, at least to Plan 9.

If I wasn't stuck thinking that I could do better with a (very fancy)
synthetic file server, Venti-like archival storage, a dynamic "proto"
mechanism and an rc-like shell with its own /rc/bin directory of
commands and scripts, I'd be tempted to do the port.

And when I looked at the Git sources, they looked as un-portable as
Charles suggests.

Lucio.

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread Ori Bernstein 
I have managed to get libgit2 ported to Plan 9, but I haven't had enough time
to actually take a shot at making a viable client yet.

https://bitbucket.org/oridb/libgit2

It needed a couple of changes to APE to make it work, but they've been 
integrated
into 9front.

On Wed, 30 Sep 2015 08:18:33 +0100, Charles Forsyth  
wrote:

> On 30 September 2015 at 04:11, erik quanstrom  wrote:
> 
> > > > is there someone else interested in write a git tool for plan 9 ?
> 
> 
> it would be useful, to access git repositories directly. unfortunately, git
> is a C program, so it's not very portable.


-- 
Ori Bernstein

Re: [9fans] Replacement for find

2015-09-30 Thread Wolfgang Helbig 
Thanks for your answers!
But I consider it ugly, to ask for the disk usage if you just want to
recursively list all files.

And then, the man page for du(1) is missing from the distribution
http://github.com/9fans/plan9port

If found one in the book "Plan9 the Manuals", snd edition. But neither
on the CD from the second Edition or the current one.

Greetings,
Wolfgang

Re: [9fans] Replacement for find

2015-09-30 Thread lucio 
> But I consider it ugly, to ask for the disk usage if you just want to
> recursively list all files.

Find queries a lot more information than du, including what du
queries, so that's purely aesthetic.

You'll find "walk" as well as my own "stat" on "sources", if you can
get to it.  I'm not sure if there are copies elsewhere.

My stat is mostly correct, but too ambitious to be bug-free.  I think
the man pages it comes with describe its failings.

Lucio.

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread hiro 
lucio, I don't know what you're refering to. Perhaps because I don't
understand POSIX, but also to understand your abstraction I would need
some more explanation.

Re: [9fans] Replacement for find

2015-09-30 Thread Alexander Kapshuk 
 On Wed, Sep 30, 2015 at 9:26 AM, Wolfgang Helbig  wrote:
> Hello 9fans,
> in Unix I use find() like
> $ ed `find . -name blabla.java`
>
> to edit a file in a deeply nested directory.
>
> How would you accomplish this with commands from plan9 for user space?
>
> Greetings,
>
> Wolfgang Helbig
>

One way is,

du -a | sed '/blabla.java$/!d; s/.* //'

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread Charles Forsyth 
On 30 September 2015 at 04:11, erik quanstrom  wrote:

> > > is there someone else interested in write a git tool for plan 9 ?


it would be useful, to access git repositories directly. unfortunately, git
is a C program, so it's not very portable.

Re: [9fans] Replacement for find

2015-09-30 Thread hiro 
leave away the 9 if you're not running ubuntu with a plan9 theme *sigh*

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread hiro 
There isn't so much quality software that can be compiled directly on
plan9 and which is accessible only via git. Most useful stuff for
9front is in mercurial repos or even directly mountable via 9p.
Still a gitfs would be a fun project for someone who wants to play
with programming a simple example file server or so.
Why do you say C programs aren't portable, we have a C compiler already?

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread Charles Forsyth 
On 30 September 2015 at 08:47, Charles Forsyth 
wrote:

> I was being sarcastic about the portability of so much contemporary C code.


Here's a small but representative example.

#if HAVE_SYS_TIME_H
#include 
#endif

#if HAVE_SYS_CLOCK_GETTIME
time_t
time_now(void)
{
  struct timespec timespec_value;
  (void) clock_gettime(CLOCK_REALTIME, _value);
  return timespec_value.tv_seconds;
}
#elif HAVE_SYS_GETTIMEOFDAY
time_t
time_now(void)
{
  struct timeval timeval_value;
  (void) gettimeofday(_value, (struct timezone *) NULL);
  return timeval_value.tv_seconds;
}
#elif HAVE_SYS_TIME
time_t
time_now(void)
{
  time_t seconds_since_epoch;
  (void) time(_since_epoch);
  return seconds_since_epoch;
}
#endif

./configure# work out which HAVE_... definitions to use

Usually there are a few more alternatives enumerated.  Surprisingly often,
the microseconds or nanoseconds
value is discarded, to get the seconds. You could just use #include
 and call time(NULL) to get that, but where's the fun?

Re: [9fans] Replacement for find

2015-09-30 Thread Charles Forsyth 
On 30 September 2015 at 09:01, Wolfgang Helbig  wrote:

> But I consider it ugly, to ask for the disk usage if you just want to
> recursively list all files.
>

It probably is not ideal, even when the circumlocution is hidden in a
script.
Perhaps find's syntax and conventions could be improved, though?

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread Charles Forsyth 
On 30 September 2015 at 08:36, hiro <23h...@gmail.com> wrote:

> Why do you say C programs aren't portable, we have a C compiler already?


I was being sarcastic about the portability of so much contemporary C code.
You can't just compile it, even in an an ANSI/POSIX environment.

Re: [9fans] Replacement for find

2015-09-30 Thread lucio 
> i'd suggest creating an index of all files you have,
> sorted into a text file.

NetBSD irritates me every Saturday, when it announces that it has
refreshed the "locate" database.  It is the default in the
distribution.

I bet "locate" can be ported to Plan 9, I've found most of NetBSD's
base code to be very portable.

Lucio.

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread lucio 
> I was being sarcastic about the portability of so much contemporary C code.
> You can't just compile it, even in an an ANSI/POSIX environment.

Philosophically, I think that we're chasing the wrong wild goose.
Computer Scientists (I've been giving Dijkstra some attention, of
late) ought to focus on how to get programmers to express models and
algorithms accurately and let engineers figure how to translate these
into Turing machines, efficiently.

Instead, we let engineers dictate to sientists how to encrypt problems
that are not nails so that hammers can deal with them.

Lucio.

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread lego12239 
On Tue, Sep 29, 2015 at 02:18:20PM -0300, Tiago Natel wrote:
> is there someone else interested in write a git tool for plan 9 ?

  May be me. But now i have no time for this :-).

-- 
Неманов Олег (Nemanov Oleg)

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread lucio 
> I have managed to get libgit2 ported to Plan 9

Contrary to all I've said so far, I think this is good.

Changes to APE, maybe less so, but maybe they ARE valuable?

I need to figure how to track 9atom and 9front without losing 9legacy.
But I've always viewed three-way merges as daunting, never mind
higher-order ones.

Lucio.

Re: [9fans] Replacement for find

2015-09-30 Thread hiro 
I'm surprised you can even remember find's command line options.
If you need to optimize this cause you have a jillion files and think
du takes too long i'd suggest creating an index of all files you have,
sorted into a text file.
Then you only have to use grep filename index.

Re: [9fans] Replacement for find

2015-09-30 Thread Wolfgang Helbig 
In Plan 9 a command is needed, that lists recursively all files. Not more and 
not less. The du(1) command offers too much. I do not want to list the disk 
usage!

The command du(1) from the second edition of plan9 only has two command line 
options (-a and -b size),
whereas du(1) from
http://github.com/0intro/plan9
offers twelve options
and from 
http://github.com/9fans/plan9port (aka Plan 9 from User Space)
eight options.
All three distributions come w/o the man page.
The Second Edition seems closest to what is needed — A du -a without the disk 
usage. Lets call it recurse(1). Its man page reads:
NAME:
recurse - list recursively the file names
SYNOPSIS:
recurse name …
DESCRIPTION
For each directory argument print recursively the filenames in the 
directory, for each filename argument,
repeat the filename.

SEE ALSO:
ls(1)

What do you think of it?

With this, du(1) can be simplified by printing the disk usage of its arguments 
only.

Greetings,
Wolfgang

The sizes of the three sources differ tremendously from 
> Am 30.09.2015 um 10:23 schrieb hiro <23h...@gmail.com>:
> 
> I'm surprised you can even remember find's command line options.
> If you need to optimize this cause you have a jillion files and think
> du takes too long i'd suggest creating an index of all files you have,
> sorted into a text file.
> Then you only have to use grep filename index.
>

Re: [9fans] Replacement for find

2015-09-30 Thread Brantley Coile 
It is indeed a matter of taste and aesthetics. One reason I prefer Plan 9 is 
the Bell Labs aesthetics, as opposed to the so called "complete" solution 
aesthetic of other design philosophies which are slaves to some orthogonality 
or other, is the small is beautiful aesthetic. I've been using Plan 9 for 25 
years and find the du solution quite attractive. I subscribe to the ideas in 
"Cat -v considered harmful" paper by Pike and prefer to build commands out of a 
smaller number of primitives. 

http://harmful.cat-v.org/cat-v/unix_prog_design.pdf 

By the way, if your using p9p you already have find(1) on the system on which 
you're hosting the acme execution environment. 

Sent from my iPad

> On Sep 30, 2015, at 4:01 AM, Wolfgang Helbig  wrote:
> 
> Thanks for your answers!
> But I consider it ugly, to ask for the disk usage if you just want to
> recursively list all files.

Re: [9fans] Replacement for find

2015-09-30 Thread Wolfgang Helbig 
Both of them exactly fill the gap!

Thank you for all your insidefull discussions.

Wolfgang

> Am 30.09.2015 um 11:58 schrieb Aram Hăvărneanu :
> 
> https://swtch.com/lsr.c
> https://github.com/4ad/mgk.ro/blob/master/cmd/lsr/lsr.go
> 
> -- 
> Aram Hăvărneanu
>

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread Brantley Coile 
How can it be a secret 'society' if there's just one member for each secret 
society?

Sent from my iPad

> On Sep 29, 2015, at 11:11 PM, erik quanstrom  wrote:
> 
>> On Tue Sep 29 12:45:25 PDT 2015, k...@sciops.net wrote:
>>> On Tue, Sep 29, 2015 at 02:18:20PM -0300, Tiago Natel wrote:
>>> is there someone else interested in write a git tool for plan 9 ?
>>> 
>>> []'s
>> 
>> This has been written.  You just need to fill out a Secret Plan 9 Super
>> Secret Society application and find three Bilderbergs to vouch for you.
> 
> it's the super secret plan 9 society here!  we *hate* the sp9sss.
> 
> to the original question: i haven't used git on plan 9.  sorry, i don't have
> any useful info.
> 
> - erik
>

Re: [9fans] Replacement for find

2015-09-30 Thread hiro 
On Plan9 it should also be possible to write a virtual overlay file
server where creation of a new file triggers the creation of an index
entry.
On linux you would use inotify for something similar.

Re: [9fans] Replacement for find

2015-09-30 Thread hiro 
Perhaps you could optimize even more by adding a special file-listing
instruction to your CPU design.

Re: [9fans] Replacement for find

2015-09-30 Thread Mark van Atten 
On Wed, Sep 30, 2015 at 12:07 PM, Steve Simon  wrote:

> NB: don't use sed or awk, they don't understand the shells
> quoting convention for filenames containing frogs.

That's a good point.

Mark.

Re: [9fans] Replacement for find

2015-09-30 Thread Aram Hăvărneanu 
https://swtch.com/lsr.c
https://github.com/4ad/mgk.ro/blob/master/cmd/lsr/lsr.go

-- 
Aram Hăvărneanu

Re: [9fans] off topic - a good Git reference

2015-09-30 Thread Steve Simon 
> How can it be a secret 'society' if there's just one member for each secret 
> society?

That, my good man, is the biggest secret of all!

☺

-Steve

Re: [9fans] Replacement for find

2015-09-30 Thread erik quanstrom 
On Wed Sep 30 01:12:36 PDT 2015, charles.fors...@gmail.com wrote:

> On 30 September 2015 at 09:01, Wolfgang Helbig  wrote:
> 
> > But I consider it ugly, to ask for the disk usage if you just want to
> > recursively list all files.
> >
> 
> It probably is not ideal, even when the circumlocution is hidden in a
> script.
> Perhaps find's syntax and conventions could be improved, though?

9atom has a relative of andrey's find.  it takes very few options.  
the -d and -D options are not easily duplicated with du.

; man find

 FIND(1)   FIND(1)

 NAME
  find - recursively list files.

 SYNOPSIS
  find [ -1Ddfq ] dir ...

 DESCRIPTION
  List each argument.  If the argument is a directory recur-
  sively list it's contents.  The default is to list the cur-
  rent directory.  Specifying -d prints only directories, -D
  prints only files, -f supresses warnings, while -q supresses
  quoting the output for rc(1). With -1, mount points will not
  be traversed.

 SOURCE
  /sys/src/cmd/find.c

 SEE ALSO
  du(1)

 BUGS
  Feeping creaturism.


- erik

Re: [9fans] Replacement for find

2015-09-30 Thread sl 
http://doc.cat-v.org/unix/find-history

sl

[9fans] copy of 9.txt.gz?

2015-09-30 Thread Mark Bucciarelli 
Hi,

Can someone here point me to where I can download
the text version of the Nemo book?

Calibre's PDF2ePub isn't cutting it.

Thanks,

Mark

Re: [9fans] copy of 9.txt.gz?

2015-09-30 Thread Iain Watson Smith 
https://drive.google.com/file/d/0B5JhhxXuFQPPLVBURU9iZEJhc28/view?usp=sharing

i'm sharing a word copy on google drive.

On 1 October 2015 at 13:08, Mark Bucciarelli  wrote:

> Hi,
>
> Can someone here point me to where I can download
> the text version of the Nemo book?
>
> Calibre's PDF2ePub isn't cutting it.
>
> Thanks,
>
> Mark
>

Re: [9fans] Replacement for find

2015-09-30 Thread Steven Stallion 
Somewhat late to the party, but I use the following in my profile:

fn find {du -a $* |awk '{print $2}'}

http://plan9.bell-labs.com/sources/contrib/stallion/profile

On Wed, Sep 30, 2015 at 8:20 AM, erik quanstrom  wrote:
> On Wed Sep 30 01:12:36 PDT 2015, charles.fors...@gmail.com wrote:
>
>> On 30 September 2015 at 09:01, Wolfgang Helbig  wrote:
>>
>> > But I consider it ugly, to ask for the disk usage if you just want to
>> > recursively list all files.
>> >
>>
>> It probably is not ideal, even when the circumlocution is hidden in a
>> script.
>> Perhaps find's syntax and conventions could be improved, though?
>
> 9atom has a relative of andrey's find.  it takes very few options.
> the -d and -D options are not easily duplicated with du.
>
> ; man find
>
>  FIND(1)   FIND(1)
>
>  NAME
>   find - recursively list files.
>
>  SYNOPSIS
>   find [ -1Ddfq ] dir ...
>
>  DESCRIPTION
>   List each argument.  If the argument is a directory recur-
>   sively list it's contents.  The default is to list the cur-
>   rent directory.  Specifying -d prints only directories, -D
>   prints only files, -f supresses warnings, while -q supresses
>   quoting the output for rc(1). With -1, mount points will not
>   be traversed.
>
>  SOURCE
>   /sys/src/cmd/find.c
>
>  SEE ALSO
>   du(1)
>
>  BUGS
>   Feeping creaturism.
>
>
> - erik
>

Re: [9fans] Replacement for find

2015-09-30 Thread arnold 
Is there a C level equivalent of the BSD fts(3) suite of routines?
Or even the System V ftw / GLIBC nftw suite?

I suspect that having this would save some wheel-reinvention in
these kinds of programs.

Thanks,

Arnold

erik quanstrom  wrote:

> On Wed Sep 30 01:12:36 PDT 2015, charles.fors...@gmail.com wrote:
>
> > On 30 September 2015 at 09:01, Wolfgang Helbig  wrote:
> > 
> > > But I consider it ugly, to ask for the disk usage if you just want to
> > > recursively list all files.
> > >
> > 
> > It probably is not ideal, even when the circumlocution is hidden in a
> > script.
> > Perhaps find's syntax and conventions could be improved, though?
>
> 9atom has a relative of andrey's find.  it takes very few options.  
> the -d and -D options are not easily duplicated with du.