After a little work, I have a Plan 9 dev environment setup. My dreamplug
boots with no problems, and after installing python and mercurial, I was
able to clone the go repo. The build completes fine on 386, but on the
dreamplug I get the errors below. Yes, I know I should probably be running
as a us
congrats! which mercurial and python did you install?
On Mon, Apr 15, 2013 at 1:00 AM, Christopher Nielsen wrote:
> After a little work, I have a Plan 9 dev environment setup. My dreamplug
> boots with no problems, and after installing python and mercurial, I was
> able to clone the go repo. The
This is a known problem with 5c. It cannot switch on vlong. As a stopgap,
you can
change the types of the things being switched on to integer (type, if I
remember right).
G.
On Mon, Apr 15, 2013 at 9:00 AM, Christopher Nielsen wrote:
> After a little work, I have a Plan 9 dev environment setup
Thanks! I'm quite pleased to have managed to get this far with a little
weekend hacking.
I followed the directions from
http://mercurial.selenic.com/wiki/Plan9FromBellLabs
Nice doc to whomever wrote it.
So using contrib, I installed the following:
fgb/z
fgb/bz2
fgb/openssl
bichued/python
stallio
I'll give that a shot and see if I get different results. It'll have to be
some time tomorrow though. What concerns me is that the error says it can't
find opnames.h when it clearly exists.
On Mon, Apr 15, 2013 at 12:08 AM, Gorka Guardiola wrote:
> This is a known problem with 5c. It cannot swi
I'm getting something similar on Sheeva. It also looks like there are still
env issues:
sheeva% ./all.rc
# Building C bootstrap tool.
cmd/dist
# Building compilers and Go bootstrap tool for host, plan9/arm.
lib9
libbio
libmach
misc/pprof
cmd/addr2line
cmd/cov
cmd/nm
cmd/objdump
cmd/pack
cmd/prof
I saw the same problem and solved it by setting GOEXPERIMENT="". Not sure
that's the correct solution, but it worked.
I will look at it in more detail tomorrow, if I have time.
--
Christopher Nielsen
"They who can give up essential liberty for temporary safety, deserve
neither liberty nor safety
1) if you don't change the type of type to be int, it will give you bogus
errors, but
the real problem is that some of the files do not compile.
2) opnames.h is autogenerated by dist. IIRC there is no problem with it
(see 1).
3) I have GOEXPERIM set to ''. You need to set a ton of variables, out
go is using switch on vlongs. support for this was backported to plan9 c compiler
some time ago. just update the compilers from sources.
Von: "Skip Tavakkolian"
/usr/fst/Go1/src/cmd/gc/reflect.c:1022[/usr/fst/Go1/src/cmd/gc/reflect.c:3400] switch _expression_ must be integer
On Mon, Apr 15, 2013 at 10:31 AM, kernel panic wrote:
> go is using switch on vlongs. support for this was backported to plan9 c
> compiler
> some time ago. just update the compilers from sources.
>
>
> Last time I checked (like a week ago) it did not work with 5c.
G.
yes. you are right, it doesnt work for 5c.
--
cinap
Gesendet: Montag, 15. April 2013 um 10:43 Uhr
Von: "Gorka Guardiola"
An: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Betreff: Re: [9fans] Go Plan9 ARM Dreamplug
On Mon, Apr 15, 2013 at 10:31 AM, kernel panic wrote:
go is usi
Sheeva/Guru -- GOARM=5
RPi -- GOARM=6 or not set (GOARM=6 is default)
Not if DreamPlug is 5 also.
setting GOARCH=arm, etc. before all.rc on an x86 cpu builds Go for x86 and
arm.
On Mon, Apr 15, 2013 at 1:34 AM, Gorka Guardiola wrote:
> 1) if you don't change the type of type to be int, it wil
> yes. you are right, it doesnt work for 5c.
Somewhere the 8c fixes for the switch selector were merged together
with other changes and no one has been able to extricate them so they
could be applied to 5c (et al.). I believe that forsyth is looking
into this, but it would be great to have this f
> GOROOT=/sys/src/golang #where the go repository resides
> GOOS=plan9
> GOARCH=$objtype
> GOHOSTARCH=$cputype
> GOBIN=/$objtype/bin
> GOPATH=/sys/src/go #wher your go stuff resides
> GOARM=5 #or 6 or 7, depending on your machine's support of floating point.
> GOEXPERIM=''
Of the above, I think GO
On 15 April 2013 10:55, wrote:
>
> Somewhere the 8c fixes for the switch selector were merged together
> with other changes and no one has been able to extricate them so they
> could be applied to 5c (et al.).
Um. No, that's not the problem. In fact, the changes were redone ages ago,
and most o
> I have got a 5c that does vlongs, and thus OREGPAIR,
> but it won't compile ghostscript yet, so it hasn't been released.
I'm not sure how to phrase this, but presumably the Go version of 5c
has been upgraded to deal with vlong switch selectors: is the Plan 9
version going to differ a lot from th
Hello,
This is Junaid from National University of Sciences and Technology.
Currently, I am a student of MS Electrical Engineering. I am really
interested in the idea of writing drivers for the Raspberry Pi. I already
have some experience over working with the I2c, GPIOs, audio stuff.
Is this the
On Sun Apr 14 14:17:35 EDT 2013, cinap_len...@gmx.de wrote:
> the way the mouse cursor is drawn currently is quite complicated.
> the cursor is redrawn from a timer interrupt 30 times a second
> and the software cursor also installs its own timer interrupt
> handler to redraw itself when it got ove
i found it not to be a big deal to just redraw the cursor without
any delay. this is usualy very quick anyway. the only exception
is when another process holds onto the drawlock for a long
time because of some expensive operation (poly drawing). and in
that case, the cursor draw process will be que
On Mon Apr 15 14:37:00 EDT 2013, cinap_len...@gmx.de wrote:
> i found it not to be a big deal to just redraw the cursor without
> any delay. this is usualy very quick anyway. the only exception
> is when another process holds onto the drawlock for a long
> time because of some expensive operation (
also, i think that mouse.xy should be updated inside a lock.
- erik
> and hz does matter because the sleep in mouse proc
> may be woken a minimum rate of hz*nproc.
ah! right. you could get even faster redraws on a mp system when
another idle processor is available. it might not just wait for the
hz timer tick but schedule the woken up mouseproc as soon as it
appea
Hi there,
I want to participate in this year's GSoC for Inferno with my own project
idea. Is there anyone who can mentor such proposal and who I can discuss it
with?
Repost of my proposal:
>>Hello,
>>
>>I'm a student from Belarusian State University, I love Inferno and I
really want to take part
On Mon Apr 15 16:28:37 EDT 2013, cinap_len...@gmx.de wrote:
> > and hz does matter because the sleep in mouse proc
> > may be woken a minimum rate of hz*nproc.
>
> ah! right. you could get even faster redraws on a mp system when
> another idle processor is available. it might not just wait for the
Junaid:
Hey there. This is a good spot for general discussion of issues
related to Plan 9 on the Raspberry Pi, and will probably get you the
broadest audience of people running it. If you'd like to discus things
specific to your proposal (or generally get a more gsoc-specific
crowd) there's
Hello,
I’m Andrea, an Italian universitary student (2st years of Computer Science
in “La Sapienza” Univesity of Rome). I am writing to find out more about
the project “Write a basic Dis interpreter for web browsers in Dart”.
I found this project so interesting because combines Dart language (
it's "$GOROOT/VERSION.cache". just put whatever you want in there or
bind it from /tmp if you don't want to pollute the non-plan9 side of
things.
On Sun, Apr 14, 2013 at 3:53 PM, Skip Tavakkolian
wrote:
> Unfortunately doesn't seem to help:
>
> cpue% ./all.rc
> # Building C bootstrap tool.
> cmd/
thank you minux and andrey.
I realized I needed something in the file; 'touch VERSION' wasn't fooling
it.
On Sun, Apr 14, 2013 at 3:30 PM, andrey mirtchovski
wrote:
> it's "$GOROOT/VERSION.cache". just put whatever you want in there or
> bind it from /tmp if you don't want to pollute the non-p
28 matches
Mail list logo
