[9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Alex-P. Natsios]

Hello 9fans,

I was looking at project ideas for this years GSoC (yes i know i am
too damn late).
I was wondering about the Goblin project and whether Mortdeus or
someone else from the community would find it as a viable GSoC
project.

due to being this late i will register a proposal anyway though
(including some info about me there) but it would be nice to have a
discussion about it.
.
--
Best Regards,

Alex-P. Natsios
(a.k.a Drakevr)

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Alex-P. Natsios]

Silly me, didn't include a link!
https://github.com/mortdeus/goblin

--
Regards,

Alex-P. Natsios
(a.k.a Drakevr)

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

On Mon Apr 29 14:55:16 EDT 2013, apnatsios@gmail.com wrote:
> Silly me, didn't include a link!
> https://github.com/mortdeus/goblin
>

in general, that looks reasonable to me.  some commands
like yesterday are rc scripts.  it's not clear to me that reimplementing
in go makes sense.

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Aram Hăvărneanu]

This looks like a reasonable list:

  ascii
  basename
  cal
  cat
  cleanname
  cmp
  date
  du
  dd
  diff
  echo
  ed
  fmt
  freq
  getflags
  grep
  join
  look
  ls
  mkdir
  mtime
  pwd
  read
  sed
  seq
  sleep
  sort
  split
  strings
  tail
  tee
  test
  touch
  tr
  troff
  unicode
  uniq

These are too large:

  acme
  awk
  mk
  rc
  sam

Alternatively, one can implement rc(1) or awk(1) in Go, rather than
implementing all the base tools.

--
Aram Hăvărneanu

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

> These are too large:
>
>   acme
>   awk
>   mk
>   rc
>   sam

or, extra credit.  :-)

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[arnold]

Aram Hăvărneanu <aram.h@mgk.ro> wrote:

> Alternatively, one can implement rc(1) or awk(1) in Go, rather than
> implementing all the base tools.

Speaking from experience, there are a fair number of dark corners
to handle if you are going to implement awk.  Contact me off list for
pointers to documentation and test suites.

Is there even a yacc equivalent from Go?  That might be a reasonable
project - add Go support to Berkely Yacc, Plan 9 Yacc, or Bison. Or larger
in scale, to implement Yacc itself in Go.

Arnold

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Aram Hăvărneanu]

> Is there even a yacc equivalent from Go?

Yes, it's a translation of the Plan 9 yacc, and it was done by Roger Peppe.

--
Aram Hăvărneanu

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Aram Hăvărneanu]

>> Is there even a yacc equivalent from Go?
>
> Yes, it's a translation of the Plan 9 yacc, and it was done by Roger Peppe.

Sorry, a translation of the Inferno yacc. It's part of the Go
distribution: http://golang.org/cmd/yacc/

--
Aram Hăvărneanu

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Jens Staal]

On 2013-04-29 21:11, Aram Hăvărneanu wrote:
> This looks like a reasonable list:

>
> Alternatively, one can implement rc(1) or awk(1) in Go, rather than
> implementing all the base tools.
>
> --
> Aram Hăvărneanu
>

The "oh" shell is (or used to be) an rc-like implementation in go so if 
that one (with modifications) got included in goblin, that is one more 
that can be scratched from the list.

https://github.com/michaelmacinnis/oh

The bad stuff for Plan9 would be the external dependencies of libtecla 
and ncurses (still have not been able to get ncurses to work :( ), so 
there would have to be lots of modifications probably.

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Bence Fábián]

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

Some of these programs are just really thin wrappers around system calls.
I don't see how they would benefit from being rewritten in go.
Goblin was a fun way to learn go, not a project to be useful.

However i would be happy to see some new programs written in go.
For example we lack a picture manipulation program.
I'd like to see one done the plan 9 way. ie layers as image(6) files
and a bunch of small filter programs taht work on them (like crop
resample..)
And some interface holding this all together. (Maybe a graphics enabled
acme?)

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

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Alex-P. Natsios]

Hello again,

Wow i wrote this post a little while before falling asleep and
certainly didn't expect such a torrent of replies O.o

