Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Marcel
    @marcel:roethke.info
    [m]
    that is already taken care of it seems. unless you enable reflow, but that does not seem to work on 2022.10 either.
    Frans de Jonge
    @Frenzie
    Selection with reflow should (more or less) work
    Screenshot_20221129_185938.png
    I don't have a PDF at hand, but that show DjVu in reflow + select
    it used to work anyway
    However, I don't use reflow so that could easily slip by me if it broke.
    Or rather
    I rarely use reflow
    and I seldom use selection
    That combines into a blind spot ;-)
    Screenshot_20221129_190214.png
    Nope, PDF reflow + select works
    Frans de Jonge
    @Frenzie
    Anyway, if selection is (mostly) fixed it means the existing patch already did that
    In which case I reiterate I don't really know what wasn't ready about it yet (at the time) since it seemed to work perfectly :-P
    Frans de Jonge
    @Frenzie
    --
    Gah, I just came across my lfs benchmarks & optimization remarks but I forgot where it came up.
    https://github.com/koreader/koreader/pull/5819#issuecomment-582864522
    NiLuJe
    @NiLuJe
    The "let's throw 500 books in a single folder" crowd
    Which, incidentally, we just got another one of those ;p
    There are only so many ways we can say "Onyx makes terrible devices", after all. That's not enough, apparently.
    More interestingly: beware that os.clock only counts CPU time
    Wait, no, I'm confusing it with something else
    Okay, no, I'm not :D
    (i.e., it's not a great tool for non purely computational benchmarks, and it's possibly extremely ill advised for I/O bound benchmarks, as I'm fairly sure it won't account for I/O time)
    NiLuJe
    @NiLuJe
    TL;DR: Using a proper clock ought to better reflect actual real world time spent, àla https://github.com/koreader/koreader/blob/61364ffc3341f4ee7ff3de0816c4a8e176a4e470/frontend/document/credocument.lua#L763-L767
    Frans de Jonge
    @Frenzie

    More interestingly: beware that os.clock only counts CPU time

    Sneaky.

    But regardless, the point remains that on my H2O a thousand files takes 2 seconds. It's much slower than I'd call pleasant but it's not over half a minute… ;-)

    And theoretically most newer devices should be a little or a lot faster…?
    However, I was actually talking about something on GH last week or something.
    Frans de Jonge
    @Frenzie

    (i.e., it's not a great tool for non purely computational benchmarks, and it's possibly extremely ill advised for I/O bound benchmarks, as I'm fairly sure it won't account for I/O time)

    It's not all that I/O bound really (up to a certain limit). What I wrote there can be easily observed with your eyes. 10k files doesn't take 10 times as much time as 1k files but rather significantly more time.

    Unless I/O itself is significantly slower when there are more files.

    That is, in some cases there's too much I/O being done and in some cases there's inefficient table loops happening in memory. The upper limit of usable could be improved; it just never occurred to me that anyone would want more than a few 100 per folder and that has nothing to do with performance reasons.
    Frans de Jonge
    @Frenzie
    I think @pazos solved the conundrum. Android scans files and while it's doing that things will be slower. I'm not really sure why that should (noticeably) affect anything if you have a perfectly reasonable few dozen items per folder though.
    https://github.com/koreader/koreader/issues/8482#issuecomment-1332012289
    Marcel
    @marcel:roethke.info
    [m]
    how to I make kodev rebuild thirdparty libs from base?
    poire-z
    @poire-z
    there might be a kodev clean, dunno, but I usually rm korearer-...emulator/koreader/libs/libthatlib.so for the libs I want to rebuild - and if needed rm -rf thirdparty/thatlib/build
    Frans de Jonge
    @Frenzie
    Or just touch thirdparty/lib/CMakeLists.txt
    But occasionally you'll want to remove all of build
    In that case note it's minutely faster to remove build/arch, keeping the git_checkout or download
    (And yes, we have a kodev clean but that just does:)
    clean:
            -rm -rf $(OUTPUT_DIR)/*
            -rm -rf $(THIRDPARTY_DIR)/{$(CMAKE_THIRDPARTY_LIBS)}/build/$(MACHINE)
    (It's almost always faster to be more targeted — I suppose we could support adding a lib behind clean but not sure it'd really save much time anyway.)
    Marcel
    @marcel:roethke.info
    [m]
    hmm, deleting build/arch does rebuild the library, if removed from korearer-...emulator/koreader/libs/ before, but also completly overwrites the git checkout.
    so i probably should just point it to my own copy of that repo
    Frans de Jonge
    @Frenzie
    You can create a branch and point the commit at your branch. (Same effect; you'll have to do that with your own repo anyway; it just doesn't necessarily need to be public.)
    Marcel
    @marcel:roethke.info
    [m]
    yes, I'm using a local repo now.
    Frans de Jonge
    @Frenzie
    To be clear I mean you can say my-branch here and it won't mess about with anything ^_^ https://github.com/koreader/koreader-base/blob/91a58d3e39190899ac7982b48753987030a9a027/thirdparty/mupdf/CMakeLists.txt#L145
    Frans de Jonge
    @Frenzie

    @NiLuJe I assume this means the Docker image needs to be updated to include the architecture?

    bash: aarch64-linux-android-gcc: command not found
    bash: aarch64-linux-android-gcc: command not found
    bash: aarch64-linux-android-gcc: command not found

    https://gitlab.com/koreader/nightly-builds/-/jobs/3444184267

    NiLuJe
    @NiLuJe
    Probably? (What make toolchain (IIRC) does in base)
    Frans de Jonge
    @Frenzie
    We explicitly remove everything unneeded
    make toolchain is like tens of gigabytes :-P
    "only" 4.3 GB, I checked
    but anyway, the Android Docker image is seriously slimmed down
    however… I'll have to check if I can get updated everything to work for that stupid Android image
    all the other ones are on newer everything already