dan-dev

Thank you! :)

It worked when installing inside the project folder and did not work when installing outside the project folder:

  // Success: Running in the project folder.
  me:~/deprank$ yarn add deprank
  yarn add v1.22.19
  warning ../package.json: No license field
  [1/5] Validating package.json...
  [2/5] Resolving packages...
  [3/5] Fetching packages...
  [4/5] Linking dependencies...
  [5/5] Building fresh packages...
  success Saved lockfile.
  success Saved 1 new dependency.
  info Direct dependencies
  └─ [email protected]
  info All dependencies
  └─ [email protected]
  $ tsdx build
  @rollup/plugin-replace: 'preventAssignment' currently defaults to false. It is recommended to set this option to `true`, as the next major version will default this option to `true`.
  @rollup/plugin-replace: 'preventAssignment' currently defaults to false. It is recommended to set this option to `true`, as the next major version will default this option to `true`.
   Creating entry file 602 ms
   Building modules 1.4 secs
  Done in 5.95s.
  me:~/deprank$ yarn run deprank src/
  yarn run v1.22.19
  warning ../package.json: No license field
  $ /home/dan/deprank/node_modules/.bin/deprank src/
  | Filename     | Lines | Dependents | PageRank |
  ------------------------------------------------
  | src/index.ts | 280   | 0          | 1.000000 |
  Done in 0.55s.
  me:~/deprank$ yarn run deprank .
  yarn run v1.22.19
  warning ../package.json: No license field
  $ /home/me/deprank/node_modules/.bin/deprank .
  | Filename                           | Lines | Dependents | PageRank 
  ----------------------------------------------------------------------
  | fixtures/core.js                   | 3     | 1          | 0.191112 |
  | fixtures/utils.js                  | 4     | 3          | 0.180576 |
  | fixtures/user/user.js              | 4     | 1          | 0.088966 |
  | src/index.ts                       | 280   | 1          | 0.069599 |
  | fixtures/todo.js                   | 6     | 1          | 0.060405 |
  | fixtures/user/index.js             | 1     | 1          | 0.060405 |
  | dist/deprank.cjs.development.js    | 829   | 1          | 0.053610 |
  | dist/deprank.cjs.production.min.js | 2     | 1          | 0.053610 |
  | fixtures/concepts.js               | 4     | 1          | 0.053610 |
  | dist/deprank.esm.js                | 820   | 0          | 0.037621 |
  | dist/index.d.ts                    | 36    | 0          | 0.037621 |
  | dist/index.js                      | 8     | 0          | 0.037621 |
  | fixtures/index.js                  | 4     | 0          | 0.037621 |
  | test/deprank.test.ts               | 28    | 0          | 0.037621 |
  Done in 0.60s.

  ------------------------------------------------------------------------------------------------------------------------------------
  // Failure: Running outside of the project folder:
  me:~$ yarn add deprank
  yarn add v1.22.19
  warning package.json: No license field
  warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
  warning No license field
  [1/4] Resolving packages...
  [2/4] Fetching packages...
  [3/4] Linking dependencies...
  [4/4] Building fresh packages...
  success Saved lockfile.
  warning No license field
  success Saved 3 new dependencies.
  info Direct dependencies
  ├─ [email protected]
  └─ [email protected]
  info All dependencies
  ├─ [email protected]
  ├─ [email protected]
  └─ [email protected]
  Done in 4.95s.

  me:~$ yarn run deprank deprank/
  yarn run v1.22.19
  warning package.json: No license field
  $ /home/me/node_modules/.bin/deprank deprank/
  | Filename                                   | Lines | Dependents | PageRank |
  ------------------------------------------------------------------------------
  | deprank/fixtures/core.js                   | 3     | 1          | 0.223479 |
  | deprank/fixtures/utils.js                  | 4     | 3          | 0.211161 |
  | deprank/fixtures/user/user.js              | 4     | 1          | 0.104035 |
  | deprank/fixtures/todo.js                   | 6     | 1          | 0.070637 |
  | deprank/fixtures/user/index.js             | 1     | 1          | 0.070637 |
  | deprank/dist/deprank.cjs.development.js    | 829   | 1          | 0.062691 |
  | deprank/dist/deprank.cjs.production.min.js | 2     | 1          | 0.062691 |
  | deprank/fixtures/concepts.js               | 4     | 1          | 0.062691 |
  | deprank/dist/deprank.esm.js                | 820   | 0          | 0.043993 |
  | deprank/dist/index.js                      | 8     | 0          | 0.043993 |
  | deprank/fixtures/index.js                  | 4     | 0          | 0.043993 |
  Done in 0.28s.

Great project!

One feature request: Running the npx command searched only for the js files, not for the ts files. When I built deprank locally with yarn, it also showed the ts files. After looking at dependency-cruiser figure it has to do with what typescript compilers are available where.

It would be great if the npx command you provide in your readme would work regardless of my local setup - dependency-cruiser has documentation and one example of a suitable npx command here: https://github.com/sverweij/dependency-cruiser/blob/develop/...

