> Also, we are trying to make our changes in a way that they could
> help the stock distribution, which is, again, what I said would be
> better than doing them in incompatible ways.
I understand this is going to be difficult, I don't expect anyone to
take this on right now, but I still maintain t
sorry, I never tried cross-compiling. I started here:
http://en.wikipedia.org/wiki/Cross_compiler#GCC_and_cross_compilation, and
http://www.cis.upenn.edu/~milom/cross-compile.html
what should be switch --target=some-target set to?
> your best bet is to cross-compile on Linux. set GOOS to plan9
> sorry, I never tried cross-compiling. I started here:
> http://en.wikipedia.org/wiki/Cross_compiler#GCC_and_cross_compilation, and
> http://www.cis.upenn.edu/~milom/cross-compile.html
>
> what should be switch --target=some-target set to?
>
>> your best bet is to cross-compile on Linux. set
> sorry, I never tried cross-compiling. I started here:
$ cd go/src
$ hg sync > /dev/null 2>&1 # places you at tip
$ export GOOS=plan9
$ export GOARCH=386
$ ./make.bash > /dev/null
conflicts: 3 shift/reduce
$ cat > /tmp/t.go
package main
func main() { println("hello"); }
$ cd /tmp
$ 8g t.go
$ 8l t
$ ./make.bash > /dev/null
make: *** [executable.o] Error 1
make: *** Waiting for unfinished jobs
do i need to merge rminnich-9go with go.googlecode.com/hg/ go???
thanks, peter
my instructions are for a pure go tree (a clone from googlecode
without any modifications). the redirection to /dev/null is to save
some email space, you don't need to have it in your tests.
also, i'm cross-compiling go for plan9 on linux/osx. i apologize, we
shouldn't have gotten out of sync so quickly.
On Fri, Nov 25, 2011 at 1:59 AM, andrey mirtchovski
wrote:
> my instructions are for a pure go tree (a clone from googlecode
> without any modifications). the redirection to /dev/nul
bash: ./make.bash: No such file or directory
I guess I should merge rminnich-9go with go.googlecode.com/hg/ go ??
thanks, ++pac
On Fri, Nov 25, 2011 at 9:06 AM, Lucio De Re wrote:
> hereas any changes to
> the original Plan 9 distribution affects my working environment
> directly, which makes it trivial to submit changes if I develop them.
>
That's what I was saying. We are working in nix in such a way that we
hope the co
> That's what I was saying. We are working in nix in such a way that we
> hope the code we are working on could be used by the stock Plan 9
> in the future. So, it's a fork, but we are still trying to cooperate with
> everyone else.
Branching seems to be a black hole, though: there is no easy way
A timely discussion before producing any code is usually more profitable.
On 25 November 2011 08:06, Lucio De Re wrote:
> And Code Review ought to be at the core of it.
surely it only makes sense that when forks appear the knives come out.
> (I know Erik has adopted at least the BCM57xx driver for 9atom). I'm
although it's in there, it doesn't work with the bcm57xx hardware i have.
so cavet emptor.
- erik
> surely it only makes sense that when forks appear the knives come out.
I guess this is part of the reason I follow 9fans so avidly :-)
++L
> A timely discussion before producing any code is usually more profitable.
>
Unarguably. But a code review system makes sure that lack of
discussion is corrected before it is too late. And prior discussion
seems pretty scarce around Plan 9. Unless of course IRC is where it
all happens, in whic
On Fri Nov 25 01:47:12 EST 2011, cinap_len...@gmx.de wrote:
> drivers should be pretty portable.
>
> there are more drastic changes like the eqlock function
> that touched many places. its basicly a normal qlock()
> that can error() out when the process gets a note or
> gets killed.
ha! i've wr
On Fri, Nov 25, 2011 at 7:55 AM, erik quanstrom wrote:
>> (I know Erik has adopted at least the BCM57xx driver for 9atom). I'm
>
> although it's in there, it doesn't work with the bcm57xx hardware i have.
> so cavet emptor.
You might want to re-synch. Recent changes have caused the BCM5755 in
my
A good clue might have been that they're "Sharepoint" experts.
On Thu, Nov 24, 2011 at 11:01 AM, Stanley Lieber
wrote:
>
> The article linked above is an example of poor journalism, complete
> with misquotes and fabricated quotes.
>
still not working; doesn't even reset.
i've taken a pass at cleaning up the code. the biggest change
is using style(6) formatting. also, coherence() is missing when
entering ring entries, since the posted write of the ring ptr can
pass the memory writes of the ring entry, from the perspective
of
re: etherbcm.c
thanks,
Again it will have to wait till monday for me to try.
BTW I'am not sure if I emphasised enough how grateful I am for all your
patient work in getting SSE working.
Its great to make progress on this, though the performance of opera +
linuxemu + equis (fgb's X11 server) is
> BTW I'am not sure if I emphasised enough how grateful I am for all your
> patient work in getting SSE working.
really it's no problem. it's something that i'd worked on before,
and had to leave behind.
ideally, i'd like to be able to use sse with 8[acl]. but that means
that i (a) have to figu
fixed for my hw. the really key bit was setting the endianness
properly. this may have been set up by your pxe hardware or bios,
if your bcm chip was built-in.
i've updated 9atom with this driver.
- erik/*
* Broadcom BCM57xx
* Not implemented:
* proper fatal error handling
* multiple ring
22 matches
Mail list logo
