On Wed, Nov 21, 2012 at 5:16 PM, Peter Bex
<address@hidden> wrote:
On Wed, Nov 21, 2012 at 12:52:02PM -0500, Claude Marinier wrote:
> Hi,
Hi!
> I am relatively new to Scheme, i.e. this is my first significant program.
> The program uses a few hash tables; some use a four element u8 vector as
> the key and others use an eight element u16 vector (yes, they are IP
> addresses). It seems to work but, when dumping the tables, I noticed
> multiple (two or three) entries for some IPv4 addresses.
>
> I have some questions.
>
> - Is this expected to work?
Of course, it's no rocket science :)
> - Am I doing something off the beaten path?
Not really.
> - How is the hash function's length parameter calculated?
It has a few prime numbers that are used as lengths, the first one
is 307 which is also the default length. Check the file srfi-69.scm in
Chicken's source code for more details.
> - Could the hash function be looking beyond the end of the vector?
Not very likely; hash tables are pretty commonly used. A typical
beginner's mistake is to assume the compiler is at fault. Or worse,
that the CPU itself is at fault. Yeah, I've made that mistake in the
past. *hangs head in shame*.
> At this point, I am not sure how to approach debugging.
The typical Schemer's way of doing this is to fire up a REPL (the csi
program, possibly in an inferior Scheme buffer in Emacs), and load the
library, then start manually typing commands to probe the system.
You could create a hash table and insert the same address a few times,
print it after each insertion and see what happens.
Of course, printf debugging is a good tool to have in your arsenal as
well, for any programming language. Just pepper your code with print-
statements and run it, see if it prints what you'd expect.
It is clear that this is expected to work and that I am not doing anything strange with the table or the keys. I can now return to the code with the conviction that I made a mistake somewhere.
This is want I really needed.
> I have created a small test program but it just works. Recreating
> this may be difficult. I
> will gratefully consider your suggestions.
See below.
> I am using Chicken Scheme 4.8.0 on Debian Squeeze (i686). The program uses
> the following packages.
>
> (require-extension numbers extras posix srfi-13 srfi-14 srfi-69
> FNVAHash hash-utils)
>
> If you want to look at the code, google this.
>
> sourceforge hostipstats
I'm going to try to say this in the nicest way I can, please don't
take it the wrong way:
Dumping a medium-size codebase on a mailinglist with the complaint
"there's an error somewhere, please help me fix it" without
specifying where exactly we're supposed to look is pretty rude.
This signals to the recipient "I value my own time but not yours",
but at the same time you're expecting the recipient to invest time
into helping you.
Not supplying a direct link is equally rude, for the same reason.
Also, please don't tell people to specifically use Google; some
hackers value (what's left of) their privacy and try to avoid Google.
With that out of the way, let's continue to (hopefully) a solution for
your problem:
My appologies. I should have left the reference to the source code out entirely. I did not expect anyone to look at the code but felt compelled to include a reference. My mistake.
If there is a next time, I will try to extract code and include it in the post.
> The main is accmlr.scm; the next phase of the project will be a user
> interface to view the data.
I finally managed to find the code after clicking through a very
generic-looking Sourceforge placeholder page just before giving up.
>From a cursory glance, it looks like the problem is the code in the
update-IPv4-counters procedure. (vector? x) returns #f for u8vectors
because those are a different type. You'll need to use the u8vector?
predicate instead:
#;1> (use srfi-4)
; loading /usr/pkg/lib/chicken/6/srfi-4.import.so ...
; loading library srfi-4 ...
#;2> (vector? (make-u8vector 4 0))
#f
#;3> (u8vector? (make-u8vector 4 0))
#t
Hope this helps!
Aha! Thank you for taking the time to look at the code. I did not expect this; I just needed to know it should work.
P.S. Donald Knuth's statement is true.
Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth