lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Tue, Aug 26, 2014 at 5:00 PM, Sean Conner <sean@conman.org> wrote:

>   Hypothetical situation:  you maintain a software package used by a sizable
> number of people.  One person pipes in asking for a change in how it works.
> Do you do it?  What if it's not a simple change?  Or it's more than one
> poerson, but less than 1% of the people who are using it are asking for the
> change?  Okay, step it up---you are getting multiple, mutually exclusive
> requests for changes?  Or maybe they're not mutually exclusive, but changes
> that just (to you) clutter up the program?
>
>   Another point of reference:  given the nature of Lua releases, *even if*
> PUC was going to make the change, it wouldn't be immediately available, and
> it won't be backported to existing versions.

I realize I am a minority -- no reason to paint extensive
hypotheticals, I've seen this lecture before.

I've said this before but I'll try one more time -- I cannot introduce
a module to enshrine what I want.  I'm trying to trick Lua into
allowing userdata where a string is expected.  I am not familiar with
how to do this, I have not fiddled with how Lua represents types
before.  It's not something the manual goes into any detail on and
Lua's source is (imo) not very easy to understand.  Right now you
can't traverse a mutable buffer without first converting/promoting the
part you're looking at into a string.  Lua's string library functions
expect strings, and third-party code expects strings (not userdata).
Introducing my own type is still a lock-out situation against those
type checks.  The best I could do is iterating by :byte() like you've
shown, but I cannot string.find(userdata_buffer, 'needle', 1, true).
I thought this was a situation to ask for the magic of upstream -- I
realize userdata are meant to encapsulate/hide things, but I had hoped
they would be able to offer a compromise through the debug
library/functions.

It frustrates me that I have to duplicate userdata into a string to
look at its contents. :\  I think I'll just give up on this
discussion, I'm being given the same replies.  Either I'm incompetent
or I have not adequately described my problem.

This was not about speed -- we talked briefly about how shared data
should be faster than duplicated, serialized data channeled through
some form of IPC, but this was about avoiding duplicates from
userdata-to-string ((memory use)).