Stack executable built against optparse-applicative-0.17.1.0 'hangs'
#475
Comments
|
Can you build with profiling then quit during the hang. You might be able to see the hot spot in the profiler output? |
|
Will do (on profiling). It appears to be something to do with |
|
I tried: The resulting and a bit further on in the file: |
|
Hmm. This is frustrating. It seems I have broken a hidden invariant for the From prettyprinter-compat-ansi-wl-pprint: renderPretty :: Float -> Int -> Doc -> SimpleDoc
renderPretty ribbonFraction pageWidth
= New.layoutSmart New.LayoutOptions
{ New.layoutPageWidth = New.AvailablePerLine pageWidth (realToFrac ribbonFraction) }
renderSmart :: Float -> Int -> Doc -> SimpleDoc
renderSmart ribbonFraction pageWidth
= New.layoutSmart New.LayoutOptions
{ New.layoutPageWidth = New.AvailablePerLine pageWidth (realToFrac ribbonFraction) }Note that they're identical, while the first one should be renderPretty :: Float -> Int -> Doc -> SimpleDoc
renderPretty ribbonFraction pageWidth
= New.layoutPretty New.LayoutOptions
{ New.layoutPageWidth = New.AvailablePerLine pageWidth (realToFrac ribbonFraction) }Now it gets worse unfortunately, because in 0.18.0 I also used I wrote a quickcheck property prop_variable_or :: ArbParser -> Property
prop_variable_or (ArbParser x) = withMaxSuccess 10000 . within 10000000 $
total . Doc.smartString 1.0 80 . extractChunk $ H.briefDesc defaultPrefs x
---
newtype ArbParser = ArbParser {
arbParser :: Parser ()
}
instance Show ArbParser where
show = Doc.prettyString 1.0 80 . extractChunk . H.briefDesc defaultPrefs . arbParser
instance Arbitrary ArbParser where
arbitrary =
ArbParser <$> sized go
where
simple = flag' () . long . unShort <$> arbitrary
go 0 = simple
go n | n > 0 =
oneof [
simple
, (<|>) <$> sub <*> sub
, (*>) <$> sub <*> sub
]
where sub = go (n `div` 2)
newtype ShortString =
ShortString { unShort:: String }
deriving Show
instance Arbitrary ShortString where
arbitrary = ShortString <$> listOf'
where
listOf' =
do k <- chooseInt (4,20)
vectorOf k (choose ('a','z')) |
|
Paging in @quchen It looks like 2 potential issues here.
|
|
I ran |
|
I've just built stack with 0.18.0 and the 0.18.1 above and I can confirm it was hanging, but is working fine with the latter (I had to change its custom hsubparser, but that was it). I'll release a 0.18.1 soon. |
|
@HuwCampbell, many thanks. My original objective was to move Stack on to the latest Briefly on Stack's custom |
|
No it only sets Mixing up the Cabal example from the test suite: parser :: Parser Args
parser = runA $ proc () -> do
opts <- asA commonOpts -< ()
cmds <- (asA . hsubparser)
( command "install"
(info installParser
(progDesc "Installs a list of packages"))
<> command "update"
(info updateParser
(progDesc "Updates list of known packages"))
<> command "configure"
(info configureParser
(progDesc "Prepare to build the package"))
<> command "build"
(info buildParser
(progDesc "Make this package ready for installation"))
<> metavar "METHODOLOGIES") -< ()
A (simpleVersioner "0.0.0") >>> A helper -< Args opts cmds |
|
@HuwCampbell, thanks also for that. I see, Stack can simply have: hsubparser' :: String -> Mod CommandFields a -> Parser a
hsubparser' commandMetavar m = hsubparser (m <> metavar commandMetavar) |
|
Candidate is up. |
|
By way of a test, I built the current |
|
0.18.1 is up. Thanks for the prompt report. |
|
So could you folks edit the metadata of the broken version on Hackage so that it can never happen to resolve as a dependency? Even though the new version is released, it is still possible to build stuff that depends on |
|
I've updated the metadata for 0.18.0 so it won't be chosen any more. |
|
Thank you Captain Huw! |
|
I'm going to change the bounds on 0.17.1 back to the old library too, as there doesn't appear to be any movement on quchen/prettyprinter#244. |
|
The maintainer of prettyprinter has not responded to the PR I have put up, so I've been forced to set 0.17.1 back to using the older ansi-wl-pprint. This whole situation has been very disappointing. |
optparse-applicative-0.18.0.0 is a deprecated release which used layoutSmart from package prettyprinter, which causes the runtime blow up in certain cases. See: pcapriotti/optparse-applicative#475 (comment)
optparse-applicative-0.18.0.0 is a deprecated release which used layoutSmart from package prettyprinter, which causes the runtime to blow up in certain cases. See: pcapriotti/optparse-applicative#475 (comment)
|
Hi all, I just ran into this as well. I'm still narrowing down the issue, but downgrading optparse-applicative didn't seem to help. Tried with GHC 9.6.5 (Stackage LTS 22.22) on a Mac M1. It simply started hanging when I added some new options to the CLI object. Very strange. |
|
The issue here was that the pretty printer library has runtime performance well beyond I've blacklisted the version which uses the So yes, sounds strange... I don't think it's the same problem. Stack traces or profiling would be appreciated. |
I am still trying to narrow down what is going on, but this is what I am experiencing on Windows (I will test on macOS tomorrow, to see if it is OS-specific):
The Stack project makes considerable use of
optparse-applicative, with Stack's complex set of commands. The current version of Stack is built against Stackage's LTS 20.21 snapshot (specifyingoptparse-applicative-0.17.0.0andansi-wl-pprint-0.6.9@rev:4). I replaced that with extra-depsoptparse-applicative-0.17.1.0andansi-wl-pprint-1.0.2.Stack then builds Stack, with no problem. However, if I then command
stack --helpwith the new executable, it just 'hangs' (with no further output). The Task Manager shows thatstack.exeis using ~ 25% to 35% of the CPU, consistently. So I guess something has got caught up in a loop somewhere.The text was updated successfully, but these errors were encountered: