Hello,
I am just curious...
Here
http://9fans.net/archive/2007/11/120
Russ Cox writes he uses bash as his default shell. Does anybody know
the reason? Is this for practicality within the linux environment? Or
has he found rc too limiting?
Ruda
because he uses a mac.
On Tuesday 28 of August 2012 10:57:06 Rudolf Sykora wrote:
> Hello,
>
> I am just curious...
> Here
> http://9fans.net/archive/2007/11/120
>
> Russ Cox writes he uses bash as his default shell. Does anybody know
> the reason? Is this for practicality within the linux environment? Or
> has he foun
On 28 August 2012 11:52, dexen deVries wrote:
> FWIW, i'm using bash as the interactive shell too, in `konsole' terminal
> emulator, because of bash' interactive line edition and command history. 9term
> doesn't fit me.
The thing is that he, according to the reference, switches off
the line editi
> FWIW, i'm using bash as the interactive shell too, in `konsole' terminal
> emulator, because of bash' interactive line edition and command history.
> 9term
> doesn't fit me.
>
> all scripting -- both standalone and in mkfiles -- goes in rc, thou.
Russ uses bash because it is uniformly crap
On 28 August 2012 15:07, Lucio De Re wrote:
> Russ uses bash because it is uniformly crappy across all architectures
> he has an interest in. There's a similar conversation going on in the
> go-nuts user group on google. It is illuminating.
I have been unable to locate the conversation...
Anywa
> Anyway, I do not understand how uniform crappiness can be advantageous...
The issue raised on Go-Nuts is that Bash shouldn't be used for
installing Go, /bin/sh should be used instead. The response is that
Bash is the most uniformly implemented of the /bin/sh's out there and
that none of the oth
On Tue, Aug 28, 2012 at 04:10:39PM +0200, Lucio De Re wrote:
> > Anyway, I do not understand how uniform crappiness can be advantageous...
>
> The issue raised on Go-Nuts is that Bash shouldn't be used for
> installing Go, /bin/sh should be used instead. The response is that
> Bash is the most un
> The issue raised on Go-Nuts is that Bash shouldn't be used for
> installing Go, /bin/sh should be used instead. The response is that
> Bash is the most uniformly implemented of the /bin/sh's out there and
> that none of the other shells (generally referred to as /bin/sh) can
> be relied upon not
On Tuesday 28 of August 2012 16:10:39 Lucio De Re wrote:
> > Anyway, I do not understand how uniform crappiness can be advantageous...
>
> The issue raised on Go-Nuts is that Bash shouldn't be used for
> installing Go, /bin/sh should be used instead. The response is that
> Bash is the most unifor
env bash - posix 2.0
https://groups.google.com/forum/#!topic/golang-nuts/aC7Qr1qtZ2I
> ypical Go shit there. If the scripts are so complicated that it's a
> pain in the ass to find a way to run them, fix the stupid scripts.
They did, by building the "go" command.
Do you think you can provide any guarantees that the subset of /bin/sh
features common to all current instances of /b
> i don't know. but the problem isn't the consistency of rc. byron's
> rc doesn't count. that's like saying the bourne shell is not consistent
> because of bash.
But I am saying that, and I believe that is what motivates the Go Team
to continue using Bash. They know that Bash works. They also
On Tue, Aug 28, 2012 at 04:52:34PM +0200, Lucio De Re wrote:
>
> Or are you oriented towards kiloLOCs of test code to see which
> features are implemented and provide compatability a la autoconf?
>
Excellent example of a false dilemma. I'm oriented towards exerting the
effort to make something
On Tue, Aug 28, 2012 at 2:27 PM, Rudolf Sykora wrote:
> Hello,
Howdy.
> I am just curious...
> Here
> http://9fans.net/archive/2007/11/120
>
> Russ Cox writes he uses bash as his default shell. Does anybody know
> the reason? Is this for practicality within the linux environment? Or
> has he fou
On Tue, Aug 28, 2012 at 8:35 PM, Kurt H Maier wrote:
> On Tue, Aug 28, 2012 at 04:52:34PM +0200, Lucio De Re wrote:
>> Or are you oriented towards kiloLOCs of test code to see which
>> features are implemented and provide compatability a la autoconf?
>
> Excellent example of a false dilemma. I'm
> And rc is not perfect. I've always felt like the 'if not' stuff was a kludge.
no, it's certainly not. (i wouldn't call if not a kludge—just ugly. the
haahr/rakitzis es' if makes more sense, even if it's wierder.)
but the real question with rc is, what would you fix?
i can only think of a fe
> On Tue, Aug 28, 2012 at 04:52:34PM +0200, Lucio De Re wrote:
>>
>> Or are you oriented towards kiloLOCs of test code to see which
>> features are implemented and provide compatability a la autoconf?
>>
>
> Excellent example of a false dilemma. I'm oriented towards exerting the
> effort to mak
On Tue, Aug 28, 2012 at 08:48:39PM +0530, Dan Cross wrote:
>
> Wonderful! Please point me to your new programming language so I can
> have a look?
>
I don't think it would do you any good, since you are apparently unable
to differentiate between programming languages and build systems.
>
> So
> perhaps (let's hope) someone else has better ideas.
The Inferno shell was (is) slick!
++L
On Tue Aug 28 11:33:06 EDT 2012, lu...@proxima.alt.za wrote:
> > perhaps (let's hope) someone else has better ideas.
>
> The Inferno shell was (is) slick!
and iirc, the slickness depends on limbo.
- erik
On Tue, Aug 28, 2012 at 05:36:58PM +0200, Lucio De Re wrote:
>
> Sure, feel free to make something that isn't shitty, there's plenty
> out there that can be improved. The machinery to install Go (from
> sources) is hardly the most important amongst them.
>
The Go team has already explicitly stat
> > Solution: replace
> > the #!/bin/sh with #!/usr/bin/env -c /bin/bash. Why not?
>
> Because there are plenty of systems out there without env or bash.
so what's the reason for this argument on 9fans? is it that it makes
building go on plan 9 harder?
- erik
On Tue, Aug 28, 2012 at 9:00 PM, Kurt H Maier wrote:
> On Tue, Aug 28, 2012 at 08:48:39PM +0530, Dan Cross wrote:
>> Wonderful! Please point me to your new programming language so I can
>> have a look?
>
> I don't think it would do you any good, since you are apparently unable
> to differentiate
On Tue, Aug 28, 2012 at 11:41:05AM -0400, erik quanstrom wrote:
>
> so what's the reason for this argument on 9fans? is it that it makes
> building go on plan 9 harder?
>
I think it started out with rc users defending their purity of essence.
I'm just an Unattached Lensman with the Galactic Bul
>> Solution: replace
>> the #!/bin/sh with #!/usr/bin/env -c /bin/bash. Why not?
>
> Because there are plenty of systems out there without env or bash.
Worth a try, though! There is very little shell code left in the Go
release. Maybe I'll give it a try on my pristine NetBSD machine.
But note
great, it's becoming a pissing contest.
On Tue, Aug 28, 2012 at 04:52:34PM +0200, Lucio De Re wrote:
>
> Do you think you can provide any guarantees that the subset of /bin/sh
> features common to all current instances of /bin/sh is adequate to
> build a moderately demanding open source package?
>
Yes. This is what is done by the R.I.
> Yes. This is what is done by the R.I.S.K. framework used for building
> KerGIS and kerTeX.
I'm pretty sure that R.I.S.K has more than 2,250 lines of code. That's
the LOC count of \.(ba)?sh$ stuff in the Go tree. Also, nobody seemed
to mention that Go also ships with rc files to build on Plan 9..
> against 9, not nix. Did you remove those system deprecated system
> calls when you removed support for printing them?
i think we're in noisy agreement, and that's probablly my fault.
sorry.
i'd removed the _X syscalls about 3 months ago from both nix
and plan 9 since they really seem useless at
On Tue, Aug 28, 2012 at 09:15:35PM +0530, Dan Cross wrote:
>
> Oh no, I can't. Please, by all means, point me to whatever it is that
> you have produced that demonstrates your prowess in this area so that
> I can learn more.
you sound upset
>
> Irrelevant.
>
The topic at hand is not irreleva
On Tue, Aug 28, 2012 at 06:05:04PM +0200, Lucio De Re wrote:
>
> But note that even if it does work, it is still not possible for the
> Go Team to release the scripts as /bin/sh scripts because, as you have
> clearly not yet grasped, not all /bin/sh instances out there can be
> shown to be compati
> My only actual statement is that a better
> solution would be de-shitting the build process so that it doesn't
> require such a precise set of software to operate.
Does that translate into being able to supply an example of such a
"de-shitting" process the Go Team could and should have followed?
On Tue, Aug 28, 2012 at 08:19:52PM +0200, Lucio De Re wrote:
>
> Does that translate into being able to supply an example of such a
> "de-shitting" process the Go Team could and should have followed? An
> irresistible paragon of building prowess? Something even the autoconf
> people would be tem
On Tue, Aug 28, 2012 at 11:13 PM, Kurt H Maier wrote:
> On Tue, Aug 28, 2012 at 09:15:35PM +0530, Dan Cross wrote:
>> Oh no, I can't. Please, by all means, point me to whatever it is that
>> you have produced that demonstrates your prowess in this area so that
>> I can learn more.
>
> you sound u
On Tuesday 28 of August 2012 11:26:19 erik quanstrom wrote:
> > And rc is not perfect. I've always felt like the 'if not' stuff was a
> > kludge.
> no, it's certainly not. (i wouldn't call if not a kludge—just ugly. the
> haahr/rakitzis es' if makes more sense, even if it's wierder.)
>
> but th
On Tue, Aug 28, 2012 at 11:50:27PM +0530, Dan Cross wrote:
>
> You are conflating bootstrapping the language with the language's
> build system. The go command is actually quite nice.
>
Also, the go command is useless unless the bootstrap build system can
construct it. I'm not conflating anyth
One last thing:
On Tue, Aug 28, 2012 at 11:56 PM, Kurt H Maier wrote:
> On Tue, Aug 28, 2012 at 11:50:27PM +0530, Dan Cross wrote:
>> You are conflating bootstrapping the language with the language's
>> build system. The go command is actually quite nice.
>
> Also, the go command is useless unle
>
> switch/case would make helluva difference over nested if/if not, if
> defaulted to fall-through.
maybe you have an example? because i don't see that. if not works
fine, and can be nested. case without fallthrough is also generally
what i want. if not, i can make the common stuff a functio
On Tuesday 28 of August 2012 14:44:40 erik quanstrom wrote:
> (...)
> > variable scoping (better than subshel) would help writing larger
> > scripts, but that's not necessarily an improvement ;-) something
> > similar to LISP's `let' special form, for dynamic binding.
>
> there is variable scoping
On Tue, Aug 28, 2012 at 9:18 AM, erik quanstrom wrote:
> i'd removed the _X syscalls about 3 months ago from both nix
> and plan 9 since they really seem useless at this point (especially
> in nix) and therefore i removed it from the tracing.
definitely makes sense if the calls are gone not to p
On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom wrote:
>> And rc is not perfect. I've always felt like the 'if not' stuff was a
>> kludge.
>
> no, it's certainly not. (i wouldn't call if not a kludge—just ugly.
Kludge perhaps in the sense that it seems to be to work around an
issue with the gr
On Tue, 28 Aug 2012 14:44:40 EDT erik quanstrom wrote:
> >=20
> > switch/case would make helluva difference over nested if/if not, if
> > defaulted to fall-through.
>
> maybe you have an example? because i don't see that. if not works
> fine, and can be nested. case without fallthrough is als
> But something that may be interesting would
> be the ability to allow the stream of computations to branch; instead
> of pipelines being just a list, make them a tree, or even some kind of
> dag (if one allows for the possibility of recombining streams).
Rc has this. It's great. See section 10 o
On Tue, Aug 28, 2012 at 5:30 PM, Kurt H Maier wrote:
> On Tue, Aug 28, 2012 at 08:48:39PM +0530, Dan Cross wrote:
>
>> So are you saying that because they use bash to build the system, the
>> language is shitty? Or just the build system is shitty?
>>
>
> I have other issues with Go as a language,
> Well, if you could explain a) how it's currently broken, and b) how a
> 'corrected' version would be useful, others might be more sympathetic
> to your concerns. From most perspectives, it doesn't appear broken at
> all; it works fine, it's just not what you would have done.
Speak for yourself,
[Since the previous one did not reach the list (?), I send it once more]
On Tue, Aug 28, 2012 at 07:12:15PM +0300, Aram H?v?rneanu wrote:
> > Yes. This is what is done by the R.I.S.K. framework used for building
> > KerGIS and kerTeX.
>
> I'm pretty sure that R.I.S.K has more than 2,250 lines of
On Tue, Aug 28, 2012 at 5:35 PM, Kurt H Maier wrote:
> On Tue, Aug 28, 2012 at 05:36:58PM +0200, Lucio De Re wrote:
>>
>> Sure, feel free to make something that isn't shitty, there's plenty
>> out there that can be improved. The machinery to install Go (from
>> sources) is hardly the most importa
On Aug 29, 2012 2:14 AM, "Jeremy Jackins" wrote:
> > Well, if you could explain a) how it's currently broken, and b) how a
> > 'corrected' version would be useful, others might be more sympathetic
> > to your concerns. From most perspectives, it doesn't appear broken at
> > all; it works fine, it
On Wed, Aug 29, 2012 at 12:09:13AM +0530, Dan Cross wrote:
> Well, if you could explain a) how it's currently broken, and b) how a
> 'corrected' version would be useful, others might be more sympathetic
> to your concerns. From most perspectives, it doesn't appear broken at
> all; it works fine, i
On Wed, 29 Aug 2012 01:11:26 +0530 Dan Cross wrote:
> On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom wro=
>
> > perhaps (let's hope) someone else has better ideas.
>
> Well, something off the top of my head: Unix pipelines are sort of
> like chains of coroutines. And they work great for defi
> > the haahr/rakitzis es' if makes more sense, even if it's wierder.)
>
> Agreed; es would be an interesting starting point for a new shell.
es is great input. there are really cool ideas there, but it does
seem like a lesson learned to me, rather than a starting point.
> I think in order to r
On Tue, 28 Aug 2012 16:34:10 EDT erik quanstrom wrote:
> my knee-jerk reaction to my own question is that making it easier
> and more natural to parallelize dataflow. a pipeline is just a really
> low-level way to talk about it. the standard
> grep x *.[ch]
> forces all the *.[ch] to be g
On Tue, Aug 28, 2012 at 07:12:15PM +0300, Aram H?v?rneanu wrote:
> > Yes. This is what is done by the R.I.S.K. framework used for building
> > KerGIS and kerTeX.
>
> I'm pretty sure that R.I.S.K has more than 2,250 lines of code. That's
> the LOC count of \.(ba)?sh$ stuff in the Go tree. Also, nob
this machine works now in mp mode (after 4 years) with
9front's acpi implementation.
http://9fans.net/archive/2008/02/671
--
cinap
I'll say it again: if a syscall is supported, it should be possible to
trace it. If you remove a system call from Plan 9, then by all means
remove the syscallfmt support, of course. But if a system call is
still valid, and can be called, deprecated or not, I don't see the
point of not being able to
Hello,
On 2012/08/29, at 4:34, dexen deVries wrote:
> now i see i can do:
>
> x=1 y=2 z=3
>
> ...and only `z' retains its new value in the external scope, while `x' and
> `y'
> are limited in scope.
No.
ar% a=1 b=2 c=3; echo $a $b $c
1 2 3
ar% a=() b=() c=()
ar% a=1 b=2 {c=3}; echo $a $b $c
On Tuesday, August 28, 2012, wrote:
> this machine works now in mp mode (after 4 years) with
> 9front's acpi implementation.
>
> http://9fans.net/archive/2008/02/671
>
> --
> cinap
>
>
Nice!
On Tue Aug 28 19:03:05 EDT 2012, cinap_len...@gmx.de wrote:
> this machine works now in mp mode (after 4 years) with
> 9front's acpi implementation.
>
> http://9fans.net/archive/2008/02/671
if there is one, can you dump the table and send it to me?
i'm just curious how it is messed up. and also
> On Tue, 28 Aug 2012 16:34:10 EDT erik quanstrom
> wrote:
> > my knee-jerk reaction to my own question is that making it easier
> > and more natural to parallelize dataflow. a pipeline is just a really
> > low-level way to talk about it. the standard
> > grep x *.[ch]
> > forces all the *
> The feature I want is the ability to pass not just character
> values in environment or pipes but arbitrary Scheme objects.
> But that requires changes at the OS level (or mapping them
> to/from strings, which is a waste if both sides can handle
> structured objects).
!? the ability to pass typ
> var:[^ctl-a]*
> | ([^ctl-a]*) ctl-a list
sorry. s/list/var/
- erik
9fans,
I dusted off rdbfs(4) today to dig into a kernel issue and ended up
running into what looks like the same issue bwc reported back in 2005:
barstow% import cons /mnt/consoles
barstow% rdbfs -d -t /386/9pccpu /mnt/consoles/target
attach /mnt/consoles/target
barstow% acid -k 1 /386/9pccpu
/38
On Tue, 28 Aug 2012 21:39:06 EDT erik quanstrom wrote:
> > The feature I want is the ability to pass not just character
> > values in environment or pipes but arbitrary Scheme objects.
> > But that requires changes at the OS level (or mapping them
> > to/from strings, which is a waste if both sid
> On Tue, 28 Aug 2012 21:39:06 EDT erik quanstrom
> wrote:
> > > The feature I want is the ability to pass not just character
> > > values in environment or pipes but arbitrary Scheme objects.
> > > But that requires changes at the OS level (or mapping them
> > > to/from strings, which is a wast
On Tue, 28 Aug 2012 22:23:20 EDT erik quanstrom wrote:
> > On Tue, 28 Aug 2012 21:39:06 EDT erik quanstrom wr
> ote:
> > > > The feature I want is the ability to pass not just character
> > > > values in environment or pipes but arbitrary Scheme objects.
> > > > But that requires changes at the
aback.com has ns.buydomains.com as nameserver, which seem to
announce itself to be responsible for the whole .com tld and
answers positively to everything with bullshit spam ip addresses
causing all further .com domain queries to get resolved by that
spam ns.buydomains.com dns. :(
is this allowed
On Tue Aug 28 23:33:20 EDT 2012, cinap_len...@gmx.de wrote:
> aback.com has ns.buydomains.com as nameserver, which seem to
> announce itself to be responsible for the whole .com tld and
> answers positively to everything with bullshit spam ip addresses
> causing all further .com domain queries to g
> > > > > The feature I want is the ability to pass not just character
> > > > > values in environment or pipes but arbitrary Scheme objects.
> > > > > But that requires changes at the OS level (or mapping them
> > > > > to/from strings, which is a waste if both sides can handle
> > > > > structure
is that machine 20 years old yet?
On 29 August 2012 11:26, erik quanstrom wrote:
> On Tue Aug 28 19:03:05 EDT 2012, cinap_len...@gmx.de wrote:
>> this machine works now in mp mode (after 4 years) with
>> 9front's acpi implementation.
>>
>> http://9fans.net/archive/2008/02/671
>
> if there is one,
not the core machine, but probably its graphics card.
it has no graphics onboard so i put an old s3 pci
card in :)
http://9hal.ath.cx/usr/cinap_lenrek/dbl/DSCN1641.JPG
i gave the machine to someone to sell it after giving
up getting plan9 interrupts in mp mode to work and got
an amd sempron machi
72 matches
Mail list logo
