robertknight
An ML model can fit into existing compiler pipelines anywhere that heuristics are used though, as an alternative to PGO.
The code for both the client and server are open source (https://github.com/hypothesis/h) so this is possible. The server is designed to support the needs of large scale deployments, so this does come with some complexity compared to a system you would design for smaller scale usage.
The text on https://web.hypothes.is/ mostly targets schools and universities, because Hypothesis pays for itself by selling integrations with online learning platforms (Canvas, D2L, Blackboard etc.) and associated support.
From skimming various papers it seems like the motivation for packing the LHS originally, even though a single element is broadcast from it at a time (nb. this is opposite to the order in this post, where the row count in the microkernel is a multiple of the register size, rather than the column count), was to reduce TLB misses. Apparently this is not a problem in practice on modern CPUs and for problem sizes common in ML inference.
1. Try not to stress too much. The point of review is to improve the quality of the code that lands, and the health of the codebase as a whole, not to grade the author.
2. When you think your work is ready for an initial review, take a short break and then review it line by line yourself, looking for any obvious mistakes or possible simplifications. I recommend doing this in a different editor or view than the one you authored the code in originally.
When reviewing someone else's code, it is annoying if there are silly mistakes that the author could obviously have caught themselves. Issues where the author was not aware of a subtle detail or a coding practice in some other part of the code are less of an issue. Identifying these are exactly what reviews are for.
This is a misunderstanding of the LGPL license requirements, as they are usually interpreted. LGPL requires that if your application dynamically links to a modified version of the library, then you must make the source code _for the modified version of the library_ open source.
The original use case for the LGPL license was the C runtime, which practically every binary on a system will link to, proprietary or otherwise. The idea is that the binary can be closed source, but any modifications made to the C runtime itself must be distributed. The idea is that an end user could take your modified version of the C library and further customize it to their needs.
In the context of bundled ffmpeg and ffprobe executables, the user could replace them with their own versions. You should make clear which version of the source was used to build them and if you have made any modifications, those must be open source.
What does the scanning process check for / which tools are used?
In Qt, there is an option to use either native windows for individual widgets or "alien" windows, in which only the top level widget is a native window - https://doc.qt.io/qt-6/qwidget.html#native-widgets-vs-alien-....
The hard part of a generic third-party commenting tool is creating the right social context for it to actually be useful. Hypothesis for example is mostly used via its integration into online learning platforms, where that context already exists.
What are you planning to do with the text after detecting / recognizing it? How fast does the detection / recognition need to be in order to be useful?
I would guess they see it as a numbers game. Enforcing sharing restrictions more aggressively will cost them some customers who rely on it, and gain them some (maybe only a minority) who currently freeload. What will the overall result be? I don't know. I would have expected them to model various scenarios though and decide there was enough potential to make it worth trying.
I do think the whole concept behind Gulp, of creating processing streams through which files are fed to transform them, before writing to disk, is less useful than it used to be. This is because a lot of that functionality can now be handled by bundlers which understand the inter-dependencies between modules rather than just taking the input as a set of files. Also Node/JS's own async functionality is much more ergonomic to use than it needs to be, so additional async abstractions on top are less useful than they were.
[1] I'm aware of some issues related to file watching. See https://github.com/gulpjs/gulp/issues/2654
Google cheats, but in a way that very few users will notice. You can only access the first 20 pages of search results. Depending on user behavior, this is one way to offer navigation via page number while limiting worst-case cost.
I think with modern methods it ought to be relatively easy to teach a system to predict the amount of rotation needed to straighten the image, or make the layout analysis tolerate minor rotations of the input better. Needs someone to actually implement it though!
OCR processing typically consist of two major steps: detecting/locating words or lines of text on the page, and recognizing lines of text.
Tesseract's text recognition uses modern methods, but the text detection phase is still based on classical methods involving a lot of heuristics, and you may need to experiment with various configuration variables to get the best results. As a result it can fail to detect text if you present it with something other than a reasonably clean document image.
Doctr (https://github.com/mindee/doctr) is a new package that uses modern methods for both text detection and recognition. It is pretty new however and I expect will take more time and effort to mature.
1. Rewrite the async function to be a generator function with a wrapper that calls `next` on the generator whenever `await`-ed Promises resolve
2. Rewrite the generator function to be a big switch statement, together with a wrapper function that drives execution.
You can play around with generators and async functions in the TypeScript playground, with TSConfig set to target ES5, to see how this works: https://www.typescriptlang.org/play?target=1#code/GYVwdgxgLg...
Making a function support being paused and resumed requires changes in how the function is run and the data that is maintained while it is executing. In addition to behaving differently than sync functions when they execute, the results are also handled differently. Async functions always return a promise - whether they `return` a literal value, return another promise or throw an exception.
Due to these differences, it makes sense that the special nature of async functions and generators must be declared up-front, with the `async` keyword or `*` for generators. It would be possible to design the language such that the function type was determined by looking at whether it contains `yield` or `await` keywords. Python does this with generator functions. However this makes an important aspect of behavior less explicit.