[9fans] GNU/Linux/Plan 9 disto

[9fans] GNU/Linux/Plan 9 disto

[rbnsw-plan9]

Not to rain on anyone's summer of code project but I think producing a Linux distro that runs on top of Plan 9 would be more beneficial to the Plan 9's future than a Plan 9 userspace on top of Glendix, though nowhere as interesting.

I've no problem with a kernel that could run both Plan 9 and Linux binaries but if your goal is that Plan 9 binaries run unchanged on such a system then you will require some sort of device mapping layer, say a FUSE file system that makes Linux devices look like their Plan 9 counterparts - the chief problem being mapping between Linux ioctls and the Plan 9 ctl file protocols.

While you could do that, I have my doubts as to how complete this would be and whether it would be maintained. Moreover, it doesn't do anything to cause Linux and Plan 9 to converge. Since it is difficult to make ioctl work over the network unless source and destination have the same binary architecture Linux needs to be encouraged to change to be closer to the Plan 9 device  model, or at least to a portable ioctl model. Providing a mapping layer just entrenches the problem with Linux and moves Linux no closer to a solution.

Unfortunately, even though there are clustering solutions available which even address process migration Linux people seems quite happy to address remote device access with ad hoc solutions. 

I see a GNU/Linux/Plan 9 distro as making Plan 9 more appealing to the greater public and to aid its domination. Screw fixing Linux to be more Plan 9 like, lets assume Plan 9 has won and the rest is a mere implementation detail. Perhaps some of users attracted buy such a disto will be encouraged to add Plan 9 support for their devices or modify Linux libraries to access Plan 9 natively rather than via Linux emulation. Nothing should be removed, where Plan 9 does something in a perfectly acceptable and sensibly complete way it should be the only mechanism provided (in the long term at least) and the Linux code reliant on the missing mechanism ported to work natively with Plan 9 - unless it is much less work to emulate whatever is missing. To take code using ioctl as an example, the code should be refactored so that both a Plan 9 and Linux libraries with a portable interface are produced, and the modified Linux source and libraries submitted to the current
 maintainers. However, standard C wchar_t based programs probably should be left alone rather the modified to use the Plan 9 string processing model.

Now just for the hell of it, let imagine a world where clustering solutions are built on a Plan 9 base. I'd certainly like something where my local processes migrate from my lower powered laptop including the Window manager migrate to a more powerful CPU when it becomes available and back again when my laptop becomes disconnected,

Now, if I ever can decide on a Linux distribution and ever get Plan 9 to boot, I will see what I can do...

Re: [9fans] GNU/Linux/Plan 9 disto

[Jens Staal]

Personally, I believe that a Plan9 target for a cross compiler might
be more interesting. GCC already added support for the Plan9 dialect
of C. If it also could be made to compile Plan9 binaries, it could be
used for an alternative self-hosting distro as the one you envisaged.

I am fully aware that this is quite herretic and probably not very
interesting for mainline Plan9.

2011/7/11  <rbnsw-plan9@yahoo.com.au>:
> Not to rain on anyone's summer of code project but I think producing a Linux distro that runs on top of Plan 9 would be more beneficial to the Plan 9's future than a Plan 9 userspace on top of Glendix, though nowhere as interesting.
>
> I've no problem with a kernel that could run both Plan 9 and Linux binaries but if your goal is that Plan 9 binaries run unchanged on such a system then you will require some sort of device mapping layer, say a FUSE file system that makes Linux devices look like their Plan 9 counterparts - the chief problem being mapping between Linux ioctls and the Plan 9 ctl file protocols.
>
> While you could do that, I have my doubts as to how complete this would be and whether it would be maintained. Moreover, it doesn't do anything to cause Linux and Plan 9 to converge. Since it is difficult to make ioctl work over the network unless source and destination have the same binary architecture Linux needs to be encouraged to change to be closer to the Plan 9 device  model, or at least to a portable ioctl model. Providing a mapping layer just entrenches the problem with Linux and moves Linux no closer to a solution.
>
> Unfortunately, even though there are clustering solutions available which even address process migration Linux people seems quite happy to address remote device access with ad hoc solutions.
>
> I see a GNU/Linux/Plan 9 distro as making Plan 9 more appealing to the greater public and to aid its domination. Screw fixing Linux to be more Plan 9 like, lets assume Plan 9 has won and the rest is a mere implementation detail. Perhaps some of users attracted buy such a disto will be encouraged to add Plan 9 support for their devices or modify Linux libraries to access Plan 9 natively rather than via Linux emulation. Nothing should be removed, where Plan 9 does something in a perfectly acceptable and sensibly complete way it should be the only mechanism provided (in the long term at least) and the Linux code reliant on the missing mechanism ported to work natively with Plan 9 - unless it is much less work to emulate whatever is missing. To take code using ioctl as an example, the code should be refactored so that both a Plan 9 and Linux libraries with a portable interface are produced, and the modified Linux source and libraries submitted to the current
>  maintainers. However, standard C wchar_t based programs probably should be left alone rather the modified to use the Plan 9 string processing model.
>
> Now just for the hell of it, let imagine a world where clustering solutions are built on a Plan 9 base. I'd certainly like something where my local processes migrate from my lower powered laptop including the Window manager migrate to a more powerful CPU when it becomes available and back again when my laptop becomes disconnected,
>
> Now, if I ever can decide on a Linux distribution and ever get Plan 9 to boot, I will see what I can do...
>
>
>

Re: [9fans] GNU/Linux/Plan 9 disto

[Gorka Guardiola]

On Mon, Jul 11, 2011 at 6:41 PM, Jens Staal <staal1978@gmail.com> wrote:
> Personally, I believe that a Plan9 target for a cross compiler might
> be more interesting. GCC already added support for the Plan9 dialect
> of C. If it also could be made to compile Plan9 binaries, it could be
> used for an alternative self-hosting distro as the one you envisaged.
>
> I am fully aware that this is quite herretic and probably not very
> interesting for mainline Plan9.
>

Not a religion, whatever works for you.

Notice though that the kernel and applications need
some more that only the extensions. All of it (including the
assembler) is written supposing caller save
and other inner specifics of kencc that would need to be dealt with
when compiling
for gcc. It would be a port, not only a recompilation.

G.

Re: [9fans] GNU/Linux/Plan 9 disto

[erik quanstrom]

> Notice though that the kernel and applications need
> some more that only the extensions. All of it (including the
> assembler) is written supposing caller save
> and other inner specifics of kencc that would need to be dealt with
> when compiling
> for gcc. It would be a port, not only a recompilation.

not only that.  waserror() depends on callee-save.

- erik

Re: [9fans] GNU/Linux/Plan 9 disto

[hiro]

> I'd certainly like something where my local processes migrate from my lower powered laptop including the Window manager migrate to a more powerful CPU when it becomes available and back again when my laptop becomes disconnected,

Here network latency is too high for such small tasks nowadays solved by CPUs.
If you have to wait for your CPU in the 21st century you're doing it wrong.

Re: [9fans] GNU/Linux/Plan 9 disto

[erik quanstrom]

On Mon Jul 11 13:58:27 EDT 2011, 23hiro@googlemail.com wrote:
> > I'd certainly like something where my local processes migrate from
> > my lower powered laptop including the Window manager migrate to a
> > more powerful CPU when it becomes available and back again when my
> > laptop becomes disconnected,
> >
> Here network latency is too high for such small tasks nowadays solved
> by CPUs.  If you have to wait for your CPU in the 21st century you're
> doing it wrong.

maybe in this particular case.  here are two others where i think
using more powerful cpus and/or networks might make a lot of sense.
- suppose you have a really low powered device that is sometimes docked.

- suppose you want to run fluid dynamics on your phone.  if you want
to make it run faster, you import some resources from a computing resource
like ec2.

it's true that network latency is a huge deal these days.  and even a multicore
machine looks like a bunch of fast cores connected to their l3 and each other
by a slow network.  but if you have a "large enough" packet of work, it can make
sense to move it over to another cpu.  i don't see why given an apropriate defn
of "large enough" this couldn't work across different orders of magnitude.

- erik

Re: [9fans] GNU/Linux/Plan 9 disto

[Charles Forsyth]

>waserror() depends on callee-save.