My suggestion would be to check if any ts file is part of the extension option (i.e. --ext=".js,.jsx, .ts, .tsx") and only then do the magic needed to also show ts files.

All good! And sorry for not making the effort to understand your position first, I want to work on that.

> The incentive structure of academia that leads to software like that, though, is also a big reason why I left. The theory is super important (that's why I work on a regex engine that only provides support for regular languages), but I also think the engineering aspect is just as important. And academia, or at least the corner I was in, just did not care about the engineering side of things at all. This in turn leads to publishing results that are hard to reproduce, because if you don't share code that is at least somewhat robust, it's going to be very costly for someone else to build on your work.

Totally get it. This also baffles me - papers in computer science that are hard to reproduce? Yes I know, publish or perish and all that BS. But I don't want to accept this: I mean I get it for psychology obviously, and then also material sciences and so on, but for compsci?... Next to proofs, programs are probably one of the most reproducible things that nature has given given us.

Good for me and many others that you cho(o)se to spend your time on building tools :)

Oh well, first of, thank you for writing ripgrep! Great work, love that tool and use it daily :)

All good, thank you for sharing your POV! I find both theory and the practical engineering feats quite interesting, and actually understood the original question as a theoretical question, not a question about general-purpose regex engine. Quite possibly that this is even how the asking person was intending it, in hindsight.

Last thing on topic (talking now about having complement and unicode in a usable regex engine): My personal, gut-feeling-based hunch is that by adding all these features not strictly related to regular languages, we kind of evolved our regex enginges and expectations towards them into a corner of the design space that works well, but might not work well when one adds complement. It feels like a constructivist world without negation and stuff on top that works, and reverse-engineering what works with negation and what not will likely be hard work. As a theory-ish kind of person (without much insight into regexes or formal grammars), I wish there would be some kind of insight into what are the atoms of a regex and which atoms can be combined witch which other atoms - I would bet that fancyFeatures and unicode+complement would have a high algorithmic complexity already in theory.

Any final tipps on the repo I linked to not disappoint users expectations? :)

Ah! I was only referring to ERE as specced by POSIX, yes.

> It's not difficult because getting it correct is difficult, it's difficult because making it correct and fast is not straight-forward.

It seems to me that you take my project as a proxy for whether regex derivations are a feasible way to deal with unicode-ready regexes that also support complements and so on. That was not my intention, I was merely attempting to show an easy implementation of regex derivations that can deal with unicode and can be extended to support complements. With this project and the paper I linked, it seems to me that answering whether this particular kind of constructing regex DFAs is a possible way to achieve what you are looking for or not should be rather straightforward.

(To my last knowledge, a regex complement is not easy to add in the presence of extra features like backtracing and lookahead.)

Nah, the type system is perfectly fine in this case: "Given (Just someValue), return someValue". Exactly what happened here, the precondition just was not fulfilled and I left the case dealing the unfulfilled precondition undefined. If one cares about such things, one should simply use one of the numerous alternative Preludes out there (to make sure to actually never use fromMaybe, head and the 3 other functions that nobodoy uses form the standard Prelude) and turn the warnings for incomplete pattern matches on. At least, thats how you could deal with it in real life.

If it is not practical matters that are the concern here, there are more than enough languages that only allow total functions and offer other sweet stuff. Haskell's main purpose was to be a lazy-by-default-language, and that people can actually write practical stuff in it is a nice side-effect.

Hold on! See: https://github.com/dan-blank/hgrep-smallcore/issues/1 Using `fromJust` is deeply frowned upon, and indeed a few eyebrows were raised then showing my code to the examiners. This and a handful other warts unfortunate, but few and easy to work around.

This function and others are in the prelude, but one can use other preludes that don't have these escape hatches.

This does not undermine the huge benefits that people get from having IO checked by the typesystem. Just as having tyepcasting in a language does not undermine the benefits of types in that language.

Thank you for trying out my tool!

Not that this was just an university project that is far from polished, and certainly not fast!

* I don't think it supports '\w' - is that part of the ERE? (otherwise I will lower my claim in the project description)

* Repetition works like this: {1,3}, did not add the syntactic sugar

---------

My setup:

me:~/hgrep-smallcore$ echo 'awd え bbb c' > test

me:~/hgrep-smallcore$ /home/me/.local/bin/hgrep-exe 'f' test

me:~/hgrep-smallcore$ /home/me/.local/bin/hgrep-exe 'b{1,3}' test

awd え bbb c

me:~/hgrep-smallcore$ /home/me/.local/bin/hgrep-exe 'え' test

awd え bbb c

Yes and straighforwardly so if you use character classes as your basic building blocks. Here I implemented a Haskell implementation that is easily extandable to include complements: https://github.com/dan-blank/hgrep-smallcore (I like this project because it translates ERE compliant regexes - sans negated character sets - down to only 4 constructs, one of which being character classes). It implements https://www.ccs.neu.edu/home/turon/re-deriv.pdf, character classes are described in 4.2.

I actually had complement in it as a 5th construct, but when the submission came closer and the examiners found some errors in my logic (my fault for not writing good enough unit tests!), I took complement out again when cleaning the project up.