Ok, thanks.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T3dbd3cda56f638ee-M16e29431130bbf818b28
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
> Last thing about your rpi image Richard, Is this the
> one used in the go arm builders? Can I asume that
> these are the only patches needed to have a working go?
>
Yes, and yes.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T3dbd3cd
Hi,
I believe Multicast works. There are some basic tests at
https://golang.org/src/net/udpsock_plan9_test.go. It should work on all
three architectures.
I don't know of any ports list. In general everything should work unless
it's doing something non-portable. I recently played around with go-gi
See https://www.flexense.com/usb3_vs_sata_disk_performance_comparison.html
Here local SATA3 vs USB3 comparison is done. While not directly comparable,
the only case where throughput is below what you can push through GbE is
single threaded small file copying. For every other case tested, GbE will
b
yeah, but check small blocksize random read/write vs. AoE or 9p over
ethernet. I'm not sure how efficient usb3 in terms of latency :)
On 9/21/19, Bakul Shah wrote:
> On Fri, 20 Sep 2019 09:53:07 +0100 Richard Miller <9f...@hamnavoe.com>
> wrote:
>>
>> > Another option worth exploring may
>> > be
On Fri, 20 Sep 2019 09:53:07 +0100 Richard Miller <9f...@hamnavoe.com> wrote:
>
> > Another option worth exploring may
> > be AOE as pi4 has a GbE (I haven't tried this yet).
>
> My go test builders are running with "local" fossil on a slice
> of disk provided over AoE from an atom server. I tried
hi,
thanks richard, this is perfect
i could not have asked for more.
-Steve
On 20 Sep 2019, at 9:43 am, Richard Miller <9f...@hamnavoe.com> wrote:
>> Only lightly tested.
>
> In a sense, plan9/arm go is tested as well as any other platform:
> under the go continuous development process, ev
> If you mean the go compiler itself, hopefully the 2GB VM you
> get on 9p/pi4 is enough to compile the compiler using a
> cross-compiled bootstrap compiler.
The compiler can compile itself natively on a pi2 or pi3.
No need to activate swap space, unless you want to run the
full test suite.
> Ano
> Only lightly tested.
In a sense, plan9/arm go is tested as well as any other platform:
under the go continuous development process, every time a change
is made to the compiler or runtime library, a complete test suite
is run on builder machines for every supported architecture and
operating syst
On Fri, 20 Sep 2019 06:29:31 +0100 Steve Simon wrote:
>
> my plan was to build and run/debug go on a raspberry pi 4 running plan9, not
> to cross compile.
If you mean go programs, the compile speed is tolerable
provided you are not building very large programs.
If you mean the go compiler itsel
Go builds on Plan9 suffer from the post-1.9 performance regression.
> On Sep 19, 2019, at 10:29 PM, Steve Simon wrote:
>
> hi,
>
> my plan was to build and run/debug go on a raspberry pi 4 running plan9, not
> to cross compile.
>
> i am confident in the linux cross compile environment i was j
hi,
my plan was to build and run/debug go on a raspberry pi 4 running plan9, not to
cross compile.
i am confident in the linux cross compile environment i was just concerned
about the plan9 os/runtime support for the pi.
i guess it comes down to plan9 os interface for the arm.
people said it
Matthew Veety writes:
> Building anything on a raspberry pi is a bit of a chore. I highly=20
> recommend running go on your cpu server and/or local to your filesystem.=20
> The generated binaries seem to work fine.
Go does wonderfully when it comes to generating binaries for
non-native architectu
Building anything on a raspberry pi is a bit of a chore. I highly
recommend running go on your cpu server and/or local to your filesystem.
The generated binaries seem to work fine. I haven't found any bugs, but I
haven't run anything serious on on my pis.
On Thu, 19 Sep 2019, Michael Misch w
I’ve used it, it works fine. Building on a raspberry pi, on the other hand is a
chore when using Go.
> On Sep 19, 2019, at 3:46 PM, Bakul Shah wrote:
>
> On Thu, 19 Sep 2019 22:41:48 +0100 Steve Simon wrote:
>>
>> does go run under plan9 on the radpberry pi or only on x86?
>
> I haven't trie
On Thu, 19 Sep 2019 22:41:48 +0100 Steve Simon wrote:
>
> does go run under plan9 on the radpberry pi or only on x86?
I haven't tried a native build but cross-compiling with
cd `go env GOROOT`/src
GOOS=plan9 GOARCH=arm ./bootstrap.bash
seems to work. bunzip2 the resulting .tbz file in $
Some Go binary packages for plan9/386, plan9/amd64
and plan9/arm are available here:
http://9legacy.org/download.html
--
David du Colombier
Nevermind, the problems went away after recompiling 1.9.2 from source a
second time, something must have went wrong with my initial bootstrap..
On Dec 20, 2017 19:29, "Dave MacFarlane" wrote:
What's the latest version of Go on amd64 that anyone's used successfully?
I just reinstalled 9front aft
; go version
go version 1.7beta1 plan9/amd64
On Wed, Dec 20, 2017, 16:32 Dave MacFarlane wrote:
> What's the latest version of Go on amd64 that anyone's used successfully?
>
> I just reinstalled 9front after putting in a new SSD on my laptop and
> I'm getting panics about errors lowering to SSA
>
> There are some binaries available here if you want to use them to
> bootstrap:
>
> http://www.9legacy.org/download.html
Already done and working fine. ;)
Thank you.
Pavel
There are some binaries available here if you want to use them to bootstrap:
http://www.9legacy.org/download.html
Chris
On Oct 11, 2017, at 6:13 AM, Richard Miller <9f...@hamnavoe.com> wrote:
>> I am trying to compile Go 1.4.3 on my Raspberry Pi following David's
>> instructions on https://gith
>
> I believe that route to bootstrapping go from scratch on Plan 9
> will work only for 386.
>
I see.
> On arm, you can either cross-compile go1.4 on another go platform
> (eg plan9/386, plan9port on linux/386, or linux/arm), or start with
> a pre-compiled plan9/arm package (there are several t
> I am trying to compile Go 1.4.3 on my Raspberry Pi following David's
> instructions on https://github.com/golang/go/wiki/Plan9.
I believe that route to bootstrapping go from scratch on Plan 9
will work only for 386.
On arm, you can either cross-compile go1.4 on another go platform
(eg plan9/386
I use GOROOT=$home/go to keep up with tip. after bootstrapping, rebuild
the standard packages and commands:
% GOBIN=$home/bin/386 $home/go/bin/go install -a std cmd
and
% GOARCH=arm go install -a std cmd
then in my profile:
% test -d $home/go/bin/plan9_^$cputype && bind
-a $home/go/bin/plan9_
> Still, how much swap are we talking about?
On a 1GB system, the default test suite swaps in only a handful of places.
It's possible to limit the concurrency enough to cut out swapping, but
then it takes longer because there's less opportunity to overlap cpu-bound
tests with file I/O and paging-i
> If you want to get to the satisfying ALL TESTS PASSED message at the end
> of the go install+test process, you will need a swap file, even on a
> 1GB raspberry pi. Trust me.
Sounds like a challenge, but I never quite wanted to know whether Plan
9 swap is or isn't broken. Still, how much swap a
> That's insane. Really.
The designer(s) of the test suite had bigger systems in mind,
so there's lots of stuff running concurrently.
On 13 April 2016 at 15:42, Charles Forsyth
wrote:
> On 13 April 2016 at 15:39, Richard Miller <9f...@hamnavoe.com> wrote:
>
>> If you want to get to the satisfying ALL TESTS PASSED message at the end
>> of the go install+test process, you will need a swap file,
>>
>
> That's insane. Really.
Mor
On 13 April 2016 at 15:39, Richard Miller <9f...@hamnavoe.com> wrote:
> If you want to get to the satisfying ALL TESTS PASSED message at the end
> of the go install+test process, you will need a swap file,
>
That's insane. Really.
> It won't need a swap file unless the program forces all that to be
> allocated, which it shouldn't,
If you want to get to the satisfying ALL TESTS PASSED message at the end
of the go install+test process, you will need a swap file, even on a
1GB raspberry pi. Trust me.
I tried that at some point. Got pi2 booting with one core, crashed with
multiple, but then again, I'm new to having to be that intimate with assembly
and kernel mode.
I'd suggest trying from scratch to port things, but there are a few 9front
differences that make it much more than just a diff.
On 13 April 2016 at 14:08, Chris McGee wrote:
> I believe that my rpi only has the 512MB of RAM so I’ll add swap.
It should be enough to increase the available virtual space by changing
that #define.
It won't need a swap file unless the program forces all that to be
allocated, which it shouldn'
Ah, that makes sense. It’s virtual memory and not the physical memory.
Do you think that your changes to the bcm will make it to 9front? If not, any
chance I could have the diffs so that I can try merging them in there myself?
Thanks,
Chris
> I didn’t realize that Go was so virtual memory hungry. I wonder why stats
> didn’t show me a large peak of memory consumption before the go compiler died?
stats -m shows physical memory usage. Every go program starts by allocating
a huge block of virtual space for its garbage-collected allocat
Thanks Richard for doing the go port to plan9/arm. I was going to start on that
myself until I found out it was already done. :-)
I didn’t realize that Go was so virtual memory hungry. I wonder why stats
didn’t show me a large peak of memory consumption before the go compiler died?
Perhaps it a
> I tried a bootstrapped version on my RPi but it fails with a "fork/exec ...
> virtual memory allocation failed” error when I try to compile anything.
Go needs a lot of virtual memory - it won't even pass the installation test
suite
if you give it less than a gigabyte. That was the reason for
> I tried a bootstrapped version on my RPi but it fails with a "fork/exec ...
> virtual memory allocation failed” error when I try to compile anything.
Go needs a lot of virtual memory - it won't even pass the installation test
suite
if you give it less than a gigabyte. That was the reason for
> Skip, isn't the point here that being able to run go binaries
> in Plan 9 on an arm machine is news to most Plan 9 users?
Go seems a little outside the scope of a Plan 9 release and I think it
would take a greater interest by the community to bring it in. I seem
to recall that Quanstro's 9atom
> I tried a bootstrapped version on my RPi but it fails with a
> "fork/exec ... virtual memory allocation failed” error when I try to
> compile anything. According to stats I have plenty of memory left
> when it runs. I’m not sure what to make of it. Any idea if the port
> is complete or if the
> Next to try on Plan 9: build a linux/s390x binary and find a machine to run
> it on :)
I have certainly done that with linux/386 under Plan 9. It works like
a charm, even if the compilation is a lot slower than doing it
natively on the target machine (which I could eventually install Go
on).
L
I see now that there is plan9/arm in tip (1.7), but not 1.6.
I tried a bootstrapped version on my RPi but it fails with a "fork/exec ...
virtual memory allocation failed” error when I try to compile anything.
According to stats I have plenty of memory left when it runs. I’m not sure what
to mak
I think Richards' CL's were submitted to main Go repo before Go 1.6 and are
now in 1.7 dev branch (tip). I believe I first saw the announcement on
godev list. as a Go user, it is a good way of keeping up with the
fast-paced development; e.g. IBM's linux/s390x port went in today!
I usually keep one
Skip, isn't the point here that being able to run go binaries
in Plan 9 on an arm machine is news to most Plan 9 users?
Perhaps even news to those who regularly use go on Plan 9.
sl
Thanks,
I'll give it a shot.
I noticed that there are some assembly files in golang for plan9/386 and no
equivalent for plan9/arm so I assumed that it wouldn't work with that
combination.
Chris
> On Apr 12, 2016, at 5:26 PM, Skip Tavakkolian
> wrote:
>
> i've not built Go under plan9/arm.
i've not built Go under plan9/arm. however, in practice (in a real Plan 9
environment) this is not an issue. the way authentication and namespaces
(including file server) work in a Plan 9 envrionment, it is natural to use
the fastest cpu available to (cross) compile apps. typical sessions are
like
I've managed to get Go running on an RPi2 using a similar method, but:
1. You need to make sure you're using go-tip. <= 1.6 doesn't have Plan9/arm
support.
2. I had to apply this patch that Richard Miller sent me to my kernel:
term% diff /n/sources/contrib/miller/9/bcm/mem.h /sys/src/9/bcm/mem.h
Hi Skip,
Have you managed to get Go running on an RPi this way?
Cheers,
Chris
>
> If you run Plan 9 in a VM, emulator or a confined device (RPi), it will be
> easier/faster to cross compile your app and copy it over. E.g. to compile for
> 9Pi:
> $ GOOS=plan9 GOARCH=arm go build
>
>
Yes, this works and is the easier of the two methods. Using a desktop OS
and starting no Go compilers:
1. download the Go 1.6 binaries for your desktop OS and install them; set
GOROOT_BOOTSTRAP to that directory (e.g. /usr/local/go)
2. copy the Go 1.6 sources (either the tar.gz or git clone of s
Hi All,
A while back there was a thread about getting newer versions of Go running on
plan9. In particular there was a panic related to a floating point error.
In case anyone is interested I have managed to get the newest version of Go
working on plan9/386 within virtualbox despite having a sim
> On 23 Feb 2016, at 18:31, lu...@proxima.alt.za wrote:
>
>> A proper duffcopy/duffzero/memmove is also an option.
>
> The adjective "proper" is revealing. I vote for that.
>
> Lucio.
>
>
It’s a bit out of my usual area of expertise, however. I have no idea what
benchmark they have been ru
> A proper duffcopy/duffzero/memmove is also an option.
The adjective "proper" is revealing. I vote for that.
Lucio.
A proper duffcopy/duffzero/memmove is also an option.
Best regards,
Kenny Levinsen
> On 23. feb. 2016, at 18.02, erik quanstrom wrote:
>
>> On Tue Feb 23 07:55:26 PST 2016, kennylevin...@gmail.com wrote:
>> A benchmark was supposedly made of the new duffcopy/duffzero which claimed
>> significa
On Tue Feb 23 07:55:26 PST 2016, kennylevin...@gmail.com wrote:
> A benchmark was supposedly made of the new duffcopy/duffzero which claimed
> significant speedup for larger copies:
> https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da
>
> I have no clue whether this hol
A benchmark was supposedly made of the new duffcopy/duffzero which claimed
significant speedup for larger copies:
https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da
I have no clue whether this holds true or not. My intention to reenable
duffcopy and continue to use duf
On Tue Feb 23 02:36:41 PST 2016, kennylevin...@gmail.com wrote:
> Ah, no - it is not a system-wide adjustment, but adjustment of the plan9
> specific runtime.sighandler implementation and everything called by it
> directly. Notes that don't exit the process are queued and should run outside
> th
Ah, no - it is not a system-wide adjustment, but adjustment of the plan9
specific runtime.sighandler implementation and everything called by it
directly. Notes that don't exit the process are queued and should run outside
the actual note handler.
I think the "magic" code will be isolated, and m
Well, avoiding XMM registers in duffcopy/duffzero is one solution, but I was
thinking of working around them entirely in code called from the note handler,
so that duffcopy/duffzero can operate as intended on plan9, rather than
littering the compiler with OS conditionals.
It puts some restricti
On 27 January 2016 at 01:40, Sean Caron wrote:
> update process running:
>
> replica/pull -v /dist/replica/network
>
Beware that the introduction of the nsec system call can cause trouble if
replica updates commands before you're running the new kernel.
> Yeah, thank goodness for snapshots :O Running replica/pull didn't turn out
> so good for my current running system. It looks like it might make the most
> sense to just archive my home directory and reload a fresh VM ...
>
> Where are they keeping the most current installation ISO these days? I'm
> Where are they keeping the most current installation ISO these days? I'm
> just not sure of what's canonical now that the old bell-labs.com domain is
> offline.
David is in charge of legacy Plan 9 outside of Bell Labs. His instructions were
pretty explicit, but if you run into trouble I'll be h
Yeah, thank goodness for snapshots :O Running replica/pull didn't turn out
so good for my current running system. It looks like it might make the most
sense to just archive my home directory and reload a fresh VM ...
Where are they keeping the most current installation ISO these days? I'm
just not
Sean,
David's (0intro) instructions are the right way to do it. If I recall
correctly, if you want to update by rebuilding from updated sources,
there's a careful dance that needs to happen for the transition from old
Rune size to the new. Geoff sent out a note to 9fans outlining the steps
at th
Answering my own silly question, on my fossil-based system, running the
following command on the console as the bootes user seems to get the update
process running:
replica/pull -v /dist/replica/network
I'll wait for this to complete and then give building Go another shot.
Thanks for answering my
Also the ports tree[1] version of golang should install fine. I haven't
tried it in a while, but also haven't changed it so it should work. That
will grab the ca certs and install (I think) 1.3.
--
Veety
> % 9fs sources
> % 9fat:
> % cp /n/sources/plan9/386/9pcf /n/9fat
> % cp /n/sources/plan9/386/9pccpu /n/9fat
> % hget http://www.9legacy.org/download/kernel/9pccpuf >/n/9fat
Of course, I mean:
hget http://www.9legacy.org/download/kernel/9pccpuf >/n/9fat/9pccpuf
--
David du Colombier
> Note: I'm running 9front. I can build on amd64 but not 386. Last attempt
> was 1.5 on 386, bootstrapped with 1.4.2:
>
> dl; go version
> go version go1.4.2 plan9/386
> dl; GOROOT_BOOTSTRAP=/usr/local/go
> dl; ./make.rc
> # Building Go bootstrap tool.
>
> I'm looking at the directions in a (cached copy) of
> http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...
>
> Is that still valid? What's the canonical procedure these days for updating
> a system?
>
> If that's roughly correct ... I'm running a single Plan 9 machine, combined
> Go builds just fine right now on the plan9 builders: http://build.golang.org
>
> 1.4 and 1.5 are very different, due to 1.5 being written in Go. i386 and
> amd64 should both build, although amd64 fails an irrelevant unittest.
>
> What do you see with 1.5.2/1.5.3? (You said you tried?)
Note: I
> All the errors seem related to the old Rune size. I suspect you're running
> an old system and it's likely to not have nsec and tsemacquire syscalls
> either.
>
> If you believe the system is up-to-date, you can cross compile a simple Go
> program using 1.5 or later targeting GOOS=plan9 GOARCH=38
Thanks, Skip. That would follow; this system is probably straight Fourth
Edition, certainly an old ISO...
I've never been 100% clear on the process for running updates; can I bring
myself up to current from where I'm at now and not have to reload or build
a fresh system? It's a VM and I can snapsh
All the errors seem related to the old Rune size. I suspect you're running
an old system and it's likely to not have nsec and tsemacquire syscalls
either.
If you believe the system is up-to-date, you can cross compile a simple Go
program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a Li
Go builds just fine right now on the plan9 builders: http://build.golang.org
1.4 and 1.5 are very different, due to 1.5 being written in Go. i386 and amd64
should both build, although amd64 fails an irrelevant unittest.
What do you see with 1.5.2/1.5.3? (You said you tried?)
Best regards,
Kenny
>From http://fqa.9front.org/appendixl.html:
# automatically converted ca certs from mozilla.org
hget http://curl.haxx.se/ca/cacert.pem >/sys/lib/tls/ca.pem
# shell script that emulates git commands
hget http://9front.org/extra/rc/git >$home/bin/rc/git
chmod
> i can try it on rpi's, plugs and BBBs
My Sheevaplug has died on me and the Olimex Olinuxino is a bit
underpowered. I'm not sure if either will ever be viable.
Olimex have some exciting new hardware coming up, but a builder is a
bit of a tall order on ARM.
Ideally, I should use my Galaxy S5,
i can try it on rpi's, plugs and BBBs
On Sun, Nov 30, 2014 at 12:37 PM, Anthony Martin wrote:
> minux once said:
> > On Nov 30, 2014 3:10 PM, "Mats Olsson" wrote:
> > > Just googled and found: https://code.google.com/p/go-wiki/wiki/GoArm
> > >
> > > So it seems that it's supported.
> > go on
Hi David!
I have several Raspberry Pi's and I'm kind of doing a research of what
can be done on this platform when it comes to programming etc.
Preferable in Plan 9 OS. I'm certain that there are lots of other
options but I'm focusing on the use of the Raspberry Pi as a hardware
platform.
Kind Re
erik quanstrom once said:
> > We're all just waiting for the tree to open up again.
>
> i thought that was the promise of dcs -- you don't have to wait.
> where did this whole thing fail?
Well, I really meant we're waiting for the point in the
development schedule that allows new code to be up f
> The following quote from GoArm makes me believe it can be done on a
> RPi
Yes. ARMv5, ARMv6 and ARMv7 are supported. But maybe something
faster than a Raspberry Pi would be better.
--
David du Colombier
The following quote from GoArm makes me believe it can be done on a RPi:
Supported operating systems
Go supports ARM on Linux. You must be running a EABI kernel. These are
generally known as armel for softfloat (compatible with ARMv5) or
armhf for hardware floating point (ARMv6 and above).
2014-
> If someone volunteers to run a plan9/arm builder, I'll
> do the port and have it in by the 1.5 release. ☺
I think I can run an plan9/arm builder. What board do you want?
--
David du Colombier
> We're all just waiting for the tree to open up again.
i thought that was the promise of dcs -- you don't have to wait.
where did this whole thing fail?
- erik
minux once said:
> On Nov 30, 2014 3:10 PM, "Mats Olsson" wrote:
> > Just googled and found: https://code.google.com/p/go-wiki/wiki/GoArm
> >
> > So it seems that it's supported.
> go on arm only supports Linux, Freebsd, Netbsd, nacl and Darwin
> (unofficial).
>
> plan 9 is not on the list (yet)
On Nov 30, 2014 3:10 PM, "Mats Olsson" wrote:
> Just googled and found: https://code.google.com/p/go-wiki/wiki/GoArm
>
> So it seems that it's supported.
go on arm only supports Linux, Freebsd, Netbsd, nacl and Darwin
(unofficial).
plan 9 is not on the list (yet).
On Sun Nov 30 12:06:43 PST 2014, plan9@gmail.com wrote:
> Just googled and found: https://code.google.com/p/go-wiki/wiki/GoArm
>
> So it seems that it's supported.
>
read the supported operating systems section:
"Go supports ARM on Linux. You must be running a EABI kernel.
so not even all
Just googled and found: https://code.google.com/p/go-wiki/wiki/GoArm
So it seems that it's supported.
2014-11-30 20:06 GMT, Mats Olsson :
> Yes, I'm using 9pi. OK. Thanks!
>
> 2014-11-30 18:31 GMT, Skip Tavakkolian :
>> are you using 9pi? if so, i don't think Go is available on plan9/arm yet.
>>
Yes, I'm using 9pi. OK. Thanks!
2014-11-30 18:31 GMT, Skip Tavakkolian :
> are you using 9pi? if so, i don't think Go is available on plan9/arm yet.
>
>
> On Sun, Nov 30, 2014 at 10:13 AM, Mats Olsson wrote:
>
>> Hi guys!
>>
>> The thing is that I've been fooling around with Plan 9 for like 7
>>
are you using 9pi? if so, i don't think Go is available on plan9/arm yet.
On Sun, Nov 30, 2014 at 10:13 AM, Mats Olsson wrote:
> Hi guys!
>
> The thing is that I've been fooling around with Plan 9 for like 7
> weeks (a real noob then) and then I read about programming in Go and
> found that int
Hi guys!
The thing is that I've been fooling around with Plan 9 for like 7
weeks (a real noob then) and then I read about programming in Go and
found that interesting and worth trying out. So the crude fact is that
I haven't any knowledge about programming in Go more than what I've
just read (at t
I *think* the commands would go something like this (untested):
hget https://storage.googleapis.com/golang/go1.3.3.src.tar.gz > go.tgz
tar xf go.tgz
cd go/src
all.rc
Mats Olsson wrote:
>Hi guys!
>
>Does anyone use Plan 9 as platform for Go programming? If so, How is
>your setup (remember that I'
I am not sure I understand the question. Programming in Go on Plan 9
is almost the same as programming in Go in Unix. The "setup" is the
same.
--
Aram Hăvărneanu
where would PostMountSrv reside? it isn't a syscall.
it is not difficult to do by hand; this version of go9p's timefs example
posts itself to /srv (plus some code to fake a few unix'isms on Plan
9). there is no authentication; permissions on the /srv file determine if a
user can mount it:
https:/
short version: you need libauth in Go (or start the go9p client/server by C
programs that do the auth).
9P facilitates authentication (but doesn't define or dictate the method).
intro(5), auth(2) and factotum(4) will be helpful. basically Tauth is used
to request a fid to negotiate authentication
Skip Tavakkolian once said:
> thanks; i should have checked that. running it on the fossil+venti server
> brings it down a bit. still, it's not stellar.
>
> bootes% go test
> PASS
> ok cmd/pack 81.480s
> bootes% go test
> PASS
> ok cmd/pack 79.719s
Here's a CL to buffer the writes in TestLar
On Mon May 5 01:19:06 EDT 2014, lu...@proxima.alt.za wrote:
> > Your numbers don't look entirely abnormal. That test issues
> > over a million small writes. (Although it really should be
> > using bufio).
>
> Are you suggesting we ought to change pack? I don't mind doing it if
> it's likely to b
thanks; i should have checked that. running it on the fossil+venti server
brings it down a bit. still, it's not stellar.
bootes% go test
PASS
ok cmd/pack 81.480s
bootes% go test
PASS
ok cmd/pack 79.719s
On Sun, May 4, 2014 at 7:51 PM, Anthony Martin wrote:
> Skip Tavakkolian once said:
>
> Your numbers don't look entirely abnormal. That test issues
> over a million small writes. (Although it really should be
> using bufio).
Are you suggesting we ought to change pack? I don't mind doing it if
it's likely to be accepted by the developers. On NetBSD and my slow
Plan 9 network, ther
Skip Tavakkolian once said:
> is anyone else seeing similar results for cmd/pack?
>
> % go test
> PASS
> ok cmd/pack 172.505s
>
> this is on an atom (d525 @ 1.8ghz, 4gb). same test on an arm (quad core a9
> @ 1.7ghz, 2gb, linux 3.8) takes much less time:
>
> % go test
> PASS
> ok cmd/pac
Fixed.
On Fri, Jan 24, 2014 at 6:31 PM, Uvelichitel wrote:
> >Hi,
>
> >I have made a support of TLS in p9p's upas/smtp and remade the support of
> TLS in p9p's upas/nfs (stunnel is not needed anymore).
> >The sources are avaliable in my working copy of plan9port:
> https://bitbucket.org/santucco
>Hi,
>I have made a support of TLS in p9p's upas/smtp and remade the support of
TLS in p9p's upas/nfs (stunnel is not needed anymore).
>The sources are avaliable in my working copy of plan9port:
https://bitbucket.org/santucco/plan9port
Can't compile on darwin (10.8). Can't make common.
> Codereview has it’s issues.
It's normal to find fault when things aren't as convenient as one
wishes, but in this case I doubt that we could replace codereview and,
most importantly, the reviewers, with something better.
If there is a better option, I'll be happy to go along with it, I'm
not an
1 - 100 of 489 matches
Mail list logo
