Re: Make "package.loaded" weak

[Francisco Olarte <folarte@...>]

On Sun, Feb 19, 2017 at 8:03 AM, Martin <eden_martin_fuhrspam@gmx.de> wrote:
> On 02/18/2017 09:29 AM, Francisco Olarte wrote:
>> Maybe I could be convinced by a better example.
> Thank you for analysis and reply!

"A mandar!", that's what we're here for.


> Let's try more "real" example.
... <aside>I have not timed lua, but in every code I've used to do
CRC's calculating
the table is way faster than mmaping ( and do not even try loading )
it from disk </aside>
....
> So in CRC calculation routine I just wish to say something like
> "local crc_table = require('CRC_2bytes_EDB88320')" and then start
> xor-ing input with it.

This is more convincing. But you realize the module which *uses*
crc_table will tie it in memory? So either you have your routine
inlined and you nullify it or, if you are requiring the crc routines,
you provide code to init the table and re-read it on demmand?

A 64k entries data table is not too much in C, it may be way bigger in
lua, although there are string tricks to alleviate it. But I see in
similar algorithms with much better tables you can get much bigger
usage.

> Yes, I may nullify "package.loaded" record for that module after
> work but it seems like struggling with consequences, not eliminating
> reason.

But there is a reason to make require cache its contents, otherwise
the Lua team would have opted for the easier route of just loading the
code from require each time. A couple of my usages come to mind. One
is a pretty printing function, huge, which I only use in debug runs.
As such when I log I just do <require
"debug_dumper".dump(data_value)"in debug builds, inside the innermost
scope, to avoid loading until needed. But when needed I do not want to
have it garbage-collected, I like to know it's cached.

All in all I think making package.loaded weak-refed will not be good,
as it would change the semantics of the language ( and it can make
programs fail. Currently you can require a lot of modules and chroot,
your approach will make programs doing that fail ). I think it would
be a much useful approach to split require in two parts. My C is
really rusty, but looking at ll_require@loadlib.c it seems the
searcher exercising code can easily by split to a separate function
and then used to build an ll_require_load or whichever function which
could be exported for cases like yours, I want a function and I want
to find it using the same mechanisms as require ( which the added
bonus that having the result as a function opens the way for some
interesting usages ).

Francisco Olarte.