Documentation

[jywarren]

Hi @rexagod ! Docs look great. Just for context, you mention testing as a use case here. Is this library intended to be used in the browser, for example as part of LDI integration (https://github.com/publiclab/Leaflet.DistortableImage/)? Or is it kind of a branch off the main project? It's very cool!

[jywarren]

Hi @rexagod can you reply here? Thanks!

[rexagod]

Is this library intended to be used in the browser,

@jywarren matcher-cli is currently (and was originally) intended to be used on local terminals and automated travis builds, but never in the browser, since this is built and works on node. This library is aimed at making available different executable commands to the user for their respective headless operations on the matcher-core library as its target. As a matter of fact, this library can have any library as its target that uses matcher-core, eg., LDI.

you mention testing as a use case here. Is this library intended to be used in the browser, for example as part of LDI integration (https://github.com/publiclab/Leaflet.DistortableImage/)? Or is it kind of a branch off the main project?

It can be thought of as an essential "toolkit" for the matcher-core lib, and the testing use case I mentioned is just one of many, eg., performance diagnostics, fetching stats, etc.

[jywarren]

Is it a toolkit that consumers of matcher-core will use?

but never in the browser

But why does it seem like you're loading a web page in your Jest tests?

So will LDI use matcher-core directly, without this library?

Thanks!

[rexagod]

Not necessarily. By the term "user" in my comment above I meant to refer to developers who need to run the algorithm under different configs and yank away any extra milliseconds it took, and visualise its behaivor just like I did. But again, the "end user", or anyone for that matter, does not need to include this library whatsoever in order to run matcher-core inside their library.

The web page, this file to be exact, is a demo page I setup in core lib just to showcase how m-cli would "target" the core lib and perform operations on it (snapshots, info collection, etc.), just like I demonstrated in #5 a while back.

So will LDI use matcher-core directly, without this library?

It can, and it is currently (in my fork's rexa-soc-branch), but say in the future if you require functionality like crossposting headless testing results back from travis to GitHub PRs just as travis finishes building them, getting an in-depth millisecond by millisecond difference of that PR in comparision to the main branch (i.e., if the PR improves/degrades performance), etc. we can consider building a LDI flavor of this lib for the same, just like I demoed for core @ #5.

[jywarren]

Hm, so if matcher-cli provides lots of features we don't actually need in LDI, then perhaps it's best we just use matcher-core directly from LDI. What would be any specific utility that /would/ be required from this lib?

[jywarren]

OK, so cool -- maybe in case there is any ambiguity, the docs for this lib should clearly say near the top of the README that matcher-cli consists primarily of utilities for developers, and not required for projects which are using matcher-core directly. That'd be a really helpful clarification -- to know that this isn't for production projects to include for use at runtime! Thanks, @rexagod !

[rexagod]

perhaps it's best we just use matcher-core directly from LDI.

We are actually doing that currently, in publiclab/Leaflet.DistortableImage#312

What would be any specific utility that /would/ be required from this lib?

This lib can diagnose the matcher-core usage scenarios inside ldi and crosspost those stats back here, but as I said earlier, it can be enhanced to do many more headless LDI-specific tasks as well, eg., measure performance improvements by any PR down to milliseconds, merge only if performance is not downgraded (in some scenarios), realtime user simulated inputs, etc.

maybe in case there is any ambiguity, the docs for this lib should clearly say near the top of the README that matcher-cli consists primarily of utilities for developers, and not required for projects which are using matcher-core directly.

Done!

[jywarren]

Great, ok, awesome, thank you @rexagod!!!

…

On Thu, Jul 11, 2019 at 6:40 PM Pranshu Srivastava ***@***.***> wrote: perhaps it's best we just use matcher-core directly from LDI. We are actually doing that currently, in publiclab/Leaflet.DistortableImage#312 <publiclab/Leaflet.DistortableImage#312> What would be any specific utility that /would/ be required from this lib? This lib can diagnose the matcher-core usage scenarios inside ldi and crosspost those stats back here, but as I said earlier, it can be enhanced to do many more headless LDI-specific tasks as well, eg., measure performance improvements by any PR down to milliseconds, merge only if performance is not downgraded (in some scenarios), realtime user simulated inputs, etc. maybe in case there is any ambiguity, the docs for this lib should clearly say near the top of the README that matcher-cli consists primarily of utilities for developers, and not required for projects which are using matcher-core directly. Done! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7?email_source=notifications&email_token=AAAF6J4JC46BYABN5OINDK3P66ZE5A5CNFSM4H27XG7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZYFVUI#issuecomment-510679761>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAF6J4RAXDY72NWKTJVIFDP66ZE5ANCNFSM4H27XG7A> .

[rexagod]

Sure thing, Jeff! 👍