[9fans] Git/fs: Possibly Usable

[9fans] Git/fs: Possibly Usable

[ori]

It was mentioned on this list a short while ago. Now, it's
more or less at the point where it works for me. Expect
many bugs and problems, and many more missing tools, but
"the rest is just scripting".

One caveat I have: Git's index file format is a bit
boneheaded, so I'm ignoring it. The index doesn't affect
the wire protocol, so this isn't an interoperability issue,
unless you share the same physical repository on both
Plan 9 and Unix. If you do, expect them to get out of
sync on uncommitted but added files.

In fact, the entire concept of the staging area has been
removed, as it's both confusing and clunky. There are now
only three states that files can be in: 'untracked',
'dirty', and 'committed'. Tracking is done with empty
files under .git/index9/{removed,tracked}/path/to/file.

It's implemented in Plan 9 flavor C, and provides tools
for writing repository contents, and a file system for
read-only access, which will mirror the current state of
the repository.

The code is here: https://bitbucket.org/oridb/git9

Install with `mk install`. There's no recursive binding
of directories, so you need to union /rc/bin/git and
$objtype/bin/git` by hand.

Documentation has not yet been written. You'll need to
read the source.

Some usage examples:

	git/clone git://git.eigenstate.org/git/ori/mc.git
	git/log
	cd subdir/name
	git/add foo.c
	git/commit
	git/push

Scripts will generally mount git/fs as needed to do
their work, but if you want to browse the repository
manually, run it yourself. You'll get `/n/git` mounted,
with the following contents:

	/n/git/object:	The objects in the repo.
	/n/git/branch:	The branches in the repo.
	/n/git/ctl:		A file showing the status of the repo.
					Currently, it only shows the current branch.

Commits are presented as directories with the following
contents:

	author:	A file containing the author name
	hash:	A file containing the commit hash
	parent:	A file containing the commit parents, one per line.
	msg:	A file containing the log message for that commit
	tree:	A directory containing a view of the repository.

So, for example:

	% ls /n/git/branch/heads/master
	/n/git/branch/heads/master/author
	/n/git/branch/heads/master/hash
	/n/git/branch/heads/master/msg
	/n/git/branch/heads/master/parent
	/n/git/branch/heads/master/tree
	% cat /n/git/branch/heads/master/hash
	7d539a7c08aba3f31b3913e0efef11c43ea9

	# This is the same commit, with the same contents.
	% ls /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef
	/n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/author
	/n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/hash
	/n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/msg
	/n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/parent
	/n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/tree

	# what git/diff will hopefully do more concisely soon, filtering
	# out the non-git files.
	ape/diff -ur /n/git/branch/heads/master/tree .
	Only in .: .git
	Only in .: debug
	diff -ur /n/git/branch/heads/master/tree/fold.myr ./fold.myr
	--- /n/git/branch/heads/master/tree/fold.myr	Wed Dec 31 16:00:00 1969
	+++ ./fold.myr	Mon Apr  1 21:39:06 2019
	@@ -6,6 +6,8 @@
	 	const foldexpr : (e : expr# -> std.option(constval))
	 ;;

	+/* Look, diffing files just works, and I don't need any fancy glue! */
	+
	 const foldexpr = {e
	 	match e
	 	| &(`Eident &[.sc=`Sclassenum, .name=name, .ty=`Tyenum &(`Body enum)]):
	Only in .: refs


The following utilities and binaries are provided:

	fs:	The git filesystem.
	fetch:	The protocol bits for getting data from a git server.
	send:	The protocol bits for sending data to a git server.
	save:	The gnarly bits for storing the files for a commit.
	conf:	A program to extract information from a config file.
	clone:	Clones a repository.
	commit:	Commits a snapshot of the working directory.
	log:	Prints the contents of a commmit log.
	add:	Tells the repository to add a file to the next commit.
	walk:	`du`, but for git status.


Supported protocols: git:// and git+ssh://. If someone
implements others, I'll gladly accept patches.

TODOs:
	git/mkpatch:	Generate a 'git am' compatible patch.
	git/apply:	Apply a diff.
	git/diff:	Wrapper wrapper around git/walk that
			diffs the changed files.
	git/merge:	Yup, what it says on the label. Should
			also be a script around git/fs.
	git/log:	Need to figure out how to make it filter
			by files.
	/n/git/HEAD:	add /n/git/head subtree which points
			to the current commit.

...And a whole bunch more.

Re: [9fans] Git/fs: Possibly Usable

[Skip Tavakkolian]

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

Very cool!  Thank you.

On Mon, Apr 1, 2019 at 9:48 PM <ori@eigenstate.org> wrote:

> It was mentioned on this list a short while ago. Now, it's
> more or less at the point where it works for me. Expect
> many bugs and problems, and many more missing tools, but
> "the rest is just scripting".
>
> One caveat I have: Git's index file format is a bit
> boneheaded, so I'm ignoring it. The index doesn't affect
> the wire protocol, so this isn't an interoperability issue,
> unless you share the same physical repository on both
> Plan 9 and Unix. If you do, expect them to get out of
> sync on uncommitted but added files.
>
> In fact, the entire concept of the staging area has been
> removed, as it's both confusing and clunky. There are now
> only three states that files can be in: 'untracked',
> 'dirty', and 'committed'. Tracking is done with empty
> files under .git/index9/{removed,tracked}/path/to/file.
>
> It's implemented in Plan 9 flavor C, and provides tools
> for writing repository contents, and a file system for
> read-only access, which will mirror the current state of
> the repository.
>
> The code is here: https://bitbucket.org/oridb/git9
>
> Install with `mk install`. There's no recursive binding
> of directories, so you need to union /rc/bin/git and
> $objtype/bin/git` by hand.
>
> Documentation has not yet been written. You'll need to
> read the source.
>
> Some usage examples:
>
>         git/clone git://git.eigenstate.org/git/ori/mc.git
>         git/log
>         cd subdir/name
>         git/add foo.c
>         git/commit
>         git/push
>
> Scripts will generally mount git/fs as needed to do
> their work, but if you want to browse the repository
> manually, run it yourself. You'll get `/n/git` mounted,
> with the following contents:
>
>         /n/git/object:  The objects in the repo.
>         /n/git/branch:  The branches in the repo.
>         /n/git/ctl:             A file showing the status of the repo.
>                                         Currently, it only shows the
> current branch.
>
> Commits are presented as directories with the following
> contents:
>
>         author: A file containing the author name
>         hash:   A file containing the commit hash
>         parent: A file containing the commit parents, one per line.
>         msg:    A file containing the log message for that commit
>         tree:   A directory containing a view of the repository.
>
> So, for example:
>
>         % ls /n/git/branch/heads/master
>         /n/git/branch/heads/master/author
>         /n/git/branch/heads/master/hash
>         /n/git/branch/heads/master/msg
>         /n/git/branch/heads/master/parent
>         /n/git/branch/heads/master/tree
>         % cat /n/git/branch/heads/master/hash
>         7d539a7c08aba3f31b3913e0efef11c43ea9
>
>         # This is the same commit, with the same contents.
>         % ls /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/author
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/hash
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/msg
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/parent
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/tree
>
>         # what git/diff will hopefully do more concisely soon, filtering
>         # out the non-git files.
>         ape/diff -ur /n/git/branch/heads/master/tree .
>         Only in .: .git
>         Only in .: debug
>         diff -ur /n/git/branch/heads/master/tree/fold.myr ./fold.myr
>         --- /n/git/branch/heads/master/tree/fold.myr    Wed Dec 31
> 16:00:00 1969
>         +++ ./fold.myr  Mon Apr  1 21:39:06 2019
>         @@ -6,6 +6,8 @@
>                 const foldexpr : (e : expr# -> std.option(constval))
>          ;;
>
>         +/* Look, diffing files just works, and I don't need any fancy
> glue! */
>         +
>          const foldexpr = {e
>                 match e
>                 | &(`Eident &[.sc=`Sclassenum, .name=name, .ty=`Tyenum
> &(`Body enum)]):
>         Only in .: refs
>
>
> The following utilities and binaries are provided:
>
>         fs:     The git filesystem.
>         fetch:  The protocol bits for getting data from a git server.
>         send:   The protocol bits for sending data to a git server.
>         save:   The gnarly bits for storing the files for a commit.
>         conf:   A program to extract information from a config file.
>         clone:  Clones a repository.
>         commit: Commits a snapshot of the working directory.
>         log:    Prints the contents of a commmit log.
>         add:    Tells the repository to add a file to the next commit.
>         walk:   `du`, but for git status.
>
>
> Supported protocols: git:// and git+ssh://. If someone
> implements others, I'll gladly accept patches.
>
> TODOs:
>         git/mkpatch:    Generate a 'git am' compatible patch.
>         git/apply:      Apply a diff.
>         git/diff:       Wrapper wrapper around git/walk that
>                         diffs the changed files.
>         git/merge:      Yup, what it says on the label. Should
>                         also be a script around git/fs.
>         git/log:        Need to figure out how to make it filter
>                         by files.
>         /n/git/HEAD:    add /n/git/head subtree which points
>                         to the current commit.
>
> ...And a whole bunch more.
>
>
>

[-- Attachment #2: Type: text/html, Size: 6813 bytes --]

Re: [9fans] Git/fs: Possibly Usable

[Dave MacFarlane]

On Tue, Apr 2, 2019 at 12:49 AM <ori@eigenstate.org> wrote:
> One caveat I have: Git's index file format is a bit
> boneheaded, so I'm ignoring it. The index doesn't affect
> the wire protocol, so this isn't an interoperability issue,
> unless you share the same physical repository on both
> Plan 9 and Unix. If you do, expect them to get out of
> sync on uncommitted but added files.
>

What problems did you have with the index format? In my experience
it was relatively sane (relative to the pack protocol/format, I mean,
which is a pretty low bar to set.)

- Dave

Re: [9fans] Git/fs: Possibly Usable

[Kyohei Kadota]

Cool! It's very interesting what implement Git in native Plan 9 style to me.

2019年4月2日(火) 13:48 <ori@eigenstate.org>:
>
> It was mentioned on this list a short while ago. Now, it's
> more or less at the point where it works for me. Expect
> many bugs and problems, and many more missing tools, but
> "the rest is just scripting".
>
> One caveat I have: Git's index file format is a bit
> boneheaded, so I'm ignoring it. The index doesn't affect
> the wire protocol, so this isn't an interoperability issue,
> unless you share the same physical repository on both
> Plan 9 and Unix. If you do, expect them to get out of
> sync on uncommitted but added files.
>
> In fact, the entire concept of the staging area has been
> removed, as it's both confusing and clunky. There are now
> only three states that files can be in: 'untracked',
> 'dirty', and 'committed'. Tracking is done with empty
> files under .git/index9/{removed,tracked}/path/to/file.
>
> It's implemented in Plan 9 flavor C, and provides tools
> for writing repository contents, and a file system for
> read-only access, which will mirror the current state of
> the repository.
>
> The code is here: https://bitbucket.org/oridb/git9
>
> Install with `mk install`. There's no recursive binding
> of directories, so you need to union /rc/bin/git and
> $objtype/bin/git` by hand.
>
> Documentation has not yet been written. You'll need to
> read the source.
>
> Some usage examples:
>
>         git/clone git://git.eigenstate.org/git/ori/mc.git
>         git/log
>         cd subdir/name
>         git/add foo.c
>         git/commit
>         git/push
>
> Scripts will generally mount git/fs as needed to do
> their work, but if you want to browse the repository
> manually, run it yourself. You'll get `/n/git` mounted,
> with the following contents:
>
>         /n/git/object:  The objects in the repo.
>         /n/git/branch:  The branches in the repo.
>         /n/git/ctl:             A file showing the status of the repo.
>                                         Currently, it only shows the current branch.
>
> Commits are presented as directories with the following
> contents:
>
>         author: A file containing the author name
>         hash:   A file containing the commit hash
>         parent: A file containing the commit parents, one per line.
>         msg:    A file containing the log message for that commit
>         tree:   A directory containing a view of the repository.
>
> So, for example:
>
>         % ls /n/git/branch/heads/master
>         /n/git/branch/heads/master/author
>         /n/git/branch/heads/master/hash
>         /n/git/branch/heads/master/msg
>         /n/git/branch/heads/master/parent
>         /n/git/branch/heads/master/tree
>         % cat /n/git/branch/heads/master/hash
>         7d539a7c08aba3f31b3913e0efef11c43ea9
>
>         # This is the same commit, with the same contents.
>         % ls /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/author
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/hash
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/msg
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/parent
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/tree
>
>         # what git/diff will hopefully do more concisely soon, filtering
>         # out the non-git files.
>         ape/diff -ur /n/git/branch/heads/master/tree .
>         Only in .: .git
>         Only in .: debug
>         diff -ur /n/git/branch/heads/master/tree/fold.myr ./fold.myr
>         --- /n/git/branch/heads/master/tree/fold.myr    Wed Dec 31 16:00:00 1969
>         +++ ./fold.myr  Mon Apr  1 21:39:06 2019
>         @@ -6,6 +6,8 @@
>                 const foldexpr : (e : expr# -> std.option(constval))
>          ;;
>
>         +/* Look, diffing files just works, and I don't need any fancy glue! */
>         +
>          const foldexpr = {e
>                 match e
>                 | &(`Eident &[.sc=`Sclassenum, .name=name, .ty=`Tyenum &(`Body enum)]):
>         Only in .: refs
>
>
> The following utilities and binaries are provided:
>
>         fs:     The git filesystem.
>         fetch:  The protocol bits for getting data from a git server.
>         send:   The protocol bits for sending data to a git server.
>         save:   The gnarly bits for storing the files for a commit.
>         conf:   A program to extract information from a config file.
>         clone:  Clones a repository.
>         commit: Commits a snapshot of the working directory.
>         log:    Prints the contents of a commmit log.
>         add:    Tells the repository to add a file to the next commit.
>         walk:   `du`, but for git status.
>
>
> Supported protocols: git:// and git+ssh://. If someone
> implements others, I'll gladly accept patches.
>
> TODOs:
>         git/mkpatch:    Generate a 'git am' compatible patch.
>         git/apply:      Apply a diff.
>         git/diff:       Wrapper wrapper around git/walk that
>                         diffs the changed files.
>         git/merge:      Yup, what it says on the label. Should
>                         also be a script around git/fs.
>         git/log:        Need to figure out how to make it filter
>                         by files.
>         /n/git/HEAD:    add /n/git/head subtree which points
>                         to the current commit.
>
> ...And a whole bunch more.
>
>

Re: [9fans] Git/fs: Possibly Usable

[Giacomo]

On April 2, 2019 4:41:09 AM UTC, ori@eigenstate.org wrote:
>It was mentioned on this list a short while ago. Now, it's
>more or less at the point where it works for me. Expect
>many bugs and problems, and many more missing tools, but
>"the rest is just scripting".
>
>One caveat I have: Git's index file format is a bit
>boneheaded, so I'm ignoring it. The index doesn't affect
>the wire protocol, so this isn't an interoperability issue,
>unless you share the same physical repository on both
>Plan 9 and Unix. If you do, expect them to get out of
>sync on uncommitted but added files.
>
>In fact, the entire concept of the staging area has been
>removed, as it's both confusing and clunky. There are now
>only three states that files can be in: 'untracked',
>'dirty', and 'committed'. Tracking is done with empty
>files under .git/index9/{removed,tracked}/path/to/file.
>
>It's implemented in Plan 9 flavor C, and provides tools
>for writing repository contents, and a file system for
>read-only access, which will mirror the current state of
>the repository.
>
>The code is here: https://bitbucket.org/oridb/git9
>
>Install with `mk install`. There's no recursive binding
>of directories, so you need to union /rc/bin/git and
>$objtype/bin/git` by hand.
>
>Documentation has not yet been written. You'll need to
>read the source.
>
>Some usage examples:
>
>	git/clone git://git.eigenstate.org/git/ori/mc.git
>	git/log
>	cd subdir/name
>	git/add foo.c
>	git/commit
>	git/push
>
>Scripts will generally mount git/fs as needed to do
>their work, but if you want to browse the repository
>manually, run it yourself. You'll get `/n/git` mounted,
>with the following contents:
>
>	/n/git/object:	The objects in the repo.
>	/n/git/branch:	The branches in the repo.
>	/n/git/ctl:		A file showing the status of the repo.
>					Currently, it only shows the current branch.
>
>Commits are presented as directories with the following
>contents:
>
>	author:	A file containing the author name
>	hash:	A file containing the commit hash
>	parent:	A file containing the commit parents, one per line.
>	msg:	A file containing the log message for that commit
>	tree:	A directory containing a view of the repository.
>
>So, for example:
>
>	% ls /n/git/branch/heads/master
>	/n/git/branch/heads/master/author
>	/n/git/branch/heads/master/hash
>	/n/git/branch/heads/master/msg
>	/n/git/branch/heads/master/parent
>	/n/git/branch/heads/master/tree
>	% cat /n/git/branch/heads/master/hash
>	7d539a7c08aba3f31b3913e0efef11c43ea9
>
>	# This is the same commit, with the same contents.
>	% ls /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef
>	/n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/author
>	/n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/hash
>	/n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/msg
>	/n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/parent
>	/n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/tree
>
>	# what git/diff will hopefully do more concisely soon, filtering
>	# out the non-git files.
>	ape/diff -ur /n/git/branch/heads/master/tree .
>	Only in .: .git
>	Only in .: debug
>	diff -ur /n/git/branch/heads/master/tree/fold.myr ./fold.myr
>	--- /n/git/branch/heads/master/tree/fold.myr	Wed Dec 31 16:00:00 1969
>	+++ ./fold.myr	Mon Apr  1 21:39:06 2019
>	@@ -6,6 +6,8 @@
>	 	const foldexpr : (e : expr# -> std.option(constval))
>	 ;;
>	 
>	+/* Look, diffing files just works, and I don't need any fancy glue!
>*/
>	+
>	 const foldexpr = {e
>	 	match e
>	 	| &(`Eident &[.sc=`Sclassenum, .name=name, .ty=`Tyenum &(`Body
>enum)]):
>	Only in .: refs
>
>	
>The following utilities and binaries are provided:
>
>	fs:	The git filesystem.
>	fetch:	The protocol bits for getting data from a git server.
>	send:	The protocol bits for sending data to a git server.
>	save:	The gnarly bits for storing the files for a commit.
>	conf:	A program to extract information from a config file.
>	clone:	Clones a repository.
>	commit:	Commits a snapshot of the working directory.
>	log:	Prints the contents of a commmit log.
>	add:	Tells the repository to add a file to the next commit.
>	walk:	`du`, but for git status.
>
>
>Supported protocols: git:// and git+ssh://. If someone
>implements others, I'll gladly accept patches.
>
>TODOs:
>	git/mkpatch:	Generate a 'git am' compatible patch.
>	git/apply:	Apply a diff.
>	git/diff:	Wrapper wrapper around git/walk that
>			diffs the changed files.
>	git/merge:	Yup, what it says on the label. Should
>			also be a script around git/fs.
>	git/log:	Need to figure out how to make it filter
>			by files.
>	/n/git/HEAD:	add /n/git/head subtree which points
>			to the current commit.
>	
>...And a whole bunch more.

Impressive!

I didn't imagine one could implement git in so few lines of C! Thanks for challenging my assumptions!

I'd like to port it to Jehanne but I cannot find a license in the repository, so in theory it's "all rights reserved" under most jurisdictions.

What's your take on this?

Did you intend to put it under public domain instead? Maybe MIT? Or LPL?


Giacomo

Re: [9fans] Git/fs: Possibly Usable

[Skip Tavakkolian]

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

Hi,

The avl library doesn't match up to 9legacy version. Any ideas?

BTW, I think your notes on this message are a great start for a README.

Thanks,
-Skip

On Mon, Apr 1, 2019 at 9:48 PM <ori@eigenstate.org> wrote:

> It was mentioned on this list a short while ago. Now, it's
> more or less at the point where it works for me. Expect
> many bugs and problems, and many more missing tools, but
> "the rest is just scripting".
>
> One caveat I have: Git's index file format is a bit
> boneheaded, so I'm ignoring it. The index doesn't affect
> the wire protocol, so this isn't an interoperability issue,
> unless you share the same physical repository on both
> Plan 9 and Unix. If you do, expect them to get out of
> sync on uncommitted but added files.
>
> In fact, the entire concept of the staging area has been
> removed, as it's both confusing and clunky. There are now
> only three states that files can be in: 'untracked',
> 'dirty', and 'committed'. Tracking is done with empty
> files under .git/index9/{removed,tracked}/path/to/file.
>
> It's implemented in Plan 9 flavor C, and provides tools
> for writing repository contents, and a file system for
> read-only access, which will mirror the current state of
> the repository.
>
> The code is here: https://bitbucket.org/oridb/git9
>
> Install with `mk install`. There's no recursive binding
> of directories, so you need to union /rc/bin/git and
> $objtype/bin/git` by hand.
>
> Documentation has not yet been written. You'll need to
> read the source.
>
> Some usage examples:
>
>         git/clone git://git.eigenstate.org/git/ori/mc.git
>         git/log
>         cd subdir/name
>         git/add foo.c
>         git/commit
>         git/push
>
> Scripts will generally mount git/fs as needed to do
> their work, but if you want to browse the repository
> manually, run it yourself. You'll get `/n/git` mounted,
> with the following contents:
>
>         /n/git/object:  The objects in the repo.
>         /n/git/branch:  The branches in the repo.
>         /n/git/ctl:             A file showing the status of the repo.
>                                         Currently, it only shows the
> current branch.
>
> Commits are presented as directories with the following
> contents:
>
>         author: A file containing the author name
>         hash:   A file containing the commit hash
>         parent: A file containing the commit parents, one per line.
>         msg:    A file containing the log message for that commit
>         tree:   A directory containing a view of the repository.
>
> So, for example:
>
>         % ls /n/git/branch/heads/master
>         /n/git/branch/heads/master/author
>         /n/git/branch/heads/master/hash
>         /n/git/branch/heads/master/msg
>         /n/git/branch/heads/master/parent
>         /n/git/branch/heads/master/tree
>         % cat /n/git/branch/heads/master/hash
>         7d539a7c08aba3f31b3913e0efef11c43ea9
>
>         # This is the same commit, with the same contents.
>         % ls /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/author
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/hash
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/msg
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/parent
>         /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/tree
>
>         # what git/diff will hopefully do more concisely soon, filtering
>         # out the non-git files.
>         ape/diff -ur /n/git/branch/heads/master/tree .
>         Only in .: .git
>         Only in .: debug
>         diff -ur /n/git/branch/heads/master/tree/fold.myr ./fold.myr
>         --- /n/git/branch/heads/master/tree/fold.myr    Wed Dec 31
> 16:00:00 1969
>         +++ ./fold.myr  Mon Apr  1 21:39:06 2019
>         @@ -6,6 +6,8 @@
>                 const foldexpr : (e : expr# -> std.option(constval))
>          ;;
>
>         +/* Look, diffing files just works, and I don't need any fancy
> glue! */
>         +
>          const foldexpr = {e
>                 match e
>                 | &(`Eident &[.sc=`Sclassenum, .name=name, .ty=`Tyenum
> &(`Body enum)]):
>         Only in .: refs
>
>
> The following utilities and binaries are provided:
>
>         fs:     The git filesystem.
>         fetch:  The protocol bits for getting data from a git server.
>         send:   The protocol bits for sending data to a git server.
>         save:   The gnarly bits for storing the files for a commit.
>         conf:   A program to extract information from a config file.
>         clone:  Clones a repository.
>         commit: Commits a snapshot of the working directory.
>         log:    Prints the contents of a commmit log.
>         add:    Tells the repository to add a file to the next commit.
>         walk:   `du`, but for git status.
>
>
> Supported protocols: git:// and git+ssh://. If someone
> implements others, I'll gladly accept patches.
>
> TODOs:
>         git/mkpatch:    Generate a 'git am' compatible patch.
>         git/apply:      Apply a diff.
>         git/diff:       Wrapper wrapper around git/walk that
>                         diffs the changed files.
>         git/merge:      Yup, what it says on the label. Should
>                         also be a script around git/fs.
>         git/log:        Need to figure out how to make it filter
>                         by files.
>         /n/git/HEAD:    add /n/git/head subtree which points
>                         to the current commit.
>
> ...And a whole bunch more.
>
>
>

[-- Attachment #2: Type: text/html, Size: 7032 bytes --]

Re: [9fans] Git/fs: Possibly Usable

[David du Colombier]

> The avl library doesn't match up to 9legacy version. Any ideas?
>
> BTW, I think your notes on this message are a great start for a README.

git9 seems to use 9front's libavl, which is a rewrite of Plan 9's libavl.
9legacy uses the original Plan9's libavl.

Please try this patch: http://9legacy.org/9legacy/patch/git9-avl.diff

--
David du Colombier

Re: [9fans] Git/fs: Possibly Usable

[Ori Bernstein]

On Wed, 3 Apr 2019 11:29:30 -0700
Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:

> Hi,
>
> The avl library doesn't match up to 9legacy version. Any ideas?

Looking at a few options. I can just say "well, patch it", but it'd
be nice to see the various plan9s playing better with each other.

There are a few options. The easy ones:

	- I can bundle the 9front libavl in git9.
	- I can remove the libavl usage, possibly replacing with
	  the objset implementation I already have.

The harder ones:

	- 9front can provide compatibility with 9legacy libavl
	- 9legacy can adopt the 9front libavl API.

The first two are easy. The other two involve herding cats,
but would make it possible for more code to be shared. Given
how few people are actually writing code on plan 9, it would
be nice to share what is there.

Right now, I'm leaning towards the second option, because all
I really use libavl for is a key-value lookup.

> BTW, I think your notes on this message are a great start for a README.

Already done.

--
Ori Bernstein <ori@eigenstate.org>

Re: [9fans] Git/fs: Possibly Usable

[Skip Tavakkolian]

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

I now realize there are two different libavl's.  It's easy enough to copy
from 9front repo (hopefully there are no cascading dependencies).

9front maintainers, can anyone speak to technical reasons for creating a
new version rather than fixing existing? Also, any thoughts on changing the
name slightly so they can both be on the same system? maybe libAVL?

Thanks,
-Skip

On Wed, Apr 3, 2019 at 1:23 PM Ori Bernstein <ori@eigenstate.org> wrote:

> On Wed, 3 Apr 2019 11:29:30 -0700
> Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
>
> > Hi,
> >
> > The avl library doesn't match up to 9legacy version. Any ideas?
>
> Looking at a few options. I can just say "well, patch it", but it'd
> be nice to see the various plan9s playing better with each other.
>
> There are a few options. The easy ones:
>
>         - I can bundle the 9front libavl in git9.
>         - I can remove the libavl usage, possibly replacing with
>           the objset implementation I already have.
>
> The harder ones:
>
>         - 9front can provide compatibility with 9legacy libavl
>         - 9legacy can adopt the 9front libavl API.
>
> The first two are easy. The other two involve herding cats,
> but would make it possible for more code to be shared. Given
> how few people are actually writing code on plan 9, it would
> be nice to share what is there.
>
> Right now, I'm leaning towards the second option, because all
> I really use libavl for is a key-value lookup.
>
> > BTW, I think your notes on this message are a great start for a README.
>
> Already done.
>
> --
> Ori Bernstein <ori@eigenstate.org>
>

[-- Attachment #2: Type: text/html, Size: 2261 bytes --]

Re: [9fans] Git/fs: Possibly Usable

[Kurt H Maier]

On Wed, Apr 03, 2019 at 05:00:15PM -0700, Skip Tavakkolian wrote:
> 9front maintainers, can anyone speak to technical reasons for creating a
> new version rather than fixing existing? Also, any thoughts on changing the
> name slightly so they can both be on the same system? maybe libAVL?

In 2016 spew wrote libbst, which is a binary search tree library that
supports both AVL and left-leaning red-black tree.  While he was at it
he wrote a faster and simpler avl implementation, and fixed venti and
nupas to work with it.  Since those were the only two things in the tree
that used AVL, nobody really cared if the old implementation went away.

I'm not sure what the advantage is to reintroducing it to 9front (aside
from the desire for zen-garden reliquaries).  The programs that use the
old API can be counted on one hand and fixing them is not difficult.

The question was raised, at the time, if the old one might have been
hand-tuned for some venti-related performance characteristics, but I
don't think anyone followed through on measuring the difference.  If
there are such idiosyncracies in the old code, they were not documented.

khm

Re: [9fans] Git/fs: Possibly Usable

[Ori Bernstein]

On Wed, 3 Apr 2019 13:23:08 -0700
Ori Bernstein <ori@eigenstate.org> wrote:

> 	- I can remove the libavl usage, possibly replacing with
> 	  the objset implementation I already have.

Did this one. Turned out to save a couple of lines, in the end.

--
Ori Bernstein <ori@eigenstate.org>

[9fans] UI design | enhancements.

[Darren Wise]

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

Hey folks,

I rarely post in-fact maybe my second ever, I was wondering if anyone
else or a group of us could work towards some window manager UI
modifications to appear more attractive in some form from the current
interface appearing in comparison to dwm(on other Nix forks) to a more
usable friendly interface like gnome, KDE and the like.

I'm just throwing the idea about really, I've not had much time at all
with Plan9 but from just my bare basic usage I can already see a great
future for Plan9 as a whole. As I say what with commitments currently
the last few years I could be way out of my depth and experience even
mentioning this and don't mind getting flamed a little.

 From my point of view and limited knowledge, usage even though very
streamlined, simple and very fast indeed it can become daunting for new
users to adopt, it's not off-putting just a little daunting and seems
somewhat inflexible to begin with. I'm sure it would attract a much
wider community with a few simple UI modifications and I'd like to hear
what others think about the subject in general.

*Maybe I should read and research more, either way I don't mean or wish
to offend anyone mentioning the above, even this post in some form might
jump start someone else or a group to just go ahead or have had thoughts
of the same previously.. Who know eh, it's Plan9.

--
WISECORP <https://wisecorp.co.uk>
Darren Wise
eMail: darren@wisecorp.co.uk <mailto:darren@wisecorp.co.uk>
www: https://wisecorp.co.uk





---
This email has been checked for viruses by AVG.
https://www.avg.com

[-- Attachment #2: Type: text/html, Size: 5580 bytes --]

Re: [9fans] UI design | enhancements.

[Ethan Gardener]

No offense taken, but just to note: I found Plan 9 very refreshing and very useful as it is.  It was a relief after the massive noise and clumsiness of traditional GUI, and the different but still irritating inherent clumsiness and bugginess of terminal emulation. That's not to say Plan 9 is without irritants, but it's the least irritating window system I've ever used.

You know, I'm *sure* that any goodness in today's GUIs is not the result of the paradigm but rather a good deal of care and sense, requiring considerable time and education, respectively.  The paradigm helps by standardising a few aspects of interaction, but you can't just apply it to programs and expect good results. It arguably has too few standards and too many features.  Far too many programs end up with nonsense like Celestia, where View Options is not under View but under the adjacent Render menu. I often want View Options to toggle certain markers, choosing between orienting the view and taking in the scene, but it's too out of the way; it doesn't have a shortcut because the author didn't imagine my use case.  The item browsers which I want even more often don't have keybindings either, which is astonishing! Other options are hidden under sub-menus; immensely fiddly things that they are.

The goodness in Plan 9's interfaces comes largely from a desire not to implement too much.  Instead, many of them are programmable.  Despite this, there are still major faults.  For instance, Acme's own window system is intrusive unless you follow a very specific workflow which was designed for programming only, and doesn't even seem to work for all programmers. Sam's dual clipboards are seriously intrusive for anyone who deals with a lot of snippets of text inside and outside the editor. (I've finally started using Sam now my usage is different, but for the entirety of my actual Plan 9 use it was just too painful.)


Besides, why would we want to attract people who are put off by superficial differences when the differences go all the way down? And, if I remember right, many Linux-lovers have bigger problems with those deeper issues than they do with the window system.  Those who can accept good-but-different internal design can and do accept different interface design.

Re: [9fans] UI design | enhancements.

[hiro]

> wondering if anyone else or a group of us could work towards

no, you!

Re: [9fans] UI design | enhancements.

[Lucio De Re]

The thing is, a UI is a combination of far too many personal tastes
and habits and a GUI multi-dimensionally more so. It's like a marble
slab that needs a Michelangelo to turn it into an image.

We've had one Michelangelo and a Rodin and only a few Greek sculptors
in the past, what, three thousand years? Do we really think that a
near infinite number of monkeys is now going to solve that problem,
specially when the marble slab is undergoing its own metamorphosis
underfoot?

Good luck!

Lucio.

Re: [9fans] UI design | enhancements.

[Bakul Shah]

Michelangelo or Rodin didn't have to worry about function, only form.

Da Vinci on the other hand....

> On Apr 14, 2019, at 10:07 PM, Lucio De Re <lucio.dere@gmail.com> wrote:
>
> The thing is, a UI is a combination of far too many personal tastes
> and habits and a GUI multi-dimensionally more so. It's like a marble
> slab that needs a Michelangelo to turn it into an image.
>
> We've had one Michelangelo and a Rodin and only a few Greek sculptors
> in the past, what, three thousand years? Do we really think that a
> near infinite number of monkeys is now going to solve that problem,
> specially when the marble slab is undergoing its own metamorphosis
> underfoot?
>
> Good luck!
>
> Lucio.
>

Re: [9fans] UI design | enhancements.

[Devine Lu Linvega]

Michelangelo would have been “middle-click!? Hell no”.

> On Apr 15, 2019, at 3:12 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> 
> Michelangelo or Rodin didn't have to worry about function, only form.
> 
> Da Vinci on the other hand....
> 
>> On Apr 14, 2019, at 10:07 PM, Lucio De Re <lucio.dere@gmail.com> wrote:
>> 
>> The thing is, a UI is a combination of far too many personal tastes
>> and habits and a GUI multi-dimensionally more so. It's like a marble
>> slab that needs a Michelangelo to turn it into an image.
>> 
>> We've had one Michelangelo and a Rodin and only a few Greek sculptors
>> in the past, what, three thousand years? Do we really think that a
>> near infinite number of monkeys is now going to solve that problem,
>> specially when the marble slab is undergoing its own metamorphosis
>> underfoot?
>> 
>> Good luck!
>> 
>> Lucio.
>> 
> 
> 

Re: [9fans] UI design | enhancements.

[Michael Misch]

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

The whole thing is a good discussion. plan9's design works, very well; for
about 80% of would be users. For differently abled people in any capacity
it all falls apart quickly. it's such a simple system though it wouldn't
take much work to extend support wherever needed.

On Mon., Apr. 15, 2019, 12:26 a.m. Devine Lu Linvega, <aliceffekt@gmail.com>
wrote:

> Michelangelo would have been “middle-click!? Hell no”.
>
> > On Apr 15, 2019, at 3:12 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> >
> > Michelangelo or Rodin didn't have to worry about function, only form.
> >
> > Da Vinci on the other hand....
> >
> >> On Apr 14, 2019, at 10:07 PM, Lucio De Re <lucio.dere@gmail.com> wrote:
> >>
> >> The thing is, a UI is a combination of far too many personal tastes
> >> and habits and a GUI multi-dimensionally more so. It's like a marble
> >> slab that needs a Michelangelo to turn it into an image.
> >>
> >> We've had one Michelangelo and a Rodin and only a few Greek sculptors
> >> in the past, what, three thousand years? Do we really think that a
> >> near infinite number of monkeys is now going to solve that problem,
> >> specially when the marble slab is undergoing its own metamorphosis
> >> underfoot?
> >>
> >> Good luck!
> >>
> >> Lucio.
> >>
> >
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 1938 bytes --]

Re: [9fans] UI design | enhancements.

[Bakul Shah]

What I meant to say is you can't apply aesthetics of art
to UI as the latter has a functional purpose. And we don't
have to wait for a Michelangelo to design a perfect UI!
In other words, I don't think a UI discussion would be
fruitless. Not to replicate KDE/Gnome etc. but to find
other alternatives that feel more in tune with plan9.

> On Apr 14, 2019, at 11:41 PM, Michael Misch <michaelmisch1985@gmail.com> wrote:
> 
> The whole thing is a good discussion. plan9's design works, very well; for about 80% of would be users. For differently abled people in any capacity it all falls apart quickly. it's such a simple system though it wouldn't take much work to extend support wherever needed.
> 
> On Mon., Apr. 15, 2019, 12:26 a.m. Devine Lu Linvega, <aliceffekt@gmail.com> wrote:
> Michelangelo would have been “middle-click!? Hell no”.
> 
> > On Apr 15, 2019, at 3:12 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> > 
> > Michelangelo or Rodin didn't have to worry about function, only form.
> > 
> > Da Vinci on the other hand....
> > 
> >> On Apr 14, 2019, at 10:07 PM, Lucio De Re <lucio.dere@gmail.com> wrote:
> >> 
> >> The thing is, a UI is a combination of far too many personal tastes
> >> and habits and a GUI multi-dimensionally more so. It's like a marble
> >> slab that needs a Michelangelo to turn it into an image.
> >> 
> >> We've had one Michelangelo and a Rodin and only a few Greek sculptors
> >> in the past, what, three thousand years? Do we really think that a
> >> near infinite number of monkeys is now going to solve that problem,
> >> specially when the marble slab is undergoing its own metamorphosis
> >> underfoot?
> >> 
> >> Good luck!
> >> 
> >> Lucio.
> >> 
> > 
> > 
> 
> 

Re: [9fans] UI design | enhancements.

[hiro]

the only art in window management is how they manage to sustain so
much inconsistency

Re: [9fans] UI design | enhancements.

[Kurt H Maier]

On Mon, Apr 15, 2019 at 12:24:44AM -0700, Bakul Shah wrote:
> And we don't have to wait for a Michelangelo to design a perfect UI!

Of course not.  We already have Mike Okuda.

khm

Re: [9fans] UI design | enhancements.

[Chris McGee]

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

Hi Darren,

Your goal seem to be to make the system less daunting for new users. I
think there are a number of ways to accomplish this.

Dressing up the UI and/or making it more like popular used interfaces might
be one way to make new users feel more comfortable. One concern with doing
this is that it allows them to come with other assumptions that may
confusions about how the underlying system works. This effort could also
increase complexity and size of the core system. Simplicity, size and
consistency are aspects of Plan 9 that I really value. Otherwise, I might
as well just use BSD or even Linux.

In my experience one of the biggest hurdles to getting curious new users to
give Plan 9 a try is just getting access to a namespace so that they can
give it a try and learn. I think that the quickest path at the moment is to
install it onto a VM like qemu (or yuck, virtualbox) since you can bypass
the whole hardware selection and compatibility pain points. I put some
YouTube videos up showing people step-by-step with a decent number of views
and comments, so I think this helped some people just to get their hands on
it. There are more ideas that I'm playing with to help people get started,
such as building a website where you can get a drawterm in your web browser
and give it a try.

Once a new user has access to the system there could be some exercises and
tutorials to engage them. There could be a variety of these depending on
the background, whether programmer, Linux user, librarian, whatever. The
key in my opinion is to not hide the core system with layer after layer of
"pretty" GUI's, but instead reveal it gradually with decent explanations. I
think that the core of Plan 9 is much easier to explain than other systems
because of its smaller size, relatively consistent interfaces and
versatility. Once you grasp one area it is much easier to begin grasping
more of it using the skills you already have. I can't say the same thing
about Linux or any other system that I have used. Like any tool, there is
some required learning and practice. Good tools amplify your learning as
you practice with it.

Once someone understands how Plan 9 works then I think they will have many
of the tools that they need to build their own networks with it. I
recommend digging into man pages and /sys/doc at this stage. There's a
wealth of well written guides in there, although some could be made a bit
more current. A guide on how to build a home network using raspberry pi
terminals and a CPU/file server from easy to acquire, but well designed,
modern hardware would be a welcome addition.

The system is far from perfect as others will tell you but there's advances
and fixes happening steadily. I'm just not sure if focusing on the initial
user experience through UI look and feel is adding much. I think a more
general discussion of GUI capabilities, such as video and 3D graphics
capabilities, would be great, but more in the context of what kinds of
tasks people want to accomplish. The trick is to fit those improvements
into the rest of the system and not just jamming them in.

Cheers,
Chris

[-- Attachment #2: Type: text/html, Size: 3399 bytes --]

Re: [9fans] UI design | enhancements.

[Darren Wise]

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

Heya folks,

Thanks very much for the replies so far, I'm still reading them as they
come in and when the flutter has calmed down a little I'll then start to
reply. I'm just letting you know I am listening and reading and not
being ignorant firing off some random eMail and then doing-one elsewhere :D

Some very high quality responses so far, good giggles as well! Awesome
insights considering my level of Plan9 usage and knowledge at this stage.

Awesome stuff!

On 15/04/2019 16:10, Chris McGee wrote:
>
> Hi Darren,
>
> Your goal seem to be to make the system less daunting for new users. I
> think there are a number of ways to accomplish this.
>
> Dressing up the UI and/or making it more like popular used interfaces
> might be one way to make new users feel more comfortable. One concern
> with doing this is that it allows them to come with other assumptions
> that may confusions about how the underlying system works. This effort
> could also increase complexity and size of the core system.
> Simplicity, size and consistency are aspects of Plan 9 that I really
> value. Otherwise, I might as well just use BSD or even Linux.
>
> In my experience one of the biggest hurdles to getting curious new
> users to give Plan 9 a try is just getting access to a namespace so
> that they can give it a try and learn. I think that the quickest path
> at the moment is to install it onto a VM like qemu (or yuck,
> virtualbox) since you can bypass the whole hardware selection and
> compatibility pain points. I put some YouTube videos up showing people
> step-by-step with a decent number of views and comments, so I think
> this helped some people just to get their hands on it. There are more
> ideas that I'm playing with to help people get started, such as
> building a website where you can get a drawterm in your web browser
> and give it a try.
>
> Once a new user has access to the system there could be some exercises
> and tutorials to engage them. There could be a variety of these
> depending on the background, whether programmer, Linux user,
> librarian, whatever. The key in my opinion is to not hide the core
> system with layer after layer of "pretty" GUI's, but instead reveal it
> gradually with decent explanations. I think that the core of Plan 9 is
> much easier to explain than other systems because of its smaller size,
> relatively consistent interfaces and versatility. Once you grasp one
> area it is much easier to begin grasping more of it using the skills
> you already have. I can't say the same thing about Linux or any other
> system that I have used. Like any tool, there is some required
> learning and practice. Good tools amplify your learning as you
> practice with it.
>
> Once someone understands how Plan 9 works then I think they will have
> many of the tools that they need to build their own networks with it.
> I recommend digging into man pages and /sys/doc at this stage. There's
> a wealth of well written guides in there, although some could be made
> a bit more current. A guide on how to build a home network using
> raspberry pi terminals and a CPU/file server from easy to acquire, but
> well designed, modern hardware would be a welcome addition.
>
> The system is far from perfect as others will tell you but there's
> advances and fixes happening steadily. I'm just not sure if focusing
> on the initial user experience through UI look and feel is adding
> much. I think a more general discussion of GUI capabilities, such as
> video and 3D graphics capabilities, would be great, but more in the
> context of what kinds of tasks people want to accomplish. The trick is
> to fit those improvements into the rest of the system and not just
> jamming them in.
>
> Cheers,
> Chris
--
WISECORP <https://wisecorp.co.uk>
Darren Wise
eMail: darren@wisecorp.co.uk <mailto:darren@wisecorp.co.uk>
www: https://wisecorp.co.uk

The company [ WISECORP ] accepts no liability for the content of this
email, or for the consequences of any actions taken on the basis of the
information provided, unless that information is subsequently confirmed
in handwriting. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance
on the contents of this information is strictly prohibited.




---
This email has been checked for viruses by AVG.
https://www.avg.com

[-- Attachment #2: Type: text/html, Size: 9693 bytes --]

Re: [9fans] UI design | enhancements.

[ab]

> Darren Wise wrote:
> snip

With all due respect (admittedly, I've thought about this before) but
Plan 9 may be better used as a model of how thoughtful engineering can
produce a great system.

Perhaps better inspiration could be achieved by setting up a public Plan
9 server (or private, it's your server) and letting people interact with
it on their own.

If you want to start smaller, you can always share some code that would
implement some graphical feature you find Plan 9 lacking in. This list
does have a disappointing lack of semicolons.

Good luck.

Re: [9fans] UI design | enhancements.

[Ethan Gardener]

On Mon, Apr 15, 2019, at 7:43 AM, Michael Misch wrote:
> The whole thing is a good discussion. plan9's design works, very well; for about 80% of would be users. For differently abled people in any capacity it all falls apart quickly.

Begging your pardon, but for *this* differently abled person it's a huge improvement on WinGnoKDE.  Anyone who wants to make *text selection* complicated ought not to be allowed near a computer, to say nothing of the numerous other problems which get in the way of just getting accustomed to and fluently using traditional GUI.

Re: [9fans] UI design | enhancements.

[Michael Misch]

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

That's good to note. (I don't consider "WinGnoKDE" a good counterpoint
anyways) but for example I have reasonably debilitating carpal tunnel
issues, and the heavy mouse use is a major bane to my general enjoyment in
Rio when it happens.

On Mon., Apr. 15, 2019, 2:00 p.m. Ethan Gardener, <eekee57@fastmail.fm>
wrote:

> On Mon, Apr 15, 2019, at 7:43 AM, Michael Misch wrote:
> > The whole thing is a good discussion. plan9's design works, very well;
> for about 80% of would be users. For differently abled people in any
> capacity it all falls apart quickly.
>
> Begging your pardon, but for *this* differently abled person it's a huge
> improvement on WinGnoKDE.  Anyone who wants to make *text selection*
> complicated ought not to be allowed near a computer, to say nothing of the
> numerous other problems which get in the way of just getting accustomed to
> and fluently using traditional GUI.
>
>

[-- Attachment #2: Type: text/html, Size: 1214 bytes --]

Re: [9fans] Git/fs: Possibly Usable

[Ori Bernstein]

On Mon, 1 Apr 2019 21:41:09 -0700
ori@eigenstate.org wrote:

> It was mentioned on this list a short while ago. Now, it's
> more or less at the point where it works for me. Expect
> many bugs and problems, and many more missing tools, but
> "the rest is just scripting".

An update: I'm now using this git implementation on a daily
basis. It's hosting its own development now, and tons of
bugs have been fixed.

All commits in the git mirror here were made with git9 on 9front:
https://github.com/oridb/git9

I'm also keeping the old mirror in hg alive:
https://bitbucket.org/oridb/git9

There's one incompatibility that I'm aware of with 9legacy, where
I use `$split{...} syntax in rc to make files with spaces work
cleanly. I don't think 9legacy imported that patch from 9atom.

The remaining missing bits, in my mind:

	- UI polish; There's some thought needed about how
	  the exposed functionality should work.

	- Patch import/export: probably git/diff -[pa] for
	  generating or importing `git format-patch` compatible
	  style diff.

	- Rebase-like functionality would be nice.

	- (Low priority, probably won't do it myself, but I'd
	  take a patch): HTTP protocol. Most places (including
	  github) serve up git protocol URLS, in the form

		git://github.com/user/repo

--
Ori Bernstein <ori@eigenstate.org>

Re: [9fans] Git/fs: Possibly Usable

[Patrick Marchand]

Hi Ori,

On 07/08, Ori Bernstein wrote:
> On Mon, 1 Apr 2019 21:41:09 -0700
> ori@eigenstate.org wrote:
>
> > It was mentioned on this list a short while ago. Now, it's
> > more or less at the point where it works for me. Expect
> > many bugs and problems, and many more missing tools, but
> > "the rest is just scripting".
>
> An update: I'm now using this git implementation on a daily
> basis. It's hosting its own development now, and tons of
> bugs have been fixed.
>

Good job ! Cant wait to get the chance to play around with it. I'll
be installing a plan9 server at my home next month so I'll be able
to test in detail then.

Have a good day

Re: [9fans] Git/fs: Possibly Usable

[Steve Simon]

I agree 100%, well done Ori, I will be trying this soon,
I am in the process of changing jobs at the moment so
I am a bit distracted but the new job will include git so I
Will be needing it.

-Steve


> On 12 Jul 2019, at 19:27, Patrick Marchand <mail@patrickmarchand.com> wrote:
> 
> Hi Ori,
> 
> On 07/08, Ori Bernstein wrote:
>> On Mon, 1 Apr 2019 21:41:09 -0700
>> ori@eigenstate.org wrote:
>> 
>>> It was mentioned on this list a short while ago. Now, it's
>>> more or less at the point where it works for me. Expect
>>> many bugs and problems, and many more missing tools, but
>>> "the rest is just scripting".
>> 
>> An update: I'm now using this git implementation on a daily
>> basis. It's hosting its own development now, and tons of
>> bugs have been fixed.
>> 
> 
> Good job ! Cant wait to get the chance to play around with it. I'll
> be installing a plan9 server at my home next month so I'll be able
> to test in detail then.
> 
> Have a good day

Re: [9fans] Git/fs: Possibly Usable

[clueelf]

Thanks Ori!

I pulled it down today and started using it against a few GitHub repos I have.  For those who are thinking about using it, it only uses 'git' and 'git+ssh' style URLs, but they work so far without incident.

git/clone git+ssh://git@github.com:tmendoza/9front-user

Once I got keys generated and pushed to github.com, worked just fine.  My updates show up as expected.

Great job!

Tony

On 7/12/2019 at 3:22 PM, "Steve Simon" <steve@quintile.net> wrote:
>
>I agree 100%, well done Ori, I will be trying this soon,
>I am in the process of changing jobs at the moment so
>I am a bit distracted but the new job will include git so I
>Will be needing it.
>
>-Steve
>
>
>> On 12 Jul 2019, at 19:27, Patrick Marchand
><mail@patrickmarchand.com> wrote:
>>
>> Hi Ori,
>>
>> On 07/08, Ori Bernstein wrote:
>>> On Mon, 1 Apr 2019 21:41:09 -0700
>>> ori@eigenstate.org wrote:
>>>
>>>> It was mentioned on this list a short while ago. Now, it's
>>>> more or less at the point where it works for me. Expect
>>>> many bugs and problems, and many more missing tools, but
>>>> "the rest is just scripting".
>>>
>>> An update: I'm now using this git implementation on a daily
>>> basis. It's hosting its own development now, and tons of
>>> bugs have been fixed.
>>>
>>
>> Good job ! Cant wait to get the chance to play around with it.
>I'll
>> be installing a plan9 server at my home next month so I'll be
>able
>> to test in detail then.
>>
>> Have a good day

Re: [9fans] Git/fs: Possibly Usable

[Ori Bernstein]

On Sun, 21 Jul 2019 16:06:54 -0500
clueelf@tonymendoza.us wrote:

> Thanks Ori!
>
> I pulled it down today and started using it against a few GitHub repos I have.  For those who are thinking about using it, it only uses 'git' and 'git+ssh' style URLs, but they work so far without incident.
>
> git/clone git+ssh://git@github.com:tmendoza/9front-user
>
> Once I got keys generated and pushed to github.com, worked just fine.  My updates show up as expected.

Good to hear!

--
Ori Bernstein <ori@eigenstate.org>

Re: [9fans] Git/fs: Possibly Usable

[Skip Tavakkolian]

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

is this an equivalent fix for 9legacy env?  (i'm guessing the answer is no)

% diff clone /bin/git/clone
75c75
< for(f in `$nl{walk -f $tree | sed 's@^'$tree'/*@@'}){
---
> for(f in `{ifs=$nl walk -f $tree | sed 's@^'$tree'/*@@'}){

also, the earliest reference to `$split{...}` notation i found is in 9atom;
can anyone confirm?

On Thu, Jul 25, 2019 at 3:01 PM Ori Bernstein <ori@eigenstate.org> wrote:

> On Sun, 21 Jul 2019 16:06:54 -0500
> clueelf@tonymendoza.us wrote:
>
> > Thanks Ori!
> >
> > I pulled it down today and started using it against a few GitHub repos I
> have.  For those who are thinking about using it, it only uses 'git' and
> 'git+ssh' style URLs, but they work so far without incident.
> >
> > git/clone git+ssh://git@github.com:tmendoza/9front-user
> >
> > Once I got keys generated and pushed to github.com, worked just fine.
> My updates show up as expected.
>
> Good to hear!
>
> --
> Ori Bernstein <ori@eigenstate.org>
>
>

[-- Attachment #2: Type: text/html, Size: 1620 bytes --]

Re: [9fans] Git/fs: Possibly Usable

[erik quanstrom]

[-- Attachment #1: Type: text/html, Size: 2126 bytes --]

Re: [9fans] Git/fs: Possibly Usable

[erik quanstrom]

[-- Attachment #1: Type: text/html, Size: 555 bytes --]

Re: [9fans] Git/fs: Possibly Usable

[Ori Bernstein]

On Mon, 5 Aug 2019 11:43:33 -0700, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:

> is this an equivalent fix for 9legacy env?  (i'm guessing the answer is no)
>
> % diff clone /bin/git/clone
> 75c75
> < for(f in `$nl{walk -f $tree | sed 's@^'$tree'/*@@'}){
> ---
> > for(f in `{ifs=$nl walk -f $tree | sed 's@^'$tree'/*@@'}){
>

You can also set ifs outside of the `{...}.

However, I think it's worth importing the 9atom change into 9legacy
rc. It's an elegant solution.

--
    Ori Bernstein

Re: [9fans] UI design | enhancements.

[Lucio De Re]

On 4/17/19, Michael Misch <michaelmisch1985@gmail.com> wrote:
> i tried to solve that problem on Linux, with a wm that tiled set-sized
> windows in a floating grid, but it was always very, very hacky. (For the
> curious, github.com/halfwit/hwwm)
>
A name (halfwit) worthy of the long-forgotten fortune database!

Lucio.

Re: [9fans] UI design | enhancements.

[Michael Misch]

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

i tried to solve that problem on Linux, with a wm that tiled set-sized
windows in a floating grid, but it was always very, very hacky. (For the
curious, github.com/halfwit/hwwm)

On Tue., Apr. 16, 2019, 9:59 p.m. Lucio De Re, <lucio.dere@gmail.com> wrote:

> On 4/16/19, Marshall Conover <marzhall.o@gmail.com> wrote:
> > [ ... ]
> > As an aside, Lucio, I'd second Ethan in that it's probably worth taking a
> > look; I'd be surprised if there was more actual code to change than there
> > was just ramp-up time to understand what you need to change, and a
> > one-or-two hour excursion into the code would probably get you how much
> > ramp-up time you need, at which point you could probably make the final
> > call on whether to move forward.
> >
> Thanks to both of you for the hint. My problem, spelled out neatly
> above, is that I have no idea how one targets the correct "window" in
> X. I have completely swallowed the Plan 9 kool-aid of fine-grained
> namespace separation and can't contemplate how xnest gets it wrong.
>
> By the same token, incidentally, I've been wondering what the X
> equivalent of 9's window could be: nowhere in X's user space have I
> found a way to spawn a task in a window that matches the geometry I
> specify, unless that task includes the geometry among the command line
> arguments. That bit of philosophy shows so clearly how different Plan
> 9 and Unix really are.
>
> I will look, however. Frankly, if rio could provide a "little" more
> support, one may be able to run firefox (I'm assuming chrome/chromium
> isn't quite as liberated) in a rio window, but my efforts a while ago
> flopped completely - for which part of me is greatly relieved: somehow
> a firefox window on a Plan 9 background would be a constant thorn in
> my side.
>
> Lucio.
>
> PS: I did look at rio, not that long ago. But I think the problem
> extends to individual graphic commands. I'll see if I can get catclock
> to behave itself, next. Or shove the xnext magic into a rio option.
>
>

[-- Attachment #2: Type: text/html, Size: 2584 bytes --]

Re: [9fans] UI design | enhancements.

[Lucio De Re]

On 4/16/19, Marshall Conover <marzhall.o@gmail.com> wrote:
> [ ... ]
> As an aside, Lucio, I'd second Ethan in that it's probably worth taking a
> look; I'd be surprised if there was more actual code to change than there
> was just ramp-up time to understand what you need to change, and a
> one-or-two hour excursion into the code would probably get you how much
> ramp-up time you need, at which point you could probably make the final
> call on whether to move forward.
>
Thanks to both of you for the hint. My problem, spelled out neatly
above, is that I have no idea how one targets the correct "window" in
X. I have completely swallowed the Plan 9 kool-aid of fine-grained
namespace separation and can't contemplate how xnest gets it wrong.

By the same token, incidentally, I've been wondering what the X
equivalent of 9's window could be: nowhere in X's user space have I
found a way to spawn a task in a window that matches the geometry I
specify, unless that task includes the geometry among the command line
arguments. That bit of philosophy shows so clearly how different Plan
9 and Unix really are.

I will look, however. Frankly, if rio could provide a "little" more
support, one may be able to run firefox (I'm assuming chrome/chromium
isn't quite as liberated) in a rio window, but my efforts a while ago
flopped completely - for which part of me is greatly relieved: somehow
a firefox window on a Plan 9 background would be a constant thorn in
my side.

Lucio.

PS: I did look at rio, not that long ago. But I think the problem
extends to individual graphic commands. I'll see if I can get catclock
to behave itself, next. Or shove the xnext magic into a rio option.

Re: [9fans] UI design | enhancements.

[Marshall Conover]

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

Thanks, Ori, that's badass. I'll have to struggle with laziness re:hooking
up to a monitor/rebooting my cpu server to give it a go, but it would be
good to get a feel of what I'm aiming for.

Mart - thanks for pointing out Microviche. I had considered whether zooming
and other features might be neat down the line, if panning felt natural, so
having something to look at for that is great.

As an aside, Lucio, I'd second Ethan in that it's probably worth taking a
look; I'd be surprised if there was more actual code to change than there
was just ramp-up time to understand what you need to change, and a
one-or-two hour excursion into the code would probably get you how much
ramp-up time you need, at which point you could probably make the final
call on whether to move forward.

Thanks!

Marshall

On Mon, Apr 15, 2019 at 5:10 PM Ori Bernstein <ori@eigenstate.org> wrote:

> On Mon, 15 Apr 2019 16:59:12 -0400
> Marshall Conover <marzhall.o@gmail.com> wrote:
>
> > For example, I feel super squished on a single screen, but I've come to
> > dislike the awkwardness of switching between multiple 'workspaces' or
> > working with tiling wms. So I'm playing around with rio at the moment to
> > see if adding a 'panning' effect, where you treat the desktop as an
> > infinitely-scrollable table and allow the user to 'pan' around the table,
> > could be a natural approach to feeling less squished. It may end up being
> > even more awkward and painful, but it may also end up being something I'm
> > left wanting for in modern DEs - that could be an attraction to 9.
>
> From man 3 vga:
>
>           panning mode
>                Depending on whether mode is on or off, enable or dis-
>                able panning in a virtual screen.  If panning is on and
>                the screen's size is larger than its actualsize, the
>                displayed portion of the screen will pan to follow the
>                mouse.  Setting the panning mode after the first attach
>                of the #i driver has no effect.
>
> --
> Ori Bernstein <ori@eigenstate.org>
>


--
Have a good day,

Marshall Conover

[-- Attachment #2: Type: text/html, Size: 2915 bytes --]

Re: [9fans] UI design | enhancements.

[Ethan Gardener]

On Tue, Apr 16, 2019, at 4:56 AM, Lucio De Re wrote:
>
> Is it worth my while to delve into p9p's innards and see if I can find
> all the locations where this needs to be corrected? Is it going to be
> one locations or far too many?

I couldn't tell you exactly, but I can tell you X window managers can be surprisingly simple things. I looked into wm2 many years ago, a sort of sibling to p9p rio in that both derive from 9wm.  I don't remember anything useful, but I do remember it was not a lot of code.

Re: [9fans] UI design | enhancements.

[Mart Zirnask]

On 15/04/2019, Marshall Conover <marzhall.o@gmail.com> wrote:
> For example, I feel super squished on a single screen, but I've come to
> dislike the awkwardness of switching between multiple 'workspaces' or
> working with tiling wms. So I'm playing around with rio at the moment to
> see if adding a 'panning' effect, where you treat the desktop as an
> infinitely-scrollable table and allow the user to 'pan' around the table,
> could be a natural approach to feeling less squished. It may end up being
> even more awkward and painful, but it may also end up being something I'm
> left wanting for in modern DEs - that could be an attraction to 9.

Semi-related, but this reminds me of a Vim plugin, Microviche,
that allows one to "pan and zoom through text":
https://www.youtube.com/watch?v=9YNiPUTGO28
https://github.com/q335r49/microviche

I'd say Microviche rpresents a text editing paradigm entirely of its
own just like Acme.
I remember having wanted to emulate something similar within Acme
(the feeling of scrolling text panes/columns horizontally), but I
didn't really try.

Mart

Re: [9fans] UI design | enhancements.

[Lucio De Re]

Here's one of many small issues I would like explained or adjusted: I
can half run rio (p9p's rio) under xnest. I seem to recall Erik
mentioning the option, but in my few efforts, it landed up with the
newly-created windows on the desktop instead of within the rio xnest.

Is it worth my while to delve into p9p's innards and see if I can find
all the locations where this needs to be corrected? Is it going to be
one locations or far too many?

I simply can't sacrifice my browser and skype to rio, my job depends
on those two.

I'm trying hard to wean myself off Thunderbird, I detest that animal
and have made some progress with Erik's upas which doesn't get totally
confused with Dovecot on the IMAP side - very minor tweaks sufficed to
compile under 9legacy (I just copied the le/be module(s) from the
library into the "distribution").

I still need to be able to operate mailman's web interface: replacing
that will with an acme/mail utility is a bit beyond me and in any case
I think mailman's days are numbered, more so now that version 3 is
starting to take shape and is going to obsolete version 2 that by
comparison is a shrew against an elephant.

Lucio.

On 4/15/19, sl@9front.org <sl@9front.org> wrote:
> thinking is hard.  there is a sweet spot somewhere between ease of use
> and knowing what you're trying to accomplish in the first place.
>
> once you learn the system, you can get a lot of mileage out of
> in-built system features, such as shell commands, lists (variables),
> functions, and pipelines.  file interfaces and private namespaces make
> these simple primitives even more powerful than they are on presumably
> more familiar unix systems.  (it has to be said: unix users already
> don't seem to get much mileage out of existing unix features.)
>
> rio is scriptable, and all of its features are exposed to file
> interfaces and text commands.  that's a huge steering wheel, even if
> your hands are small.
>
> all the cosmetic stuff new users typically complain about can be
> modified with a minimum of knowledge and skill.  this is a benefit of
> the terse, simple programming style.  sometimes, even a deficient
> program can be better than a featureful one, if the deficient program
> is simple and easy to modify.  just implement whatever it is you
> actually want to do.
>
> some people would say this is ugly:
>
> http://plan9.stanleylieber.com/rio/img/20190415.png
>
> sl
>
>


--
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824
FAX: +27 58 653 1435

Re: [9fans] UI design | enhancements.

[sl]

thinking is hard.  there is a sweet spot somewhere between ease of use
and knowing what you're trying to accomplish in the first place.

once you learn the system, you can get a lot of mileage out of
in-built system features, such as shell commands, lists (variables),
functions, and pipelines.  file interfaces and private namespaces make
these simple primitives even more powerful than they are on presumably
more familiar unix systems.  (it has to be said: unix users already
don't seem to get much mileage out of existing unix features.)

rio is scriptable, and all of its features are exposed to file
interfaces and text commands.  that's a huge steering wheel, even if
your hands are small.

all the cosmetic stuff new users typically complain about can be
modified with a minimum of knowledge and skill.  this is a benefit of
the terse, simple programming style.  sometimes, even a deficient
program can be better than a featureful one, if the deficient program
is simple and easy to modify.  just implement whatever it is you
actually want to do.

some people would say this is ugly:

http://plan9.stanleylieber.com/rio/img/20190415.png

sl

Re: [9fans] UI design | enhancements.

[Ori Bernstein]

On Mon, 15 Apr 2019 16:59:12 -0400
Marshall Conover <marzhall.o@gmail.com> wrote:

> For example, I feel super squished on a single screen, but I've come to
> dislike the awkwardness of switching between multiple 'workspaces' or
> working with tiling wms. So I'm playing around with rio at the moment to
> see if adding a 'panning' effect, where you treat the desktop as an
> infinitely-scrollable table and allow the user to 'pan' around the table,
> could be a natural approach to feeling less squished. It may end up being
> even more awkward and painful, but it may also end up being something I'm
> left wanting for in modern DEs - that could be an attraction to 9.

>From man 3 vga:

          panning mode
               Depending on whether mode is on or off, enable or dis-
               able panning in a virtual screen.  If panning is on and
               the screen's size is larger than its actualsize, the
               displayed portion of the screen will pan to follow the
               mouse.  Setting the panning mode after the first attach
               of the #i driver has no effect.

--
Ori Bernstein <ori@eigenstate.org>

Re: [9fans] UI design | enhancements.

[Marshall Conover]

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

Hi Darren!

I can see how 9's current UI could be considered a 'roadblock' to the
average user due to its unfamiliarity, and making it closer to modern looks
may make plan 9 pass the smell test for users more often. Personally,
though, it seems like a bit of a slog; there's not much exciting going on
in changing a UI to look like 'every other' UI, and I'd also wonder about
maintenance - you might update it to look familiar now, but in three years
where will it be, especially with web frameworks changing things so
frequently and invading the desktop with elektron? That said, if it does
draw more users, upkeep might get easier (just having people prompting with
issue reports can be productive), and it's genuinely nice to have a more
active community.

But, I'd be really interested to see it taken a step further. Instead of
just a facelift, I'd love to see changes that show a reflection on modern
UIs and their problems, and attempts to fix them. That'd not just remove a
roadblock for new users, but create change that may actually draw them.

For example, I feel super squished on a single screen, but I've come to
dislike the awkwardness of switching between multiple 'workspaces' or
working with tiling wms. So I'm playing around with rio at the moment to
see if adding a 'panning' effect, where you treat the desktop as an
infinitely-scrollable table and allow the user to 'pan' around the table,
could be a natural approach to feeling less squished. It may end up being
even more awkward and painful, but it may also end up being something I'm
left wanting for in modern DEs - that could be an attraction to 9.

In something that I feel relates closer to the heart of 9, one problem I
see in modern UIs is the inability to easily interact between programs.
Each UI acts as an island, and the best generic interface for interaction
you can get between them is allowing programs to send screen clicks, with
the nightmare quickly following of figuring out how to know where to click.
Web APIs are somewhat en route to addressing that with their REST endpoints
and swagger API definitions, but it seems so much more simple to instead
use files and directories over 9p.

Getting really out there, I'd love to see a tightly coupled way of
representing the commands you can send to a program via its ctl file API in
9 and a visual representation of that program in rio. I'd love if the UIs I
was using in a program corresponded to their filesystem API so much as to
be almost a mapping, perhaps even letting you generate a UI from the
filesystem API and some simple mark(down|up). I think a shell that worked
off of this concept could be fascinating - not unlike a browser in some
ways, but in keeping close to the filesystem abstraction, perhaps allowing
for much better interaction with the small, text-stream focused programs
that the unix mentality prefers.

In sum, I'd be happy to see an increase in users from a facelift, but what
I'd love to see are new draws that fix modern problems.

On a more practical level, you may find it notable that the nuklear lib
<https://bitbucket.org/mischief/libnuklear> has been ported for plan 9. It
may be a good start to create a UI that users coming from current workflows
will be comfortable looking at and interacting with. If you want to chat
with the porter of the nuklear lib for 9, you'll find him in this plan
9-focused discord server: https://discord.gg/6daut5T. You may also find
it's a good place for discussion like this.

Thanks for starting the discussion, and good luck!

Marshall

[-- Attachment #2: Type: text/html, Size: 4014 bytes --]

Re: [9fans] UI design | enhancements.

[ori]

> Hey folks,
>
> I rarely post in-fact maybe my second ever, I was wondering if anyone
> else or a group of us could work towards some window manager UI
> modifications to appear more attractive in some form from the current
> interface appearing in comparison to dwm(on other Nix forks) to a more
> usable friendly interface like gnome, KDE and the like.

I don't think this would fit well on plan 9. There's room for improvement
in what exists,  but I think large and complex environments are liabilities.

It's not something I'd be interested in using.

> I'm just throwing the idea about really, I've not had much time at all
> with Plan9 but from just my bare basic usage I can already see a great
> future for Plan9 as a whole. As I say what with commitments currently
> the last few years I could be way out of my depth and experience even
> mentioning this and don't mind getting flamed a little.

If you want this, you're going to need to write the code.

In general, ideas are cheap, and people are unlikely to pitch in until
they see where you're going. And specifically, people already know where
to go if they want KDE or Gnome.