@ Aram Hăvărneanu :

Thanks for the interest! some of the tools you mentioned are already
implemented in Goblin, but i could always take a second look at them
see whether they need any "modernizing" tweak or be more golang/
idiomatic go like.

@Kurt, @Andrey It is hyped and tinkertoy like  kit but calling it java
like is too much :P

--
Regards,

Alex-P. Natsios
(a.k.a Drakevr)

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Aram Hăvărneanu]

> I don't see how they would benefit from being rewritten in go.

Go versions of base Plan 9 tools would be very useful to me for a
number of reasons. Unfortunately, none of them have to do anything
with Plan 9 (but then almost nothing posted on 9fans does) and
probably my reasons don't apply to many other people, but here they
are nevertheless.

Sometimes I need to deploy something written in rc(1) over a
heterogenous Linux cluster, and a statically compiled rc(1) would be a
blessing. I don't want to deal with deploying all plan9port/9base and
"modern" distributions make building plan9port statically very hard
and annoying. A Go version of rc(1) would also make it easier to be be
embedded in Go programs. I'd also want a static version of sam to run
on servers by copying it through ssh without having to install it
first.

I avoid the distribution craze as much as possible, I netboot nodes
with just a kernel and busybox in an initrd. I would love to have Plan
9 tools in that initrd instead of busybox. A static Go binary that
contains all the tools would be a blessing.

Now one can argue that building rc(1) and sam(1) statically can be
done, albeit it requires tinkering, embedding rc(1) in Go is not that
useful, and plan9port can be made into a single busybox-like binary
with some effort and you'd be right. It's not much work, but it's work
I have to do, and since it's only myself who is interested in what I
written above it would be me that would have to maintain all this
stuff. A Go version of the tools would be more interesting for many
people, so there would be more people who would use and maintain it
(including myself), and this version would support my use cases out of
the box without any effort.

--
Aram Hăvărneanu

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

> with Plan 9 (but then almost nothing posted on 9fans does) and

nominated for the the geekier-than-thou meme of the week.

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Kurt H Maier]

On Tue, Apr 30, 2013 at 11:31:48AM -0400, erik quanstrom wrote:
> > with Plan 9 (but then almost nothing posted on 9fans does) and
>
> nominated for the the geekier-than-thou meme of the week.
>
> - erik
>

I thought 9fans was a raspberry pi support list.

khm

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Bence Fábián]

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

I wasn't talking about rc(1). I was talking about echo, tee, cat, touch,
rm, sleep, etc..


2013/4/30 Aram Hăvărneanu <aram.h@mgk.ro>

>
> Sometimes I need to deploy something written in rc(1) over a
> heterogenous Linux cluster, and a statically compiled rc(1) would be a
> blessing.

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

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[tlaronde]

On Tue, Apr 30, 2013 at 05:26:50PM +0200, Aram H?v?rneanu wrote:
> > I don't see how they would benefit from being rewritten in go.
>
> Sometimes I need to deploy something written in rc(1) over a
> heterogenous Linux cluster,

This is in part Plan9 related. For kerTeX, simply because my compilation
framework was done this way, I use POSIX.2 utilities: sh(1) and make(1)
mainly. So, on Plan9, kerTeX compiles under APE.

But, despite POSIX being the one standard for systems, not everything is
really present everywhere, even on Unices (ed(1) is typically something
that is left out, while this is the only _line_ editor so the only
editor that should be here).

So I will have, to ensure that kerTeX runs everywhere, to provide some
core utilities. And I think I will switch from sh(1) (ksh or ash) to
rc(1) because rc(1) has regexp manipulations, and this is typically a
lot of what is done in the scripts (the a=$(echo $b | sed ...) is not
really efficient or beautiful).

So there may be a rc(1) base sys utilities set some day. (But if someone
does it before me, I will not be unhappy)

Because, using only C89 (or C99) is great. System(3) is standard C. But
the interpreter is neither guaranteed nor defined. If you have scripts
(and MetaPost has some for example; and kerTeX administration needs some
for the packages...)
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Steve Simon]