caller-save, and a few other conventions (or rather, no need for more conventions).
specifically, it's enough to save the pc and stack. all variables will
have the right values on non-zero return from setjmp, regardless of the
presence or absence of "volatile", and that return can be done by
simply setting the pc and the stack pointer to the values in the jmp_buf.

Re: [9fans] GNU/Linux/Plan 9 disto

[Charles Forsyth]

setting up cross-compilation with gcc, and even using it once set up,
has historically been surprisingly complicated; has that changed?

Re: [9fans] GNU/Linux/Plan 9 disto

[hiro]

> it's true that network latency is a huge deal these days.  and even a
> multicore
> machine looks like a bunch of fast cores connected to their l3 and each
> other
> by a slow network.  but if you have a "large enough" packet of work, it can
> make
> sense to move it over to another cpu.  i don't see why given an apropriate
> defn
> of "large enough" this couldn't work across different orders of magnitude.

I agree there are a lot of cases where I still want exactly that. On
plan9 of course I don't pull from sources over my mobile phone,
instead pull and compile on the CPU server. Some sane non-transparent
CPU offloading worth it because of
 1. slow networks and
 2. compilers still running fastest on fast CPUs

My main point is there won't be any space left for CPU offloading when
it gets limited not only by good old network latency, but also the
increasingly powerful GPGPU/APU/FPGA/CPLD/ASIC side.

Correct me if I'm wrong.

Re: [9fans] GNU/Linux/Plan 9 disto

[Jens Staal]

Would the the work  already done on the Plan9 binary format and
syscall mapping that has been made for the Glendix kernel be useful as
"documentation" for implementing a Plan9 binary output in GCC?

and in the other direction, would it be useful to make a Plan9 libc
port to compile "real" Plan9 binaries with GCC on Linux? Would this be
mutually more benefitial than the current P9P?

I am waaay out of my league here so sorry if I say something stupid.

 2011/7/11 Gorka Guardiola <paurea@gmail.com>:
> On Mon, Jul 11, 20he11 at 6:41 PM, Jens Staal <staal1978@gmail.com> wrote:
>> Personally, I believe that a Plan9 target for a cross compiler might
>> be more interesting. GCC already added support for the Plan9 dialect
>> of C. If it also could be made to compile Plan9 binaries, it could be
>> used for an alternative self-hosting distro as the one you envisaged.
>>
>> I am fully aware that this is quite herretic and probably not very
>> interesting for mainline Plan9.
>>
>
> Not a religion, whatever works for you.
>
> Notice though that the kernel and applications need
> some more that only the extensions. All of it (including the
> assembler) is written supposing caller save
> and other inner specifics of kencc that would need to be dealt with
> when compiling
> for gcc. It would be a port, not only a recompilation.
>
> G.
>
>

Re: [9fans] GNU/Linux/Plan 9 disto

[Pavel Zholkover]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

> setting up cross-compilation with gcc, and even using it once set up,
> has historically been surprisingly complicated; has that changed?
>

I'm not sure about gcc, but the go toolchain can produce quite well working
Plan 9 binaries.

Taru also has the go toolchain running native in itself after some
modifications.

Pavel

[-- Attachment #2: Type: text/html, Size: 378 bytes --]

Re: [9fans] GNU/Linux/Plan 9 disto

[Ethan Grammatikidis]

On Mon, 11 Jul 2011 20:31:08 +0100
Charles Forsyth <forsyth@terzarima.net> wrote:

> setting up cross-compilation with gcc, and even using it once set up,
> has historically been surprisingly complicated; has that changed?

Not the last time I tried, a couple of years ago.

I quite liked Gcc when it was at version 2.93 and I wasn't considering cross-compilation. Now I find it sickening even from a purely practical point of view. It's still usable for compiling my own simple code, and where other programmers haven't tried to be clever it will generally produce acceptable results, but..... erg! It makes me shiver. It's like walking through a minefield, except that when things go wrong the only thing that gets hurt is your brain. (And, of course, you can lose a lot of time.)

Re: [9fans] GNU/Linux/Plan 9 disto

[Ethan Grammatikidis]

On Tue, 12 Jul 2011 02:10:50 +0200
hiro <23hiro@googlemail.com> wrote:

>  2. compilers still running fastest on fast CPUs

I have a quad core I bought specifically for compiling, that was one of the major tasks the box was going to do as I wanted to get more involved in Source Mage GNU/Linux. It performed admirably, but the vast majority of the compiles were IO bound. The IO in question was all to RAM -- the sources were unpacked to tmpfs and the compilation performed there. I used make -j6; 6 jobs, 2 more than the number of cores, and unless it was compiling Firefox or one or two other very large packages, average core utilization would be around 50%.

I don't know if the opinion stated above comes from C++ compiles or from the insane optimization techniques Gcc is sometimes capable of. I choose my words carefully; I mean to use "insane" there because you can increase compilation time dramatically by demanding more optimization from Gcc, and never notice the difference in desktop use. Even given relatively compute-intensive tasks such as compilation, IO limitation is still very significant as my example above shows.

To my mind, the really scary thing about Gcc is that the less heavyweight optimization paths are less well tested. You don't really have a choice about burning up your CPUs on optimization which is worthless for most code. I got lucky; when I bought my quad core Gcc did not yet have specific optimizations for it at all, so I was able to use the generic x86_64 optimization path. I stopped using Source Mage before that generic path had a chance to bit-rot.

There is yet another thing, and now I'm starting to feel ill relating the troubles. Gcc's optimization can be crap for those programs which most require it! Video transformation requires an algorithm which is actually *slowed* by the optimization attempts of Gcc as well as (iirc) Intel's CC. It can be done right, DEC had a compiler which could optimize it well, but video playback software still relies on assembler code because Gcc doesn't do it right. I'm sure video playback is not the only compute-intensive task in which such an algorithm is used. It doesn't stretch my imagination much to see rendering or even perhaps fluid dynamics having such a problem, and we can fall back to assembler with 8c just as easily as with Gcc.

With all these factors, I don't think it's religious at all to say Gcc is one big pile of shit and -- I'm sorry, hiro, -- to wonder at anyone who wants to use it.

[9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Tue, Jul 12, 2011 at 08:59:22AM +0300, Pavel Zholkover wrote:
>
> I'm not sure about gcc, but the go toolchain can produce quite well working
> Plan 9 binaries.
>
> Taru also has the go toolchain running native in itself after some
> modifications.
>
Is there a link to this, please?

I want to take this opportunity to inform 9fans that Russ Cox has helped
me extensively to update the Go release so that the source code for
the 386 assembler, linker and C compiler (8a, 8l and 8c) can be built
without further modification on a 386 Plan 9 native platform.  The leap
to the other target CPU architectures (x64 and arm) is small and I have
been preparing the patched sources for it.

The obvious next step is 8g, but I'm holding back on that right now
so that more extensive testing can take place, rather than propagate
bad decisions.

I need some help testing the work so far, even more I need some sound
advice, specifically on how to release the scaffolding needed for the Plan
9 environment without prematurely adding it to the Go release.  At the
moment, I'm using a CVS repository as a poor(stupid?)-man's version
of Mercurial Queues and it is possible that this will continue to be
adequate for a while still; I'm concerned about failure of vision, though.

Putting the repository on "sources" may be one way of propagating my
efforts at this point, but for obvious reasons updates will have to be
submitted on a different channel.  Again, suggestions are welcome.  I do
have Mercurial available on a public server, but I'm not comfortable with
the tool enough to encourage its use at this point, I find grasping all
the facets of revision control provided by mercurial extremely difficult.

As for the testing required, I am looking for confirmation that 8c, 8a
and 8l perform as expected in a Plan 9/386 environment, it is building
this environment that I find hard to do right now, hence my request for
some assistance.  Naturally, this can all be discussed offline.

++L

Re: [9fans] GNU/Linux/Plan 9 disto

[hiro]

Compiling should be called decompressing ;)

Re: [9fans] GNU/Linux/Plan 9 disto

[Richard Miller]

> On
> plan9 of course I don't pull from sources over my mobile phone,
> instead pull and compile on the CPU server.

Compiling on a phone is no longer so far-fetched.  Compiling all
of plan9port from scratch on a Nokia n900 takes about 1.5 hours.
It seems to be less hassle just to install gcc on the n900 than to
set up Nokia's weird cross-compiling environment on another host.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Francisco J Ballesteros]

If you could put just a tgz at sources I'm willing to test it,
even for updates, I could just unpack the tgz again and rebuild the thing.
although I don't have much spare time these days and it's likely
I wont be able to help other than by testing (sorry about that).

But it's great news in any case :)
Thanks a lot to you guys.

On Tue, Jul 12, 2011 at 5:13 PM, Lucio De Re <lucio@proxima.alt.za> wrote:
> On Tue, Jul 12, 2011 at 08:59:22AM +0300, Pavel Zholkover wrote:
>>
>> I'm not sure about gcc, but the go toolchain can produce quite well working
>> Plan 9 binaries.
>>
>> Taru also has the go toolchain running native in itself after some
>> modifications.
>>
> Is there a link to this, please?
>
> I want to take this opportunity to inform 9fans that Russ Cox has helped
> me extensively to update the Go release so that the source code for
> the 386 assembler, linker and C compiler (8a, 8l and 8c) can be built
> without further modification on a 386 Plan 9 native platform.  The leap
> to the other target CPU architectures (x64 and arm) is small and I have
> been preparing the patched sources for it.
>
> The obvious next step is 8g, but I'm holding back on that right now
> so that more extensive testing can take place, rather than propagate
> bad decisions.
>
> I need some help testing the work so far, even more I need some sound
> advice, specifically on how to release the scaffolding needed for the Plan
> 9 environment without prematurely adding it to the Go release.  At the
> moment, I'm using a CVS repository as a poor(stupid?)-man's version
> of Mercurial Queues and it is possible that this will continue to be
> adequate for a while still; I'm concerned about failure of vision, though.
>
> Putting the repository on "sources" may be one way of propagating my
> efforts at this point, but for obvious reasons updates will have to be
> submitted on a different channel.  Again, suggestions are welcome.  I do
> have Mercurial available on a public server, but I'm not comfortable with
> the tool enough to encourage its use at this point, I find grasping all
> the facets of revision control provided by mercurial extremely difficult.
>
> As for the testing required, I am looking for confirmation that 8c, 8a
> and 8l perform as expected in a Plan 9/386 environment, it is building
> this environment that I find hard to do right now, hence my request for
> some assistance.  Naturally, this can all be discussed offline.
>
> ++L
>
>

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Skip Tavakkolian]

