Pretty cool!
On Tue, Nov 15, 2011 at 1:10 PM, Anthony Martin wrote:
> Attached is a modified version of p9p yacc that
> supports the Go grammar. I'll be sending a
> version of Plan 9 yacc later today.
>
> The following is a description of the changes.
>
> 1. The %error-verbose directive is ign
Attached is a modified version of p9p yacc that
supports the Go grammar. I'll be sending a
version of Plan 9 yacc later today.
The following is a description of the changes.
1. The %error-verbose directive is ignored.
2. A description of the final grammar is
printed before the state de
Reread what I posted. I said that I will modify yacc for different
reasons and gave my reasons for doing so. I NEVER said RUN INFERNO.
Yes ron, what a lot of noise. And I'll SHOUT whenever I think it might
help, Mr aptly named Scatomancer.
brucee
On 14 November 2011 09:30, Scato Logic wrote:
>
Let me get this straight. The goal is to get a successful full native build
of go under plan9. Currently, the build requires bison which no one wants
to port to plan9 but can be run via linuxemu. Brucee has offered to modify
his limbo version of yacc to make things work but that yacc will then need
The bisonerrors script is 124 lines. This email thread is now 724
lines. I figure when the number of lines of this thread is 10x the
size of the bisonerrors script it would be nice to replace the endless
discussion with some code :-)
ron
that's what i said ...
If all the information is available in y.output then surely modifying
yacc will cut out the middle man.
brucee
On 13 November 2011 21:08, Steve Simon wrote:
> Perhaps I'am way off base but surely the neatest solution would be to
> modify yacc to produce a nice clean messa
Perhaps I'am way off base but surely the neatest solution would be to
modify yacc to produce a nice clean message format, modify the gc
to use that format.
The reason for not using just the same format blindly is it was designed
with the structure of gc in mind rather than a clean output format.
my motivation is that the limbo version of yacc is out of date
severely (doesn't cope with cc.y) and it seems like a good time to
have a 5c in limbo that copes with all and sundry arm variants - two
more were released this week - with loadable arch modules. and to
write shorter sentences.
brucee
> If all the information is available in y.output then surely modifying
> yacc will cut out the middle man.
>
That's not quite how I remember it, I'm sure that there was no trivial
way to alter the output from yacc to conform to the needs of Russ'
error messages. That said, even if y.output does
If all the information is available in y.output then surely modifying
yacc will cut out the middle man.
On my list.
brucee
On 12 November 2011 20:23, Bakul Shah wrote:
> On Fri, 11 Nov 2011 12:54:28 PST Bakul Shah wrote:
>> On Fri, 11 Nov 2011 08:07:21 PST ron minnich wrote:
>> > If somebod
On Fri, 11 Nov 2011 12:54:28 PST Bakul Shah wrote:
> On Fri, 11 Nov 2011 08:07:21 PST ron minnich wrote:
> > If somebody wants to look at enhancing yacc so that the extra bison
> > bits can be supported, that would probably do the trick. I have no
> > idea of the level of effort, I have not loo
> I'm modifying yacc for other purposes, and yes I know how it works.
>
Nobody could doubt that :-)
> If bison is not too vomituos I will try and help.
Don't overlook Bakul's suggestions, they may have much merit. A quick
glance at my previous efforts suggests having to fight with the wide
char
I'm modifying yacc for other purposes, and yes I know how it works.
If bison is not too vomituos I will try and help.
brucee
On 12 November 2011 15:51, Lucio De Re wrote:
>> One further issue is whether go has any other bison
>> dependencies.
>
> None as serious as the error message generation.
> One further issue is whether go has any other bison
> dependencies.
None as serious as the error message generation. But your research is
invaluable, let's hope it leads in the right direction.
++L
> I think porting bison is the wrong way to go, personally.
Having tried it, I can only agree. But I'm going to give it another
go, if only to remind myself why I didn't complete the task the first
time 'round.
++L
On Fri, Nov 11, 2011 at 6:54 PM, Bakul Shah wrote:
> On Fri, 11 Nov 2011 08:07:21 PST ron minnich wrote:
>> If somebody wants to look at enhancing yacc so that the extra bison
>> bits can be supported, that would probably do the trick. I have no
>> idea of the level of effort, I have not looked.
> One further issue is whether go has any other bison
> dependencies.
as off march (when I last played with a port) it didn't,
there where a few bits of bison syntax which are different
in yacc but these could be papered over whith a few lines of
sed - ur yacc could even be taught this alternative
On Fri, 11 Nov 2011 12:58:30 PST ron minnich wrote:
> On Fri, Nov 11, 2011 at 12:54 PM, Bakul Shah wrote:
>
> > Might it be worth looking Merr or iyacc? Porting bison to
> > plan9 seems like a hugh punishment for a quick hack:-)
> > Implementing Jeffery's directly in yacc might benefit other
>
On Fri, Nov 11, 2011 at 12:54 PM, Bakul Shah wrote:
> Might it be worth looking Merr or iyacc? Porting bison to
> plan9 seems like a hugh punishment for a quick hack:-)
> Implementing Jeffery's directly in yacc might benefit other
> parsers as well.
If it's worth a look then I hope someone look
On Fri, 11 Nov 2011 08:07:21 PST ron minnich wrote:
> If somebody wants to look at enhancing yacc so that the extra bison
> bits can be supported, that would probably do the trick. I have no
> idea of the level of effort, I have not looked.
After some googling I see that src/cmd/gc/bisonerrors w
> i'm well aware we can tweak go and remove better error messages. that
> doesn't count IMHO. We're working to get to the point where we don't
> tweak the go source at all and it just builds. I don't see the point
> in making a go for Plan 9 that is in some way compromised. So, getting
> back to my
i'm well aware we can tweak go and remove better error messages. that
doesn't count IMHO. We're working to get to the point where we don't
tweak the go source at all and it just builds. I don't see the point
in making a go for Plan 9 that is in some way compromised. So, getting
back to my original
> at one time the go .y wasn't bison dependent. is the new dependency
> a choice or requirement?
It makes it possible to produce clever error messages, but it depends
on a bison extension. I agree with Russ that it is worth it, but it
does throw a massive spanner in the works.
++L
I believe go can be tweeked a little build correctly without
bison, but some of the error messages gc generates will be less
helpful.
for me the best solution would be for yacc to be modified
to produce the error message tables directly, rather than
mimicing bison - producing a debug file withch c
On Fri Nov 11 11:08:13 EST 2011, rminn...@gmail.com wrote:
> Go is pretty solid on 386 and I'm slowly puzzling my way through NIX support.
>
> One thing that stands in the way of full native build is the bison issue.
>
> If somebody wants to look at enhancing yacc so that the extra bison
> bits c
Go is pretty solid on 386 and I'm slowly puzzling my way through NIX support.
One thing that stands in the way of full native build is the bison issue.
If somebody wants to look at enhancing yacc so that the extra bison
bits can be supported, that would probably do the trick. I have no
idea of th
26 matches
Mail list logo
