Sorry for the late response, Jeff. Apologies. I just booted up virtualbox.
On Fri, Apr 4, 2014 at 11:09 AM, Jeff Sickel wrote:
>
>
>> On Apr 3, 2014, at 1:04 PM, Ramakrishnan Muthukrishnan
>> wrote:
>
>> I tried cloning the go repo multiple times with the new hg and I get
>> the error *everytim
> I got a fresh copy of go from the current hg tip and applied this
> patch. I now see some other errors while it builds pkg/math module: I
> had not seen these before, so perhaps something new that landed in the
> go repo may be responsible for it?
>
> go/src/pkg/math/abs.go:14: internal error: ab
On Wed, Apr 2, 2014 at 10:49 AM, David du Colombier <0in...@gmail.com> wrote:
> Two days ago, I've fixed the script mklibc.rc to
> generate the libc_plan9.h file properly on 9atom.
>
> https://codereview.appspot.com/82660044/
>
> Please give a try and review this change to
> get it submitted before
> On Apr 3, 2014, at 1:04 PM, Ramakrishnan Muthukrishnan
> wrote:
> I tried cloning the go repo multiple times with the new hg and I get
> the error *everytime*. :(
What file system are you using?
Have you tried 'hg clone -U'?
There are a few cases with hg where the repository your trying to
On Thu Apr 3 21:11:07 EDT 2014, vu3...@gmail.com wrote:
> On Thu, Apr 3, 2014 at 11:53 PM, David du Colombier <0in...@gmail.com> wrote:
> >> i hope this isn't begging the obvious, but with huge
> >> masses of code, i find it helpful to hunt down the initial
> >> error message and start adding debu
On Thu, Apr 3, 2014 at 11:53 PM, David du Colombier <0in...@gmail.com> wrote:
>> i hope this isn't begging the obvious, but with huge
>> masses of code, i find it helpful to hunt down the initial
>> error message and start adding debugging code.
>
> I think it's more a matter of spare time and repr
> I tried cloning the go repo multiple times with the new hg and I get
> the error *everytime*. :(
I'm having troubles to reproduce this problem recently.
It seems to depends on your network connection. I suppose
there is an issue somewhere in the networking code.
If that's a problem for you, you
> i hope this isn't begging the obvious, but with huge
> masses of code, i find it helpful to hunt down the initial
> error message and start adding debugging code.
I think it's more a matter of spare time and reproducibility ☺.
--
David du Colombier
On Thu, Apr 3, 2014 at 11:27 PM, David du Colombier <0in...@gmail.com> wrote:
>> ; hg clone http://code.google.com/p/go
>>
>> ...
>> adding file changes
>> transaction abort!
>> failed to truncate 00manifest.i
>> rollback failed - please run hg recover
>> abort: invalid arguments
>> ; cd go
>>
On Thu Apr 3 13:59:36 EDT 2014, 0in...@gmail.com wrote:
> > ; hg clone http://code.google.com/p/go
> >
> > ...
> > adding file changes
> > transaction abort!
> > failed to truncate 00manifest.i
> > rollback failed - please run hg recover
> > abort: invalid arguments
> > ; cd go
> > ; hg recov
> ; hg clone http://code.google.com/p/go
>
> ...
> adding file changes
> transaction abort!
> failed to truncate 00manifest.i
> rollback failed - please run hg recover
> abort: invalid arguments
> ; cd go
> ; hg recover
> no interrupted transaction available
> ;
It looks similar to an issue I
> adding file changes
> transaction abort!
> failed to truncate 00manifest.i
> rollback failed - please run hg recover
> abort: invalid arguments
looks like that error path was never tested. :-)
- erik
Sorry, late into it again.
David,
I picked the new hg from 9legacy website (2.9.1) and used it to pull
Go source. But I consistently get this error on both Bell Labs plan9
and 9atom on virtualbox.
; hg clone http://code.google.com/p/go
...
adding file changes
transaction abort!
failed to tr
> They are incompatible. For example, some Fmt verbs (like %F) does produce
> slightly different output. It was an explicit requirement from the Go team
> to use their variants of these libraries.
do you see why i think that relationship is upside down?
- erik
> why is the alternative to modify plan 9, and why can't they
> live with the system fmt/rune routines?
They are incompatible. For example, some Fmt verbs (like %F) does produce
slightly different output. It was an explicit requirement from the Go team
to use their variants of these libraries.
--
On Apr 3, 2014, at 12:58 AM, erik quanstrom wrote:
>
> On Thu Apr 3 01:51:59 EDT 2014, 0in...@gmail.com wrote:
>>> the script itself reminds me of gcc fixincludes.
>>
>> This is probably not ideal, but the alternative would be
>> to split libc.h in three parts: libc.h, fmt.h and utf.h
>> and on
> > ? cmd/nm [no test files]
> > pack.test 1119: suicide: sys: trap: fault read addr=0xeafc
> > pc=0x254b6 *** Test killed: ran too long (3m0s).
> > FAILcmd/pack180.007s
> > ? cmd/yacc[no test files]
>
> It was probably a real error. However, other
> Sorry, David.
> I made mistake to copy your patch file to Plan9
> system (I've not set abaco yet).
>
> I retried your above patch, and perfectly seamless results
> which are included here.
I don't think the error you encountered was related to
the patch, since it's only related to a compilation
On Thu Apr 3 01:51:59 EDT 2014, 0in...@gmail.com wrote:
> > the script itself reminds me of gcc fixincludes.
>
> This is probably not ideal, but the alternative would be
> to split libc.h in three parts: libc.h, fmt.h and utf.h
> and only include libc.h in Go (because Go has his own
> variants of
> the script itself reminds me of gcc fixincludes.
This is probably not ideal, but the alternative would be
to split libc.h in three parts: libc.h, fmt.h and utf.h
and only include libc.h in Go (because Go has his own
variants of libfmt and libutf).
--
David du Colombier
>> https://codereview.appspot.com/82660044/
>>
>> Please give a try and review this change to
>> get it submitted before the Go 1.4 release.
Sorry, David.
I made mistake to copy your patch file to Plan9
system (I've not set abaco yet).
I retried your above patch, and perfectly seamless results
w
On Wed Apr 2 01:20:42 EDT 2014, 0in...@gmail.com wrote:
> Two days ago, I've fixed the script mklibc.rc to
> generate the libc_plan9.h file properly on 9atom.
>
> https://codereview.appspot.com/82660044/
>
> Please give a try and review this change to
> get it submitted before the Go 1.4 release
> https://codereview.appspot.com/82660044/
>
> Please give a try and review this change to
> get it submitted before the Go 1.4 release.
I tried this, and compilation becomes seamless.
However, a new test error occured as:
=
? cmd/nm [no test files]
pack.test 1119: suicide: sys: tr
Thanks David.
> How did you succeed to run go_bootstrap? Have you
> just switched from the 9atom pc kernel to the pcpae
> kernel?
I just switched from 9atom pc to pcpae kernel.
When I run /usr/sys/src/go/src/all.rc, it fails
to make $GOROOT/include/plan9/libc_plan9.h.
Then, I removed the lines o
> before the Go 1.4 release.
Sorry, I mean Go 1.3 of course.
--
David du Colombier
Two days ago, I've fixed the script mklibc.rc to
generate the libc_plan9.h file properly on 9atom.
https://codereview.appspot.com/82660044/
Please give a try and review this change to
get it submitted before the Go 1.4 release.
--
David du Colombier
> Someone can explain the meaning of the last error?
> --- FAIL: TestResolveIPAddr (0.00 seconds)
> ipraw_test.go:74: ResolveIPAddr(ip6:ipv6-icmp, ::1) failed: write
> /net/cs: cs: no match
> FAIL
> FAIL net 0.948s
The ResolveIPAddr test is failing because you don't have
the ::1 addre
I built pcpae kernel and recompiled go distribution,
and probably success.
Attached is the go compilation result, and the last line
shows the used go version.
Someone can explain the meaning of the last error?
Kenji
# Building C bootstrap tool.
cmd/dist
# Building compilers and Go bootstrap tool
> Ok, I'll try it.
> I have somewhat complicated feeling on linux's PAE kernal.
> Isn't ther anything wrong to run pae kernel, somthing
> like some application don't run on it etc.
everything should run fine.
- erik
> you'll need to run the pae kernel. it has support for
> sse, which you will need for go.
Ok, I'll try it.
I have somewhat complicated feeling on linux's PAE kernal.
Isn't ther anything wrong to run pae kernel, somthing
like some application don't run on it etc.
Kenji
> The fact that '9fs atom' is there means atom is
> completely independent distribution of Plan9?
technically, atom is independent sources, but
i wouldn't read anything into that.
9fs atom is just an easy way to access the source.
> By the way, I'm definitely running 386 kernel.
you'll need to
> the 386pae kernel is in /sys/src/9/pcpae. it is the same as the pc kernel,
> except is uses physical address extension to address more than 4GB
> of memory. (but not too much more. :-))
Thanks, eric.
I found '9fs atom' just now.☺
Yes, I found /sys/src/9/pcpae and teg2 directory.
Much proceedi
On Mon Mar 31 21:01:35 EDT 2014, kokam...@hera.eonet.ne.jp wrote:
> I've been apart from Plan9 for days, then, please
> forgive my silly question.
>
> What is 386pae kernel, and how I can find
> which kernel I'm running.
the 386pae kernel is in /sys/src/9/pcpae. it is the same as the pc kernel,
I've been apart from Plan9 for days, then, please
forgive my silly question.
What is 386pae kernel, and how I can find
which kernel I'm running.
Kenji
--- Begin Message ---
which kernel are you running? the 386 kernel or the 386pae kernel?
- erik
--- End Message ---
which kernel are you running? the 386 kernel or the 386pae kernel?
- erik
> Are you running 9atom? Ramakrishnan Muthukrishnan is also
> running 9atom. I suspect this problem is specific to 9atom,
> since I never encountered it on Plan 9.
Yes, I'm running 9atom.
> Could you run acid on the process and provide us the
> output of asm(*PC) and regs()? Thanks.
Included is
> I also had the same result using the recent Go code.
> This is cause by the line of
> $GOTOOLDIR/go_bootstrap cleaan -i std
> in make.rc.
>
> It can also make the same result for the
> $GOTOOLDIR/go_bootstrap install ... line.
>
> My go_bootstrap file size is 5143780.
>
> Has anyone solved t
> On Wed, Mar 26, 2014 at 6:08 PM, David du Colombier <0in...@gmail.com> wrote:
>> You can easily fix the generated include/plan9/plan9_libc.h file by
>> hand for now. It seems /sys/include/libc.h is slightly different on
>> 9atom, so the include/plan9/mklibc.rc script have to be adapted. Don't
>>
On Wed, Mar 26, 2014 at 7:17 PM, erik quanstrom wrote:
> On Wed Mar 26 08:39:24 EDT 2014, 0in...@gmail.com wrote:
>> You can easily fix the generated include/plan9/plan9_libc.h file by
>> hand for now. It seems /sys/include/libc.h is slightly different on
>> 9atom, so the include/plan9/mklibc.rc s
> this guess is incorrect. i installed python/hg on 9atom
> 3 weeks ago with jeff, and there were no issues at all.
This is Go, not Python.
--
David du Colombier
> Yes, you are right. I see an empty enum declaration:
>
> enum {
> }
>
> .. in between the "extern .. tokenize.." and "extern .. malloc .. "
> declarations.
>
> I will see how this file is generated. Thank you very much. I am
> running 9atom and not the Bell Labs plan9. I am not sure if some
>
On Wed Mar 26 08:39:24 EDT 2014, 0in...@gmail.com wrote:
> You can easily fix the generated include/plan9/plan9_libc.h file by
> hand for now. It seems /sys/include/libc.h is slightly different on
> 9atom, so the include/plan9/mklibc.rc script have to be adapted. Don't
> forget to comment out the g
On Wed, Mar 26, 2014 at 5:39 PM, Mark van Atten wrote:
>>Attaching a
>> screenshot. I still can't seem to copy text to/from virtualbox.
>
> One thing you can do is to run Plan 9 in virtualbox but use drawterm
> on the host to access it. Then you
> can copy/paste from the drawterm window.
I haven'
On Wed, Mar 26, 2014 at 6:08 PM, David du Colombier <0in...@gmail.com> wrote:
> You can easily fix the generated include/plan9/plan9_libc.h file by
> hand for now. It seems /sys/include/libc.h is slightly different on
> 9atom, so the include/plan9/mklibc.rc script have to be adapted. Don't
> forget
You can easily fix the generated include/plan9/plan9_libc.h file by
hand for now. It seems /sys/include/libc.h is slightly different on
9atom, so the include/plan9/mklibc.rc script have to be adapted. Don't
forget to comment out the generation of plan9_libc.h in src/make.rc.
--
David du Colombier
>Attaching a
> screenshot. I still can't seem to copy text to/from virtualbox.
One thing you can do is to run Plan 9 in virtualbox but use drawterm
on the host to access it. Then you
can copy/paste from the drawterm window.
Mark.
On Wed, Mar 26, 2014 at 5:23 PM, wrote:
> Could you post or have a look at libc_plan9.h - that file is generated by
> stripping out some things from /sys/include/libc.h and it appears that
> something in that process has generated a syntax error.
Pete,
Yes, you are right. I see an empty enum de
Could you post or have a look at libc_plan9.h - that file is generated by
stripping out some things from /sys/include/libc.h and it appears that
something in that process has generated a syntax error.
Pete
ps. I think it’s impossible to copy from vbox unless you have guest additions
installed
Beside the Mercurial issue, the Go 1.2 release will not work on Plan 9. You
have to follow tip. Just remove "-u release" from the clone line.
--
David du Colombier
As I wrote in the previous email [1], I have Python and Mercurial
compiled from sources. When I use it to pull the golang sources, I
noticed the following error:
$ hg clone -u release http://code.google.com/p/go
[...]
added 19559 ...
updating to branch release-branch.go1.2
abort: invalid argument:
50 matches
Mail list logo