i can test, i can also give you access to my environment if you want.

-Skip

On Tue, Jul 12, 2011 at 8:13 AM, Lucio De Re <lucio@proxima.alt.za> wrote:
> On Tue, Jul 12, 2011 at 08:59:22AM +0300, Pavel Zholkover wrote:
>>
>> I'm not sure about gcc, but the go toolchain can produce quite well working
>> Plan 9 binaries.
>>
>> Taru also has the go toolchain running native in itself after some
>> modifications.
>>
> Is there a link to this, please?
>
> I want to take this opportunity to inform 9fans that Russ Cox has helped
> me extensively to update the Go release so that the source code for
> the 386 assembler, linker and C compiler (8a, 8l and 8c) can be built
> without further modification on a 386 Plan 9 native platform.  The leap
> to the other target CPU architectures (x64 and arm) is small and I have
> been preparing the patched sources for it.
>
> The obvious next step is 8g, but I'm holding back on that right now
> so that more extensive testing can take place, rather than propagate
> bad decisions.
>
> I need some help testing the work so far, even more I need some sound
> advice, specifically on how to release the scaffolding needed for the Plan
> 9 environment without prematurely adding it to the Go release.  At the
> moment, I'm using a CVS repository as a poor(stupid?)-man's version
> of Mercurial Queues and it is possible that this will continue to be
> adequate for a while still; I'm concerned about failure of vision, though.
>
> Putting the repository on "sources" may be one way of propagating my
> efforts at this point, but for obvious reasons updates will have to be
> submitted on a different channel.  Again, suggestions are welcome.  I do
> have Mercurial available on a public server, but I'm not comfortable with
> the tool enough to encourage its use at this point, I find grasping all
> the facets of revision control provided by mercurial extremely difficult.
>
> As for the testing required, I am looking for confirmation that 8c, 8a
> and 8l perform as expected in a Plan 9/386 environment, it is building
> this environment that I find hard to do right now, hence my request for
> some assistance.  Naturally, this can all be discussed offline.
>
> ++L
>
>

Re: [9fans] GNU/Linux/Plan 9 disto

[Ethan Grammatikidis]

On Tue, 12 Jul 2011 19:09:44 +0100
Richard Miller <9fans@hamnavoe.com> wrote:

> > On
> > plan9 of course I don't pull from sources over my mobile phone,
> > instead pull and compile on the CPU server.
>
> Compiling on a phone is no longer so far-fetched.  Compiling all
> of plan9port from scratch on a Nokia n900 takes about 1.5 hours.
> It seems to be less hassle just to install gcc on the n900 than to
> set up Nokia's weird cross-compiling environment on another host.

This is exactly what I found on my Zaurus a few years ago... and then I found that the available basesystems were broken for compilation and putting a sane basesystem together was impossible. Glibc was installed, and recompiling that was... well, I never succeeded despite trying very hard and having plenty of time to put into it. Deitlibc didn't even have an arm port when I first wanted one, and ucLibc again wanted to do everything in a confusing alternate environment. It wasn't exactly cross-compilation, it was an environment which ran in QEmu, but anything I built in that QEmu VM wouldn't run on the real hardware, despite static linking. Horrible mess. I never did get to use that Zaurus properly. Hm, I never finished getting p9p to compile, either. I submitted one small patch but it wasn't all that was needed and I lost interest in the Zaurus altogether about a year before p9p was fixed for arm/Linux.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Tue, Jul 12, 2011 at 08:35:26PM +0200, Francisco J Ballesteros wrote:
> If you could put just a tgz at sources I'm willing to test it,
> even for updates, I could just unpack the tgz again and rebuild the thing.
> although I don't have much spare time these days and it's likely
> I wont be able to help other than by testing (sorry about that).
>
OK, here's my side of things.

I've uploaded to sources the /go hierarchy that, to the best of my
knowledge, should make it possible for a mildly savvy Plan 9 user to
build 8a, 8l and 8c on a 386 platform.

The location is /n/sources/contrib/lucio/go and is meant to install in
the root (at /go, to be specific).  I have hard coded in many mkfiles the
assignment ROOT=/go to keep things simple, so it's easiest to go along
with this convention until somebody puts some effort into improving is.

The test operation I perform is to change directory to /go/src/cmd/8c
and execute "mk".  It ought to execute without problems, but my Plan 9
platform may have some tweaks that I have forgotten, so it's important
to report to me anything unexpected.

If "8c" builds correctly, the executable can be "mk install"ed into
/go/386/bin, off the cuff I'm notsure that this directory is created,
so it may be necessary to check first.  I would need to correct the
"devproto" file (in "/go") to make sure all target directories are in
fact created.

To build your own development environment, I suggest:

	% 9fs sources
	% disk/mkext -a -s /n/sources/contrib/lucio/go /n/sources/contrib/lucio/go/devproto |
		disk/mkext -d /go

There are many inconsistencies I am vaguely aware of, feel free to remind
me and make suggestion on how to improve them.	The mkfiles randomly rely
on GOROOT et al or make their own decisions about where the sources are
installed: they need to be identified, some thought applied and a final
approach decided upon.	/sys/src/cmd/mk* files are used arbitrarily
(these are the ones I remember, others may bite you as well), the idea
is that if we need slight variations we ought to target $ROOT/src/cmd/mk*
instead, but these are early days and there are inconsistencies lurking.

/go/386/include/u.h is particularly of interest: bits of fluff have been
tucked away in there to simplify porting and may appear particularly ugly.

I will try to document all the important details, but like all
programmers, I have a subconscious need to avoid documenting anything
at all costs.  I will reply to all reasonable questions.

Lucio.

PS: I assume there are p9p users here who, like me, believe it would be
advantageous to add the Go toolchain to the p9p distribution.  I'd like
to hear from them.  I can't give that particular task a high priority,
but I'm keen to encourage others to make some progress on that front.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Wed, Jul 13, 2011 at 08:31:58PM +0200, Lucio De Re wrote:
> There are many inconsistencies I am vaguely aware of, feel free to remind
> me and make suggestion on how to improve them.

One problem is the lack of execute permissions, you may have to fix these.

