Re: [Mesa-dev] [PATCH 3/3] glsl: remove out of date comments from file header
On Wed, Feb 10, 2016 at 8:45 PM, Timothy Arceriwrote: > The bison/flex generated code hasn't been keeped in version control s/keeped/kept/ > for a long time, and I doubt anyone is going to argue for putting > all this validation in the parser. > --- > src/compiler/glsl/ast_to_hir.cpp | 18 +- > 1 file changed, 1 insertion(+), 17 deletions(-) > > diff --git a/src/compiler/glsl/ast_to_hir.cpp > b/src/compiler/glsl/ast_to_hir.cpp > index b558589..fc0d448 100644 > --- a/src/compiler/glsl/ast_to_hir.cpp > +++ b/src/compiler/glsl/ast_to_hir.cpp > @@ -23,7 +23,7 @@ > > /** > * \file ast_to_hir.c > - * Convert abstract syntax to to high-level intermediate reprensentation > (HIR). > + * Convert abstract syntax to high-level intermediate reprensentation (HIR). > * > * During the conversion to HIR, the majority of the symantic checking is > * preformed on the program. This includes: > @@ -31,22 +31,6 @@ > ** Symbol table management > ** Type checking > ** Function binding > - * > - * The majority of this work could be done during parsing, and the parser > could > - * probably generate HIR directly. However, this results in frequent changes > - * to the parser code. Since we do not assume that every system this > complier > - * is built on will have Flex and Bison installed, we have to store the code > - * generated by these tools in our version control system. In other parts of > - * the system we've seen problems where a parser was changed but the > generated > - * code was not committed, merge conflicts where created because two > developers > - * had slightly different versions of Bison installed, etc. > - * Removing this seems fine. > - * I have also noticed that running Bison generated parsers in GDB is very > - * irritating. When you get a segfault on '$$ = $1->foo', you can't very > - * well 'print $1' in GDB. > - * > - * As a result, my preference is to put as little C code as possible in the > - * parser (and lexer) sources. These bits don't seem irrelevant. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] glsl: remove out of date comments from file header
Ping. Are people ok with this historical text being removed? On Thu, 2016-02-11 at 15:45 +1100, Timothy Arceri wrote: > The bison/flex generated code hasn't been keeped in version control > for a long time, and I doubt anyone is going to argue for putting > all this validation in the parser. > --- > src/compiler/glsl/ast_to_hir.cpp | 18 +- > 1 file changed, 1 insertion(+), 17 deletions(-) > > diff --git a/src/compiler/glsl/ast_to_hir.cpp > b/src/compiler/glsl/ast_to_hir.cpp > index b558589..fc0d448 100644 > --- a/src/compiler/glsl/ast_to_hir.cpp > +++ b/src/compiler/glsl/ast_to_hir.cpp > @@ -23,7 +23,7 @@ > > /** > * \file ast_to_hir.c > - * Convert abstract syntax to to high-level intermediate > reprensentation (HIR). > + * Convert abstract syntax to high-level intermediate > reprensentation (HIR). > * > * During the conversion to HIR, the majority of the symantic > checking is > * preformed on the program. This includes: > @@ -31,22 +31,6 @@ > ** Symbol table management > ** Type checking > ** Function binding > - * > - * The majority of this work could be done during parsing, and the > parser could > - * probably generate HIR directly. However, this results in > frequent changes > - * to the parser code. Since we do not assume that every system > this complier > - * is built on will have Flex and Bison installed, we have to store > the code > - * generated by these tools in our version control system. In other > parts of > - * the system we've seen problems where a parser was changed but the > generated > - * code was not committed, merge conflicts where created because two > developers > - * had slightly different versions of Bison installed, etc. > - * > - * I have also noticed that running Bison generated parsers in GDB > is very > - * irritating. When you get a segfault on '$$ = $1->foo', you can't > very > - * well 'print $1' in GDB. > - * > - * As a result, my preference is to put as little C code as possible > in the > - * parser (and lexer) sources. > */ > > #include "glsl_symbol_table.h" ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] glsl: remove out of date comments from file header
The bison/flex generated code hasn't been keeped in version control for a long time, and I doubt anyone is going to argue for putting all this validation in the parser. --- src/compiler/glsl/ast_to_hir.cpp | 18 +- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp index b558589..fc0d448 100644 --- a/src/compiler/glsl/ast_to_hir.cpp +++ b/src/compiler/glsl/ast_to_hir.cpp @@ -23,7 +23,7 @@ /** * \file ast_to_hir.c - * Convert abstract syntax to to high-level intermediate reprensentation (HIR). + * Convert abstract syntax to high-level intermediate reprensentation (HIR). * * During the conversion to HIR, the majority of the symantic checking is * preformed on the program. This includes: @@ -31,22 +31,6 @@ ** Symbol table management ** Type checking ** Function binding - * - * The majority of this work could be done during parsing, and the parser could - * probably generate HIR directly. However, this results in frequent changes - * to the parser code. Since we do not assume that every system this complier - * is built on will have Flex and Bison installed, we have to store the code - * generated by these tools in our version control system. In other parts of - * the system we've seen problems where a parser was changed but the generated - * code was not committed, merge conflicts where created because two developers - * had slightly different versions of Bison installed, etc. - * - * I have also noticed that running Bison generated parsers in GDB is very - * irritating. When you get a segfault on '$$ = $1->foo', you can't very - * well 'print $1' in GDB. - * - * As a result, my preference is to put as little C code as possible in the - * parser (and lexer) sources. */ #include "glsl_symbol_table.h" -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev