Re: Suggestion: Lua 5.3 -- a facility for creating and manipulting Lua file handles (C API)

[Andrew Starks <andrew.starks@...>]

This is a great conversation. Excuse me for butting in, please...

On Fri, Nov 15, 2013 at 5:59 PM, Sir Pogsalot <sir.pogsalot@gmail.com> wrote:

<snip some good stuff...>

> I think I'll go back on what I said about :getfd().  I don't like fds being
> known to the Lua side of things, but a fair number of libraries expect that
> method to exist.  It is somewhat common, but I think it only exists because
> people are representing files as different types (bad).  :>

I don't think that is true... well, it is, because Windows sockets are
not files, their... SOCKETS? or handles or... i can't remember.
They're not FILE *, though.

Actually, it's also not for that reason. I think it's because, while
many socket libraries act on the FDs themselves, there are some (the
nanomsg library that I'm working on) that use them only as a signal
mechanism. If you read/write to them, "undefined behaviour" happens
(shits bed).

I believe this is because nanomsg and ZMQ are better looked as
something other than a framework. They're like a reorganization of the
network stack. If traditional stacks, you have *hardware layer ->
transport layer -> network protocol -> application stack*.

[Obviously this must still exist on some level, as this is reality and
nanomsg/zmq are abstractions (frameworks) thereof, but they do their
tricks at a low level so...]

With nanomsg, you have *message pattern (domain) -> transport
protocol(s) -> address bindings -> end point(s)*

Here, the traditional methods on a stream don't work the same, because
one of the points of these libraries is that the message is atomic.
"It's not here... not here... BAM! The whole freakin' thing is here!"

So, I'd like to do the same thing that you want to do, but with
nanomsg. My approach is going to be really different than yours. Many
of the things I'd do would look stupid. I'm guessing. One or two of
them might not actually **be** stupid.

>
> The main focus of my socket bindings is that I was trying to be as true to
> the C prototype as possible so it would be easy for beginners to take a C
> networking tutorial and translate it to Lua without much guessing or digging
> through documentation.  Sometimes I feel like details about luasocket are
> hard to find...
>
> I like your socket option code in net.c though, it's much friendlier than
> what I tried to do by adding every defined CONSTANT I could and having a
> get/setsockopt().  That's the only part of my code I really am not happy
> with yet.  I still need to get it to compile in Visual Studio, though...
>

This paragraph got me really excited. Well... not excited. It's more
that I feel your pain.

My solution, after trying the "every option * getter * setter" path,
was to make an option struct that mixed and matched a small handful of
functions. Some functions were "0 == true, everything else is an int",
some were "-1 is false, everything else is an it" and one was "error
and tell them that this property is read only." Then the rest of the
struct held the property name, the default value, the void * to the
property and the sizeof.

I can say that, compared to Lua, it looks like poop with cheese on it.
Compared to your average C code, it looks pretty tightly designed, but
without all of the neat #define hacks that make C code look truly
confounding.


Also, I too must get everything that I do working in Linux, and the
Mac and Windows. I find VS to be frustrating at first, but the more I
see the methods behind their magic, the more I come to empathise with
their approaches. I'm not saying it's better. It's just
understandable.

I need to do some clean up on my project before I post it. It's not
ground-breaking, but I'd love to get your comments on it. It sounds
like you're a more experienced "me", when it comes to playing with
this stuff.

Except, well... I'm *slightly* more experienced when it comes to
whether or not I should bother to post a suggestion to change Lua's
implementation. Only slightly, though. :)


-Andrew