Lucio.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[stephano zanzin]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

Great! I just came to the list today looking for some content about Go in
p9, I'll code many stuff in Go and was wondering if it was ported. Count me
in for testing and would be much appreciated if you highlight what have been
done to bring 386 Go over Plan 9.

On Wed, Jul 13, 2011 at 3:45 PM, Lucio De Re <lucio@proxima.alt.za> wrote:

> On Wed, Jul 13, 2011 at 08:31:58PM +0200, Lucio De Re wrote:
> > There are many inconsistencies I am vaguely aware of, feel free to remind
> > me and make suggestion on how to improve them.
>
> One problem is the lack of execute permissions, you may have to fix these.
>
> Lucio.
>
>


--
S.

[-- Attachment #2: Type: text/html, Size: 992 bytes --]

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Thu, Jul 14, 2011 at 03:59:08PM -0300, stephano zanzin wrote:
>
> Great! I just came to the list today looking for some content about Go in
> p9, I'll code many stuff in Go and was wondering if it was ported. Count me
> in for testing and would be much appreciated if you highlight what have been
> done to bring 386 Go over Plan 9.
>
It is possible to cross-compile Go on Linux for Plan 9, the details are
a bit vague and I, for one, would not mind somebody rehashing them here
or providing a pointer to them.

The stuff I'm working on is nowhere near ready for prime time.  But it's
progress.

++L

PS: I'm assembly a TODO list for my end of the action, I fear it is a
pretty long one :-(

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Iruatã Souza]

http://groups.google.com/group/golang-dev/browse_thread/thread/c44be49fe9ca42e7/cb98571d81888b9f?lnk=gst&q=plan9front#cb98571d81888b9f

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Fazlul Shahriar]

On Thu, Jul 14, 2011 at 4:21 PM, Lucio De Re <lucio@proxima.alt.za> wrote:
> It is possible to cross-compile Go on Linux for Plan 9, the details are
> a bit vague and I, for one, would not mind somebody rehashing them here
> or providing a pointer to them.

I have a script shown below that I source. Then, running ./make.bash
in $GOROOT/src will build and install everything. You can also build
tests using the host system's gotest (run with -c flag). I'm disabling
hg because codereview might attempt to run Plan 9's gofmt, etc, which
won't work and mess up your CL. More details about the environment
variables are here: http://golang.org/doc/install.html#environment

export GOROOT=/s/9vx/go
export GOOS=plan9
export GOARCH=386
export GOHOSTOS=linux
export GOHOSTARCH=386
export GOBIN=$GOROOT/bin
export PATH=$GOROOT/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/games:$PLAN9/bin
export PS1="goplan9; "
alias goplan9=:
alias gotest=$HOME/go/bin/gotest
alias gofmt=$HOME/go/bin/gofmt
alias hg='echo this is a cross-compile env'

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

I've been trying to port (GNU) bison to Plan 9 to make it easier
to get the Go release to compile under the Plan 9 native toolchain.
I needed to take a breather yesterday, it is just oh so frustrating!
Has anyone got bison ported yet?  I suppose I could try linuxemu (hadn't
thought of that!) in desperation, although I think I'll get there with
a fresh effort.

Where are the yacc experts?  The Go release desperately needs a yacc
advocate.  Desperately, as the Go Authors (you know who you are :-)
are hard to persuade when changes to the release are expansive.

I do appreciate their philosophy.  Looking at the amount of work that
goes into Go daily, I'm amazed at how hard they work and at the fact that
they can do any development on top of actively reviewing all submissions.

I was thinking that Google ought to employ someone to do just reviewing
(a small team), as suggested by Fred Brooks in the Mythical Man Month",
but I know that the quality persons required in that role would lose their
minds pretty quickly, no matter how good the tools available to them.

Anyway, I'm unhappily quagmired right now, I'll make some sort of
announcement when I find my way out.

++L

PS: The Go release will eventually slow down, one expects. At that point,
perhaps, one ought to apply a lavish amount of quality control.  Hm,
maybe a wish list can be the first step to that?  I have a few items...

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Ethan Grammatikidis]

On Fri, 22 Jul 2011 06:40:38 +0200
Lucio De Re <lucio@proxima.alt.za> wrote:

> I've been trying to port (GNU) bison to Plan 9 to make it easier
> to get the Go release to compile under the Plan 9 native toolchain.
> I needed to take a breather yesterday, it is just oh so frustrating!
> Has anyone got bison ported yet?  I suppose I could try linuxemu (hadn't
> thought of that!) in desperation, although I think I'll get there with
> a fresh effort.

Go has already been ported by Taru, a fact noted in the thread on
golang-nuts where you announced your intention to try to port Go a
little while ago. Is it so hard as that to see how she did
it?

Source:
http://pkg.violetti.org/src/go-2011.05.10.tbz

Actually, I asked her and she's happy for you to email her with
questions, too. taruti@taruti.net

Sorry if I sound a bit snippy. I have struggled with various compiles
myself and reached the conclusion that any such struggling is pointless
when there's any other way, so it's a bit painful to watch you
struggling to duplicate work already done.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[kokamoto]

> Source:
> http://pkg.violetti.org/src/go-2011.05.10.tbz

I tried this just now.
It's amazing!
Thanks to the author, and you.

I've been had an interest to Golang.   However, I don't like Mac OSX and Linux.
Yes, I tried them, however....

Now I can look into Golang on my Plan9 system.

Kenji

Re: [9fans] GNU/Linux/Plan 9 disto

[Enrico Weigelt]

* Jens Staal <staal1978@gmail.com> wrote:

> Personally, I believe that a Plan9 target for a cross compiler might
> be more interesting. GCC already added support for the Plan9 dialect
> of C. If it also could be made to compile Plan9 binaries, it could be
> used for an alternative self-hosting distro as the one you envisaged.

ACK. If, lets say, crosstool-NG could produce an GCC-alike (not necessarily
GCC itself, but supporting the same command line interfaces) cross-toolchain
for native Plan9 and p9p, that would be a *big* help. Perhaps even extend
the autohell to support it.

On the other hand, we could also port plan9's make to GNU natively.


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] GNU/Linux/Plan 9 disto

[Enrico Weigelt]

* Charles Forsyth <forsyth@terzarima.net> wrote:
> >waserror() depends on callee-save.
>
> caller-save, and a few other conventions (or rather, no need for more conventions).
> specifically, it's enough to save the pc and stack. all variables will
> have the right values on non-zero return from setjmp, regardless of the
> presence or absence of "volatile", and that return can be done by
> simply setting the pc and the stack pointer to the values in the jmp_buf.

What exactly is different between these calling conventions ?
How much does the Plan9 code depend on them ?


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] GNU/Linux/Plan 9 disto

[erik quanstrom]

> * Charles Forsyth <forsyth@terzarima.net> wrote:
> > >waserror() depends on callee-save.
> > 
> > caller-save, and a few other conventions (or rather, no need for more conventions).
> > specifically, it's enough to save the pc and stack. all variables will
> > have the right values on non-zero return from setjmp, regardless of the
> > presence or absence of "volatile", and that return can be done by
> > simply setting the pc and the stack pointer to the values in the jmp_buf.
> 
> What exactly is different between these calling conventions ?

http://en.wikipedia.org/wiki/Calling_convention

> How much does the Plan9 code depend on them ?

since you haven't specified a unit with which to measure
this dependency, i'll give it as 1.773 µdirac/tatum·fortnight.
alternatively, i've seen this specified as 6.773 Mlenat·emacs.
(it just looks stupendous when you think of it that way.)

in other words, it's not a deep dependency, but a pervasive
and difficult to dislodge one.  without the convention, waserror()
becomes too subtile and quick to anger to be of any use to
mortal programmers.

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Sat, Jul 23, 2011 at 05:14:07AM -0400, erik quanstrom wrote:
> in double-checking this patch, i found that // comments are
> already used in cc.y.  the difference in output between the
> old yacc and the new version is amusing.  yacc doesn't see
> the comment and translates $n in the comments.
>
Thanks for going to all that trouble, Erik, I really appreciate it.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Ethan Grammatikidis]

On Fri, 22 Jul 2011 18:59:02 -0400
Russ Cox <rsc@swtch.com> wrote:

