On Tue, Jun 29, 2010 at 04:00:09PM -0700, Russ Cox wrote:
i think people get too hung up on trying to make
the port back perfect. just make it work.
then make it better.
But it's the toolchain I'm after. I like Go a lot, but I feel that
a viable toolchain that produces ELF files for Linux
On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen eri...@gmail.com wrote:
On Sat, Jun 26, 2010 at 4:26 AM, lu...@proxima.alt.za wrote:
but I can dig
them up, clean them up, and share them,
My particular concern is to encourage convergence towards a single
source distribution rather than
2010/6/29 Rob Pike robp...@gmail.com:
On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen eri...@gmail.com wrote:
On Sat, Jun 26, 2010 at 4:26 AM, lu...@proxima.alt.za wrote:
but I can dig
them up, clean them up, and share them,
My particular concern is to encourage convergence towards a
Which things are yet to be done to get the port done?
FTS, I'm interesting in getting Go here because I'm going to write
the i.e. window system (successor of o/live, o/mero, ...) also in go, to run
at least the viewer native on unix systems. The C version is still cooking.
On Tue, Jun 29, 2010 at 7:36 PM, Francisco J Ballesteros n...@lsub.org wrote:
On Tue, Jun 29, 2010 at 9:48 AM, Francisco J Ballesteros n...@lsub.org wrote:
FTS, I'm interesting in getting Go here because I'm going to write
the i.e. window system (successor of o/live, o/mero, ...) also in go, to run
at least the viewer native on unix systems. The C version is still
Is the porting process active?
It seems to be an opportunistic concurrent activity (which is why I
tried to create a central repo so we'd get some benefit from the
sparse multiple activities). Most people were just waiting for Andrey
:)
There is some stuff that Forysth/Jmk have been looking
Anyone (Russ?) can repeat here aprox. what the workaround for b was, for
those like me that didn't attend usenix?
On Tue, Jun 29, 2010 at 8:10 PM, Eric Van Hensbergen eri...@gmail.com wrote:
Is the porting process active?
It seems to be an opportunistic concurrent activity (which is why I
a) Simple logistics (makefile/script transformations, Sape's branch
has some of this, what the right way to do this in order to be
integrated back into the mainline go tree is an open question)
[...]
I wonder if one way of avoiding (a) is just to rig to cross-compile
from Linux/MacOSX to
I was sleep-deprived much of the week, so my memory is most likely not
exact (so hopefully Russ will provide a clarification), but I believe
he said something along the lines of pointing to the top of the stack
as a workaround. I haven't had a chance to look at it yet, so that's
about as much of
On Tue Jun 29 16:46:40 EDT 2010, eri...@gmail.com wrote:
erik's attempt is now in the go-plan9 repo under its own branch for
those that wish to take a look.
Hopefully I merged it properly.
it compiles and links, but obviously doesn't run
since there really is no runtime.
- erik
On Tue, Jun 29, 2010 at 2:15 PM, Devon H. O'Dell devon.od...@gmail.com wrote:
Or syscall implementation or net / fd / etc implementation.
pkg/runtime should be easy. I'll do it tonight.
It would be nice to avoid a system call if possible :-)
ron
On Tue Jun 29 22:04:19 BST 2010, rminn...@gmail.com wrote:
Can someone remind me of the problem? Is it simply the need to be able
to set %gs?
Could a write to /dev/arch of something like
gs 0xwhatever
which sets %gs for that process solve the problem?
Or is it bigger than that?
ron
Or is it bigger than that?
the go toolchain is replete with go-specific things,
and produces incompatible .8 files (and perhaps for other architectures),
because of the way certain changes were made.
as russ suggested, it's probably easiest just to have a /bin/go
and put go/8c, go/8l etc in
the segment registers are just indices to the kernels descriptor tables.
setting the segment registers can be done with assembly instructions from
userspace. but what you need is being able to modify the descriptors in
a save way from userspace!
i needed this for linuxemu to implement
what i said to people at usenix was approximately
the following.
i think that porting go to plan 9 - the time to get
something working that runs all the go programs -
is not more than a week of concerted effort.
i also think that it just hasn't been high enough
priority for anyone (myself
On Sat, Jun 26, 2010 at 4:26 AM, lu...@proxima.alt.za wrote:
but I can dig
them up, clean them up, and share them,
My particular concern is to encourage convergence towards a single
source distribution rather than divergence as seems to have been the
case so far with Plan 9 native, Inferno,
On Fri, Jun 25, 2010 at 22:19, lu...@proxima.alt.za wrote:
[snip]
There's a fourth objective, but it may be above my skill level, which
is to port all the other Plan 9 and/or Inferno architectures into the
consolidated toolchain.
[snip]
I've been (slowly) working on this for MIPS with the
On 26 Jun 2010, at 06:19, lu...@proxima.alt.za wrote:
The [568]c compilers in the Go tree are based on the Inferno/Plan 9
compilers. Did something change?
Yes, they added ELF, didn't they? And they used GCC to compile
everything, which is the bit I've been trying to consolidate since
more
but I can dig
them up, clean them up, and share them,
My particular concern is to encourage convergence towards a single
source distribution rather than divergence as seems to have been the
case so far with Plan 9 native, Inferno, p9p and now Go. What I have
chosen to do, ill-advised as it may
My particular concern is to encourage convergence towards a single
source distribution rather than divergence as seems to have been the
case so far with Plan 9 native, Inferno, p9p and now Go. What I have
[...]
And, obvious sequitur, what would it take to replace Plan 9's patch
approach with
My particular concern is to encourage convergence towards a single
source distribution rather than divergence as seems to have been the
case so far with Plan 9 native, Inferno, p9p and now Go. What I have
[...]
And, obvious sequitur, what would it take to replace Plan 9's patch
approach with
The [568]c compilers in the Go tree are based on the Inferno/Plan 9
compilers. Did something change?
Yes, they added ELF, didn't they? And they used GCC to compile
everything, which is the bit I've been trying to consolidate since
more or less the very beginning. The objective of the
23 matches
Mail list logo
