Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)
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] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)
On Fri, Jul 22, 2011 at 05:36:42AM +, arn...@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)
On Fri, 22 Jul 2011 08:33:50 +0200 Lucio De Re lu...@proxima.alt.za wrote: On Fri, Jul 22, 2011 at 05:36:42AM +, arn...@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)
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)
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)
On Fri Jul 22 01:37:35 EDT 2011, arn...@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)
On Fri, Jul 22, 2011 at 08:41:49AM -0400, erik quanstrom wrote: On Fri Jul 22 01:37:35 EDT 2011, arn...@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)
On Fri, 22 Jul 2011 06:40:38 +0200 Lucio De Re lu...@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. tar...@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)
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)
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)
On Jul 22, 2011, at 6:03 AM, Lucio De Re lu...@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.
Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)
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)
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)
On Fri, 22 Jul 2011 17:37:32 +0200 Lucio De Re lu...@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)
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)
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)
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)
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)
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)
On Fri, 22 Jul 2011 19:48:41 +0200 Lucio De Re lu...@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)
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)
On Jul 22, 2011, at 1:53 PM, erik quanstrom quans...@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)
On Fri, 22 Jul 2011 17:35:24 +0100 Steve Simon st...@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)
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)
On Fri Jul 22 14:25:06 EDT 2011, comeauat9f...@gmail.com wrote: On Jul 22, 2011, at 1:53 PM, erik quanstrom quans...@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)
On Fri Jul 22 14:32:43 EDT 2011, eeke...@fastmail.fm wrote: On Fri, 22 Jul 2011 17:35:24 +0100 Steve Simon st...@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)
On Fri, 22 Jul 2011 13:53:41 EDT erik quanstrom quans...@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)
On Jul 22, 2011, at 2:38 PM, Bakul Shah ba...@bitblocks.com wrote: On Fri, 22 Jul 2011 13:53:41 EDT erik quanstrom quans...@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)
On Jul 22, 2011, at 2:33 PM, erik quanstrom quans...@labs.coraid.com wrote: On Fri Jul 22 14:32:43 EDT 2011, eeke...@fastmail.fm wrote: On Fri, 22 Jul 2011 17:35:24 +0100 Steve Simon st...@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)
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)
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)
On Fri, 22 Jul 2011 14:48:44 EDT comeauat9f...@gmail.com
comeauat9f...@gmail.com wrote:
On Jul 22, 2011, at 2:38 PM, Bakul Shah ba...@bitblocks.com wrote:
On Fri, 22 Jul 2011 13:53:41 EDT erik quanstrom quans...@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)
On Fri, Jul 22, 2011 at 02:22:54PM -0400, comeauat9f...@gmail.com wrote: On Jul 22, 2011, at 1:53 PM, erik quanstrom quans...@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)
On Fri, Jul 22, 2011 at 07:30:47PM +0100, Ethan Grammatikidis wrote: On Fri, 22 Jul 2011 17:35:24 +0100 Steve Simon st...@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)
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)
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)
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)
On Fri, Jul 22, 2011 at 11:55:45AM -0700, Bakul Shah wrote:
On Fri, 22 Jul 2011 14:48:44 EDT comeauat9f...@gmail.com
comeauat9f...@gmail.com wrote:
On Jul 22, 2011, at 2:38 PM, Bakul Shah ba...@bitblocks.com wrote:
On Fri, 22 Jul 2011 13:53:41 EDT erik quanstrom
quans...@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)
On Fri, 22 Jul 2011 19:48:41 +0200 Lucio De Re lu...@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)
On Fri, 22 Jul 2011 15:09:35 EDT erik quanstrom quans...@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)
On Fri, 22 Jul 2011 21:00:53 +0200 Lucio De Re lu...@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 st...@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)
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)
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)
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)
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
Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)
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 lu...@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.
Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)
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)
http://groups.google.com/group/golang-dev/browse_thread/thread/c44be49fe9ca42e7/cb98571d81888b9f?lnk=gstq=plan9front#cb98571d81888b9f
Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)
On Thu, Jul 14, 2011 at 4:21 PM, Lucio De Re lu...@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)
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 installed 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)
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.
[9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)
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)
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 lu...@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)
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 lu...@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