> go uses various features of bison to make
> writing the grammar easier and to be able
> to give good syntax error diagnostics.
>
> there are two viable choices here.
>
> 1. port bison.
> 2. run bison on another system,
> copy the go.tab.[ch] files over,
> and don't delete them.
>
> if #1 is too much, do #2, which is trivial.

All right, I won't waste my time then. I think someone else has already mentioned linuxemu as a possible 'other system' to run bison on. Linuxemu seems to come up a lot lately, I would like to hope it lasts as a suitable environment for this sort of thing, but knowing gnoonix (if you'll pardon the slur) I don't suppose it will.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

in double-checking this patch, i found that // comments are
already used in cc.y.  the difference in output between the
old yacc and the new version is amusing.  yacc doesn't see
the comment and translates $n in the comments.

- erik

----
in cpyact() replace case '/' with

	case '/':
		/* look for comments; sync with skipcom() */

		Bputrune(faction, c);
		c = Bgetrune(finput);
		switch(c){
		default:
			goto lcopy;
		case '/':
			Bputrune(faction, c);
			while((c = Bgetrune(finput)) != Beof){
				Bputrune(faction, c);
				if(c == '\n'){
					lineno++;
					goto loop;
				}
			}
			break;

		case '*':
			Bputrune(faction, c);
			match = 0;
			while((c = Bgetrune(finput)) != Beof){
				Bputrune(faction, c);
				if(c == '\n')
					lineno++;
				if(match && c == '/')
					goto loop;
				match = c == '*';
			}
			break;
		case Beof:
			break;
		}
		error("EOF inside comment");

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Russ Cox]

go uses various features of bison to make
writing the grammar easier and to be able
to give good syntax error diagnostics.

there are two viable choices here.

1. port bison.
2. run bison on another system,
copy the go.tab.[ch] files over,
and don't delete them.

if #1 is too much, do #2, which is trivial.

russ

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Ethan Grammatikidis]

On Fri, 22 Jul 2011 21:00:53 +0200
Lucio De Re <lucio@proxima.alt.za> wrote:

> On Fri, Jul 22, 2011 at 07:30:47PM +0100, Ethan Grammatikidis wrote:
> >
> > On Fri, 22 Jul 2011 17:35:24 +0100
> > "Steve Simon" <steve@quintile.net> wrote:
> >
> > > My understanding is that bison can be convinced to output some static
> > > tables which the Go authors munge into some C source (with awk).
> >
> > I wonder what it would take to add that feature to Plan 9's yacc. I'm
> > not normally one to suggest adding features, but if the authors of Go
> > found it useful I'm a bit inclined to think about it.
>
> Now that's a suggestion that makes some sense.  I'll see if I can
> figure out how Bison does it and if it is not too tightly coupled to
> bison-specific internals, I may be able to enhance yacc.  Don't hold
> your breath.

Not holding my breath. :) After reading Erik's reply I decided to look
at it from the other end; the go internals to see if there was another
way of doing it, but yeah, no-one should hold their breath on my
account either.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Bakul Shah]

On Fri, 22 Jul 2011 15:09:35 EDT erik quanstrom <quanstro@labs.coraid.com>  wrote:
> > What does pcc have to do with this? This is a yacc problem. [Also tested
> > on 9atom]
>
> did you rebuild from source?  the yacc binary might be older than ~jan 2010.
>
> - erik