If anyone is interested I have (re)ported rc(1) to linux
together with the few tools that are unique to plan9: p(1)
mc(1) and ls(1).

ls may seem a strange choice but I access Linux over ssh
from plan9 and want to be able to do things like "ls ../port" and
get the files listed with the ../port/ path so I can plumb them.
My ls is based on the plan9 code and obeys its rules.

I have also ported rc(1) and a base set of command line tools to
win32. rc(1) builds standalone but some of the tools need libregexp
libbio and libstring which included

I attach to windows using a cpu(1) like command dos(1) which opens
an rc(1) shell on windows via an nt service - listen(1).

This allows me to use the cross compilers there I need for work.

Anyone wants any/all of this give me a shout.

-Steve

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Steve Simon]

I realise I have misrepresented this work, the Linux port of rc(1)
was Geoff Collyer's work, both the earlier port some years ago and
a recent update which makes the port work again. I provided a minor
patch or two.

There has been a win32.c in the labs distribution of rc(1) for years
but it has never (to my knowledge) worked.

I did a major overhall of the win32 port and back ports of a few
plan9 tools to posix (I know, I know), and packaged the whole thing up.

-Steve

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[suharik]

> rc in go
Also, some extensions could be useful:
* Inferno shell style local variables with := statement
* <> $file { ... } statement
* <>{ ... } statement, which returns both input and output pipes of command

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

> * Inferno shell style local variables with := statement
already have.  syntax is:
	var=val cmd
> * <> $file { ... } statement
already have.

> * <>{ ... } statement, which returns both input and output pipes of command

? pipes aren't first-class language elements.

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[suharik]

> syntax is: var=val cmd
Sure, foo=() bar=() baz=() { ... } works, but that's not very practical.
> ? pipes aren't first-class language elements.
Well, they are files:
    ; foo=>{cat} ; echo $foo
    /dev/fd/6
(linux)
I'm talking about something, that returns list with input and output
fd to a command.

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

On Tue Apr 30 18:50:42 EDT 2013, gleb.ax.sh@gmail.com wrote:
> > syntax is: var=val cmd
> Sure, foo=() bar=() baz=() { ... } works, but that's not very practical.

i don't see the practical issue.  the idiom described works fine.

not liking the syntax is not a good reason to introduce incompatable
ways of doing things.

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[suharik]

With := you can define locale variable where you need it.
That's like pascal style (where you define all variables before the
code) versus c style (where you define variables with code).
Not critical, but there is a practical issue.


2013/5/1 erik quanstrom <quanstro@labs.coraid.com>:
> On Tue Apr 30 18:50:42 EDT 2013, gleb.ax.sh@gmail.com wrote:
>> > syntax is: var=val cmd
>> Sure, foo=() bar=() baz=() { ... } works, but that's not very practical.
>
> i don't see the practical issue.  the idiom described works fine.
>
> not liking the syntax is not a good reason to introduce incompatable
> ways of doing things.
>
> - erik
>

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Brantley Coile]

Just a nit, but the Algol style of assignment, "becomes" if you will, didn't define the variable instance.  It was just an assignment.


sent from my ipad

On Apr 30, 2013, at 4:45 PM, "suharik" <gleb.ax.sh@gmail.com> wrote:

> With := you can define locale variable where you need it.
> That's like pascal style (where you define all variables before the
> code) versus c style (where you define variables with code).

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

On Tue Apr 30 19:45:29 EDT 2013, gleb.ax.sh@gmail.com wrote:
> With := you can define locale variable where you need it.
> That's like pascal style (where you define all variables before the
> code) versus c style (where you define variables with code).
> Not critical, but there is a practical issue.

rc uses a 1 pass compiler with limited backpatching.  it may be
difficult, or at least inelegant, to implement add-hoc variable
locals with the current compilation strategy.  especially in
the face of notes.

sure, you could implement the language a different way, but
rc is structurally so cool, it wouldn't feel like rc without the
virtual machine.  at least to me.

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Matthew Veety]

