> 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
On Nov 11, 2011, at 8:06 PM, Rudolf Sykora wrote:
> screen prints wrongly. Furthermore, now page displays different things
> than gv.
>
> I hoped that with postscript one can achieve the same results
> everywhere, but it actually seems difficult...
When this happens to me, normally it is becaus
Just like to take a quick moment to say hello to the list and
introduce myself. Hi there! =D
For roughly the last 6 years or so, I've been picking away at "Atomic
OS" - a metaphorical OS / abstraction layer for web application
developers. (That's my goal anyway.)
Initially the direction was inf
http://plan9.bell-labs.com/sources/extra/plan9.tar.bz2
built daily
On Nov 11, 2011, at 11:58 AM, Rudolf Sykora wrote:
> Is there a simple way to get a local copy of some of sources' subtree?
On 11 November 2011 19:38, Rudolf Sykora wrote:
> Further, when I take the directory /sys/lib/postscript/font from plan9
> and copy it to (replace with it) the contents of p9p's
> $PLAN9/postscript/font I get a result quite similar to the previously
> shown output of the heirloom suite, i.e., eve
> The problems I have described exist in plan9port and heirloom
> software. I haven't yet tried to what extent it also applies to plan9
> proper. And it seems you are suggesting some changes to the latter
> software.
As I have tried, I really don't see any of the mentioned problems when
using my p
> 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
> 1/ when on plan9 one can do
> 9fs sources
> to get access to p9 sources
>
> Can one do sth similar on linux (say with p9p installed)?
You don't even need to have plan9port if you don't need authentication.
On Linux, you can use v9fs:
% mount -t 9p 204.178.31.11 /n/sources
You can also use v9
> So what problem should your change remove? (I am sorry it's not clear
> to me from your code.)
you should not see eqn eating runes after this patch.
- erik
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
Dear Erik,
thank you for looking at the problem. Nonetheless, I am bit puzzled.
The problems I have described exist in plan9port and heirloom
software. I haven't yet tried to what extent it also applies to plan9
proper. And it seems you are suggesting some changes to the latter
software.
Also, a
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
this does work on my system. here's the diff:
- erik
-
/n/sources/plan9//sys/src/cmd/eqn/text.c:1,6 - text.c:1,7
#include "e.h"
#include "y.tab.h"
#include
+ #include
#define CSSIZE 1000
char cs[CSSIZE+20]; /* text string converted into this */
/n/sources/plan9//sys/s
Hello,
1/ when on plan9 one can do
9fs sources
to get access to p9 sources
Can one do sth similar on linux (say with p9p installed)?
2/ Related:
there is a web access to the sources
http://plan9.bell-labs.com/sources/plan9
Is there a simple way to get a local copy of some of sources' subtree?
I
Hello,
In my new linux installation + p9p I found myself having problems with
using p9p troff.
To ilustrate, consider the input for troff
.\".do xflag 3
.\".lc_ctype en_US.utf8
em-dash:—
.br
brackets, big delta, sqrt:
.EQ
left ( { αΔ - sqrt 2 } over 5χ right )
.EN
which is then used with
9 eqn a
26 matches
Mail list logo
