2013/5/1 Steve Simon :
> 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 d
> 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
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
On Wed May 1 21:02:26 EDT 2013, devon.od...@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 mig
2013/5/1 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.
Agree. But I think he means GPL compatible, not GPL. Goblin is MIT-licensed.
Also I think there are valid points in ensuring that
my apologies for the tasteless comment, but IMHO making goblin GPL'ed
will cause uriel to be spinning at a higher rate than desired.
> 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 expl
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
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
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 fi
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 simplif
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
On Apr 30, 2013, at 20:56, erik quanstrom wrote:
> On Tue Apr 30 19:45:29 EDT 2013, gleb.ax...@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
On Tue Apr 30 19:45:29 EDT 2013, gleb.ax...@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 issu
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" wrote:
> With := you can define locale variable where you need it.
> That's like pascal style (where
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 :
> On Tue Apr 30 18:50:42 EDT 2013, gle
On Tue Apr 30 18:50:42 EDT 2013, gleb.ax...@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
> 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 com
> * 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
> 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
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 ne
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
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/ pat
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 compilat
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
>
> 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.
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
> 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 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 ma
> 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
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 whet
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 mani
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 mo
> 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.
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
> 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 hash
On Mon Apr 29 16:01:24 EDT 2013, ara...@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 com
> 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
On Mon Apr 29 15:54:08 EDT 2013, mirtchov...@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
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 cm
>> 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
> 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
Aram Hăvărneanu 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 te
> These are too large:
>
> acme
> awk
> mk
> rc
> sam
or, extra credit. :-)
- erik
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
u
I'm happy to help any student attempting this.
--
Aram Hăvărneanu
On Mon Apr 29 14:55:16 EDT 2013, apnats...@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
Silly me, didn't include a link!
https://github.com/mortdeus/goblin
--
Regards,
Alex-P. Natsios
(a.k.a Drakevr)
47 matches
Mail list logo