On Apr 30, 2013, at 20:56, erik quanstrom <quanstro@quanstro.net> wrote:

> On Tue Apr 30 19:45:29 EDT 2013, gleb.ax.sh@gmail.com wrote:
>> With := you can define locale variable where you need it.
>> That's like pascal style (where you define all variables before the
>> code) versus c style (where you define variables with code).
>> Not critical, but there is a practical issue.
> 
> rc uses a 1 pass compiler with limited backpatching.  it may be
> difficult, or at least inelegant, to implement add-hoc variable
> locals with the current compilation strategy.  especially in
> the face of notes.
> 
> sure, you could implement the language a different way, but
> rc is structurally so cool, it wouldn't feel like rc without the
> virtual machine.  at least to me.
> 
> - erik
> 

Why don't you just translate the C to Go. Plan 9 sources map pretty well to Go. 

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Yaroslav]

2013/5/1 Steve Simon <steve@quintile.net>:
> There has been a win32.c in the labs distribution of rc(1) for years
> but it has never (to my knowledge) worked.
>
> I did a major overhall of the win32 port and back ports of a few
> plan9 tools to posix (I know, I know), and packaged the whole thing up.

sounds like it deserves to become submitted as a patch.

--
- Yaroslav

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Paul Patience]

I don't know if you've seen this,
but there is also a plan9portport
to windows [1]. Not everything
works, but sam and rc do.

[1] https://bitbucket.org/knieriem/pf9

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[tlaronde]

On Tue, Apr 30, 2013 at 07:18:16PM +0100, Steve Simon wrote:
>[...]
> I have also ported rc(1) and a base set of command line tools to
> win32. rc(1) builds standalone but some of the tools need libregexp
> libbio and libstring which included
>

Well, I'm definitively interested since I'd like to have a defined
minimal set of tools (mainly text ones) plus rc(1) for compilation (for
creating Makefiles---whatever flavor, maybe mk(1) ones---using the
native or cross-compilers with my R.I.S.K. framework, that I started
to use for Plan9 or Unices like, but for Windows too for kerTeX)
and for providing the tools to have only rc(1) scripts for kerTeX
on whatever system (for the system(3) invocations---for MetaPost---or
for administrating the packages).

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

> The bad stuff for Plan9 would be the external dependencies of libtecla 
> and ncurses (still have not been able to get ncurses to work :( ), so 
> there would have to be lots of modifications probably.

if thine libraries offend thee, pluck them out....

command line editing is not necessary, and irrelevant
to our issue—scripts.

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Aram Hăvărneanu]

I'm happy to help any student attempting this.

--
Aram Hăvărneanu

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[andrey mirtchovski]

I wish the "goblin" project was used to re-imagine how the old plan9
commands may be done in a new language, rather than simply rewriting
the commands almost line-for-line while introducing errors. Take a
look at basename/main.go -- that functionality is already in package
"path", why bother? Or cmp/main.go, where we see:

flag.Bool("l", false, "do not print and character")

or

flag.Bool("s", false, "silent, do not print errors")

(the last one omits a very important detail: exit status is still set)

cat/main.go is just io.Copy too, no need to muck about with buffers. and so on.

this project needs a significant QA effort to bring it up to the
quality of both Plan9 programs and the Go stdlib.

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

On Mon Apr 29 15:54:08 EDT 2013, mirtchovski@gmail.com wrote:
> I wish the "goblin" project was used to re-imagine how the old plan9
> commands may be done in a new language, rather than simply rewriting
> the commands almost line-for-line while introducing errors. Take a
> look at basename/main.go -- that functionality is already in package
> "path", why bother? Or cmp/main.go, where we see:

do you envision a system with no shell at all?

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[andrey mirtchovski]

> do you envision a system with no shell at all?

I haven't thought about a system, but as I was going through a similar
exercise I decided that instead of copying the code I would put on my
go hat on and implement from scratch with whatever tools go gave me.
Freq for example uses the standard hashmap. Cmp, comm and uniq spawn
readers that concurrently gobble up the inputs while a state machine
implements the logic via select{} on channels. I can see those willing
to build a system out of this leveraging go's fast compilation and
distribute only a shell and compiler+linker, but I can't speak for
them.

