Hoogle Search

Within LTS Haskell 24.36 (ghc-9.10.3)

Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.

Exact lookup

1. module GHCJS.Foreign

   No documentation available.

2. ForCapture :: AudioDeviceUsage

   sdl2	SDL.Audio

   The device will be used for sample capture.

3. ForPlayback :: AudioDeviceUsage

   sdl2	SDL.Audio

   The device will be used for sample playback.

4. module Development.Shake.Forward

   A module for producing forward-defined build systems, in contrast to standard backwards-defined build systems such as shake. Based around ideas from fabricate. As an example:

   import Development.Shake
   import Development.Shake.Forward
   import Development.Shake.FilePath
   
   main = shakeArgsForward shakeOptions $ do
   contents <- readFileLines "result.txt"
   cache $ cmd "tar -cf result.tar" contents
   

   Compared to backward-defined build systems (such as normal Shake), forward-defined build systems tend to be simpler for simple systems (less boilerplate, more direct style), but more complex for larger build systems (requires explicit parallelism, explicit sharing of build products, no automatic command line targets). As a general approach for writing forward-defined systems:
   • Figure out the sequence of system commands that will build your project.
   • Write a simple Action that builds your project.
   • Insert cache in front of most system commands.
   • Replace most loops with forP, where they can be executed in parallel.
   • Where Haskell performs real computation, if zero-build performance is insufficient, use cacheAction.
   All forward-defined systems use AutoDeps, which requires fsatrace to be on the $PATH. You can obtain fsatrace from https://github.com/jacereda/fsatrace. You must set shakeLintInside to specify where AutoDeps will look for dependencies - if you want all dependencies everywhere use [""]. This module is considered experimental - it has not been battle tested. There are now a few possible alternatives in this space:
   • Pier http://hackage.haskell.org/package/pier/docs/Pier-Core-Artifact.html (built on Shake).
   • Rattle https://github.com/ndmitchell/rattle (by the same author as Shake).
   • Stroll https://github.com/snowleopard/stroll.

5. type Format = Text

   swagger2	Data.Swagger

   No documentation available.

6. type Format = Text

   swagger2	Data.Swagger.Internal

   No documentation available.

7. module Brick.Forms

   Note - this API is designed to support a narrow (but common!) set of use cases. If you find that you need more customization than this offers, then you will need to consider building your own layout and event handling for input fields. For a fuller introduction to this API, see the "Input Forms" section of the Brick User Guide. Also see the demonstration programs for examples of forms in action. This module provides an input form API. This API allows you to construct an input interface based on a data type of your choice. Each input in the form corresponds to a field in your data type. This API then automatically dispatches keyboard and mouse input events to each form input field, manages rendering of the form, notifies the user when a form field's value is invalid, and stores valid inputs in your data type when possible. A form has both a visual representation and a corresponding data structure representing the latest valid values for that form (referred to as the "state" of the form). A FormField is a single input component in the form and a FormFieldState defines the linkage between that visual input and the corresponding portion of the state represented by that visual; there may be multiple FormFields combined for a single FormFieldState (e.g. a radio button sequence). To use a Form, you must include it within your application state type. You can use formState to access the underlying state whenever you need it. See programs/FormDemo.hs for a complete working example. Also note that, by default, forms and their field inputs are concatenated together in a vBox. This can be customized on a per-field basis and for the entire form by using the functions setFieldConcat and setFormConcat, respectively. Bear in mind that for most uses, the FormField and FormFieldState types will not be used directly. Instead, the constructors for various field types (such as editTextField) will be used instead.

8. data Form s e n

   brick	Brick.Forms

   A form: a sequence of input fields that manipulate the fields of an underlying state that you choose. This value must be stored in the Brick application's state. Type variables are as follows:

   • s - the data type of your choosing containing the values manipulated by the fields in this form.
   • e - your application's event type
   • n - your application's resource name type

9. data FormField a b e n

   brick	Brick.Forms

   A form field. This represents an interactive input field in the form. Its user input is validated and thus converted into a type of your choosing. Type variables are as follows:

   • a - the type of the field in your form state that this field manipulates
   • b - the form field's internal state type
   • e - your application's event type
   • n - your application's resource name type

10. FormField :: n -> (b -> Maybe a) -> Bool -> (Bool -> b -> Widget n) -> (BrickEvent n e -> EventM n b ()) -> FormField a b e n

    brick	Brick.Forms

    No documentation available.

Page 284 of many | Previous | Next