From 3016fd2460b94797af547b464c08f48c87cb9884 Mon Sep 17 00:00:00 2001
From: "Meredith L. Patterson" <clonearmy@gmail.com>
Date: Thu, 3 May 2012 02:09:00 +0100
Subject: [PATCH] Got rid of old comments about how jsparse caches, since we've
 settled on a cache layout

---
 src/hammer.h | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/src/hammer.h b/src/hammer.h
index 773f3e12..b91b9dc8 100644
--- a/src/hammer.h
+++ b/src/hammer.h
@@ -26,15 +26,7 @@
  *   input - the entire string being parsed
  *   index - current position in input
  *   length - size of input
- * THE FOLLOWING DESCRIBES HOW JSPARSE DOES IT. OUR MILEAGE MAY VARY.
- *   cache - a hash table describing the state of the parse, including partial parse_results. 
- *           It's actually a hash table of [parser_id, hash_table[index, parse_result]],
- *           where the parser id is incremented as the parse goes along (parsers that have
- *           already been applied once don't get a new parser_id ... but the global variable
- *           still increments? not sure why that is, need to debug some), and the locations
- *           at which it's been applied are memoized.
- * 
- *           In our case, it's a hash table from parser_cache_key_t to parse_state_t. 
+ *   cache - a hash table describing the state of the parse, including partial parse_results. It's a hash table from parser_cache_key_t to parse_state_t. 
  *
  */
 #define BYTE_BIG_ENDIAN 0x1
-- 
GitLab