Re: [Mesa-dev] [PATCH 3/3] glsl: remove out of date comments from file header

[Matt Turner]

On Wed, Feb 10, 2016 at 8:45 PM, Timothy Arceri
 wrote:
> 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

[Timothy Arceri]

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

[Timothy Arceri]

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