Yampa 0.14.1 → 0.14.2
raw patch · 13 files changed
+54/−112 lines, 13 filesPVP ok
version bump matches the API change (PVP)
API changes (from Hackage documentation)
Files
- CHANGELOG +7/−0
- Yampa.cabal +1/−2
- examples/Diagrams.hs +6/−2
- examples/Elevator/Elevator.hs +11/−4
- examples/TailgatingDetector/TailgatingDetector.hs +0/−1
- examples/TailgatingDetector/TestTGMain.hs +11/−10
- examples/yampa-game/MainBouncingBox.hs +1/−1
- examples/yampa-game/MainCircleMouse.hs +4/−1
- examples/yampa-game/MainWiimote.hs +4/−3
- examples/yampa-game/YampaSDL.hs +4/−0
- src/FRP/Yampa.hs +2/−86
- src/FRP/Yampa/InternalCore.hs +0/−1
- tests/HaddockCoverage.hs +3/−1
CHANGELOG view
@@ -1,3 +1,10 @@+2023-04-07 Ivan Perez <ivan.perez@keera.co.uk>+ * Yampa.cabal: Version bump (0.14.2) (#259).+ * src/: Conformance with style guide (#255).+ * examples/: Conformance with style guide (#255), move example to+ yampa-test library (#257).+ * README: Add game to list of games and apps in README (#254).+ 2023-02-07 Ivan Perez <ivan.perez@keera.co.uk> * Yampa.cabal: Version bump (0.14.1) (#251). * src/: Replace broken links (#253), fix typo (#252).
Yampa.cabal view
@@ -30,7 +30,7 @@ build-type: Simple name: Yampa-version: 0.14.1+version: 0.14.2 author: Henrik Nilsson, Antony Courtney maintainer: Ivan Perez (ivan.perez@keera.co.uk) homepage: https://github.com/ivanperez-keera/Yampa/@@ -116,7 +116,6 @@ if !impl(ghc >= 8.0) build-depends: fail == 4.9.*- test-suite hlint type:
examples/Diagrams.hs view
@@ -1,8 +1,12 @@ {-# LANGUAGE Arrows #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE NoMonomorphismRestriction #-}---- | Example of connecting the diagrams drawing library with Yampa.+-- |+-- Copyright : (c) Ivan Perez, 2018-2022+-- License : BSD-style (see the LICENSE file in the distribution)+-- Maintainer : ivan.perez@keera.co.uk+--+-- Example of connecting the diagrams drawing library with Yampa. -- -- Based on: -- https://archives.haskell.org/projects.haskell.org/diagrams/gallery/VectorField.html
examples/Elevator/Elevator.hs view
@@ -1,8 +1,15 @@ {-# LANGUAGE Arrows #-}--- Module : Elevator--- Description : Elevator simulation based on the Fran version by Thompson.--- Copyright : The University of Nottingham, 2004--- Authors : Henrik Nilsson+-- |+-- Module : Elevator+-- Description : Elevator simulation based on the Fran version by Thompson.+-- Copyright : (c) Ivan Perez, 2014-2022+-- (c) George Giorgidze, 2007-2012+-- (c) Henrik Nilsson, The University of Nottingham, 2004-2006+-- License : BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer : ivan.perez@keera.co.uk+-- Stability : provisional+-- Portability : non-portable (GHC extensions) -- -- Elevator simulation based on the Fran version from Simon Thompson's paper "A -- functional reactive animation of a lift using Fran".
examples/TailgatingDetector/TailgatingDetector.hs view
@@ -29,7 +29,6 @@ -- nature of the problem, and it makes use of the the fact that CONTINUATIONS -- ARE FIRST CLASS ENTITIES in a way which arguably also is justified -- by the nature of the problem.- module TailgatingDetector where import Data.List (sortBy, (\\))
examples/TailgatingDetector/TestTGMain.hs view
@@ -67,16 +67,17 @@ ppTestMCT t = mapM_ (putStrLn . show) (testMCT t) testMTGD :: Time -> [(Time, (Event [(Id,Id)], [(Id, Car)]))]-testMTGD t_max = filter (isEvent . fst . snd) $- takeWhile (\(t, _) -> t <= t_max) $- embed (localTime- &&& (proc _ -> do s <- uavStatus -< ()- h <- highway -< ()- (v, ect) <- mkVideoAndTrackers -< (h, s)- (ics, etgs) <- findTailgaters -< (v,s,ect)- etgs <- mtgd -< ics- returnA -< (etgs, ics)))- (deltaEncode smplPer (repeat ()))+testMTGD t_max =+ filter (isEvent . fst . snd) $+ takeWhile (\(t, _) -> t <= t_max) $+ embed (localTime+ &&& (proc _ -> do s <- uavStatus -< ()+ h <- highway -< ()+ (v, ect) <- mkVideoAndTrackers -< (h, s)+ (ics, etgs) <- findTailgaters -< (v,s,ect)+ etgs <- mtgd -< ics+ returnA -< (etgs, ics)))+ (deltaEncode smplPer (repeat ())) ppTestMTGD t = mapM_ (putStrLn . show) (testMTGD t)
examples/yampa-game/MainBouncingBox.hs view
@@ -20,7 +20,7 @@ -- The first two arguments to reactimate are the value of the input signal -- at time zero and at subsequent times, together with the times between -- samples.--- +-- -- The third argument to reactimate is the output consumer that renders -- the signal. --
examples/yampa-game/MainCircleMouse.hs view
@@ -70,7 +70,10 @@ state <- readIORef controllerState e <- pollEvent case e of- MouseMotion x y _ _ -> writeIORef controllerState (Controller (fromIntegral x, fromIntegral y)) >> sdlGetController controllerState+ MouseMotion x y _ _ -> do writeIORef+ controllerState+ (Controller (fromIntegral x, fromIntegral y))+ sdlGetController controllerState _ -> return state -- * Graphics
examples/yampa-game/MainWiimote.hs view
@@ -23,7 +23,7 @@ -- The first two arguments to reactimate are the value of the input signal -- at time zero and at subsequent times, together with the times between -- samples.--- +-- -- The third argument to reactimate is the output consumer that renders -- the signal. --@@ -110,7 +110,7 @@ let finX = width * propX finY = height * propY - return (finX, finY) + return (finX, finY) -- | Initializes the wiimote, optionally returning the sensing function. It -- returns Nothing if the Wiimote cannot be detected. Users should have a BT@@ -121,5 +121,6 @@ wm <- cwiidOpen case wm of Nothing -> return ()- Just wm' -> void $ cwiidSetRptMode wm' 15 -- Enable button reception, acc and IR+ Just wm' -> void $ cwiidSetRptMode wm' 15 -- Enable button reception, acc+ -- and IR return wm
examples/yampa-game/YampaSDL.hs view
@@ -1,3 +1,7 @@+-- |+-- Copyright : (c) Ivan Perez, 2017-2022+-- License : BSD-style (see the LICENSE file in the distribution)+-- Maintainer : ivan.perez@keera.co.uk module YampaSDL where import Data.IORef
src/FRP/Yampa.hs view
@@ -150,90 +150,6 @@ -- * Auxiliary modules -- -- * "FRP.Yampa.Arrow" -- Arrow-generic functions.---- ToDo:------ - Specialize def. of repeatedly. Could have an impact on invaders.------ - New defs for accs using SFAcc------ - Make sure opt worked: e.g.------ - > repeatedly >>> count >>> arr (fmap sqr)------ - Introduce SFAccHld.------ - See if possible to unify AccHld wity Acc??? They are so close.------ - Introduce SScan. BUT KEEP IN MIND: Most if not all opts would--- - have been possible without GADTs???------ - Look into pairs. At least pairing of SScan ought to be interesting.------ - Would be nice if we could get rid of first & second with impunity--- - thanks to Id optimizations. That's a clear win, with or without--- - an explicit pair combinator.------ - delayEventCat is a bit complicated ...--------- Random ideas:------ - What if one used rules to optimize--- - (arr :: SF a ()) to (constant ())--- - (arr :: SF a a) to identity--- But inspection of invader source code seem to indicate that--- these are not very common cases at all.------ - It would be nice if it was possible to come up with opt. rules--- that are invariant of how signal function expressions are--- parenthesized. Right now, we have e.g.--- arr f >>> (constant c >>> sf)--- being optimized to--- cpAuxA1 f (cpAuxC1 c sf)--- whereas it clearly should be possible to optimize to just--- cpAuxC1 c sf--- What if we didn't use SF' but--- SFComp :: <tfun> -> SF' a b -> SF' b c -> SF' a c--- ???------ - The transition function would still be optimized in (pretty much)--- the current way, but it would still be possible to look "inside"--- composed signal functions for lost optimization opts.--- Seems to me this could be done without too much extra effort/no dupl.--- work.--- E.g. new cpAux, the general case:------ @--- cpAux sf1 sf2 = SFComp tf sf1 sf2--- where--- tf dt a = (cpAux sf1' sf2', c)--- where--- (sf1', b) = (sfTF' sf1) dt a--- (sf2', c) = (sfTF' sf2) dt b--- @------ - The ONLY change was changing the constructor from SF' to SFComp and--- adding sf1 and sf2 to the constructor app.!------ - An optimized case:--- cpAuxC1 b sf1 sf2 = SFComp tf sf1 sf2--- So cpAuxC1 gets an extra arg, and we change the constructor.--- But how to exploit without writing 1000s of rules???--- Maybe define predicates on SFComp to see if the first or second--- sf are "interesting", and if so, make "reassociate" and make a--- recursive call? E.g. we're in the arr case, and the first sf is another--- arr, so we'd like to combine the two.------ - It would also be intersting, then, to know when to STOP playing this--- game, due to the overhead involved.------ - Why don't we have a "SWITCH" constructor that indicates that the--- structure will change, and thus that it is worthwile to keep--- looking for opt. opportunities, whereas a plain "SF'" would--- indicate that things NEVER are going to change, and thus we can just--- as well give up?- module FRP.Yampa ( -- * Basic definitions@@ -319,12 +235,12 @@ , kSwitch, dkSwitch -- ** Parallel composition and switching- -- *** Parallel composition and switching over collections with broadcasting+ -- *** Parallel composition and switching with broadcasting , parB , pSwitchB,dpSwitchB , rpSwitchB,drpSwitchB - -- *** Parallel composition and switching over collections with general routing+ -- *** Parallel composition and switching with general routing , par , pSwitch, dpSwitch , rpSwitch,drpSwitch
src/FRP/Yampa/InternalCore.hs view
@@ -52,7 +52,6 @@ -- "FRP.Yampa.Event" defines events and event-manipulation functions. -- -- Finally, see [<#g:26>] for sources of randomness (useful in games).- module FRP.Yampa.InternalCore ( module Control.Arrow
tests/HaddockCoverage.hs view
@@ -81,7 +81,9 @@ getFilesAndDirectories :: FilePath -> IO ([FilePath], [FilePath]) getFilesAndDirectories dir = do- c <- map (dir </>) . filter (`notElem` ["..", "."]) <$> getDirectoryContents dir+ c <- map (dir </>) . filter (`notElem` ["..", "."])+ <$> getDirectoryContents dir+ (,) <$> filterM doesDirectoryExist c <*> filterM doesFileExist c -- find-based implementation (not portable)