Hash Table Not Overwriting - mIRC Discussion Forums

So I can add new people to the list, but when I try to leave the list it doesn't actually save the file that I left. It's like it's not overwriting the file so that the key that left the table is gone.

Code:

on *:TEXT:-list*:#: { 
  hload -i list List.ini IGNs
  if ($2 == join) {
    if ($4) || ($len($3) <= 3) || ($len($3) >= 25) {
      msg $chan $nick make sure your IGN is written without spaces.
    }
    else if ($3) {
      if ( $hget(list, $nick) > 0) {
        msg $chan $nick is already on the list as $hget(list, $nick) .
      }
      else if ( $hfind(list, $3, 1).data > 0) {
        msg $chan $3 was already put on the list by $hfind(list, $3, 1).data .
      }
      else {
        hadd list $nick $3
        
        hsave -i list List.ini IGNs
        msg $chan $nick $3 joins the list ( $chr(35) $hget(list, 0).item ) as $3 .
      }
    }
  }
  elseif ($2 == leave) {
    if ( $hget(list, $nick) > 0) {
      msg $chan $nick ( IGN: $hget(list, $nick) ) leaves the list.
      hdel -sw list $nick
      hsave -i list List.ini IGNs
    }
  }
}

I also have some questions aside from it not saving the key being removed. I also can't find a way to look for a value (not key) and return the key associated with it. I'd also like to know if there's a simple command for returning the number of keys in the table.

if you look in the /help section on hash tables, it documents how you can do a hget that will tell you the number of keys in a table. Also there is a way to search through the 'data' associated with a key, and once you found it you could display its key, its all in /help.

Pay particular attention to the .item etc. information in help for hash tables, i think all that you want is there.

You're right that I overlooked the .item thing (it correctly tells me the number of keys now) and I figured out what I was doing wrong with the value search to find the related keys.

But do you have anything for why it's not overwriting the file without the removed keys? It's like it really doesn't want to acknowledge that they left the list. It'll write a new value for the key if I change it, but if I tell it to "hdel" the key and save it still shows up in the file.

That seems to be the behavior for ini files, despite you not using the -a switch. Also note there's no -o switch like you've used.

So there's no way to remove a key from the ini file?

from help:
/hdel -sw <name> <item>

Deletes an item from a hash table.

The -w switch indicates that item is a wildcard, all matching items are freed.

I believe, this is what your looking for.

Which is what I have. The issue is that when I save the file afterwards, the old key is still in the file and I don't understand why since it's no longer in the table and it's supposed to be overwriting the file.

You can clear the ini section before you hsave, hsave not overwriting sounds like a bug but it may not be fixed if it's standing existing behavior.

How do I "clear the ini section" then?

/remini list.ini IGNs

Any reason why when someone joins after being removed that they end up at the top of the list? (I did add what you said.)

e.g.
x joins, y joins, z joins in that order.
x leaves, x joins.
It still lists them in the file as x, y, z.

Hash tables are "unordered".

Okay. I'm not sure what you really mean by that. Unordered would imply to me that you're saying that it SHOULD say y, z, x since it doesn't order them, but that's not the order it places them in in my given example. For whatever reason, the removed key is placed back in the same location of the table if they rejoin even if its value is different.

The value doesn't matter at all. The key is being hashed and is then placed in a bucket. The placement is deterministic but seemingly random.

http://en.wikipedia.org/wiki/Hash_table

Okay then. Well I switched to trying to use simple arrays to do the same job, but I'm having an issue trying to use a variable to determine the element I want to look at.

Code:

on *:TEXT:-test*:#: {
  var %test
  set %test[0] bob
  set %test[0].ign ign1
  set %test[1] joe
  set %test[1].ign ign2
  set %test[2] tim
  set %test[2].ign ign3
  set %test[3] george
  set %test[3].ign ign4
  
  remini Test.ini List
  var %i = 0
  var %cur = %test[%i]
  ;this current part isn't working

  msg $chan %cur
  while (%test[%i] != $null) {
    writeini Test.ini List %test[%i] %test[%i].ign
    ;again this part isn't working
    inc %i
  }
  
  msg $chan saved? %anum
}

I'm pretty sure this isn't the best way the implement the arrays from what I've seen (which use an array table or something), but it's the simplest. It DOES work if I tell it to access an actual number element instead of %i. Like displaying %test[0] shows "bob" and %test[0].ign shows ign1 but having %i = 0 returns nothing.

Pretty pointless to reply again, but I just want to say thanks to you two for helping me out. I'm ditching the project in favor of a simpler method suggested by a friend so don't worry about replying. Thank you for the help though!

This sounds like a bug to me as well. When using /hsave to save a hash table to an INI file, I think most scripters would expect the INI section to contain only the saved hash table, not a random mix of old and new items. Even though this behaviour has been around for a long time, I think it would make sense to fix it. This issue will be fixed for the next version.