Just did. yacc.c on the 9atom VM has a date of May 6, 2011.
Did I do a `pull' since then?  No.  plan9 for me is just a toy
so I avoid using painful things like replica! I don't
understand why the main plan9 repo is not switched over to
mercurial (or why the community has not agreed on an
alternative mercurial repo).

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Bakul Shah]

On Fri, 22 Jul 2011 19:48:41 +0200 Lucio De Re <lucio@proxima.alt.za>  wrote:
> The crucial feature is that any changes to the Go distribution should slot
> into the Plan 9 port of Go as seamlessly as possible.

Agree with the goal.

>            As it may take me many months to get the project completed,
> I'd rather work in tandem with the Go runtime developers, who seem to
> have taken the same route as I have, namely to include their changes _in_
> the Go distribution as they go along.

Iteratively plan9 specific diffs will get smaller and smaller
but it will take a long time.  This is precisely why I
suggested do a quick port (of course, while minimizing
changes). That allows people start using go in plan9 as soon
as possible and you will then likely have more help. In
parallel you can work with the go developers to integrate your
changes.

> > I'd first fix Make.* to use byacc, or even better, p9p yacc, and
> > run all the tests on a bsd and just fix %error-verbose. If they pass,
> > no need to port bison or may be even byacc.
>
> That's an interesting approach I had not considered.  It involves
> considerable throw-away work, but it will be instructive.  Right now
> my priority is to smooth out quite a few wrinkles in my repository,
> where the last batch of changes needs extensive rework, not all caused
> by Bison-itis.  As soon as I have my head out of the water, I'll follow
> the much appreciated advice I have received from you all.

I already did the easy part!  p9p yacc needs to be updated to
p9 yacc as it doesn't understand //.  byacc works but things
fail at bisonerrors script use.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 11:55:45AM -0700, Bakul Shah wrote:
> On Fri, 22 Jul 2011 14:48:44 EDT "ComeauAt9Fans@gmail.com" <comeauat9fans@gmail.com>  wrote:
> > On Jul 22, 2011, at 2:38 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> > > On Fri, 22 Jul 2011 13:53:41 EDT erik quanstrom <quanstro@labs.coraid.com>=
> >   wrote:
> > >> can you give am example where // comments with ' cause
> > >> trouble.  i can't replicate.
> > >>
> > >> - erik
> > >
> > > In 9vx:
> > >
> > > term% yacc go/src/cmd/gc/go.y
> > >
> > > fatal error:newline in string or char. const., /go/src/cmd/gc/go.y:528
> > >
> > >
> > >        // If the last token read by the lexer was consumed
> > >        // as part of the case, clear it (parser has cleared yychar).
> > >        // If the last token read by the lexer was the lookahead
> > >        // leave it alone (parser has it cached in yychar).
> > > ====>  // This is so that the stmt_list action doesn't look at
> > >        // the case tokens if the stmt_list is empty.
> > >        yylast = yychar;
> >
> > pcc accepts -+ as well as cpp, perhaps a way to pass it as an environment and
> > /or make variable?
>
> What does pcc have to do with this? This is a yacc problem. [Also tested
> on 9atom]

I don't know either, but the yacc source doesn't explain how this
error arises.  Erik is right to be skeptical.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

> What does pcc have to do with this? This is a yacc problem. [Also tested
> on 9atom]

did you rebuild from source?  the yacc binary might be older than ~jan 2010.

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[tlaronde]

On Fri, Jul 22, 2011 at 02:53:12PM -0400, erik quanstrom wrote:
> > pcc accepts -+ as well as cpp, perhaps a way to pass it as an environment and/or make variable?
>
> how about making it the default and ignore the option.

The '//' is really an unfortunate thing, since "divide multiply" or
"multiply divide" ('/*' and '*/') are an invalid combination so a good
choice for the comments, while '//' could be an operator (whether a
"geometrical" one, or for parallelization of processes in an extension
of C).

So, but it is a personal taste, by principle it should not be a default.

>From a practical point of view...
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 11:32:43AM -0700, Skip Tavakkolian wrote:
> I really would like an educated answer to this -- if anyone has done
> the deep thinking:  Can I assume that I can use linuxemu -- as a close
> enough approximation of linux -- to run the Go build (i.e. all.bash)?
> Or, can anyone think of a reason why it would not work?
>
I assumed I could use linuxemu for Bison, at least, but I have not tried.
The build is pretty much location independent, but I imagine you'll find
at least a few assumptions that linuxemu does not satisfy.  Please let
us all know how it goes.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 07:30:47PM +0100, Ethan Grammatikidis wrote:
>
> On Fri, 22 Jul 2011 17:35:24 +0100
> "Steve Simon" <steve@quintile.net> wrote:
>
> > My understanding is that bison can be convinced to output some static
> > tables which the Go authors munge into some C source (with awk).
>
> I wonder what it would take to add that feature to Plan 9's yacc. I'm
> not normally one to suggest adding features, but if the authors of Go
> found it useful I'm a bit inclined to think about it.

Now that's a suggestion that makes some sense.  I'll see if I can
figure out how Bison does it and if it is not too tightly coupled to
bison-specific internals, I may be able to enhance yacc.  Don't hold
your breath.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 02:22:54PM -0400, ComeauAt9Fans@gmail.com wrote:
>
> On Jul 22, 2011, at 1:53 PM, erik quanstrom <quanstro@labs.coraid.com> wrote:
> > can you give am example where // comments with ' cause
> > trouble.  i can't replicate.
>
> My guess is that he is not referring to 8c et al but too pcc. That means something like:
>
> // I can't replicate
>
> Becomes an error. Many classic UNIX[-like] preprocessors will diagnose
> it as an error as it's pre-ANSI processing

The fact is, the "'" is reported as an error in "cmd/gc/go.y" and
"cmd/gc/mkbuiltin.c" and whereas the latter is correct, the former doesn't
make sense.  The comments are within "C" code that should not be compiled
with pcc but with 8c.  I need to get to the bottom of that problem.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Bakul Shah]

On Fri, 22 Jul 2011 14:48:44 EDT "ComeauAt9Fans@gmail.com" <comeauat9fans@gmail.com>  wrote:
> On Jul 22, 2011, at 2:38 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> > On Fri, 22 Jul 2011 13:53:41 EDT erik quanstrom <quanstro@labs.coraid.com>=
>   wrote:
> >> can you give am example where // comments with ' cause
> >> trouble.  i can't replicate.
> >>
> >> - erik
> >
> > In 9vx:
> >
> > term% yacc go/src/cmd/gc/go.y
> >
> > fatal error:newline in string or char. const., /go/src/cmd/gc/go.y:528
> >
> >
> >        // If the last token read by the lexer was consumed
> >        // as part of the case, clear it (parser has cleared yychar).
> >        // If the last token read by the lexer was the lookahead
> >        // leave it alone (parser has it cached in yychar).
> > ====>  // This is so that the stmt_list action doesn't look at
> >        // the case tokens if the stmt_list is empty.
> >        yylast = yychar;
>
> pcc accepts -+ as well as cpp, perhaps a way to pass it as an environment and
> /or make variable?

What does pcc have to do with this? This is a yacc problem. [Also tested
on 9atom]

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 02:20:37PM -0400, erik quanstrom wrote:
>
> > Russ correctly points out that the problem lies with cpp and not with 8c,
> > while careful inspection of the yacc sources including your correction to
> > accept // does not reveal any way in which yacc can be held responsible.
>
> are you giving cpp the -+ option?
> cpp doesn't eat // comments by default.
>
As mentioned, I put considerable effort to avoid cpp and currently have
no idea what I've missed.  Russ also raised that issue, I have known
about -+ since then.

Thanks for bringing it up, anyway.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

> pcc accepts -+ as well as cpp, perhaps a way to pass it as an environment and/or make variable?

how about making it the default and ignore the option.

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[ComeauAt9Fans@gmail.com]

On Jul 22, 2011, at 2:33 PM, erik quanstrom <quanstro@labs.coraid.com> wrote:

> On Fri Jul 22 14:32:43 EDT 2011, eekee57@fastmail.fm wrote:
>> On Fri, 22 Jul 2011 17:35:24 +0100
>> "Steve Simon" <steve@quintile.net> wrote:
>> 
>>> My understanding is that bison can be convinced to output some static
>>> tables which the Go authors munge into some C source (with awk).
>> 
>> I wonder what it would take to add that feature to Plan 9's yacc. I'm not normally one to suggest adding features, but if the authors of Go found it useful I'm a bit inclined to think about it.
> 
> can you make this argument independent of go?  it could
> be that go could have done it differently but chose to depend
> on a bison feature.

Erik has a good point; don't assume too much even if they had a reason 

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[ComeauAt9Fans@gmail.com]

On Jul 22, 2011, at 2:38 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> On Fri, 22 Jul 2011 13:53:41 EDT erik quanstrom <quanstro@labs.coraid.com>  wrote:
>> can you give am example where // comments with ' cause
>> trouble.  i can't replicate.
>> 
>> - erik
> 
> In 9vx:
> 
> term% yacc go/src/cmd/gc/go.y
> 
> fatal error:newline in string or char. const., /go/src/cmd/gc/go.y:528
> 
> 
>        // If the last token read by the lexer was consumed
>        // as part of the case, clear it (parser has cleared yychar).
>        // If the last token read by the lexer was the lookahead
>        // leave it alone (parser has it cached in yychar).
> ====>        // This is so that the stmt_list action doesn't look at
>        // the case tokens if the stmt_list is empty.
>        yylast = yychar;

pcc accepts -+ as well as cpp, perhaps a way to pass it as an environment and/or make variable?

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

>  fatal error:newline in string or char. const., /go/src/cmd/gc/go.y:528
>
>
> 		// If the last token read by the lexer was consumed
> 		// as part of the case, clear it (parser has cleared yychar).
> 		// If the last token read by the lexer was the lookahead
> 		// leave it alone (parser has it cached in yychar).
> ====>		// This is so that the stmt_list action doesn't look at
> 		// the case tokens if the stmt_list is empty.
> 		yylast = yychar;

i still can't replicate.  i pasted exactly this block into a yacc file
and it works just fine.  are you sure you are using up-to-date
binaries?  barring that, can you send me the .y file?

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Bakul Shah]

On Fri, 22 Jul 2011 13:53:41 EDT erik quanstrom <quanstro@labs.coraid.com>  wrote:
> can you give am example where // comments with ' cause
> trouble.  i can't replicate.
>
> - erik

In 9vx:

term% yacc go/src/cmd/gc/go.y

 fatal error:newline in string or char. const., /go/src/cmd/gc/go.y:528


		// If the last token read by the lexer was consumed
		// as part of the case, clear it (parser has cleared yychar).
		// If the last token read by the lexer was the lookahead
		// leave it alone (parser has it cached in yychar).
====>		// This is so that the stmt_list action doesn't look at
		// the case tokens if the stmt_list is empty.
		yylast = yychar;

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

On Fri Jul 22 14:32:43 EDT 2011, eekee57@fastmail.fm wrote:
> On Fri, 22 Jul 2011 17:35:24 +0100
> "Steve Simon" <steve@quintile.net> wrote:
>
> > My understanding is that bison can be convinced to output some static
> > tables which the Go authors munge into some C source (with awk).
>
> I wonder what it would take to add that feature to Plan 9's yacc. I'm not normally one to suggest adding features, but if the authors of Go found it useful I'm a bit inclined to think about it.

can you make this argument independent of go?  it could
be that go could have done it differently but chose to depend
on a bison feature.

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Skip Tavakkolian]

I really would like an educated answer to this -- if anyone has done
the deep thinking:  Can I assume that I can use linuxemu -- as a close
enough approximation of linux -- to run the Go build (i.e. all.bash)?
Or, can anyone think of a reason why it would not work?

-Skip

P.S. at any rate, I plan to try this over the weekend.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

On Fri Jul 22 14:25:06 EDT 2011, comeauat9fans@gmail.com wrote:
> On Jul 22, 2011, at 1:53 PM, erik quanstrom <quanstro@labs.coraid.com>
> wrote:
> > can you give am example where // comments with ' cause trouble.  i
> > can't replicate.
> >
> My guess is that he is not referring to 8c et al but too pcc.  That
> means something like:
>
> // I can't replicate
>
> Becomes an error.  Many classic UNIX[-like] preprocessors will
> diagnose it as an error as it's pre-ANSI processing

i think that's pretty much it.

the original claim was that yacc had troubles, but i don't see
a problem.  in fact a quick read of the code says that yacc is clean.
however, cpp if not given the -+ option will not recognize
c++ comments (see fixlex()), and is sure that ' is to be interpreted
as in c.  therefore, it does tend to do strange things if it can't match
's.

why does go need cpp?  is the go source that littered with
preprocessor gnarlies?  that would be a big dissapointment.

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Ethan Grammatikidis]

On Fri, 22 Jul 2011 17:35:24 +0100
"Steve Simon" <steve@quintile.net> wrote:

> My understanding is that bison can be convinced to output some static
> tables which the Go authors munge into some C source (with awk).

I wonder what it would take to add that feature to Plan 9's yacc. I'm not normally one to suggest adding features, but if the authors of Go found it useful I'm a bit inclined to think about it.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[ComeauAt9Fans@gmail.com]

On Jul 22, 2011, at 1:53 PM, erik quanstrom <quanstro@labs.coraid.com> wrote:
> can you give am example where // comments with ' cause
> trouble.  i can't replicate.

My guess is that he is not referring to 8c et al but too pcc. That means something like:

// I can't replicate

Becomes an error. Many classic UNIX[-like] preprocessors will diagnose it as an error as it's pre-ANSI processing

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

> Russ correctly points out that the problem lies with cpp and not with 8c,
> while careful inspection of the yacc sources including your correction to
> accept // does not reveal any way in which yacc can be held responsible.

are you giving cpp the -+ option?
cpp doesn't eat // comments by default.

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Ethan Grammatikidis]

On Fri, 22 Jul 2011 19:48:41 +0200
Lucio De Re <lucio@proxima.alt.za> wrote:

> For the rest, I have been alerted in private mail that Taru's work
> contains many adjustments whose intention was to get the code to compile.
> I have a similar code base and Erik Quanstrom has another.  I know my
> early set of patches is totally inadequate today, I often refer to it in
> this phase of this project.  I presume that Erik and Taru both will find
> their patches significantly out of sync with future Go releases before
> too long.  As it may take me many months to get the project completed,
> I'd rather work in tandem with the Go runtime developers, who seem to
> have taken the same route as I have, namely to include their changes _in_
> the Go distribution as they go along.

My apologies, I didn't understand quite how much the Go codebase changes.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 01:53:41PM -0400, erik quanstrom wrote:
> can you give am example where // comments with ' cause
> trouble.  i can't replicate.
>
I don't have an example ready at hand.

Russ correctly points out that the problem lies with cpp and not with 8c,
while careful inspection of the yacc sources including your correction to
accept // does not reveal any way in which yacc can be held responsible.

But I do not use cpp in the Go port so I have no idea why I encounter
the same problem as Bakul.  Just to be even more explicit, I used pcc to
compile cmd/gc/mkbuiltin1.c and it failed, as expected.  I have modified
mkbuiltin1.c to compile under 8c now, the problem has been resolved.

Weird, but I haven't yet reached a point where I can investigate this
to greater depth.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 07:53:30PM +0200, Lucio De Re wrote:
> That suggests that porting Bison is a "must" as anything else will
> not meet the criterion of being included in the Go distribution.
> Bootstrapping Bison seems to be my main obstacle (it relies on Bison
> features, not least the very same %error-verbose I have encountered in
> Go), but it can be overcome by using cross-processing from either NetBSD
> or UBUNTU, so that's just some effort on my part.
>
I fear this is the exact opposite of what Bakul recommends.  I hope
it is clear that my approach is totally contrary to his suggestions,
through no ill will on either side :-)

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

can you give am example where // comments with ' cause
trouble.  i can't replicate.

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 05:35:24PM +0100, Steve Simon wrote:
>
> My understanding is that bison can be convinced to output some static
> tables which the Go authors munge into some C source (with awk).
>
> These tables allow the Go parser to generate more useful and
> accurate error messages.
>
That matches my recollections from some superficial inspection a few days
ago.  Thanks for bringing these memories back and clarifying them for me.

> I believe using bison is not mandatory if you don't mind hacking
> the code a little, but you won't get the nicer error handling.
>
That suggests that porting Bison is a "must" as anything else will
not meet the criterion of being included in the Go distribution.
Bootstrapping Bison seems to be my main obstacle (it relies on Bison
features, not least the very same %error-verbose I have encountered in
Go), but it can be overcome by using cross-processing from either NetBSD
or UBUNTU, so that's just some effort on my part.

> This is educated guesswork from looking at the code a few months ago,
> please don't treat it as gospel.
>
Pretty good analysis, if my memory is anything to go by.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 08:39:56AM -0700, Bakul Shah wrote:
>
> Is your goal to a) have the standard go distribution build on plan9
> with no changes or b) do a minimal infrastructure to make future ports
> easy or c) do a one time port?
>
The crucial feature is that any changes to the Go distribution should slot
into the Plan 9 port of Go as seamlessly as possible.  What has happened
to me a couple of times since Go was first released, is that I applied
immense quantities of patching to my heart's content to the released Go
sources, only to need to re-apply them, with similar difficulty only a
few month laters, to a changed source base.

I am pleased and extremely grateful that the number of such necessary
changes has been reduced significantly, with Russ Cox's help, by
incorporating these changes into the Go distribution.  At this point,
there are only two adjustments I believe will be hard to eliminate
entirely, although I think now that the second has a simple solution.

And, yes, there is a rather big carpet I have swept some items under
and Russ has rejected corrections that would be really nice to have,
in all case with a firm, but understanding hand.  The end result is that
after importing the Go distribution in toto into the Plan 9 repository I
set up for it, the 386, arm and x64 C compilers, assemblers and linkers
all are generated correctly on my Plan 9 platform.  Untested except for
8l and no doubt with some imperfections, but I consider this progress.
The code review process my patches are undergoing adds enough confidence
that I'm willing to relegate testing to some time in the future when I
have a more complete code base and the corresponding executable binaries.

I have also made my life a touch harder by declining to use the APE
environment, but the structure of the Go distribution makes that less
of a burden than one may assume.

> If it is c), why not just use the 9front port? If b) or a), why not
> look at what they have done at the very least?
>
One reason for not looking at Taru's work (I guess it is feeble, but
who is to know?) is that I don't know the status of its copyright; I
have ceded copyright to the Go Authors (more accurately, I have filled
the necessary paperwork to satisfy their legal requirements), but I can
hardly apply that cession to Taru's work.

For the rest, I have been alerted in private mail that Taru's work
contains many adjustments whose intention was to get the code to compile.
I have a similar code base and Erik Quanstrom has another.  I know my
early set of patches is totally inadequate today, I often refer to it in
this phase of this project.  I presume that Erik and Taru both will find
their patches significantly out of sync with future Go releases before
too long.  As it may take me many months to get the project completed,
I'd rather work in tandem with the Go runtime developers, who seem to
have taken the same route as I have, namely to include their changes _in_
the Go distribution as they go along.

> I'd first fix Make.* to use byacc, or even better, p9p yacc, and
> run all the tests on a bsd and just fix %error-verbose. If they pass,
> no need to port bison or may be even byacc.

That's an interesting approach I had not considered.  It involves
considerable throw-away work, but it will be instructive.  Right now
my priority is to smooth out quite a few wrinkles in my repository,
where the last batch of changes needs extensive rework, not all caused
by Bison-itis.  As soon as I have my head out of the water, I'll follow
the much appreciated advice I have received from you all.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Bakul Shah]

On Fri, 22 Jul 2011 17:37:32 +0200 Lucio De Re <lucio@proxima.alt.za>  wrote:
> But until I clear my slate of a number of distractions, I can only ask
> more knowledgeable persons to look at the code and make suggestions to
> the Go Authors, directly or through my submissions to CodeReview, on
> how to eliminate Bison dependencies that make porting the Go code base
> to Plan 9 difficult.  Or help me deal with these problems in a manner
> that can be incorporated into the Go release.

go is too big and changes too fast so rather than try bend it
in the plan9 direction, my advice is to make *no* changes to
the go sources. Just use sed / ed scripts & patch to modify
what you need to during a build, and add some plan9 specific
files/scripts -- this is approach b) from my previous email --
usually what is done in *BSD ports. This can get a port up
quickly. You may still want to feed back changes to the
authors but this usually involves lengthy interactions and is
best done in background mode.

More specifically
1. comment out %error-version
2. fix plan9 yacc to handle apostrophes in // comments because
   that is a bug.  Alternatively sed 's,//.*,/* & */,'
3. if you find any other bison dependency, work around.
4. avoid porting bison!

I commented out %error-version and removed apostrophes in //
comments in go.y and now the plan9 yacc handles the syntax
fine.

Trying all.bash with yacc, I see that the output of awk script
"bisonerrors" fails. I don't have a great desire to port go to
plan9 so I stopped here but you can checkout what is done here
in the 9front port and/or compare bison y.output.c with yacc
y.output.c because y.output.c is what bisonerrors munges. My
guess is you will need a more or less equivalent yaccerrors
script. As Steve says you won't get nicer error handling but
so it goes.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Steve Simon]

My understanding is that bison can be convinced to output some static
tables which the Go authors munge into some C source (with awk).

These tables allow the Go parser to generate more useful and
accurate error messages.

I believe using bison is not mandatory if you don't mind hacking
the code a little, but you won't get the nicer error handling.

This is educated guesswork from looking at the code a few months ago,
please don't treat it as gospel.

-Steve

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

i think we're going off the deep end.

my comments were ment to draw this line
- go used to be compatable with plan old yacc,
- and i don't think the go authors really want to depend on yacc,

so the conclusion i would draw is that the path
of least resistance is to remove the fluff from go
and be done with it.  i bet the go authors would
even accept that patch.  i'd bet that bit snuck in.

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Jul 22, 2011, at 6:03 AM, Lucio De Re <lucio@proxima.alt.za> wrote:
>> 
>> 
> So far, as Bakul pointed out, only %error-verbose (from memory) stands out
> in my most recent changes, but there are other reasons and, unfortunately,
> GNU Bison uses its own extensions to bootstrap, which is where I may
> well be getting even more muddled up.

Is your goal to a) have the standard go distribution build on plan9 with no changes or b) do a minimal infrastructure to make future ports easy or c) do a one time port?

If it is c), why not just use the 9front port? If b) or a), why not look at what they have done at the very least?

I'd first fix Make.* to use byacc, or even better, p9p yacc, and run all the tests on a bsd and just fix %error-verbose. If they pass, no need to port bison or may be even byacc.

[-- Attachment #2: Type: text/html, Size: 1523 bytes --]

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 11:13:26AM -0400, erik quanstrom wrote:
>
> why do you think changes to the grammar would depend on bison?
>
Is that what I said?  I meant that the yacc modules were almost certainly
altered considerably since the introduction of new language features.
I don't have the theoretical knowledge to establish which of the lexis
or the grammar were affected, I just believe that changes did occur and
that Bison dependencies were introduced.

But until I clear my slate of a number of distractions, I can only ask
more knowledgeable persons to look at the code and make suggestions to
the Go Authors, directly or through my submissions to CodeReview, on
how to eliminate Bison dependencies that make porting the Go code base
to Plan 9 difficult.  Or help me deal with these problems in a manner
that can be incorporated into the Go release.

Unfortunately, I'm not in a position to post to sources something that
will still compile in the Plan 9 environment, so the distractions need
to be dealt with first.

Right now, besides a few changes to my current code review submissions,
some of which have nothing to do with Bison, I also have suggestions on
porting Bison to Plan 9, checking out byacc from NetBSD, porting byacc
to Plan 9 and checking the Go port by Taru.  All of that, while losing
track of the problem(s) I was trying to address in the first place,
which I seem to remember was the presence of apostrophes (single quotes)
in // comments.  Sigh!

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

> > if it does, that is something new.  plan 9 yacc had no troubles
> > at all with the grammar when i did it.
> >
> It does, the Go syntax has changed a lot: you may have missed the efforts
> that went into dropping trailing semicolons and much other syntactic
> "candy" that has made Go quite unusual.

why do you think changes to the grammar would depend on bison?

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 08:41:49AM -0400, erik quanstrom wrote:
> On Fri Jul 22 01:37:35 EDT 2011, arnold@skeeve.com wrote:
> > Does Go use things that are bison-specific?  If not, maybe Berkeley Yacc
> > (there are various versions around) would be easier to port.
>
> if it does, that is something new.  plan 9 yacc had no troubles
> at all with the grammar when i did it.
>
It does, the Go syntax has changed a lot: you may have missed the efforts
that went into dropping trailing semicolons and much other syntactic
"candy" that has made Go quite unusual.

I think that is where the yacc changes come from, but I must confess
I'm only guessing.

So far, as Bakul pointed out, only %error-verbose (from memory) stands out
in my most recent changes, but there are other reasons and, unfortunately,
GNU Bison uses its own extensions to bootstrap, which is where I may
well be getting even more muddled up.

I will report back in a little while.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[erik quanstrom]

On Fri Jul 22 01:37:35 EDT 2011, arnold@skeeve.com wrote:
> Does Go use things that are bison-specific?  If not, maybe Berkeley Yacc
> (there are various versions around) would be easier to port.

if it does, that is something new.  plan 9 yacc had no troubles
at all with the grammar when i did it.

- erik

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 12:42:12AM -0700, Bakul Shah wrote:
> $ yacc gc/go.y
> yacc: e - line 120 of "go.y", syntax error
> %error-verbose
> ^
> This is a bison dropping. I haven't looked at the go sources
> but hopefully this can be worked around easily.
>
It resolves to a bunch of #ifdefs, #undefs, #defines, which can be
corrected easily.  But the generated code is full of issues that 8c
does not like to compile, for various reasons (I'll post the details
elsewhere when I get a chance.  I don't know if that applies to byacc.
Thanks for raising it, I do have access to byacc on NetBSD and of course
I can try to port that to Plan 9 rather than bison.  We'll see...

> I didn't actually run any of the generated code but given the
> -y flag I have hopes.... In the worst can you can write a
> bison script around byacc and massage what needs to be.
>
> Try compiling /usr/src/usr.bin/yacc from *BSD. Let me know if
> you run into problems.

I will, both, once I've refreshed my recollections and tried some
tangential possibilities.

Thanks to both of you for the help.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[arnold]

If it's bison -y -d then maybe even Plan 9 Yacc would work.

The bison dist has a manual, probably even with an index, in which you
can look up suspicious constructs and decide if they can be safely tossed
or not.

Thanks,

Arnold

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Bakul Shah]

On Fri, 22 Jul 2011 08:33:50 +0200 Lucio De Re <lucio@proxima.alt.za>  wrote:
> On Fri, Jul 22, 2011 at 05:36:42AM +0000, arnold@skeeve.com wrote:
> >
> > Does Go use things that are bison-specific?  If not, maybe Berkeley Yacc
> > (there are various versions around) would be easier to port.
> >
> That's why I ask about Bison experts, it's hard to tell how deep the
> usage of bison-specific features goes without some familiarity.  I do
> suspect that there is a whole generation of programmers out there that
> only knows the GNU dialects and I'm not a member of that club.
>
> I am only slightly curious about BSD Yacc (is that what NetBSD uses,
> I wonder?) as my education stopped short of compiler construction
> principles. Back then compiler generators were still a novelty.

You shouldn't need to dig into yacc.

I see from Make.* that has bison -y -d is used, which means it
is supposed emulate posix yacc.  Just to check I tried with
yaccing with the FreeBSD yacc:

*a/a.y  	-- ok
cc/cc.y 	-- ok
goyacc/units.y	-- ok


$ yacc gc/go.y
yacc: e - line 120 of "go.y", syntax error
%error-verbose
^
This is a bison dropping. I haven't looked at the go sources
but hopefully this can be worked around easily.

I didn't actually run any of the generated code but given the
-y flag I have hopes.... In the worst can you can write a
bison script around byacc and massage what needs to be.

Try compiling /usr/src/usr.bin/yacc from *BSD. Let me know if
you run into problems.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Fri, Jul 22, 2011 at 05:36:42AM +0000, arnold@skeeve.com wrote:
>
> Does Go use things that are bison-specific?  If not, maybe Berkeley Yacc
> (there are various versions around) would be easier to port.
>
That's why I ask about Bison experts, it's hard to tell how deep the
usage of bison-specific features goes without some familiarity.  I do
suspect that there is a whole generation of programmers out there that
only knows the GNU dialects and I'm not a member of that club.

I am only slightly curious about BSD Yacc (is that what NetBSD uses,
I wonder?) as my education stopped short of compiler construction
principles. Back then compiler generators were still a novelty.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[arnold]

Does Go use things that are bison-specific?  If not, maybe Berkeley Yacc
(there are various versions around) would be easier to port.

Arnold

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Alex Brainman]

On Friday, 15 July 2011 06:23:16 UTC+10, Lucio De Re  wrote:
> >
> It is possible to cross-compile Go on Linux for Plan 9, the details are
> a bit vague and I, for one, would not mind somebody rehashing them here
> or providing a pointer to them.
>

This is how I build windows executables on linux: http://code.google.com/p/go-wiki/wiki/WindowsCrossCompiling. I suspect, these instructions will work just fine to build plan9 executable too. You would have to replace "windows" for "plan9" everywhere.

Alex