Re: [9fans] 9vx on mountain lion
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 problems are: (a) cursor shape keeps same as that of Mac (b) initial back ground color is white. that should be dark grey. both are bearable for me. thanks for all. Kenji Arisawa On 2013/02/18, at 10:04, Jeff Sickel j...@corpus-callosum.com wrote: It's the long ago announced (over five years ago) and finally enacted removal of Carbon APIs that are biting you. At some point someone can pull in the changes from darwin-cocoa or recent p9p devdraw/cocoa-screen.m to get 9vx to build and run on OSX 10.8+. -jas On Feb 17, 2013, at 5:09 PM, Benjamin Huntsman bhunts...@mail2.cu-portland.edu wrote: Nice... I was just getting that same error a few days ago when I tried to build it too. I chalked it up to some earlier posts that said something along the lines of use a binary from Snow Leopard... and didn't want to ask around to see if it's been fixed. Glad to see I'm not alone... -Ben
Re: [9fans] install failing to detect SATA disk
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 quans...@quanstro.netwrote: Back to the Plan 9 install issue on native h/w.. does Plan 9 support SATA controllers? My VBox VM also needed the HDD to be on the IDE controller. it does support ahci controllers. vbox causes problems for a lot of oses, and that's probablly a bigger project. i'm going to guess this is a power management issue. the ahci driver was written before the standard, and thus has been a little slow in catching up. could you try downloading 9atom, which is quite close to the distribution (http://ftp.quanstro.net/other/9atom.iso.bz2)? it has a few power management wiggles that may fix your issue. - erik
[9fans] Do plan9 users know/use acme?
And if so have they analysed WHY they like it? How mature [not too problematic for a plan9 beginner] is the rPi installation? ==TIA
Re: [9fans] 9vx on mountain lion
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
Re: [9fans] Do plan9 users know/use acme?
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, avoid9...@gmail.com 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
Re: [9fans] Do plan9 users know/use acme?
a simple web search, or the wiki, has more than enough. On 18 February 2013 20:59, avoid9...@gmail.com 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
Re: [9fans] 9vx on mountain lion
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 problem anyway. -- David du Colombier
Re: [9fans] 9vx on mountain lion
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 don't seem to be much of a priority. It would be nice if the (partial) fixes for OS-X were to find their way into the repository, though. ++L
Re: [9fans] c compiler bug
On Sat, Feb 16, 2013 at 9:38 PM, erik quanstrom quans...@quanstro.netwrote: 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 the code) 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. -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Re: [9fans] c compiler bug
On 18 February 2013 13:02, Comeau At9Fans comeauat9f...@gmail.com 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 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 scope). The behaviour is undefined in ANSI C if two declarations that refer to the same object or function do not have compatible types (normally, you're protected by another rule that you can't have incompatible declarations *in the same scope*). ANSI C does, however, forbid the inner static declaration (which surprised me) The declaration of an identifier for a function that has block scope shall have no explicit storage-class specifier other than extern. (6.7.1)
Re: [9fans] c compiler bug
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 scope). since nested functions are not allowed, applying nested scope seems a bit odd. anyway, ... if the declaration were in the same place but the referenced function were in another file, the -T would have prevented the link. my question is, why doesn't the c compiler internally apply the same rule? - erik
[9fans] two questions about go in Plan 9
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 proc does not report EOF to the other end of the connection. It might be something I made or something I didn't understand, but just in case these are known I thought I might ask here. thanks
Re: [9fans] c compiler bug
On 18 February 2013 15:02, erik quanstrom quans...@quanstro.net wrote: since nested functions are not allowed, applying nested scope seems a bit odd. Nevertheless, that is what it is.
Re: [9fans] two questions about go in Plan 9
Yeah I get those too. There are also some process spawning issues and UTF issues in http. -- Veety
Re: [9fans] two questions about go in Plan 9
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 be able to interrupt it. Now, in go on Plan 9, I can't interrupt it and I can't make the stream hangup. What do you do in that case? Or, more likely, what am I doing wrong? thanks On Feb 18, 2013, at 4:07 PM, n...@lsub.org wrote: 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 proc does not report EOF to the other end of the connection. It might be something I made or something I didn't understand, but just in case these are known I thought I might ask here. thanks [/mail/box/nemo/msgs/201302/876]
Re: [9fans] install failing to detect SATA disk
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. Having some issues booting (rootfs is being mounted ro). Once I fix this I'll check if the 9atom installation is broken because it might be assuming it has some space in the next partition. I'll let you know how it goes. On Mon, Feb 18, 2013 at 3:07 AM, Peter A. Cejchan tyap...@gmail.com wrote: 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 quans...@quanstro.netwrote: Back to the Plan 9 install issue on native h/w.. does Plan 9 support SATA controllers? My VBox VM also needed the HDD to be on the IDE controller. it does support ahci controllers. vbox causes problems for a lot of oses, and that's probablly a bigger project. i'm going to guess this is a power management issue. the ahci driver was written before the standard, and thus has been a little slow in catching up. could you try downloading 9atom, which is quite close to the distribution (http://ftp.quanstro.net/other/9atom.iso.bz2)? it has a few power management wiggles that may fix your issue. - erik
Re: [9fans] install failing to detect SATA disk
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
Re: [9fans] 9vx on mountain lion
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 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 don't seem to be much of a priority. It would be nice if the (partial) fixes for OS-X were to find their way into the repository, though. ++L
Re: [9fans] two questions about go in Plan 9
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
Re: [9fans] two questions about go in Plan 9
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're trying to signal in-band, which is only a short cut. Would it be expensive to put the signalling out of band? ++L [/mail/box/nemo/msgs/201302/889]
Re: [9fans] two questions about go in Plan 9
network connections on plan9 can be hanged up by writing hangup into the corresponding ctl file. -- cinap
Re: [9fans] two questions about go in Plan 9
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]
Re: [9fans] two questions about go in Plan 9
That's how I do it usually. On Feb 18, 2013, at 13:12, Francisco J Ballesteros n...@lsub.org 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 corresponding ctl file. -- cinap [/mail/box/nemo/msgs/201302/897]
Re: [9fans] going too far?
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 package source directories., so I'm guessing it's also going through and cleaning the dependencies of the target. open(/etc/ld.so.cache, O_RDONLY) = 3 open(/lib/x86_64-linux-gnu/libpthread.so.0, O_RDONLY) = 3 open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY) = 3 open(/proc/stat, O_RDONLY|O_CLOEXEC) = 3 Process 3345 attached (waiting for parent) Process 3345 resumed (parent 3344 ready) [pid 3344] open(/proc/sys/net/core/somaxconn, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/home/john/mygo/src/github.com/floren/ellipsoid, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/home/john/mygo/src/github.com/floren/ellipsoid/ellipsoid.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/home/john/mygo/src/github.com/floren/ellipsoid/ellipsoid_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/doc.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/export_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/fmt_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/format.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/print.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/scan.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/scan_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/stringer_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/errors, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/errors/errors.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/errors/errors_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/errors/example_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/alg.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/append_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/arch_amd64.h, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/asm_amd64.s, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/atomic_amd64.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/cgocall.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/cgocall.h, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/chan.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/chan_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/closure_amd64.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/closure_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/compiler.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/complex.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/cpuprof.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/debug.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/defs1_linux.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/defs2_linux.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/defs_arm_linux.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/defs_linux.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/defs_linux_amd64.h, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/error.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/export_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/extern.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/float.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/gc_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/hashmap.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/hashmap.h, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/iface.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/lock_futex.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/lock_sema.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/malloc.h, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/malloc1.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/mallocrand.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/mallocrep.go,
Re: [9fans] two questions about go in Plan 9
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 ideas are welcome in this phase. We can try to export a Hangup() function for Plan 9 for the Conn type (or for individual implementations of the type). On 18 February 2013 10:12, Francisco J Ballesteros n...@lsub.org 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 corresponding ctl file. -- cinap [/mail/box/nemo/msgs/201302/897]
Re: [9fans] two questions about go in Plan 9
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 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 ideas are welcome in this phase. We can try to export a Hangup() function for Plan 9 for the Conn type (or for individual implementations of the type). On 18 February 2013 10:12, Francisco J Ballesteros n...@lsub.org 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 corresponding ctl file. -- cinap [/mail/box/nemo/msgs/201302/897] [/mail/box/nemo/msgs/201302/902]
Re: [9fans] two questions about go in Plan 9
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.Close should write hangup to ctl and SetLinger could easily be implemented (it returns EPLAN9 on the Go version I'm using -- tip from a few days ago). -Skip On Mon, Feb 18, 2013 at 11:04 AM, Nemo n...@lsub.org wrote: 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 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 ideas are welcome in this phase. We can try to export a Hangup() function for Plan 9 for the Conn type (or for individual implementations of the type). On 18 February 2013 10:12, Francisco J Ballesteros n...@lsub.org 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 corresponding ctl file. -- cinap [/mail/box/nemo/msgs/201302/897] [/mail/box/nemo/msgs/201302/902]
Re: [9fans] 9vx on mountain lion
Hello, I have tried. it seems the drawterm binary works OK. Kenji Arisawa On 2013/02/19, at 1:22, Jeff Sickel j...@corpus-callosum.com 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. -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 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 don't seem to be much of a priority. It would be nice if the (partial) fixes for OS-X were to find their way into the repository, though. ++L
Re: [9fans] going too far?
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 by doing echo 3 /proc/sys/vm/drop_caches on linux, for example). on plan9 the situation is different due to 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. On Mon, Feb 18, 2013 at 11:41 AM, John Floren j...@jfloren.net wrote: 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 package source directories., so I'm guessing it's also going through and cleaning the dependencies of the target. open(/etc/ld.so.cache, O_RDONLY) = 3 open(/lib/x86_64-linux-gnu/libpthread.so.0, O_RDONLY) = 3 open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY) = 3 open(/proc/stat, O_RDONLY|O_CLOEXEC) = 3 Process 3345 attached (waiting for parent) Process 3345 resumed (parent 3344 ready) [pid 3344] open(/proc/sys/net/core/somaxconn, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/home/john/mygo/src/github.com/floren/ellipsoid, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/home/john/mygo/src/github.com/floren/ellipsoid/ellipsoid.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/home/john/mygo/src/github.com/floren/ellipsoid/ellipsoid_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/doc.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/export_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/fmt_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/format.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/print.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/scan.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/scan_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/fmt/stringer_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/errors, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/errors/errors.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/errors/errors_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/errors/example_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/alg.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/append_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/arch_amd64.h, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/asm_amd64.s, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/atomic_amd64.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/cgocall.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/cgocall.h, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/chan.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/chan_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/closure_amd64.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/closure_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/compiler.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/complex.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/cpuprof.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/debug.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/defs1_linux.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/defs2_linux.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/defs_arm_linux.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/defs_linux.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/defs_linux_amd64.h, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/error.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/export_test.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/extern.go, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/float.c, O_RDONLY|O_CLOEXEC) = 3 [pid 3344] open(/usr/local/go/src/pkg/runtime/gc_test.go,
Re: [9fans] going too far?
the go tool necessarily needs to read all source files for all packages sorry, not all source files, just the 'import' section.
Re: [9fans] going too far?
On 19 February 2013 01:36, Charles Forsyth charles.fors...@gmail.comwrote:
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 gather the package dependencies for ellipsoid.
Re: [9fans] going too far?
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 because the original executed 7 separate 'go
clean' commands, each one of which does all the work to resolve import
dependencies. the results would've been different if 'mk clean'
executed 'go clean ./...' instead of a separate go clean for each
subdir.
here's a more representative example that deals with a single package
(archive/tar) inside the go standard lib. the go tool did _not_ build
anything in this case, it still had to look at everything to resolve
all the necessary deps before deciding that nothing had to be built:
http://pastie.org/6220084
Re: [9fans] going too far?
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
Re: [9fans] going too far?
On 18 February 2013 19:23, andrey mirtchovski mirtchov...@gmail.com 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, the kernel does cache (/sys/src/9/port/cache.c), but not as
much as needed for that example.
Streaming probably isn't interesting if you're anyway caching, unless the
files are huge.
The directory structure and metadata also matters. With floren's simpler
example, I got a 0.30 elapsed time when I tried it:
subito% time go clean github.com/floren/ellipsoid
0.03u 0.01s 0.30r go clean github.com/floren/ellipsoid
With a caching system in the way (fscfs), the first time, the time goes up
from that:
subito% time go clean github.com/floren/ellipsoid
0.02u 0.04s 0.44r go clean github.com/floren/ellipsoid
subito% cat /n/cached/cfsctl
Client Server
#calls Δ ms/callΔ #calls Δ ms/callΔ
1 1 0.670 0.670 1 1 0.660 0.660 Tversion
1 1 0.365 0.365 1 1 0.343 0.343 Tauth
1 1 0.495 0.495 1 1 0.484 0.484 Tattach
433 433 0.188 0.188 352 352 0.219 0.219 Twalk
333 333 0.223 0.223 332 332 0.115 0.115 Topen
359 359 0.202 0.202 359 359 0.189 0.189 Tread
3 3 0.242 0.242 3 3 0.236 0.236 Twrite
427 427 0.009 0.009 0 0 Tclunk
93 93 0.122 0.122 93 93 0.116 0.116 Tstat
36 36 ndirread
323 323 ndelegateread
0 0 ninsert
0 0 ndelete
0 0 nupdate
833411 833411 bytesread
113 113 byteswritten
777224 777224 bytesfromserver
56187 56187 bytesfromdirs
0 0 bytesfromcache
777050 777050 bytestocache
The cache doesn't save any reading, because there is no redundancy, but it
cuts
the number of walk requests (because it's caching directory structure and
there is
overlap there).
The next time
subito% time go clean github.com/floren/ellipsoid
0.01u 0.01s 0.25r go clean github.com/floren/ellipsoid
It has cut the calls through to the server dramatically, at the risk
of getting out-of-date information, which could be a nuisance on a shared
project.
(Linux vfs doesn't have to worry about that because it's all local, and
dangerous anyway.)
The only opens and reads that do go through are for directory contents,
because fscfs doesn't cache them (I didn't need that on Blue Gene).
subito% cat /n/cached/cfsctl
Client Server
#calls Δ ms/callΔ #calls Δ ms/callΔ
1 0 0.670 1 0 0.660 Tversion
1 0 0.365 1 0 0.343 Tauth
1 0 0.495 1 0 0.484 Tattach
864 431 0.098 0.007 352 0 0.219 Twalk
666 333 0.119 0.016 349 17 0.115 0.112 Topen
717 358 0.153 0.105 603 244 0.172 0.147 Tread
3 0 0.242 3 0 0.236 Twrite
854 427 0.008 0.008 0 0 Tclunk
186 93 0.122 0.122 186 93 0.116 0.116 Tstat
72 36 ndirread
531 208 ndelegateread
0 0 ninsert
0 0 ndelete
0 0 nupdate
148 833237 bytesread
113 0 byteswritten
777224 0 bytesfromserver
112374 56187 bytesfromdirs
777050 777050 bytesfromcache
777050 0 bytestocache
This is with IL/IP which is ever-so-slightly faster than TCP/IP (I tried
them both), because there's less overhead,
especially on the reads (that get through).
I don't think streaming will help you, really; the main difference is not
fetching it at all,
and only if you're working with the same contents a lot;
and you need to cache directory contents and other metadata, with all that
entails.
The iostats wasn't particularly strange for that one, so I wonder if
there's something about nemo's example
that gets {go clean ...} wandering through all the src/cmd stuff so often.
Re: [9fans] going too far?
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
Re: [9fans] going too far?
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.lax01.mailroute.net (Postfix) with ESMTP id DE4D63C2510 for 9fans@9fans.net; Tue, 19 Feb 2013 02:28:03 + (GMT) - erik
Re: [9fans] going too far?
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 usual discussion about 9p replacements is they tend to start with a false, or not quite true premise. - erik
