How to do table lookups? (fwd)

Edmund Dengler <>
Wed Mar 3 21:05:03 CET 2004


Arggh! Hit the reply too early.

---------- Forwarded message ----------

Hi all!

On Wed, 3 Mar 2004, Vance Shipley wrote:

> Edmund,
>
> You should look at erl_interface (ei specifically) which is a
> C library you link with your C program which provides everything
> you need to implement a "C node".  This way you can just send
> atoms, integers, strings, etc. and receive them as normal in
> your Erlang node.

The program is somebody else's, unfortunately, and thus I need to
interface to it's output, rather than modifying it to use ei. On the other
hand, I have been eyeing ei for use in Snort to have it report to an
Erlang node.

>
> }    <<First:1/binary, Rest/binary>> = Bytes,
>
> The above will not work.  It should be:
>
>     <<First:8/binary, Rest/binary>> = Bytes,

I thought if you use /binary, then the default unit is 8bits, so the
:1/binary = :8. At least, this is how I read it in the bit syntax. Is this
wrong?

>
> }  But this would seem slow (as we need to sequentially scan down the
>
> Don't worry about it.

Still leaves the issue of no reverse lookups, which is why I wanted some
form of data structure.

>
> }  I thought of using the process dictionary, but this seemed to be the wrong
>
> Just say no to the process dictionary.
>
> }  Now I could create some kind of state variable (with all the appropriate
> }  dictionaries), but this would be awkward to keep passing around, as it is
> }  needed only at the lowest levels.
>
> This is the way it's done.  You pass state data around like a hot potato.
> It may seem awkward somehow but it has it's own beauty.  Erlang has no
> global variables, get used to passing everything you need.

Oh, I realize this. _But_, it does make it awkward to program what are
essentially compile time lookup tables (calculate once, use everywhere). I
suppose I could start to use functions ("please return me a function to do
this", but then I would be passing around the function pointer). At least
with non-pure languages such as Scheme, this sort of awkwardness can be
avoided.

>
> }  Should I create a process, and use message passing? This would seem to
> }  consume extra overhead, and I would need to pass along a process ID
> }  (unless I wanted to do a lookup each time) similar to the state idea.
>
> This is what you do when multiple processes need access to the same
> data.  It's the way it works.  Quit worrying about performance.
> (However in this case it's the wrong approach).
>
> }  Is there a better way?
>
> Definetly use ei.
>
> Another word of advice; you should always assume you are doing the
> wrong thing if you write a receive statement (unless your name is
> on the cover of the Erlang book).  Everything can and should be
> done with the standard behaviours.
>
>   [This is rule of thumb advice for less than expert Erlang
>    coders.  Once you are an expert you can implement your own
>    behaviours]

Actually, I was looking at the gen_server, and was having an issue with
regards to the receives not seeming to be able to have a guard. I have a
couple of programs where I do synchronization based on guard expressions
to implement bounded queues. While I could rewrite to not do this, it
would definitely not be as clean.

> In the case of C nodes this may seem necessary but it actually
> isn't.  Just have your ei program format it's messages appropriately
> and make your Erlang program a gen_server/gen_fsm.  If you look at
> gen_server.erl you'll see the messaghes it expects are of the form:
>
> 	{'$gen_cast', Msg}
> 	{'$gen_call', From, Msg}

Back to this being somebody else's program, and so do not have an option
of ei.

>
> While you're there look at how much is being done under the hood
> for you and you'll see why you should use a standard behaviour.
>
> }     Port = open_port({spawn, "EXE"}, [stream, binary]).
>
> Windows?  Can't help you.

Nope, OpenBSD/Linux. The program does not detect that the listening
program has closed the file descriptors, and so hangs on full pipes
without dying.

>
> 	-Vance
>

Regards!
Ed





More information about the erlang-questions mailing list