Of course, the benefits of such a rewrite for the sake of
"re-imagination" are only marginal in most cases because the Plan 9
programs are very well thought-out high quality code. I just don't
want to see it blindly rewritten without any thought put into it. Or,
rather, don't want to do it myself :)

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Aram Hăvărneanu]

> this project needs a significant QA effort to bring it up to the
> quality of both Plan9 programs and the Go stdlib.

Absolutely. There's no point in doing this if the code is not idiomatic.

--
Aram Hăvărneanu

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

On Mon Apr 29 16:01:24 EDT 2013, aram.h@mgk.ro wrote:
> > this project needs a significant QA effort to bring it up to the
> > quality of both Plan9 programs and the Go stdlib.
>
> Absolutely. There's no point in doing this if the code is not idiomatic.

i'm not sure.  the specification of the commands should not
belie the implementation language.

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Kurt H Maier]

On Mon, Apr 29, 2013 at 01:52:32PM -0600, andrey mirtchovski wrote:
> I wish the "goblin" project was used to re-imagine how the old plan9
> commands may be done in a new language, rather than simply rewriting
> the commands almost line-for-line while introducing errors.

Most of the code in goblin was written when go was very new, before it
became a java-like library-based tinkertoy kit.

khm

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[andrey mirtchovski]

> Most of the code in goblin was written when go was very new, before it
> became a java-like library-based tinkertoy kit.

i know when it was written, i was there. go was already a java-like
library-based tinkertoy kit by then.

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[mortdeus]

Sure im always open to contributions. The only requirements for goblin are...

1. The plan9 command line api may not be changed. 

2. No import dependencies outside go's standard library except (http://godoc.org/github.com/guelfey/flag9) due to rule 1. (maybe termbox will be allowed if it simplifies the implementation greatly.)

3. All tools must be implemented as cross platform if possible. If we can emulate plan9 behavior in userland like inferno does then thats probably the way to go.

4. Most commands in goblin should be new implementations rather than C -> Go ports of the plan9 commands. Lucent PL is not GPL compatible and the goal is to not reintroduce code licensed under Lucent PL if it can be avoided. Some code like yacc has already been ported to Go from outside the goblin project and it doesnt make sense to replicate the effort in circumstances like this. Other than cases like this, I will reject code that appears to be directly derived of plan9's source.

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[mortdeus]

On Monday, April 29, 2013 1:47:41 PM UTC-5, "Alex-P. Natsios" wrote:
> Hello 9fans,
>
>
>
> I was looking at project ideas for this years GSoC (yes i know i am
>
> too damn late).
>
> I was wondering about the Goblin project and whether Mortdeus or
>
> someone else from the community would find it as a viable GSoC
>
> project.
>
>
>
> due to being this late i will register a proposal anyway though
>
> (including some info about me there) but it would be nice to have a
>
> discussion about it.
>
> .
>
> --
>
> Best Regards,
>
>
>
> Alex-P. Natsios
>
> (a.k.a Drakevr)

Sure anybody interested should open an issue on the github page
specifying which command they are interested in working on so we
dont have a bunch of people writing the same command.

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Alex-P. Natsios]

Hello,

I have uploaded my proposal and will also submit a poc/demo cmd tonight.
https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/drakevr/19001

comments most welcome and certainly appreciated.

PS. yes i know the timeline feels strange and on the last part near
unattainable but of course i am open to discuss and or change goals
depending on progress and demands.
--
Regards,

Alex-P. Natsios
(a.k.a Drakevr)

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[mortdeus]

On Wednesday, May 1, 2013 6:13:13 AM UTC-5, "Alex-P. Natsios" wrote:
> Hello,
> 
> 
> 
> I have uploaded my proposal and will also submit a poc/demo cmd tonight.
> 
> https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/drakevr/19001
> 
> 
> 
> comments most welcome and certainly appreciated.
> 
> 
> 
> PS. yes i know the timeline feels strange and on the last part near
> 
> unattainable but of course i am open to discuss and or change goals
> 
> depending on progress and demands.
> 
> --
> 
> Regards,
> 
> 
> 
> Alex-P. Natsios
> 
> (a.k.a Drakevr)
Some of the commands on your list are already completed. I marked them with a *.
  ascii
  *basename 
  cal
  *cat
  *cleanname
  *cmp
  *date
  du
  dd
  diff
  *echo
  ed
  fmt
  freq
  getflags
  grep
  join
  look
  *ls
  *mkdir
  *mtime
  pwd
  read
  sed
  seq
  *sleep
  sort
  split
  *strings
  tail
  *tee
  test
  *touch
  tr
  troff
  unicode
  uniq

Most of these commands are trivial to implement in Go due to the fact that the standard library already implements the functionality. The only reason why they havent been implemented yet is because I havent had time to work on them.

The commands I highly desire being worked on, some that can very possibly be developed over the summer, are awk, man, mosh (this will replace ssh1, ssh2 http://mosh.mit.edu/), plumb, mk, grep, sed, diff/idiff, lex, yacc (implement ability for yacc to output a parser for C instead of go.), ed, bc, acid/db, ndb, hoc, and rc.

Also some other commands that would be really neat to have is all the commands that interface with webapps. For example; tinyurl, thesaurus, weather, news, dict, would all be very cool plan9 commands to implement.

These are just my recommendations and any contribution to goblin will be greatly appreciated. Thanks for your interest.     

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

> 4.  Most commands in goblin should be new implementations rather than
> C -> Go ports of the plan9 commands.  Lucent PL is not GPL compatible
> and the goal is to not reintroduce code licensed under Lucent PL if it
> can be avoided.  Some code like yacc has already been ported to Go

can you explain why licensing under the gpl the goal?

i don't want to start a license war, but i have a practical
problem with the gpl.  it makes my life harder because if
i use it, then i have to justify it and prove i'm in compliance.

since i'd rather write code than compliance statements, go versions
of plan 9 commands would be less useful to me were they gpl'd.

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[andrey mirtchovski]

my apologies for the tasteless comment, but IMHO making goblin GPL'ed
will cause uriel to be spinning at a higher rate than desired.

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Devon H. O'Dell]

2013/5/1 andrey mirtchovski <mirtchovski@gmail.com>:
> my apologies for the tasteless comment, but IMHO making goblin GPL'ed
> will cause uriel to be spinning at a higher rate than desired.

Agree. But I think he means GPL compatible, not GPL. Goblin is MIT-licensed.

Also I think there are valid points in ensuring that goblin actually
preserves Plan 9 behavior. It is not clear that this is the case right
now.

I don't agree that all of these commands can be implemented over GSoC
by a single student. awk and troff are not small tasks, for instance.

--dho

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[erik quanstrom]

On Wed May  1 21:02:26 EDT 2013, devon.odell@gmail.com wrote:
> I don't agree that all of these commands can be implemented over GSoC
> by a single student. awk and troff are not small tasks, for instance.

ed and sed are not trivial either.  i think a fairly slavish first cut would
be fine.  i might be missing something, but i don't see the benefit of
gpl compatability.  the lucent license is open group certified.

- erik

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Lyndon Nerenberg]

On 2013-05-01, at 5:11 PM, andrey mirtchovski wrote:

> my apologies for the tasteless comment, but IMHO making goblin GPL'ed
> will cause uriel to be spinning at a higher rate than desired.

Has anyone determined the probable – let alone desirable! – uriel spin rate?  And can we determine a base spin rate against which we can derive a license-specific level of bogosity vs. a calibrated reference license (e.g. Lucent 1.02)?

--lyndon

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Matthew Veety]

> my apologies for the tasteless comment, but IMHO making goblin GPL'ed
> will cause uriel to be spinning at a higher rate than desired.
> 

There has been talk of using the free energy that Uriel can harness for power generation. Free software neck beards are more renewable than wind power, and uriel is more efficient than wind turbines.