develooper Front page | perl.perl5.porters | Postings from August 2012

Re: [PATCH] Module::CoreList delta support

Thread Previous | Thread Next
Aristotle Pagaltzis
August 5, 2012 00:20
Re: [PATCH] Module::CoreList delta support
Message ID:
* David Leadbeater <> [2012-08-04 23:30]:
> On 4 August 2012 21:29, Aristotle Pagaltzis <> wrote:
> > So we’re looking at <1MB in memory (incl. all overheads), a pittance
> > on disk, near zero load time, most parsing work done in a few
> > heavy-weight builtins with almost no looping in Perl code, and
> > equally fast access to the data by either axis, with no spin-up key
> > index generation for either of them.
> Putting a tie interface on top of that might not be that nice. I do
> wonder if the next step is to make a cleaner API and deprecate the
> access via hash "API" as mentioned earlier in the thread.

Actually I don’t think it will be terrible. But moving from the hash to
a cleaner interface is a good idea in any case.

> With this approach I assume generation will be involved somewhere and
> it's worth thinking about that aspect:
> * Where will the generation will take place?
>  (First thought is a .PL file run as part of the core perl build
>  process and Module-CoreList build process -- in that case we wouldn't
>  reduce the size of those distributions, but may reduce the size of
>  built packages)

Well, how is the data for a new release generated now? I assumed that
generating the data for the new format would slot right in there.
I really have absolutely no idea about the module, all I was interested
in is whether I could come up with a credible solution to storing the
data table.

> * What the diff for a release manager will look like
>  (Presumably the data can be in a nicer format than a table with very
>  long lines if it's generated from something else).

That is a weakness in the scheme I outlined. Lines need to be fixed
length for the unpack sleight of hand to work, which means adding a perl
release will change (read: lengthen) every single line in the file. With
git at your disposal you can use word-based diff though, which will
nicely show only the tail of each line getting extended. If presented as
a patch then it will be 750+ lines long every time, though.

> * How this fits in with scripts in Porting, etc.
>  (e.g. test_porting at the moment will act as a sanity test on
> due to the strict version check there, may be worth
>  having an explicit test for the data consistency).

I’m afraid I’m not at all aware of how that process works. What is its
purpose and where are the cogs of its machinery which do the main work?
I can just go through the release manager docs (and one of these days
I really should) but if there are any shortcuts to the bits that are
relevant to MCL I shall be glad to hear about them.

Aristotle Pagaltzis // <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About