On Mon Feb 18 22:10:05 EST 2013, mirtchov...@gmail.com wrote:
> > there's 32-bits of tag space. why *can't* 9p do multiple outstanding?
>
> i wrote it in py9p. it worked fine when we tested it between sandia
> and calgary couple of years ago. we promptly forgot about it :)
my problem with the us
that's about 90 minute delay. odd. here are the interesting headers;
it seems internal to 9fans.net
Received: from gw17.lax01.mailroute.net ([199.89.0.117])
[...]
Tue, 19 Feb 2013 03:55:18 + (GMT)
Received: from ladd.quanstro.net (ladd.quanstro.net [69.55.170.73])
by gw17.lax
> i did not receive this message (gmail to blame?), but based on this
i am subscribed twice, and 9fans sometimes never
sends a message to a particular address. there's no
pattern that i've seen
- erik
On 18 February 2013 19:23, andrey mirtchovski wrote:
> sorry, not all source files, just the 'import' section.
In nemo's example, it seemed to have wandered off into go/src/cmd, reading
4k from everything there each time, which began to add up,
if I've read the iostats correctly.
As to caching
> both 9p's nature and the lack of caching. i was hoping that one of the
> new protocols coming up that do streaming and outstanding requests and
> caching could help with this.
there's 32-bits of tag space. why *can't* 9p do multiple outstanding?
- erik
>> I wonder if there's something about nemo's example
>> that gets {go clean ...} wandering through all the src/cmd stuff so often.
i did not receive this message (gmail to blame?), but based on this
snippet I can reply that you're seeing each file referenced at least 7
times in iostats' output be
On 19 February 2013 01:36, Charles Forsyth wrote:
> I wonder if there's something about nemo's example
> that gets {go clean ...} wandering through all the src/cmd stuff so often.
>
One difference is that I had floren's code outside the go tree, although it
would still need to
enter that to gathe
> the go tool necessarily needs to read all source files for all
> packages
sorry, not all source files, just the 'import' section.
the go tool necessarily needs to read all source files for all
packages in the program's include tree to build a list of what may be
outdated and needs to be recompiled. linux/osx vfs caching makes this
a relatively painless operation (although it's still expensive if you
flush the caches manually
Hello,
I have tried.
it seems the drawterm binary works OK.
Kenji Arisawa
On 2013/02/19, at 1:22, Jeff Sickel wrote:
> Take a look at the changes in
>
> https://bitbucket.org/jas/drawterm-cocoa
>
> A bit different from the p9p side, but does handle the cursor
> changes et al.
>
> -ja
i think linux and windows both distinguish between allowing io to
complete or not via shutdown() and close() respectively (close causes
a RST instead of FIN).
if my understanding is correct, then: netFD.CloseRead and CloseWrite
for Plan 9 will work by just closing the ctl and data fd's;
netFD.Clo
yes. that was the problem.
perhaps exporting hangup would be
fine.
or perhaps a close in a tcp stream
should also interrupt the reader in
plan9, if any.
thanks
On Feb 18, 2013, at 7:58 PM, aku...@mail.nanosouffle.net wrote:
> In order to deal with Conn types, you're supposed to just
> use t
In order to deal with Conn types, you're supposed to just
use the interface's functions. Unfortunately, Conn's
Close() simply closes the associated fd. I think in general,
this is fine. For the Listener, a Close() will do the hangup.
I'm updating the net package implementation for Plan 9,
so new i
"go clean" does the same thing on Linux under strace, reading the
headers from all the .go files of each package's dependencies. I have
included the strace output of "strace -e open -f go clean
github.com/floren/ellipsoid" below.
The help for the command says "Clean removes object files from packa
That's how I do it usually.
On Feb 18, 2013, at 13:12, Francisco J Ballesteros wrote:
> I know, but, what's the std way to do that in go in plan 9?
>
> On Feb 18, 2013, at 7:07 PM, cinap_len...@gmx.de wrote:
>
>> network connections on plan9 can be hanged up by writing "hangup" into
>> the co
I know, but, what's the std way to do that in go in plan 9?
On Feb 18, 2013, at 7:07 PM, cinap_len...@gmx.de wrote:
> network connections on plan9 can be hanged up by writing "hangup" into
> the corresponding ctl file.
>
> --
> cinap
>
> [/mail/box/nemo/msgs/201302/897]
network connections on plan9 can be hanged up by writing "hangup" into
the corresponding ctl file.
--
cinap
not really. in some cases a server I
have wants to close the con to a
client and there's a reader proc.
I would like to hang up even if the
client doesn't.
On Feb 18, 2013, at 5:54 PM, lu...@proxima.alt.za wrote:
>> What do you do in that case? Or, more likely, what am I doing wrong?
>
> You'
> What do you do in that case? Or, more likely, what am I doing wrong?
You're trying to signal in-band, which is only a short cut. Would it
be expensive to put the signalling out of band?
++L
Take a look at the changes in
https://bitbucket.org/jas/drawterm-cocoa
A bit different from the p9p side, but does handle the cursor
changes et al.
-jas
On Feb 18, 2013, at 6:51 AM, lu...@proxima.alt.za wrote:
>> Yiyus' and Ron's repositories have the same content.
>>
>> The current v
> Good news:
> 9atom successfully detected the SATA drive, the unpartitioned space in it
> and used it for the installation.
that is good news. it's a lot easier to fix the other stuff once
the machine is booting. :-)
- erik
Good news:
9atom successfully detected the SATA drive, the unpartitioned space in it
and used it for the installation.
Bad news:
It ended up corrupting my Linux root partition which was after the
unpartitioned space. Fortunately I had a back of the root partition and I
could quickly recover it. Ha
Forgive me,
Somehow I removed the -v from the call to go test. That makes the log print
only for failed tests.
Regarding TCP, forsyth reminded me that it's what I'd get with the std. Plan 9
system calls, which
is so.
I guess my question is… how can I interrupt a reader in that case? In C I'd
Yeah I get those too. There are also some process spawning issues and UTF
issues in http.
--
Veety
On 18 February 2013 15:02, erik quanstrom wrote:
> since nested functions are not allowed, applying nested scope seems
> a bit odd.
>
Nevertheless, that is what it is.
Hi,
I've been using go for a few things in Plan 9, and noticed a couple of things.
I'd just like to know if it's me or if this also happens to others:
- diagnostics issued by log.Print et al. don't show up unless I call log.Fail
- closing a tcp connection which is still open by a nearby reader pr
> No, the compiler is simply applying scope rules. Without that inner
> declaration explicitly overriding the outer declaration--whether
> static or extern is used-- it will not compile (eg, if you put "static
> void fn(Outer*);" or "extern void fn(Outer*);" and remove static from
> fn in the file
On 18 February 2013 13:02, Comeau At9Fans wrote:
> seems to be doing is setting up allowing the call to compile and once that
> is satisfied then the subsequent definition "has" to match it, as perhaps a
> way to do type punning.
No, the compiler is simply applying scope rules. Without that inn
On Sat, Feb 16, 2013 at 9:38 PM, erik quanstrom wrote:
> i don't think this should link, since wrongaddr calls
> fn with an Outer* not an Inner*.
> ...
Normally in more mainstream C the nested "static void fn(Outer*);"
declaration would produce a diagnostic and instead what it (the compiler
and
> Yiyus' and Ron's repositories have the same content.
>
> The current vx32 repository (based on Ron's) is:
>
> https://bitbucket.org/0intro/vx32
That's three, I guess there's strength in numbers :-)
> It doesn't fix the reported problem anyway.
And I'm still praying for the Go fixes, but they
> I understood that the consolidated repository was
>
> https://bitbucket.org/yiyus/vx32
>
> Am I missing something?
Yiyus' and Ron's repositories have the same content.
The current vx32 repository (based on Ron's) is:
https://bitbucket.org/0intro/vx32
It doesn't fix the reported proble
a simple web search, or the wiki, has more than enough.
On 18 February 2013 20:59, wrote:
> And if so have they analysed WHY they like it?
>
> How mature [not too problematic for a plan9 beginner] is the rPi
> installation?
>
> ==TIA
>
>
http://research.swtch.com/acme
http://bendyworks.com/geekville/lab_projects/2012/11/getting-plan-9-running-on-the-raspberry-pi
HTH,
++pac
On Mon, Feb 18, 2013 at 10:59 AM, wrote:
> And if so have they analysed WHY they like it?
>
> How mature [not too problematic for a plan9 beginner] is the rP
> Try to compile from https://bitbucket.org/rminnich/vx32
I understood that the consolidated repository was
https://bitbucket.org/yiyus/vx32
Am I missing something?
++L
And if so have they analysed WHY they like it?
How mature [not too problematic for a plan9 beginner] is the rPi
installation?
==TIA
Yes, I can recommend Erik' s 9atom, too, it solved my problems with
installation onto a SATA-II HD some time ago...
Regards,
++pac
On Sat, Feb 16, 2013 at 4:11 PM, erik quanstrom wrote:
> > Back to the Plan 9 install issue on native h/w.. does Plan 9 support SATA
> > controllers? My VBox VM also
Hello,
Thanks for the information.
it was bothersome to apply cocoa-screen.m in p9p to screen.c in vx32.
The problem comes from the function setcursor() in screen.c.
so, for the temporally, I made the function dummy.
it seems the compiled 9vx is stable without serious problems.
remaining problem
37 matches
Mail list logo
