Skip to content

Conversation

@ktak-007
Copy link
Contributor

No description provided.

}

fclose(h);
fclose(oh);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this c code was already significantly better then what an applicant for senior firmware engineer wrote in London 😅

now it's even better, thank you 🙏🏽

removeBundleFromQueue loads
(input, action) <- liftIO $ getInputForBundle bundle
perform input action
when runable $ do
Copy link
Collaborator

@jappeace jappeace Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need this check? and what happens if it's not a gzip/runnabble?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I can add puml files to this PR)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh wow!
hmmm, is it possible to link from the comment to this puml file? It's beneficial.
great work, thanks 🙏🏽

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@ulidtko ulidtko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Decent workaround, and good diagram! Please add it too.

Two comments.

  1. This wires in a hard coupling / dependency on bundles being gzipped. Not uncompressed, not bzip2, not xz, not zst.

    • It's OK for now, as keter hardcodes a dependency onto gzip too:
      let entries = Tar.read $ decompress lbs
    • but will make adding other compression algos more difficult, would that ever become desired.
  2. I think we should not decompress while retaining the entire thing in memory (both the archive, and the resulting tar file). It's a no-brainer use-case for conduits, which Keter already depends on. See inline

isGzip :: FilePath -> KeterM AppManager Bool
isGzip bundle = do
eres <- liftIO $ E.try @SomeException $ do
content <- B.concat . L.toChunks <$> fmap decompress (L.readFile bundle)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can get pretty heavy on RAM.

Bundles can get ~200 MB compressed... and more uncompressed... It's a pity to use so much memory just to get a Bool!

And keter already has conduit-extra in dependencies. So it'd be pretty simple:

import Conduit
import Data.Conduit.Zlib as Zlib

isGzip :: FilePath -> IO Bool
isGzip bundle =
  either (const False) (const True) =<< E.try @SomeException (
    runConduitRes $
      Conduit.sourceFile bundle
      .| Gzip.ungzip
      .| sinkNull 
  )

... and will process the file in constant memory, never retaining more than 1 chunk.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found that this example always shows true on gzip files. To check full file loading I've add readSize and countSize steps. It leads to run it in State monad.

@ktak-007 ktak-007 force-pushed the unnecessary-file-reloading-issue-slow-318 branch from a5426fe to 07e8f6c Compare November 5, 2025 00:59
@jappeace jappeace merged commit 1f35fe2 into snoyberg:master Nov 10, 2025
9 checks passed
@jappeace
Copy link
Collaborator

thanks 🙏🏽

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants