lmi
[Top][All Lists]
Advanced

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

Re: [lmi] PATCH: use compressed .mst files


From: Greg Chicares
Subject: Re: [lmi] PATCH: use compressed .mst files
Date: Mon, 29 Oct 2018 10:25:12 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 2018-10-25 18:00, Vadim Zeitlin wrote:
[...]
>       https://github.com/vadz/lmi/pull/100

I've done something quite similar in commit 0f81d542.

>  The code changes are really simple and the only potentially questionable
> thing is the use of access() to test for the file existence, but this is
> how lmi seems to do it elsewhere, so I did it here too, even though this
> code could use wxFileName::Exists() instead or even just try to open the
> file input stream and rely on the error generated by it -- except that this
> would have required dealing with wxLog and lmi code does not do this
> anywhere else, so I didn't do it here neither.

This would have introduced a dependency on classes
    wxFileInputStream
    wxLZMAInputStream
    wxStringOutputStream
which aren't otherwise used in lmi code. Sorry, I had thought it might
be possible to use wx's builtin liblzma more directly.

But, given that the only purpose is obfuscation, I decided to XOR the
MST files' contents with 0xFF instead of calling into any libraries.
I should have thought of that simple, robust solution up front.

>  I spent more time on makefile changes than on the code because I couldn't
> figure out what would be the best or, maybe, least objectionable way of
> dealing with installing the template files. Initially I really wanted to
> rely on make for updating them, i.e. have a "%.zst: %.mst" rule, but this
> required many changes to the "install" target and, after looking at them, I
> wasn't sure if you'd like it, so I've finally implemented the current
> version which uses this "-e -o -nt" construct explicitly instead of relying
> on make. This is a bit silly but OTOH it's not that bad and like this my
> changes could be limited to pure additions, which will hopefully make them
> easier to review and integrate.

Yes, I went down the same paths before concluding that the best way to
do something that's trivial in zsh is to write a trivial zsh script.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]