Re: [QUESTIONS] Snapshot has not compiled in a couple of days

The problem is in the ecpq stuff. There is a duplicate def of S_SIGNED.
Cab we fix this, so I can test the compile on HPUX?

My cvs tree from 980223 03:00 UTC (about 24 hours ago) compiled to completion, but
I do see a duplicate definition of S_SIGNED in preproc.y. Remove that symbol from
line 234 of that file and try again.

/usr/bin/bison -y -d preproc.y
conflicts: 5 shift/reduce
gcc -I../include -O2 -g -Wall -DMAJOR_VERSION=1 -DMINOR_VERSION=0 -DPATCHLEVEL=0 -c
y.tab.c -o y.tab.o
...
preproc.y:289: warning: passing arg 1 of `free' discards `const' from pointer target
type
gcc -g -O2 -Wall -o ecpg y.tab.o pgc.o type.o ecpg.o ../lib/typename.o

I removed the duplicate S_SIGNED from my source code and noticed these remaining
messages. Can we get rid of the shift/reduce conflicts? I haven't looked at the code,
but there is a debugging flag on yacc/bison ("-v") which will write a log file
identifying the conflicting statements. I have some experience debugging this on the
main parser, but need to work on docs so shouldn't do this at the moment :(

- Tom

On Wed, 25 Feb 1998, Thomas G. Lockhart wrote:

The problem is in the ecpq stuff. There is a duplicate def of S_SIGNED.
Cab we fix this, so I can test the compile on HPUX?

My cvs tree from 980223 03:00 UTC (about 24 hours ago) compiled to completion, but
I do see a duplicate definition of S_SIGNED in preproc.y. Remove that symbol from
line 234 of that file and try again.

/usr/bin/bison -y -d preproc.y
conflicts: 5 shift/reduce
gcc -I../include -O2 -g -Wall -DMAJOR_VERSION=1 -DMINOR_VERSION=0 -DPATCHLEVEL=0 -c
y.tab.c -o y.tab.o
...
preproc.y:289: warning: passing arg 1 of `free' discards `const' from pointer target
type
gcc -g -O2 -Wall -o ecpg y.tab.o pgc.o type.o ecpg.o ../lib/typename.o

I removed the duplicate S_SIGNED from my source code and noticed these
remaining messages. Can we get rid of the shift/reduce conflicts? I
haven't looked at the code, but there is a debugging flag on yacc/bison
("-v") which will write a log file identifying the conflicting
statements. I have some experience debugging this on the main parser,
but need to work on docs so shouldn't do this at the moment :(

If I can figure out bison, I'll try and work these out...one way
to learn, I guess :)

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

remaining messages. Can we get rid of the shift/reduce conflicts? I
haven't looked at the code, but there is a debugging flag on yacc/bison
("-v") which will write a log file identifying the conflicting
statements. I have some experience debugging this on the main parser,
but need to work on docs so shouldn't do this at the moment :(

If I can figure out bison, I'll try and work these out...one way
to learn, I guess :)

This ecps is hot, but it seems it is still 'in process' as we approach
release date. Can we do what we did with pgaccess, and get a web site
that has the most recent version, and just ship a current version with
6.3, and people can go to the web site to get the newest copy? We put a
nice README in the pgaccess directory pointing people to a web site
having the most recent version. Seemed to work well.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

On Tue, 24 Feb 1998, Bruce Momjian wrote:

remaining messages. Can we get rid of the shift/reduce conflicts? I
haven't looked at the code, but there is a debugging flag on yacc/bison
("-v") which will write a log file identifying the conflicting
statements. I have some experience debugging this on the main parser,
but need to work on docs so shouldn't do this at the moment :(

If I can figure out bison, I'll try and work these out...one way
to learn, I guess :)

This ecps is hot, but it seems it is still 'in process' as we approach
release date. Can we do what we did with pgaccess, and get a web site
that has the most recent version, and just ship a current version with
6.3, and people can go to the web site to get the newest copy? We put a
nice README in the pgaccess directory pointing people to a web site
having the most recent version. Seemed to work well.

ecpg isn't a seperate package, so this isn't really an alternative
in this case :(

The above problem is more an annoyance then anything, and, quite
frankly, I don't understand enough about yacc/bison to work out where.
Well, I understand more now then when I started, but still have a long way
to go. Next Nutshell book, I fear :)

I'm going to do a run through of the code again tomorrow at work,
on the two Solaris boxes, and check for compiler problems...

Jan, how goes the pg_shadow stuff? I believe we still have
breakage in initdb, but Bruce is waiting for that patch before
investigating further?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Thomas G. Lockhart writes:

/usr/bin/bison -y -d preproc.y
conflicts: 5 shift/reduce
gcc -I../include -O2 -g -Wall -DMAJOR_VERSION=1 -DMINOR_VERSION=0 -DPATCHLEVEL=0 -c
y.tab.c -o y.tab.o
...
preproc.y:289: warning: passing arg 1 of `free' discards `const' from pointer target
type
gcc -g -O2 -Wall -o ecpg y.tab.o pgc.o type.o ecpg.o ../lib/typename.o

I removed the duplicate S_SIGNED from my source code and noticed these remaining
messages. Can we get rid of the shift/reduce conflicts? I haven't looked at the code,
but there is a debugging flag on yacc/bison ("-v") which will write a log file
identifying the conflicting statements. I have some experience debugging this on the
main parser, but need to work on docs so shouldn't do this at the moment :(

I see what I can do. Unfortunately I'm not really a bison expert either.

Michael

--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10