google-sparsehash - Project Hosting on Google Code

Today 22 hours ago issue 50 (Source won't compile on Unix systems) changed by csilvers - Weird, I thought I had compiled the unittest before I submitted the last SVN revision, but maybe not. It does look like I did an incomplete job of adding StrHash as the hash function template-parameter everywhere I was hashing a string. I believe the fix is to just change sparse_hash_map<string, XXX> to sparse_hash_map<string, XXX, StrHash> and likewise with dense_hash_map. We also need to change sparse_hash_map<char, XXX> if any of those occur. I'll take care of it after I'm back from vacation. If you'd like to do the patch earlier than that, feel free, and can attach it here! Status: Accepted Labels: Type-Defect Priority-Medium Weird, I thought I had compiled the unittest before I submitted the last SVN revision, but maybe not. It does look like I did an incomplete job of adding StrHash as the hash function template-parameter everywhere I was hashing a string. I believe the fix is to just change sparse_hash_map<string, XXX> to sparse_hash_map<string, XXX, StrHash> and likewise with dense_hash_map. We also need to change sparse_hash_map<char, XXX> if any of those occur. I'll take care of it after I'm back from vacation. If you'd like to do the patch earlier than that, feel free, and can attach it here! Status: Accepted Labels: Type-Defect Priority-Medium 22 hours ago issue 51 (Experminal sparse hash c code won't compile on visual studio...) Status changed by csilvers - Sorry, but we don't maintain the code in the experimental directory. You're welcome to do whatever you'd like to get the code working! -- and can post a patch here. I'm happy to add the patch to the experimental directory in future releases, in case it helps anyone. That said, I think in.h is just used for the inet_ntoa routines. In modern unices, it's probably better to use bswap32/64. So you shouldn't need winsock, just the windows equivalent of bswap32/64. Status: WontFix Sorry, but we don't maintain the code in the experimental directory. You're welcome to do whatever you'd like to get the code working! -- and can post a patch here. I'm happy to add the patch to the experimental directory in future releases, in case it helps anyone. That said, I think in.h is just used for the inet_ntoa routines. In modern unices, it's probably better to use bswap32/64. So you shouldn't need winsock, just the windows equivalent of bswap32/64. Status: WontFix Yesterday 36 hours ago issue 51 (Experminal sparse hash c code won't compile on visual studio...) reported by m.nabil.hafez - What steps will reproduce the problem? 1. Compile the experimental C sparsehash on visual studio 2. netinet/in.h not found -> as it's a unix specific header What is the expected output? What do you see instead? Code is portable What version of the product are you using? On what operating system? windows 7 Please provide any additional information below. we can replace netinet/in.h with the winsock lib, any idea ? What steps will reproduce the problem? 1. Compile the experimental C sparsehash on visual studio 2. netinet/in.h not found -> as it's a unix specific header What is the expected output? What do you see instead? Code is portable What version of the product are you using? On what operating system? windows 7 Please provide any additional information below. we can replace netinet/in.h with the winsock lib, any idea ? 47 hours ago issue 50 (Source won't compile on Unix systems) reported by shiranpasternak - What steps will reproduce the problem? 1. Check out revision 46 from trunk 2. Run ./configure 3. Run make What is the expected output? What do you see instead? Got the following error: ./src/google/sparsehash/sparsehashtable.h: In member function `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::move_from(google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::MoveDontCopyT, google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>&, size_t) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]': ./src/google/sparsehash/sparsehashtable.h:738: instantiated from `google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::sparse_hashtable(google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::MoveDontCopyT, google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>&, size_t) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparsehash/sparsehashtable.h:435: instantiated from `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::squash_deleted() [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparsehash/sparsehashtable.h:444: instantiated from `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::set_deleted_key(const Key&) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparse_hash_map:269: instantiated from `void google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::set_deleted_key(const typename google::sparse_hashtable<std::pair<const _Key, _Tp>, Key, HashFcn, google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::SelectKey, google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::SetKey, EqualKey, Alloc>::key_type&) [with Key = std::string, T = std::string, HashFcn = __gnu_cxx::hash<std::string>, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' src/hashtable_unittest.cc:1084: instantiated from here ./src/google/sparsehash/sparsehashtable.h:654: error: no match for call to `(__gnu_cxx::hash<std::string>) (const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)' make[1]: *** [hashtable_unittest.o] Error 1 What version of the product are you using? On what operating system? Tried it on 2 operating systems: * Red Hat Enterprise Linux WS release 4 (Nahant Update 3) * OpenSolaris 2008.11 snv_101b_rc2 X86 Please provide any additional information below. When I roll back to revision 44, everything works fine. What steps will reproduce the problem? 1. Check out revision 46 from trunk 2. Run ./configure 3. Run make What is the expected output? What do you see instead? Got the following error: ./src/google/sparsehash/sparsehashtable.h: In member function `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::move_from(google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::MoveDontCopyT, google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>&, size_t) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]': ./src/google/sparsehash/sparsehashtable.h:738: instantiated from `google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::sparse_hashtable(google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::MoveDontCopyT, google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>&, size_t) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparsehash/sparsehashtable.h:435: instantiated from `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::squash_deleted() [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparsehash/sparsehashtable.h:444: instantiated from `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::set_deleted_key(const Key&) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparse_hash_map:269: instantiated from `void google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::set_deleted_key(const typename google::sparse_hashtable<std::pair<const _Key, _Tp>, Key, HashFcn, google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::SelectKey, google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::SetKey, EqualKey, Alloc>::key_type&) [with Key = std::string, T = std::string, HashFcn = __gnu_cxx::hash<std::string>, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' src/hashtable_unittest.cc:1084: instantiated from here ./src/google/sparsehash/sparsehashtable.h:654: error: no match for call to `(__gnu_cxx::hash<std::string>) (const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)' make[1]: *** [hashtable_unittest.o] Error 1 What version of the product are you using? On what operating system? Tried it on 2 operating systems: * Red Hat Enterprise Linux WS release 4 (Nahant Update 3) * OpenSolaris 2008.11 snv_101b_rc2 X86 Please provide any additional information below. When I roll back to revision 44, everything works fine. Last 30 days Dec 15, 2009 issue 49 (build fails for mingw) commented on by rogerpack2005 - #ifndef _MSC_VER seems to do the trick thanks! -r #ifndef _MSC_VER seems to do the trick thanks! -r Dec 14, 2009 issue 49 (build fails for mingw) changed by csilvers - I think the right fix is to change the WIN32 #ifdef to _MSC_VER, in hasthable_unittest.cc. I'll make that part of the next release. Status: Started Labels: Type-Defect Priority-Medium I think the right fix is to change the WIN32 #ifdef to _MSC_VER, in hasthable_unittest.cc. I'll make that part of the next release. Status: Started Labels: Type-Defect Priority-Medium Dec 14, 2009 issue 49 (build fails for mingw) reported by rogerpack2005 - What steps will reproduce the problem? 1. attempt to compile using msys http://groups.google.com/group/google- sparsehash/browse_thread/thread/b0ddb3f8c611f751 What steps will reproduce the problem? 1. attempt to compile using msys http://groups.google.com/group/google- sparsehash/browse_thread/thread/b0ddb3f8c611f751 Dec 11, 2009 issue 47 (Feature request: get deleted_key and empty_key) Labels changed by csilvers - Shaun has offered to write up a patch. Yay! Shaun, can you also (e)sign the contributor license at http://code.google.com/legal/individual-cla-v1.0.html ? Thanks, craig Labels: Type-Enhancement Priority-Medium Shaun has offered to write up a patch. Yay! Shaun, can you also (e)sign the contributor license at http://code.google.com/legal/individual-cla-v1.0.html ? Thanks, craig Labels: Type-Enhancement Priority-Medium Dec 11, 2009 issue 48 (dense_hash_map fails for large data sets) changed by csilvers - You need to specify a hash function for char. Otherwise, you're hashing pointers, which will not work as you want. See the first example in http://google-sparsehash.googlecode.com/svn/trunk/doc/dense_hash_map.html } I tried resize(100000) at startup but this only affects the load factor and has no } bearing on the size. That's not correct. It actually does affect the size, but not the load factor. You can also try using the one-arg constructor where you pass in the size, rather than having to call resize after creating the object. Status: Invalid Labels: Type-Defect Priority-Medium You need to specify a hash function for char. Otherwise, you're hashing pointers, which will not work as you want. See the first example in http://google-sparsehash.googlecode.com/svn/trunk/doc/dense_hash_map.html } I tried resize(100000) at startup but this only affects the load factor and has no } bearing on the size. That's not correct. It actually does affect the size, but not the load factor. You can also try using the one-arg constructor where you pass in the size, rather than having to call resize after creating the object. Status: Invalid Labels: Type-Defect Priority-Medium Dec 11, 2009 issue 48 (dense_hash_map fails for large data sets) commented on by rags.iyengar - Also, map.size() seems to have a ceiling of ~844. I tried resize(100000) at startup but this only affects the load factor and has no bearing on the size. Is there a way of increasing the number of buckets? I'm only concerned with rapid lookups; don't really care for memory Also, map.size() seems to have a ceiling of ~844. I tried resize(100000) at startup but this only affects the load factor and has no bearing on the size. Is there a way of increasing the number of buckets? I'm only concerned with rapid lookups; don't really care for memory Dec 11, 2009 issue 48 (dense_hash_map fails for large data sets) reported by rags.iyengar - What steps will reproduce the problem? 1. populate a dense_hash_map<const char, const char> with 30,000 entries 2. the key is a 21 character long(e.g "ODBC456789.12/45-BA91") 3. 4. What is the expected output? What do you see instead? Calling map.find on a key I know was inserted should return the value. instead find returns map.end What version of the product are you using? On what operating system? sparsehash-1.5.2 (dense_hash_map) on MSVC 7.1.6030 Please provide any additional information below. What steps will reproduce the problem? 1. populate a dense_hash_map<const char, const char> with 30,000 entries 2. the key is a 21 character long(e.g "ODBC456789.12/45-BA91") 3. 4. What is the expected output? What do you see instead? Calling map.find on a key I know was inserted should return the value. instead find returns map.end What version of the product are you using? On what operating system? sparsehash-1.5.2 (dense_hash_map) on MSVC 7.1.6030 Please provide any additional information below. Dec 11, 2009 issue 47 (Feature request: get deleted_key and empty_key) reported by sjackman - Implement accessors for deleted and empty_key. Implement accessors for deleted and empty_key. Dec 10, 2009 issue 46 (constructor get stuck in an infinite loop for some values on...) Status changed by csilvers - Status: Started Status: Started Dec 10, 2009 issue 46 (constructor get stuck in an infinite loop for some values on...) commented on by csilv...@google.com - Gotcha. Makes sense to me. I'll add an overflow assert() in the next release, so at least in debug mode you'll die rather than go into an infinite loop. Gotcha. Makes sense to me. I'll add an overflow assert() in the next release, so at least in debug mode you'll die rather than go into an infinite loop. Dec 10, 2009 issue 46 (constructor get stuck in an infinite loop for some values on...) commented on by pmelsted - I'm not sure either what the right behaviour should be. When inserting a delete key the hashtable fails with an assert, perhaps this would also be an option here. This came up by accident, I was initializing the hashtable with an unspecified value (doh!) and it happened to be initialized with 3.2 billion. The program was unresponsive and I had no idea why until I debugged it, getting a crash would have told me where the problem was. I don't think there is a valid use case for asking for more than 2^31 elements in your table, since they would have to occupy 4 bytes each (otherwise there aren't enough distinct ones to fill the table), in which case you've exhausted the memory. So in my opinion, failing with an assert is the best thing to do in this situation. I'm not sure either what the right behaviour should be. When inserting a delete key the hashtable fails with an assert, perhaps this would also be an option here. This came up by accident, I was initializing the hashtable with an unspecified value (doh!) and it happened to be initialized with 3.2 billion. The program was unresponsive and I had no idea why until I debugged it, getting a crash would have told me where the problem was. I don't think there is a valid use case for asking for more than 2^31 elements in your table, since they would have to occupy 4 bytes each (otherwise there aren't enough distinct ones to fill the table), in which case you've exhausted the memory. So in my opinion, failing with an assert is the best thing to do in this situation. Dec 09, 2009 issue 46 (constructor get stuck in an infinite loop for some values on...) Labels changed by csilvers - Definitely a problem! But I'm not sure what the 'right' behavior here would be. sz can't be 2^32 because that's too big to fit in 32 bits. But I'm confused how this could occur in practice. Do you have a machine where size_t is 32 bits but you can address more than 32 bits of memory? If not, how are youu planning to get more than 2^31 elements in your hashtable? I'm trying to understand what the right thing to do here is. I could make sz always be 64 bits, but that seems wrong -- it should really be size_type. I guess I could just make construction fail somehow if you pass in something > \|size_type\| / 2? What particular use-case brought this up? Labels: Type-Defect Priority-Medium Definitely a problem! But I'm not sure what the 'right' behavior here would be. sz can't be 2^32 because that's too big to fit in 32 bits. But I'm confused how this could occur in practice. Do you have a machine where size_t is 32 bits but you can address more than 32 bits of memory? If not, how are youu planning to get more than 2^31 elements in your hashtable? I'm trying to understand what the right thing to do here is. I could make sz always be 64 bits, but that seems wrong -- it should really be size_type. I guess I could just make construction fail somehow if you pass in something > \|size_type\| / 2? What particular use-case brought this up? Labels: Type-Defect Priority-Medium Dec 09, 2009 issue 46 (constructor get stuck in an infinite loop for some values on...) reported by pmelsted - What steps will reproduce the problem? 1. sparse_hash_map<int> sp_Map(x) for any x between 1<<31 and (1<<32)-1 2. wait forever! 3. are we done with step 2? What is the expected output? What do you see instead? constructor should not get stuck in an infinite loop Please use labels and text to provide additional information. The constructor in sparsehashtable.h, calls min_size(num_elts, min_buckets) and tries to find the smallest power of 2 greater than num_elts. This is done by initializing sz to a default value of 32 and repeatedly multiplying sz by 2 until we find a value which can hold buckets (with af fudge factor). if num_elts is greater than 2^31 the result for sz should be 2^32. On 32-bit systems sz overflows to 0 and gets stuck in an infinite loop since sz = 2 doesn't modify sz. Theoretically this is also a problem on 64 bit systems, but I doubt anyone would want a hashtable of size 2^63 (yet). The code for min_size, taken from trunk size_type min_size(size_type num_elts, size_type min_buckets_wanted) { size_type sz = HT_MIN_BUCKETS; while ( sz < min_buckets_wanted \|\| num_elts >= sz enlarge_resize_percent ) sz = 2; return sz; } What steps will reproduce the problem? 1. sparse_hash_map<int> sp_Map(x) for any x between 1<<31 and (1<<32)-1 2. wait forever! 3. are we done with step 2? What is the expected output? What do you see instead? constructor should not get stuck in an infinite loop Please use labels and text to provide additional information. The constructor in sparsehashtable.h, calls min_size(num_elts, min_buckets) and tries to find the smallest power of 2 greater than num_elts. This is done by initializing sz to a default value of 32 and repeatedly multiplying sz by 2 until we find a value which can hold buckets (with af fudge factor). if num_elts is greater than 2^31 the result for sz should be 2^32. On 32-bit systems sz overflows to 0 and gets stuck in an infinite loop since sz = 2 doesn't modify sz. Theoretically this is also a problem on 64 bit systems, but I doubt anyone would want a hashtable of size 2^63 (yet). The code for min_size, taken from trunk size_type min_size(size_type num_elts, size_type min_buckets_wanted) { size_type sz = HT_MIN_BUCKETS; while ( sz < min_buckets_wanted \|\| num_elts >= sz * enlarge_resize_percent ) sz = 2; return sz; } Dec 01, 2009 r46 ( Erase returns an iterator, like tr1 says to (csilvers) ...) committed by csilvers - Erase returns an iterator, like tr1 says to (csilvers) * Speed up densehashtable::clear() a bit (jeff) * BUGFIX: operator= when the 2 empty-keys differ (andreidam) * BUGFIX: fit hashtable copying when empty-key isn't set (andreidam) * BUGFIX: some actions could shrink ht even with min-load 0 (shaunj) * Improve densehashtable code for the deleted key (gpike) * Update comments and docs on space and time use (gpike, csilvers) * BUGFIX: Fix a bug causing excessive recopying (csilvers) * PORTING: Remove obsolete Detect64BitPoortabilityProblems (csilvers) * PORTING: Fix the build for Stratus VOS: no # in filenames (csilvers) * Erase returns an iterator, like tr1 says to (csilvers) * Speed up densehashtable::clear() a bit (jeff) * BUGFIX: operator= when the 2 empty-keys differ (andreidam) * BUGFIX: fit hashtable copying when empty-key isn't set (andreidam) * BUGFIX: some actions could shrink ht even with min-load 0 (shaunj) * Improve densehashtable code for the deleted key (gpike) * Update comments and docs on space and time use (gpike, csilvers) * BUGFIX: Fix a bug causing excessive recopying (csilvers) * PORTING: Remove obsolete Detect64BitPoortabilityProblems (csilvers) * PORTING: Fix the build for Stratus VOS: no # in filenames (csilvers) Earlier this year Nov 05, 2009 issue 45 (Can't compile on debian lenny i386) Status changed by csilvers - Looks like you filed this under the wrong project. Can you re-file under google-perftools? Status: Invalid Looks like you filed this under the wrong project. Can you re-file under google-perftools? Status: Invalid Nov 05, 2009 issue 45 (Can't compile on debian lenny i386) reported by fredericsmailbox - Source code just updated and can't compile it on Debian Lenny i386 (./configure --enable-minimal and without): In file included from src/symbolize.cc:37: src/symbolize.h:45: error: ‘uintptr_t’ was not declared in this scope src/symbolize.h:45: error: template argument 1 is invalid src/symbolize.h:45: error: template argument 3 is invalid src/symbolize.h:45: error: template argument 4 is invalid src/symbolize.h:45: error: invalid type in declaration before ‘;’ token src/symbolize.cc: In function ‘bool Symbolize(char, int, SymbolMap)’: src/symbolize.cc:134: error: expected initializer before ‘iter’ src/symbolize.cc:135: error: ‘iter’ was not declared in this scope src/symbolize.cc:135: error: request for member ‘end’ in ‘* symbolization_table’, which is of non-class type ‘int’ src/symbolize.cc:168: error: expected initializer before ‘fill’ src/symbolize.cc:172: error: ‘fill’ was not declared in this scope make: *** [libtcmalloc_minimal_internal_la-symbolize.lo] Error 1 Regards Frederic Source code just updated and can't compile it on Debian Lenny i386 (./configure --enable-minimal and without): In file included from src/symbolize.cc:37: src/symbolize.h:45: error: ‘uintptr_t’ was not declared in this scope src/symbolize.h:45: error: template argument 1 is invalid src/symbolize.h:45: error: template argument 3 is invalid src/symbolize.h:45: error: template argument 4 is invalid src/symbolize.h:45: error: invalid type in declaration before ‘;’ token src/symbolize.cc: In function ‘bool Symbolize(char, int, SymbolMap)’: src/symbolize.cc:134: error: expected initializer before ‘iter’ src/symbolize.cc:135: error: ‘iter’ was not declared in this scope src/symbolize.cc:135: error: request for member ‘end’ in ‘* symbolization_table’, which is of non-class type ‘int’ src/symbolize.cc:168: error: expected initializer before ‘fill’ src/symbolize.cc:172: error: ‘fill’ was not declared in this scope make: *** [libtcmalloc_minimal_internal_la-symbolize.lo] Error 1 Regards Frederic Oct 11, 2009 issue 44 (windows/port.cc:TmpFile returns a pointer to a local varaibl...) changed by csilvers - This is actually fine -- the function returns a string, not a pointer, so the local buffer is converted to a string before being returned. I'm closing this as NotABug. Though maybe it's a good bug to file with the static analysis tool? :-) Status: WontFix Labels: Type-Defect Priority-Medium This is actually fine -- the function returns a string, not a pointer, so the local buffer is converted to a string before being returned. I'm closing this as NotABug. Though maybe it's a good bug to file with the static analysis tool? :-) Status: WontFix Labels: Type-Defect Priority-Medium Oct 07, 2009 issue 44 (windows/port.cc:TmpFile returns a pointer to a local varaibl...) reported by jrleek - We found this bug with a static analysis tool. It's an easy fix. Line 55 of src/windows/port.cc has: char tmppath_buffer[1024]; line 62 has: return tmppath_buffer; oops. What version of the product are you using? On what operating system? I found this in version 1.3, but it's still there in 1.5.2. We found this bug with a static analysis tool. It's an easy fix. Line 55 of src/windows/port.cc has: char tmppath_buffer[1024]; line 62 has: return tmppath_buffer; oops. What version of the product are you using? On what operating system? I found this in version 1.3, but it's still there in 1.5.2. Jun 11, 2009 issue 41 (Error in documentation of max_load_factor and min_load_facto...) Labels changed by csilvers - Labels: Type-Defect Priority-Medium Labels: Type-Defect Priority-Medium Jun 11, 2009 issue 43 (Library Paths) Status changed by csilvers - For questions like this, you can just mail them to the mailing list for this project: google-sparsehash@googlegroups.com. In this case, I don't really understand your question. What do you mean by "library path"? Status: Invalid For questions like this, you can just mail them to the mailing list for this project: google-sparsehash@googlegroups.com. In this case, I don't really understand your question. What do you mean by "library path"? Status: Invalid Jun 11, 2009 issue 42 (Fix build for VOS: # not allowed in filenames) Summary changed by csilvers - Summary: Fix build for VOS: # not allowed in filenames Summary: Fix build for VOS: # not allowed in filenames Jun 11, 2009 issue 42 (Submit Port) changed by csilvers - No problem -- I'll just replace the # for everyone. It's not really needed. Status: Started Labels: Type-Defect Priority-Medium No problem -- I'll just replace the # for everyone. It's not really needed. Status: Started Labels: Type-Defect Priority-Medium Jun 10, 2009 issue 43 (Library Paths) reported by bornlibra23 - Can I have the object, include & executable lilbrary paths? I couldnt find them in the manual. I am especially looking for object path if any. Can I have the object, include & executable lilbrary paths? I couldnt find them in the manual. I am especially looking for object path if any. Jun 10, 2009 issue 42 (Submit Port) commented on by bornlibra23 - It is a port to Stratus VOS operating system. Sorry for the typo. I dont know how to diff files so I will just tell the files & how to identify the change. hashtable_unittest.cc : Search for __VOS__ sparsetable_unittest.cc: Search for __VOS__ Both these locations assume that # is a allowed character in the file name but on VOS it isnt. Can configure check for such characters? Thanks Ashutosh Warikoo It is a port to Stratus VOS operating system. Sorry for the typo. I dont know how to diff files so I will just tell the files & how to identify the change. hashtable_unittest.cc : Search for __VOS__ sparsetable_unittest.cc: Search for __VOS__ Both these locations assume that # is a allowed character in the file name but on VOS it isnt. Can configure check for such characters? Thanks Ashutosh Warikoo Jun 08, 2009 issue 42 (Submit Port) Status changed by csilvers - Can you clarify: are you trying to submit a port, or a post? If it's a port, just put it here: you can attach the diff as a file. If it's a post, you can send it to google-sparsehash@googlegroups.com. Status: Invalid Can you clarify: are you trying to submit a port, or a post? If it's a port, just put it here: you can attach the diff as a file. If it's a post, you can send it to google-sparsehash@googlegroups.com. Status: Invalid Jun 07, 2009 issue 42 (Submit Port) reported by bornlibra23 - Hello Project Owner Actually I Am Trying To Submit A Post. Couldnt Find Any Other Way To Contact. How Do I Submit It? Hello Project Owner Actually I Am Trying To Submit A Post. Couldnt Find Any Other Way To Contact. How Do I Submit It? May 15, 2009 issue 41 (Error in documentation of max_load_factor and min_load_facto...) commented on by tenox2800 - Great! Thanks again! Great! Thanks again! May 15, 2009 issue 41 (Error in documentation of max_load_factor and min_load_facto...) Status changed by csilvers - Oops! In fact, the prototype is totally wrong. I've fixed it on all 4 pages, which will be in the next release. Status: Started Oops! In fact, the prototype is totally wrong. I've fixed it on all 4 pages, which will be in the next release. Status: Started May 14, 2009 issue 41 (Error in documentation of max_load_factor and min_load_facto...) reported by tenox2800 - The documentation for sparse_hash_map reads: float max_load_factor(size_t new_grow) and float min_load_factor(size_t new_grow) In both of these cases it seems that new_grow is a float not a size_t. The documentation for sparse_hash_map reads: float max_load_factor(size_t new_grow) and float min_load_factor(size_t new_grow) In both of these cases it seems that new_grow is a float not a size_t. May 12, 2009 issue 40 (sparcehash/sparcehashtable.h:670 'set' parameter is not used...) Status changed by csilvers - OK, fixed in sparsehash 1.5.2, just released. Status: Fixed OK, fixed in sparsehash 1.5.2, just released. Status: Fixed May 12, 2009 sparsehash-1.5.2.zip (Zip file for sparsehash 1.5.2 (includes .sln and .vcproj fil...) file uploaded by csilvers - Labels: Type-Source OpSys-Windows Featured Labels: Type-Source OpSys-Windows Featured May 12, 2009 sparsehash-1.5.2.tar.gz (Tarball for sparsehash 1.5.2) file uploaded by csilvers - Labels: Type-Source OpSys-All Featured Labels: Type-Source OpSys-All Featured May 12, 2009 sparsehash_1.5.2-1_amd64.deb (Deb for sparsehash 1.5.2 (64 bit)) file uploaded by csilvers - Labels: Type-Package OpSys-Linux Labels: Type-Package OpSys-Linux May 12, 2009 sparsehash-1.5.2-1.noarch.rpm (RPM for sparsehash 1.5.2) file uploaded by csilvers - Labels: Type-Package OpSys-Linux Labels: Type-Package OpSys-Linux May 12, 2009 r45 (Tag for sparsehash 1.5.2) committed by csilvers - Tag for sparsehash 1.5.2 Tag for sparsehash 1.5.2 May 12, 2009 r44 (Tue May 12 14:16:38 2009 Google Inc. <opensource@google.com...) committed by csilvers - Tue May 12 14:16:38 2009 Google Inc. <opensource@google.com> * sparsehash: version 1.5.2 release * Fix compile error: not initializing set_key in all constructors Tue May 12 14:16:38 2009 Google Inc. <opensource@google.com> * sparsehash: version 1.5.2 release * Fix compile error: not initializing set_key in all constructors May 12, 2009 issue 40 (sparcehash/sparcehashtable.h:670 'set' parameter is not used...) commented on by tenox2800 - Thanks a lot! Thanks a lot! May 12, 2009 issue 40 (sparcehash/sparcehashtable.h:670 'set' parameter is not used...) changed by csilvers - This is indeed a bug. I'll put out a new release... Status: Started Labels: Type-Defect Priority-Medium This is indeed a bug. I'll put out a new release... Status: Started Labels: Type-Defect Priority-Medium May 12, 2009 issue 40 (sparcehash/sparcehashtable.h:670 'set' parameter is not used...) reported by tenox2800 - What steps will reproduce the problem? 1. Compile with -Wall What is the expected output? What do you see instead? Before upgrading to the 1.5.1 there was no warning, after I get the following: /home/traymond/arch/xhost/include/google/sparsehash/sparsehashtable.h:670: warning: unused parameter 'set' What version of the product are you using? On what operating system? sparcehash-1.5.1 on Red Hat Please provide any additional information below. C++ compiler version: g++ (GCC) 3.4.6 20060404 What steps will reproduce the problem? 1. Compile with -Wall What is the expected output? What do you see instead? Before upgrading to the 1.5.1 there was no warning, after I get the following: /home/traymond/arch/xhost/include/google/sparsehash/sparsehashtable.h:670: warning: unused parameter 'set' What version of the product are you using? On what operating system? sparcehash-1.5.1 on Red Hat Please provide any additional information below. C++ compiler version: g++ (GCC) 3.4.6 20060404 May 09, 2009 issue 39 (equal_range does not work) commented on by sjackman - Speedy! Thanks a lot, Craig. Speedy! Thanks a lot, Craig. May 08, 2009 r43 (Tag for sparsehash tcsh 6.14.00 (Astron) 2005-03-25 (x86_64-...) committed by csilvers - Tag for sparsehash tcsh 6.14.00 (Astron) 2005-03-25 (x86_64-unknown-linux) options wide,nls,dl,al,kan,rh,nd,color,filec Tag for sparsehash tcsh 6.14.00 (Astron) 2005-03-25 (x86_64-unknown-linux) options wide,nls,dl,al,kan,rh,nd,color,filec May 08, 2009 r42 (Fri May 8 15:23:44 2009 Google Inc. <opensource@google.com...) committed by csilvers - Fri May 8 15:23:44 2009 Google Inc. <opensource@google.com> * sparsehash: version 1.5.1 release * Fix broken equal_range() for all the hash-classes (csilvers) Fri May 8 15:23:44 2009 Google Inc. <opensource@google.com> * sparsehash: version 1.5.1 release * Fix broken equal_range() for all the hash-classes (csilvers) May 08, 2009 issue 39 (equal_range does not work) Status changed by csilvers - I've just released sparsehash 1.5.1 to fix this bug. Status: Fixed I've just released sparsehash 1.5.1 to fix this bug. Status: Fixed May 08, 2009 sparsehash-1.5.1.zip (Zip file for sparsehash 1.5.1 (includes .sln and .vcproj fil...) file uploaded by csilvers - Labels: Type-Source OpSys-Windows Featured Labels: Type-Source OpSys-Windows Featured May 08, 2009 sparsehash-1.5.1.tar.gz (Tarball for sparsehash 1.5.1) file uploaded by csilvers - Labels: Type-Source OpSys-All Featured Labels: Type-Source OpSys-All Featured May 08, 2009 sparsehash_1.5.1-1_amd64.deb (Deb for sparsehash 1.5.1 (64 bit)) file uploaded by csilvers - Labels: Type-Package OpSys-Linux Labels: Type-Package OpSys-Linux

issue 50 (Source won't compile on Unix systems) reported by shiranpasternak - What steps will reproduce the problem? 1. Check out revision 46 from trunk 2. Run ./configure 3. Run make What is the expected output? What do you see instead? Got the following error: ./src/google/sparsehash/sparsehashtable.h: In member function `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::move_from(google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::MoveDontCopyT, google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>&, size_t) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]': ./src/google/sparsehash/sparsehashtable.h:738: instantiated from `google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::sparse_hashtable(google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::MoveDontCopyT, google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>&, size_t) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparsehash/sparsehashtable.h:435: instantiated from `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::squash_deleted() [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparsehash/sparsehashtable.h:444: instantiated from `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::set_deleted_key(const Key&) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparse_hash_map:269: instantiated from `void google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::set_deleted_key(const typename google::sparse_hashtable<std::pair<const _Key, _Tp>, Key, HashFcn, google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::SelectKey, google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::SetKey, EqualKey, Alloc>::key_type&) [with Key = std::string, T = std::string, HashFcn = __gnu_cxx::hash<std::string>, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' src/hashtable_unittest.cc:1084: instantiated from here ./src/google/sparsehash/sparsehashtable.h:654: error: no match for call to `(__gnu_cxx::hash<std::string>) (const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)' make[1]: *** [hashtable_unittest.o] Error 1 What version of the product are you using? On what operating system? Tried it on 2 operating systems: * Red Hat Enterprise Linux WS release 4 (Nahant Update 3) * OpenSolaris 2008.11 snv_101b_rc2 X86 Please provide any additional information below. When I roll back to revision 44, everything works fine.

What steps will reproduce the problem? 1. Check out revision 46 from trunk 2. Run ./configure 3. Run make What is the expected output? What do you see instead? Got the following error: ./src/google/sparsehash/sparsehashtable.h: In member function `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::move_from(google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::MoveDontCopyT, google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>&, size_t) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]': ./src/google/sparsehash/sparsehashtable.h:738: instantiated from `google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::sparse_hashtable(google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::MoveDontCopyT, google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>&, size_t) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparsehash/sparsehashtable.h:435: instantiated from `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::squash_deleted() [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparsehash/sparsehashtable.h:444: instantiated from `void google::sparse_hashtable<Value, Key, HashFcn, ExtractKey, SetKey, EqualKey, Alloc>::set_deleted_key(const Key&) [with Value = std::pair<const std::string, std::string>, Key = std::string, HashFcn = __gnu_cxx::hash<std::string>, ExtractKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SelectKey, SetKey = google::sparse_hash_map<std::string, std::string, __gnu_cxx::hash<std::string>, std::equal_to<std::string>, std::allocator<std::string> >::SetKey, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' ./src/google/sparse_hash_map:269: instantiated from `void google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::set_deleted_key(const typename google::sparse_hashtable<std::pair<const _Key, _Tp>, Key, HashFcn, google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::SelectKey, google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::SetKey, EqualKey, Alloc>::key_type&) [with Key = std::string, T = std::string, HashFcn = __gnu_cxx::hash<std::string>, EqualKey = std::equal_to<std::string>, Alloc = std::allocator<std::string>]' src/hashtable_unittest.cc:1084: instantiated from here ./src/google/sparsehash/sparsehashtable.h:654: error: no match for call to `(__gnu_cxx::hash<std::string>) (const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)' make[1]: *** [hashtable_unittest.o] Error 1 What version of the product are you using? On what operating system? Tried it on 2 operating systems: * Red Hat Enterprise Linux WS release 4 (Nahant Update 3) * OpenSolaris 2008.11 snv_101b_rc2 X86 Please provide any additional information below. When I roll back to revision 44, everything works fine.

Today

Yesterday

Last 30 days

Earlier this year