pgilad

What real-world problems can be solved at companies with LLMs and how to approach non-trivial tasks

Thanks! I like your work on it. I have several ideas on how to generally improve the CSP development that I want to implement, and needed a good infrastructure for doing it: - CSP optimizations, like removing redundant fields (like a minifier) - CSP parsing - CSP security warnings or rating (like for unsafe eval) - CSP Presets, might be general presets, or extendable presets for various tools, like Google Analytics for example - CSP deprecations and level supports

So far, I've created this tool to help me with it's usage (See https://github.com/pgilad/www.giladpeleg.com/blob/master/scr...), but the best feature is by far using Typescript (I considered using Java) for typed directives and sources.

Probably never. False positives is just a nice catch-phrase ;) But I don't presume to know other people's naming patterns

Yep, truly avoiding false positives and capturing all todos you would need to really parse the source code (perhaps creating an AST or lexical parsing).

Even if you build that tool (which handles many languages) - it has an extra headache cost with the parsing time, which might be really slow for large projects.

I actually started Leasot with Javascript AST checking which never misses TODOS but is very hard to extend to other languages, as well as parsing speed was a magnitude slower.

Watson looks really nice... Could definitely learn from it.

In github issues you mean exporting a TODO to a github issue? If so, I don't think that belongs in Leasot, but rather an external tool for creating/manipulating Github issues (And I'm sure that kind of tool exists).

;) I'm in no way offended. I guess kazinator is spending his time much better than me. But anyway, if anyone is more comfortable using CLI (or any IDE that provides this) with grep/ack/ag/pt and that solves parsing todos for him, that's great. I would only use Leasot if you need easy integration with other tools (think JSONs/XML), want to trim down false positives (such as variable names, strings etc...).

There are probably other use cases, but overall, if cli regex works great for you, stick with it.

Regarding if Leasot is pointless or not, well everyone is entitled to their own opinion (kazinator). In the greater sense I guess the world needs more todo doers than todo parsers ;)

This is a great solution. I would only use Leasot if you need to weed out some false positives (variable names, strings etc...) and perhaps want to output in a special format (JSON, XML, markdown...) for another tool (Think jenkins CI for example).

If CLI regex matching (grep, ag, git grep, pt, ack...) works for you, I would stick with it ;)

Well you can see my comment above, but overall ag|awk|pt will be much faster (but might be less accurate). Leasot tries to weed out some false positive (by creating better comment for file type specific comment regexes). Also provides several reporters (JSON, XML, Markdown...) if you want to integrate with other tools (jenkins, travis etc...)

Leasot is written in Node.js. Regarding pretty output - that could definitely be argued, but Leasot also allows for different reporters, say you want the output in JSON/XML for an external tool. That is extendable, whereas grep over regex in CLI is fast & powerful but not as flexible

Thanks for the comments. Regarding simple `ag` or `grep` usages: Yeah, that will definitely be faster (as with git grep). The problem arises when you have false positives due to either strings, variable names or other things (perhaps template or pattern matches). Then you will need extremely good regex (which leasot implements) or be really good with filtering the results.

Now what happens when you want the output in different formats? I had a person contacting me for exporting as xml since he wants to plug it in for a CI (jenkins). What if you want a JSON for your own tool?

Leasot is far from the perfect solution to TODOs, but if your use case requires anything other than simple regex, you will run into the same issues that Leasot tries to solve.

As far as speed, in my work project, parsing 552 javascript files takes around 0.2s on my mac. Some of these files being really big.

This could actually be implemented, but it was more work with the regex so I skipped it for now, seeing that most TODOs are at the beginning of the line.

Also, you run into problems with strings which might be a false positive

I'm not aware of any linters applying this sort of logic in suggesting to extract numbers to their own declarations. One could also go as far as declaring strings and whatnot...