Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
>>> "Paul" == Paul Hilfinger <[EMAIL PROTECTED]> writes: > In fact, this issue did get discussed when the GLR skeleton got > introduced, and the language (or lack of it) is, AIR, deliberate on > the part of the lead maintainers at the time. On consideration, I > would prefer that the same terms apply to all skeletons as now apply > to the C LALR(1) skeleton. I think that there does come a point at > which copylefting becomes shooting oneself in the foot. That decision was made by RMS, prompted by me. I'm fine with putting the exception on all the skeletons. ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
Paul Hilfinger wrote: In fact, this issue did get discussed when the GLR skeleton got introduced, and the language (or lack of it) is, AIR, deliberate on the part of the lead maintainers at the time. On consideration, I would prefer that the same terms apply to all skeletons as now apply to the C LALR(1) skeleton. I think that there does come a point at which copylefting becomes shooting oneself in the foot. This looks to me as a problem of competitive advantage: if bison was one of the only programs providing C++ or GLR parsers generation, it could be seen as a way to promote GPLed software. It might have been true when these skeleton first appeared, but I don't think it is any more, since both commercial and open source implementations exist now. In which case it seems to me that the opposite attitude is better, that is promote the use of bison with an unrestrictive license on the skeletons, and hope it will promote the use of other open source software. -- Sylvain ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
>>> "Sylvain" == Sylvain Schmitz <[EMAIL PROTECTED]> writes: > Paul Hilfinger wrote: >> In fact, this issue did get discussed when the GLR skeleton got >> introduced, and the language (or lack of it) is, AIR, deliberate on >> the part of the lead maintainers at the time. On consideration, I >> would prefer that the same terms apply to all skeletons as now apply >> to the C LALR(1) skeleton. I think that there does come a point at >> which copylefting becomes shooting oneself in the foot. > This looks to me as a problem of competitive advantage: if bison was > one of the only programs providing C++ or GLR parsers generation, it > could be seen as a way to promote GPLed software. It might have been > true when these skeleton first appeared, but I don't think it is any > more, since both commercial and open source implementations exist now. > In which case it seems to me that the opposite attitude is better, > that is promote the use of bison with an unrestrictive license on the > skeletons, and hope it will promote the use of other open source > software. I concur. ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
It would simplify if the supported Bison skeleton files were distributed under the same copyright. The unsupported skeleton files, if any, should be put in a special place, either in the distribution, or outside it, I think. At 12:50 -0800 2005/03/09, Paul Hilfinger wrote: >In fact, this issue did get discussed when the GLR skeleton got >introduced, and the language (or lack of it) is, AIR, deliberate on >the part of the lead maintainers at the time. On consideration, I >would prefer that the same terms apply to all skeletons as now apply >to the C LALR(1) skeleton. I think that there does come a point at >which copylefting becomes shooting oneself in the foot. > >The best presentation I've seen of the GPL for the corporate audience >goes something like this: > >If your lawyer takes a look at the GPL, he should say something >like, "Hmm, well this appears to be a pretty ordinary license that >allows us to use this software under certain conditions. >Hello---my word, these conditions certainly are liberal. >Apparently, we don't have to pay any royalties (unlike your typical >Microsoft license), we are free to reverse engineer (unlike your >typical Microsoft license), to examine the source (UYTML), >to modify (UYTML), to redistribute (UYTML), and even to >publicly vilify (UYTML)." > >How strange then that use of the OUTPUT from using such a program >should be more strictly controlled than is the output of MS Word! > >In short, I am strongly in favor of making the terms of use for Bison >output uniformly liberal across skeletons. > >Paul Hilfinger > > > > This is most likely an error: The other skeleton files did not exist at the > > time that stuff was written. Akim Demaille is resposnible for the C++ file > > and Paul Hilfinger for the GLR file. They probably forgot to insert the > > correct copyright. If so, this is a Bug-Bison issue. > > > > At 14:28 +0100 2005/03/09, Michel Rosien wrote: > > >Hello, =A0 I have read the "Conditions for Using Bison" on page 3 of t >h= > > e > > Bison 2.0 documentation. The first lines say: =A0 As of Bison versio >n > > 1.24, we have changed the distribution terms for yyparse to permit using > > Bison's output in nonfree programs when Bison is generating C code for > > LALR(1) parsers =A0 Does this mean that=A0this only applies when > > using the skeleton file=A0yacc.c and that this NOT applies when using the > > skeleton files glr.c or lalr1.cc? This would mean that you can not make glr > > parsers (%glr-parser) or c++ parsers if you want to use the output in > > nonfree programs. =A0 The last lines of the "Conditions for using Bison" > > mention: You can tell whether the exception applies to your '.c' > > output file by inspecting it to see whether it says "As a special > > exception, when this file is copied by Bison into a Bison output file, you > > may use that output file without restriction." =A0 If I inspect > > the skeleton files yacc.c , glr.c and lalr1.cc I see that only yacc.c > > contains this text. =A0 Is this correct? If so, could you explain why this > > distinction is made? =A0 Regards, =A0 > > --Michel___ > > >Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison > > > > > > ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
At 10:53 +0100 2005/03/10, Sylvain Schmitz wrote: >Paul Hilfinger wrote: > >> In fact, this issue did get discussed when the GLR skeleton got >> introduced, and the language (or lack of it) is, AIR, deliberate on >> the part of the lead maintainers at the time. On consideration, I >> would prefer that the same terms apply to all skeletons as now apply >> to the C LALR(1) skeleton. I think that there does come a point at >> which copylefting becomes shooting oneself in the foot. > >This looks to me as a problem of competitive advantage: if bison was one >of the only programs providing C++ or GLR parsers generation, it could >be seen as a way to promote GPLed software. It might have been true >when these skeleton first appeared, but I don't think it is any more, >since both commercial and open source implementations exist now. In >which case it seems to me that the opposite attitude is better, that is >promote the use of bison with an unrestrictive license on the skeletons, >and hope it will promote the use of other open source software. One other way to view this is that the output of a copyrighted program is rarely viewed as being covered by the copyright of the program that made it. Take, for example, the text-files produced by a copyrighted program. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: ERROR: version file does not exist or are not readable
Please keep the cc to help-bison, so others know. When you get the right bison installed, its version can be checked by the --version option. At 08:42 +0100 2005/03/10, <[EMAIL PROTECTED]> wrote: >The error where not generated by bison. When I test with "which bison" I found that the computer use some other program that also is called bison. So, when I change the path everything works correctly. > >-Ursprungligt meddelande- >Från: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Hans >Aberg >Skickat: onsdagen den 9 mars 2005 19:24 >Till: Olsson Magnus (VN-PRRT) >Kopia: help-bison@gnu.org >Ämne: Re: ERROR: version file does not exist or are not readable > > >You must provide more info about when and how the error occurs (version, >installation, etc.): I can't find that error string in Bison 2.0 nor in the >M4 that Bison uses. If you use an older Bison version, try to update, as >older versions are not supported. And bugs should be reported to the >Bug-Bison list. > >At 16:04 +0100 2005/03/08, <[EMAIL PROTECTED]> wrote: >>When I try to run bison I get folowing: >> >>ERROR: version file does not exist or are not readable >> >> >> >> >>___ >>Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison > > > > >___ >Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
Sylvain Schmitz <[EMAIL PROTECTED]> writes: > It might have been true when these skeleton first appeared, but I > don't think it is any more, since both commercial and open source > implementations exist now. OK, let's solve the problem. The first step: could you please come up with a brief list of the commercial and other alternative implementations, as compared to Bison? If we present such a list to RMS in a concise and pragmatic way, he'll most likely change his mind, just as he changed his mind for the yacc skeleton. ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
Hans Aberg <[EMAIL PROTECTED]> writes: > the output of a copyrighted program is rarely viewed as being > covered by the copyright of the program that made it. No, actually it's quite common. For example, if I run the traditional /usr/ccs/bin/yacc that is shipped with Solaris 9, the output file y.tab.c contains the following lines: /* * Copyright (c) 1993 by Sun Microsystems, Inc. */ There is no other wording granting permission to copy, so under the Berne convention you have no right to copy the output file y.tab.c unless you have some other agreement with Sun. I suspect that the only reason this "works" is that Sun and its users are relatively sloppy about copyright issues, and they don't really care about crossing all the Ts and dotting all the Is. The GNU project tends to be pickier (following the usual rule of thumb that the less money you have, the more careful you have to be about the law :-). ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
problem linking program containing bison-generated parser
Hello, I'm currently trying to gain some experience with flex and bison. In one of my projects, I'd like to use these two tools together with some Qt classes. I'm not trying to create an object-oriented parser, I'm just using Qt's string and list objects as I'm much more familiar with them. The idea is to feed an input file through a bison-generated parser and create an object structure that is processed subsequently. However, I get the following error message during linking (output abbreviated): , | .. | bison -y -d -t -v CDLparse.y | ... | if test -f y.tab.h; then \ | to=`echo "CDLparse_H" | sed \ | -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \ | -e 's/[^ABCDEFGHIJKLMNOPQRSTUVWXYZ]/_/g'`; \ | sed -e "/^#/!b" -e "s/Y_TAB_H/$to/g" -e "s|y\.tab\.h|CDLparse.h|" \ | y.tab.h >CDLparse.ht; \ | rm -f y.tab.h; \ | if cmp -s CDLparse.ht CDLparse.h; then \ | rm -f CDLparse.ht ;\ | else \ | mv CDLparse.ht CDLparse.h; \ | fi; \ | fi | if test -f y.output; then \ | mv y.output CDLparse.output; \ | fi | sed '/^#/ s|y\.tab\.c|CDLparse.c|' y.tab.c >CDLparse.ct && mv CDLparse.ct | CDLparse.c | rm -f y.tab.c | ... | flex -d -s -B CDLlex.l | ... | sed '/^#/ s|lex.yy\.c|CDLlex.c|' lex.yy.c >CDLlex.c | rm -f lex.yy.c | if gcc -DHAVE_CONFIG_H -I. -I. -I.-DYY_NO_UNISTD_H -g -O2 -MT | quickconfig-CDLlex.o -MD -MP -MF ".deps/quickconfig-CDLlex.Tpo" -c -o | quickconfig-CDLlex.o `test -f 'CDLlex.c' || echo './'`CDLlex.c; \ | then mv -f ".deps/quickconfig-CDLlex.Tpo" ".deps/quickconfig-CDLlex.Po"; | else rm -f ".deps/quickconfig-CDLlex.Tpo"; exit 1; fi | ... | if gcc -DHAVE_CONFIG_H -I. -I. -I.-DYY_NO_UNISTD_H -g -O2 -MT | quickconfig-CDLparse.o -MD -MP -MF ".deps/quickconfig-CDLparse.Tpo" -c -o | quickconfig-CDLparse.o `test -f 'CDLparse.c' || echo './'`CDLparse.c; \ | then mv -f ".deps/quickconfig-CDLparse.Tpo" ".deps/quickconfig-CDLparse.Po"; | else rm -f ".deps/quickconfig-CDLparse.Tpo"; exit 1; fi | g++ -g -O2 -o quickconfig quickconfig-quickconfig.o | quickconfig-QCGenerator.o quickconfig-CDLlex.o quickconfig-CDLparse.o | quickconfig-GetOpt.o -lm -lfl -L/usr/qt/3/lib -lqt -L -lXext -lX11 -lm -lSM | -lICE -ldl -ljpeg | quickconfig-QCGenerator.o(.text+0xfab): In function `QCGenerator::parseInputFile()': | /home/vwegert/Entwicklung/Linux/Qt/QuickConf/cvs/src/QCGenerator.cpp:145: | undefined reference to `yyparse()' | collect2: ld returned 1 exit status ` However, readelf -s quickconfig-CDLparse.o returns , | Symbol table '.symtab' contains 51 entries: |Num:Value Size TypeBind Vis Ndx Name | 0: 0 NOTYPE LOCAL DEFAULT UND | 1: 0 FILELOCAL DEFAULT ABS CDLparse.c | 2: 0 SECTION LOCAL DEFAULT1 | 3: 0 SECTION LOCAL DEFAULT3 | 4: 0 SECTION LOCAL DEFAULT4 | 5: 0 SECTION LOCAL DEFAULT5 | 6: 0 SECTION LOCAL DEFAULT6 | 7: 0 SECTION LOCAL DEFAULT8 | 8: 0 SECTION LOCAL DEFAULT 10 | 9: 303 OBJECT LOCAL DEFAULT 10 yytranslate | 10: 014070 OBJECT LOCAL DEFAULT 10 yyprhs | 11: 01a0 190 OBJECT LOCAL DEFAULT 10 yyrhs | 12: 026070 OBJECT LOCAL DEFAULT 10 yyrline | 13: 0 SECTION LOCAL DEFAULT 12 | 14: 02c0 368 OBJECT LOCAL DEFAULT 10 yytname | 15: 044070 OBJECT LOCAL DEFAULT 10 yyr1 | 16: 04a070 OBJECT LOCAL DEFAULT 10 yyr2 | 17: 0500 113 OBJECT LOCAL DEFAULT 10 yydefact | 18: 058043 OBJECT LOCAL DEFAULT 10 yydefgoto | 19: 05c0 113 OBJECT LOCAL DEFAULT 10 yypact | 20: 064043 OBJECT LOCAL DEFAULT 10 yypgoto | 21: 068097 OBJECT LOCAL DEFAULT 10 yytable | 22: 070097 OBJECT LOCAL DEFAULT 10 yycheck | 23: 0780 113 OBJECT LOCAL DEFAULT 10 yystos | 24: 121 FUNCLOCAL DEFAULT1 yy_stack_print | 25: 0 SECTION LOCAL DEFAULT 13 | 26: 0080 175 FUNCLOCAL DEFAULT1 yy_reduce_print | 27: 013087 FUNCLOCAL DEFAULT1 yysymprint | 28: 0190 5 FUNCLOCAL DEFAULT1 yydestruct | 29: 0 SECTION LOCAL DEFAULT 14 | 30: 0 SECTION LOCAL DEFAULT 16 | 31: 0 SECTION LOCAL DEFAULT 18 | 32: 0 SECTION LOCAL DEFAULT 20 | 33: 0 SECTION LOCAL DEFAULT 21 | 34: 0 SECTION LOCAL DEFAULT 22 | 35: 0 SECTION LOCAL DEFAULT 23 | 36: 0 NOTYPE GLOBAL DEFAULT UND stderr | 37: 0 NOTYPE GLOBAL DEFAULT UND fwrite | 38: 0 NOTYPE GLOBAL DEFAULT UND fputc | 39: 0 NOTYPE GLOBAL DEFAULT UND fprintf |
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
> Hans Aberg <[EMAIL PROTECTED]> writes: > > > the output of a copyrighted program is rarely viewed as being > > covered by the copyright of the program that made it. > > No, actually it's quite common. For example, if I run the traditional > /usr/ccs/bin/yacc that is shipped with Solaris 9, the output file > y.tab.c contains the following lines: > > /* > * Copyright (c) 1993 by Sun Microsystems, Inc. > */ > > There is no other wording granting permission to copy, so under the > Berne convention you have no right to copy the output file y.tab.c > unless you have some other agreement with Sun. Actually, I believe that the Berne convention gives no standing whatever to written copyright notices of this sort. Instead, if I produce a copyrightable work, that work is protected by copyright unless I take steps to make it otherwise. Here the issue is works that are produced by the operation of copyrighted software. I don't know what the default status is of works produced by X's use of Y's copyrighted programs, but I rather suspect that such products belong to X unless the license granted to X by Y explicitly makes other provisions. Paul Hilfinger ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
Paul Hilfinger <[EMAIL PROTECTED]> writes: > Actually, I believe that the Berne convention gives no standing > whatever to written copyright notices of this sort. Instead, if I > produce a copyrightable work, that work is protected by copyright > unless I take steps to make it otherwise. Yes, that's correct. I mentioned the y.tab.c copyright notice of Solaris Yacc mainly to point out that it's clear that Sun is making a copyright claim in this area. I mentioned the Berne convention because not every country is a signatory, and in non-signatory countries like the Cayman Islands my analysis of what's permitted might not be correct. > I don't know what the default status is of works produced by X's use > of Y's copyrighted programs, but I rather suspect that such products > belong to X It depends on whether the produced works are "derivative works" of Y's copyrighted programs. For many programs (e.g., "cat") it's quite clear that the program's output is not a derivative work of the program. But in the case of Yacc, it's pretty clear that the C output file is a derivative work of both the Yacc template file and the user's source file. So, legally speaking, the user and Sun both have copyright interest in the C output file, and you need permission from both parties before you can redistribute that file. ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
[For some unknown reason, my email to Paul Eggert bounces.] Paul Eggert's comment does not prove commonness :-), except perhaps in the case of Yacc and related programs. When I try to think about computer software in general, it always is the principle that Paul Hilfinger indicates. If the program owner would be able to copyright also the output from a program, it would be in practise impossible to use such programs. (Think of rendering programs for movies, text editors, typesetting programs, audio and DVD players, etc.) As for the copyrighting issue itself, it rarely goes to court. Isn't there only about one case where the GPL has been tried in court? At 14:04 -0800 2005/03/10, Paul Hilfinger wrote: > > Hans Aberg <[EMAIL PROTECTED]> writes: > > > > > the output of a copyrighted program is rarely viewed as being > > > covered by the copyright of the program that made it. > > > > No, actually it's quite common. For example, if I run the traditional > > /usr/ccs/bin/yacc that is shipped with Solaris 9, the output file > > y.tab.c contains the following lines: > > > > /* > > * Copyright (c) 1993 by Sun Microsystems, Inc. > > */ > > > > There is no other wording granting permission to copy, so under the > > Berne convention you have no right to copy the output file y.tab.c > > unless you have some other agreement with Sun. > >Actually, I believe that the Berne convention gives no standing >whatever to written copyright notices of this sort. Instead, if I >produce a copyrightable work, that work is protected by copyright >unless I take steps to make it otherwise. Here the issue is works >that are produced by the operation of copyrighted software. I don't >know what the default status is of works produced by X's use of Y's >copyrighted programs, but I rather suspect that such products belong >to X unless the license granted to X by Y explicitly makes other >provisions. > >Paul Hilfinger > > >___ >Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: problem linking program containing bison-generated parser
Volker Wegert wrote: However, I get the following error message during linking (output abbreviated): Stupid question, but I assume that you are aware of the name mangling in C++ and are properly externing your declarations to compensate ? -- alfonso e. urdaneta www.red82.com - are you ready ? ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Identifying rule responsible for lookahead
No, there is no such Bison design doc's: Only reading the Bison source code itself. (Apart from that somebody wrote something in Spanish, I think.) link ? -- alfonso e. urdaneta www.red82.com - are you ready ? ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
