Re: ksh(1): encapsulate hashtable iteration usage

2012-02-19 Thread Steffen Daode Nurpmeso
Otto Moerbeek wrote [2012-02-19 08:49+0100]: while I did graduate on a theoretical computer science subject myself I have no doubt about that. (?) I think this alternate hash table stuff is all overkill for ksh. But a linear array based implementation with INT_MAX/2 is a heavy thing. Did you

Re: ksh(1): encapsulate hashtable iteration usage

2012-02-18 Thread Steffen Daode Nurpmeso
Steffen Daode Nurpmeso wrote [2012-02-15 14:55+0100]: the patch below localizes access of struct table internals to table.c by using the ktwalk()/ktnext() interface from proto.h instead of doing handcrafted table iterations. Yes it was wrong because it didn't take the flags into account

Re: ksh(1): encapsulate hashtable iteration usage

2012-02-18 Thread Otto Moerbeek
On Sat, Feb 18, 2012 at 09:18:29PM +0100, Steffen Daode Nurpmeso wrote: [snip] while I did graduate on a theoretical computer science subject myself I think this alternate hash table stuff is all overkill for ksh. A typical shell instance has very little vars. Added to that, the ksh code is

ksh(1): encapsulate hashtable iteration usage

2012-02-15 Thread Steffen Daode Nurpmeso
Hey all, the patch below localizes access of struct table internals to table.c by using the ktwalk()/ktnext() interface from proto.h instead of doing handcrafted table iterations. Surely a useful change regardless of possibly turning over to a node-based hashmap approach. --steffen Index: