I hope it won't seem rude to suggest it, but the go-nuts list is the
optimum place for your specific concerns. The Go authors read it and
are very conscientious in responding to serious questions.
The Go authors did express confidence that GC performance could
eventually be made competitive, alth
On Tue, Feb 01, 2011 at 11:06:33PM -0800, ron minnich wrote:
> Missionaries, at least
> according to the cartoons, sometimes are invited to dinner, and other
> times are invited to BE dinner. :-)
>
And they often are fatter than sacred cows :-)
++L
On Tue, 01 Feb 2011 23:06:33 PST ron minnich wrote:
>
> Just remember, Smiley, it's a good idea not to come across too much
> like a missionary bringing knowledge to the ignorant heathens -- which
> is certainly a bit of the tone of your notes. Missionaries, at least
> according to the cartoons,
Actually, I think we've talked quite enough at this point, perhaps
it's time to take a break and let's see some concrete work. Where's
the mkfile that broke your .h? What do your macros look like? What are
you going to do? I'll retire from the thread now.
Just remember, Smiley, it's a good idea no
And russ cox, and everyone else in the CONTRIBUTORS file.
On Feb 2, 2011 12:39 AM, "Scott Sullivan" wrote:
On Wed, 02 Feb 2011 05:14:54 +, smi...@zenzebra.mv.com wrote:
Can Libmo be compiled to native machine code?
There was some mention that, during the history of Plan 9, developers
had difficulty maintaining two different languages on the system. I
wonder how much of that difficulty would sti
On 02/02/2011 12:14 AM, smi...@zenzebra.mv.com wrote:
[...] though I would hesitate to use ANY code written by
Google without a thorough audit.
This is where I point out that GO isn't so much written by Google, as
more it's written by Rob Pike and Ken Thompson who now work at Google.
--
Scott
ron minnich writes:
> I think you should set your sights higher than the macro approach you
> propose. At least in my opinion it's a really ugly idea.
You might be surprised to hear that I agree. :) It's far from an ideal
solution. I am certainly open to alternatives!
> You could make a lasti
> I know the cp suicide is a problem in cp, because I designed the test
> case to exercise a buffer overflow I found at /sys/src/cmd/cp.c:77,93
>
> void
> copy(char *from, char *to, int todir)
> {
> Dir *dirb, dirt;
> char name[256];
> int fdf, fdt, mode;
>
> Two means, one end: don't lose that .h file!
>
I'm still waiting to see that crazy mkfile...
--
Federico G. Benavento
> > There's a reason it does not use that stuff, and it may not be what
> > you think.
>
> OK, come on already, quit teasing me! :) What's the secret reason?
when ron says this it's almost always a formula that means that it was
not done out of ignorance, stogginess, etc. as oo proponents tend t
On Tue, Feb 1, 2011 at 4:28 PM, wrote:
> ron minnich writes:
>
>> There's a reason it does not use that stuff, and it may not be what
>> you think.
>
> OK, come on already, quit teasing me! :) What's the secret reason?
I don't think it's a secret. There is a not very small group of people
who
ron minnich writes:
>>However, the Plan 9 code (at last that under /sys/src/cmd)
>> doesn't seem to make use of iterators, string objects (or even
>> object-orientation), modern string parsing routines, etc.
>
> There's a reason it does not use that stuff, and it may not be what
> you think.
OK,
> Instead of upgrading S-ATA interfaces, CPUs and RAM, I can plug more
> SOCs into my switch. I agree that this is not a very economic option
> yet, but it's an old, ongoing trend as I see it.
yes, people have been doing this with pcs (in 1u/2u/3u boxes)
for so long that all the parts are standard
> i can get as many nics or sata ports as i wish. i can plug as much memory in
> as i want.
Really? You can upgrade more easily, but there are still limits.
Instead of upgrading S-ATA interfaces, CPUs and RAM, I can plug more
SOCs into my switch. I agree that this is not a very economic option
Dyslexia and confirmation bias. Wikipedia says I have source amnesia.
I do remember reading about the thing, but only that.
However nice it may be, I can't justify buying yet another N900-parity SBC.
Nick
On 2/1/11, Ethan Grammatikidis wrote:
>
> On 27 Jan 2011, at 8:50 pm, Nick LaForge wrote
On Tue, Feb 1, 2011 at 10:33 AM, ron minnich wrote:
> p.s. If you're going to rewrite /bin, maybe it's time to look at Go?
I've written a few unix-style programs in Go:
http://code.google.com/p/mango-doc/
http://code.google.com/p/simple-shell-utils/
(neither are exactly examples of my best-foot
On Tue, Feb 1, 2011 at 11:52 AM, erik quanstrom wrote:
> On Tue Feb 1 12:32:34 EST 2011, stanley.lie...@gmail.com wrote:
>> in plan 9: using upas/fs, i mounted my gmail inbox over imap, then
>> started acme. at some point, the acme window disappeared. newly
>> received messages in my gmail inbo
On Tue, Feb 1, 2011 at 9:51 AM, wrote:
>However, the Plan 9 code (at last that under /sys/src/cmd)
> doesn't seem to make use of iterators, string objects (or even
> object-orientation), modern string parsing routines, etc.
There's a reason it does not use that stuff, and it may not be what you
ron minnich writes:
>> term% cp abc* abc* x
>> # watch the cp executable suicide
>> # now, make SURE there's nothing in this rio window that you want to keep...
>> term% rm abc*
>> # watch the rio window go bye bye!
>>
>
> it's not cp and it's not rio. I think you need to diagnose this a bit
> be
On Tue Feb 1 12:32:34 EST 2011, stanley.lie...@gmail.com wrote:
> in plan 9: using upas/fs, i mounted my gmail inbox over imap, then
> started acme. at some point, the acme window disappeared. newly
> received messages in my gmail inbox continue to get marked as read
> shortly after they arrive.
in plan 9: using upas/fs, i mounted my gmail inbox over imap, then
started acme. at some point, the acme window disappeared. newly
received messages in my gmail inbox continue to get marked as read
shortly after they arrive. my assumption is that upas/fs is still
accessing the mailbox. how can
On Feb 1, 2011 1:05 AM, wrote:
> Reading about Plan 9, I was quite excited to install it. I was quite
> excited when I first booted and ran it, too. But I distinctly felt my
> heart sink a little the first time it hung. Since then, I've browsed
> some of the OS source code and, having done that
On 27 Jan 2011, at 8:50 pm, Nick LaForge wrote:
I mean 'Pandaboard'.
On 1/27/11, Nick LaForge wrote:
A9 based SoCs do 1080p, and you can try one out by getting a
Pandoraboard.
heh, speaking of the pandora[1] has anyone looked at it with an eye
to getting plan 9 on it? It's pocket size
On Tue, Feb 1, 2011 at 8:45 AM, erik quanstrom wrote:
>> Is fossil not a file system if it doesn't maintain a disk cache
>> and only dumps to venti? Perhaps our disagreement would be
>> solved by saying that its not a disk file system. Don't you
>> oppress me we with narrow minded views of what
On 28 Jan 2011, at 1:36 pm, erik quanstrom wrote:
if you want to be a cynic, a non-pluggable architecture is super
for hardware companies. they can segment the heck out of
the market and get to the bad old says of charging big bucks
for little extra features. since there's no way to add them
On Tue, Feb 1, 2011 at 6:49 AM, erik quanstrom wrote:
>> least for me). Then I don't have to worry about whether I screwed up a
>> file system setup: that's what distributed repos are for.
>
> hg isn't a filesystem.
hg is not a lot of things. It is one thing, however, and the thing it
is is extre
> Is fossil not a file system if it doesn't maintain a disk cache
> and only dumps to venti? Perhaps our disagreement would be
> solved by saying that its not a disk file system. Don't you
> oppress me we with narrow minded views of what a file system
> is and isn't.
my "narrow views"? perhaps
On Tue, Feb 1, 2011 at 9:45 AM, erik quanstrom wrote:
> On Tue Feb 1 10:40:33 EST 2011, eri...@gmail.com wrote:
>> doesn't mean its not a file system -- nothing saying such things can't
>> be layered.
>
> hg itself is not a file system, and i would imagine if one
> layered hgfs on top, one would
>Then set up a repo on a free place like bitbucket.
or github. wasn't that in the news lately?
>The docs I've read seem to
>suggest that gcc is kind of "glued onto the side of" Plan 9 proper.
it's kind of unglued off the side of Plan 9 proper: gcc came unstuck
(in more ways than one).
i'm afraid it's harder to port (or do i mean compile?) than it ever was.
and then there's glibc, which you
Hi,
I'm a new kid on the block, I installed Plan9 on my TP A21e today. It
lacks a built-in network card so I use a PCMCIA card in it. The card
was not recognized by installer but quintile figured out (many
thanks!) that is based on NS8390 which is supported by Plan9. Can
somebody help me to make t
On Tue Feb 1 10:40:33 EST 2011, eri...@gmail.com wrote:
> doesn't mean its not a file system -- nothing saying such things can't
> be layered.
hg itself is not a file system, and i would imagine if one
layered hgfs on top, one would either need to manually
trigger "dumps", or one wouldn't want to
doesn't mean its not a file system -- nothing saying such things can't
be layered.
On Tue, Feb 1, 2011 at 9:18 AM, erik quanstrom wrote:
> On Tue Feb 1 10:01:54 EST 2011, eri...@gmail.com wrote:
>> http://www.ueber.net/code/r/hgfs ?
>>
>> I'm sure its not the only one
>
> but it is quite dis
On Tue Feb 1 10:01:54 EST 2011, eri...@gmail.com wrote:
> http://www.ueber.net/code/r/hgfs ?
>
> I'm sure its not the only one
but it is quite distinct in concept from a cwfs no?
- erik
http://www.ueber.net/code/r/hgfs ?
I'm sure its not the only one
On Tue, Feb 1, 2011 at 8:49 AM, erik quanstrom wrote:
>> least for me). Then I don't have to worry about whether I screwed up a
>> file system setup: that's what distributed repos are for.
>
> hg isn't a filesystem.
>
> - erik
> least for me). Then I don't have to worry about whether I screwed up a
> file system setup: that's what distributed repos are for.
hg isn't a filesystem.
- erik
> term% mkdir trashdir && cd trashdir && mkdir x
> term% touch `{i=0; while (test $i -lt 128) { echo -n abcdefghijklmnop;
> i=`{echo $i+1|hoc} } }
> term% cp abc* abc* x
> # watch the cp executable suicide
> # now, make SURE there's nothing in this rio window that you want to keep...
> term% rm ab
> Some, yes. But most not. At least not yet. :) I expect I might run
> into trouble figuring out how to pass around strings containing NUL
> bytes, though.
why would you do that? what's the application? if you tell me
sed'ing an object file, i'm going to remain unconvinced. if you
tell me su
lotte% 9fs sources
lotte% diff /sys/src/cmd/rc/plan9.c /n/sources/plan9/sys/src/cmd/rc/plan9.c
446d445
< char *s;
468,474c467
<
< s = dir[f].dbuf[dir[f].i].name;
< if(strlen(s) >= NDIR){
< pfmt(err, "rc: file name too long: %s\n", s);
< return 0;
<
Somehow a particular problem with a particular application
has degenerated into a rather unfair generalization of the
whole system:
> Reading about Plan 9, I was quite excited to install it. I was quite
> excited when I first booted and ran it, too. But I distinctly felt my
> heart sink a little
> term% mkdir trashdir && cd trashdir && mkdir x
> term% touch `{i=0; while (test $i -lt 128) { echo -n abcdefghijklmnop;
> i=`{echo $i+1|hoc} } }
> term% cp abc* abc* x
> # watch the cp executable suicide
> # now, make SURE there's nothing in this rio window that you want to keep...
> term% rm ab
42 matches
Mail list logo
