proj-oot-ootLibrariesNotes12

http://shellhaters.org/

---

if malloc rounds up the space it allocates for you, then there should be a way to find out the actual amount of space that it gave you so that you can make use of it

---

https://www.haiku-os.org/legacy-docs/bebook/

---

https://github.com/WebAssembly/WASI/blob/master/phases/snapshot/docs.md

---

https://betterdev.blog/minimal-safe-bash-script-template/ https://news.ycombinator.com/item?id=25429899

-- SNES raytracing custom chip

https://www.shironekolabs.com/posts/superrt/

---

https://genode.org/documentation/genode-foundations/20.05/index.html

---

https://github.com/glouw/ctl https://lobste.rs/s/9gc2ku/c_template_library

"

C TEMPLATE LIBRARY (CTL)

CTL is a fast compiling, type safe, header only, template-like library for ISO C11. Motivation

CTL aims to improve C11 developer productivity by implementing the following STL containers in ISO C11:

deq.h = std::deque lst.h = std::list pqu.h = std::priority_queue que.h = std::queue set.h = std::set stk.h = std::stack str.h = std::string vec.h = std::vector

"

---

t0astbread 3 days ago [–]

Frameworks and languages to build small to mid-sized web applications that aren't no-code or low-code or tied into an online service. Basically, PHP alternatives.

Here's a "wishlist" of features I'd like in such a framework:

reply

---

haskell extension recommendations:

haskell

https://limperg.de/ghc-extensions/ basic track:

    3.1 Syntactic Niceties
        3.1.1 TupleSections
        3.1.2 LambdaCase
        3.1.3 MultiWayIf
        3.1.4 BlockArguments
        3.1.5 TypeOperators
        3.1.6 NumericUnderscores
    3.2 Overloaded Literals
        3.2.1 OverloadedStrings
        3.2.2 OverloadedLists
    3.3 Patterns
        3.3.1 ViewPatterns
        3.3.2 PatternSynonyms
    3.4 Type System
        3.4.1 ExplicitForAll
        3.4.2 TypeApplications
        3.4.3 ScopedTypeVariables
        3.4.4 RankNTypes
        3.4.5 LiberalTypeSynonyms
    3.5 Records
        3.5.1 NamedFieldPuns
        3.5.2 RecordWildCards
    3.6 Classes
        3.6.1 FlexibleInstances
        3.6.2 FlexibleContexts
        3.6.3 DeriveFunctor, DeriveFoldable, DeriveTraversable
        3.6.4 GeneralizedNewtypeDeriving
        3.6.5 InstanceSigs
        3.6.6 ConstrainedClassMethods
        3.6.7 MultiParamTypeClasses
        3.6.8 FunctionalDependencies
        3.6.9 DeriveGeneric
    3.7 Typed Holes
        3.7.1 Typed Holes and Type Wildcards
        3.7.2 NamedWildCards
        3.7.3 PartialTypeSignatures

https://taylor.fausak.me/2020/11/22/haskell-survey-results/#s2q5 <34% net:

+37% -4% DerivingStrategies? +37% -4% MultiParamTypeClasses? +37% -4% TupleSections? +35% -7% DataKinds? +33% -4% KindSignatures? +32% -6% TypeFamilies? +30% -4% StandaloneDeriving? +30% -6% MultiWayIf? +29% -5% DeriveDataTypeable? +28% -5% ConstraintKinds? +28% -5% TypeOperators? +28% -6% ViewPatterns? +26% -4% InstanceSigs? +26% -5% DeriveLift? +25% -4% NumericUnderscores? +24% -6% NamedFieldPuns? +24% -5% EmptyCase? +24% -6% GADTSyntax +24% -6% ExplicitForAll? +23% -5% BinaryLiterals? +23% -6% FunctionalDependencies? +23% -10% DeriveAnyClass? +22% -9% RecordWildCards? +21% -6% DefaultSignatures? +21% -6% ExistentialQuantification? +20% -5% PatternSynonyms? +19% -13% ApplicativeDo?

https://taylor.fausak.me/2019/11/16/haskell-survey-results/#s2q5

Which language extensions would you like to be enabled by default?

Multiple select. 48% OverloadedStrings? 40% LambdaCase? 34% DeriveGeneric? 29% DeriveFunctor? 29% GADTs 28% BangPatterns? 26% FlexibleInstances? 25% FlexibleContexts? 25% ScopedTypeVariables? 25% RankNTypes? DeriveFoldable? GeneralizedNewtypeDeriving? TypeApplications? TypeFamilies? DeriveTraversable? 20% DataKinds? TupleSections? MultiParamTypeClasses? DerivingVia? TypeOperators? 17% KindSignatures? DerivingStrategies? 15% DeriveDataTypeable? MultiWayIf? ViewPatterns? StandaloneDeriving? ConstraintKinds? DeriveAnyClass? RecordWildCards? 13% EmptyCase? ApplicativeDo? 12% FunctionalDependencies? ExplicitForAll? InstanceSigs? 11% GADTSyntax PatternSynonyms? NamedFieldPuns? NumericUnderscores? 10%

http://dev.stephendiehl.com/hask/#language-extensions

The Benign

It’s not obvious which extensions are the most common but it’s fairly safe to say that these extensions are benign and are safely used extensively:

    NoImplicitPrelude
    OverloadedStrings
    LambdaCase
    FlexibleContexts
    FlexibleInstances
    GeneralizedNewtypeDeriving
    TypeSynonymInstances
    MultiParamTypeClasses
    FunctionalDependencies
    NoMonomorphismRestriction
    GADTs
    BangPatterns
    DeriveGeneric
    DeriveAnyClass
    DerivingStrategies
    ScopedTypeVariables

The Advanced

These extensions are typically used by advanced projects that push the limits of what is possible with Haskell to enforce complex invariants and very type-safe APIs.

    PolyKinds
    DataKinds
    DerivingVia
    GADTs
    RankNTypes
    ExistentialQuantification
    TypeFamilies
    TypeOperators
    TypeApplications
    UndecidableInstances

The Lowlevel

These extensions are typically used by low-level libraries that are striving for optimal performance or need to integrate with foreign functions and native code. Most of these are used to manipulate base machine types and interface directly with the low-level byte representations of data structures.

    CPP
    BangPatterns
    CApiFFI
    Strict
    StrictData
    RoleAnnotations
    ForeignFunctionInterface
    InterruptibleFFI
    UnliftedFFITypes
    MagicHash
    UnboxedSums
    UnboxedTuples

https://gist.github.com/mightybyte/6c469c125eb50e0c2ebf4ae26b5adfff

Level 0 - Use at will

Tried and true extensions. Very unlikely to cause problems. You can use these and rarely get any complaints.

    ApplicativeDo
    AutoDeriveTypeable -- Automatic derivation of Typeable
    BangPatterns
    Cpp
    DeriveDataTypeable
    DeriveFoldable
    DeriveFunctor
    DeriveGeneric
    DeriveLift
    DeriveTraversable
    EmptyDataDecls
    ExistentialQuantification
    ExplicitForAll
    FlexibleContexts
    FlexibleInstances
    ForeignFunctionInterface
    GeneralizedNewtypeDeriving
    JavaScriptFFI
    KindSignatures
    LambdaCase
    MagicHash
    MonomorphismRestriction
    MultiParamTypeClasses
    OverloadedLists
    OverloadedStrings
    PackageImports
    PartialTypeSignatures
    RankNTypes
    RecordWildCards -- This one is somewhat controversial
    ScopedTypeVariables
    StandaloneDeriving
    TupleSections
    TypeApplications
    UnboxedTuples
    ViewPatterns

Level 1 - More complex, but well understood

More complexity than level 0, but on the whole quite well understood and useful. Pose a little bit more of an obstacle in terms of concepts you need to understand to use them. Implementations without level 1 are still preferred if possible.

    AllowAmbiguousTypes
    DefaultSignatures
    DerivingStrategies
    FunctionalDependencies
    GADTs
    ImplicitPrelude -- Alternate preludes meh
    QuasiQuotes
    RecursiveDo
    TemplateHaskell
    TypeFamilies
    TypeOperators
    TypeSynonymInstances
    UndecidableInstances

https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/#any-flavor-you-like

Now, with that small digression out of the way, the question becomes precisely which extensions should go into that default-extensions list. I happen to like using most of the features GHC makes available, so I enable a whopping 34 language extensions by default. As of GHC 8.2, here is my list:

    ApplicativeDo
    BangPatterns
    ConstraintKinds
    DataKinds
    DefaultSignatures
    DeriveFoldable
    DeriveFunctor
    DeriveGeneric
    DeriveLift
    DeriveTraversable
    DerivingStrategies
    EmptyCase
    ExistentialQuantification
    FlexibleContexts
    FlexibleInstances
    FunctionalDependencies
    GADTs
    GeneralizedNewtypeDeriving
    InstanceSigs
    KindSignatures
    LambdaCase
    MultiParamTypeClasses
    MultiWayIf
    NamedFieldPuns
    OverloadedStrings
    PatternSynonyms
    RankNTypes
    ScopedTypeVariables
    StandaloneDeriving
    TupleSections
    TypeApplications
    TypeFamilies
    TypeFamilyDependencies
    TypeOperators

https://www.schoolofhaskell.com/user/PthariensFlame/guide-to-ghc-extensions

The extensions which are currently covered are:

    BangPatterns
    BinaryLiterals
    DatatypeContexts
    DoAndIfThenElse
    DoRec
    EmptyCase
    EmptyDataDecls
    ExistentialQuantification
    ExplicitForAll
    GADTs
    GADTSyntax
    Haskell98
    Haskell2010
    LambdaCase
    LiberalTypeSynonyms
    MonadComprehensions
    MultiWayIf
    NegativeLiterals
    NPlusKPatterns
    NondecreasingIndentation
    NumDecimals
    OverloadedLists
    OverloadedStrings
    PackageImports
    ParallelListComp
    PatternGuards
    PatternSignatures
    PatternSynonyms
    PolymorphicComponents
    PostfixOperators
    Rank2Types
    RankNTypes
    RecursiveDo
    ScopedTypeVariables
    TransformListComp
    TupleSections
    UnicodeSyntax
    ViewPatterns

Welcome View Patterns Pattern Synonyms Record WildCards? (and OverloadedStrings?) Bang Patterns Rebindable Syntax (and NoMonomorphismRestriction?) List Comprehensions (and ParallelListComp?, TransformListComp?, MonadComprehensions?, RecordWildCards?) Type Operators Recursive Do Nullary Type Classes Implicit Parameters Type Families (and FlexibleContexts?) Multi Param Type Classes (and FlexibleInstances?) Functional Dependencies Deriving (and DeriveFunctor? DeriveFoldable? DeriveTraversable? DeriveDataTypeable? GeneralizedNewtypeDeriving?) Derive Generic (and UndecidableInstances? FunctionalDependencies? TypeOperators?) Overloaded Strings Rank N Types (and TypeFamilies? GADTs KindSignatures?) Existential Quantification Scoped Type Variables Arrows Template Haskell Static Pointers Thanks

git clone https://github.com/tssm/up-to-date-real-world-haskell.git cd up-to-date-real-world-haskell/ /bin/grep LANGUAGE *.org

BangPatterns? CPP DeriveDataTypeable? FlexibleContexts? ForeignFunctionInterface? FunctionalDependencies? FlexibleInstances? GeneralizedNewtypeDeriving? MultiParamTypeClasses? PatternGuards? TypeSynonymInstances?

git clone https://github.com/tssm/up-to-date-real-world-haskell.git cd up-to-date-real-world-haskell/ /bin/grep LANGUAGE *.org

BangPatterns? CPP DeriveDataTypeable? FlexibleContexts? FlexibleInstances? ForeignFunctionInterface? FunctionalDependencies? GeneralizedNewtypeDeriving? MultiParamTypeClasses? PatternGuards? TypeSynonymInstances?

git clone https://github.com/bos/rwh.git cd rwh /bin/grep -r LANGUAGE *

BangPatterns? CPP DeriveDataTypeable? EmptyDataDecls? FlexibleContexts? FlexibleInstances? ForeignFunctionInterface? FunctionalDependencies? GeneralizedNewtypeDeriving? MultiParamTypeClasses? OverlappingInstances? PatternGuards? TypeSynonymInstances? UndecidableInstances?

(so these two lists are the same except the second one adds: EmptyDataDecls? OverlappingInstances? UndecidableInstances? )

>34% net 2020:

BangPatterns? DeriveFoldable? DeriveFunctor? DeriveGeneric? DeriveTraversable? DerivingVia? FlexibleContexts? FlexibleInstances? GADTs GeneralizedNewtypeDeriving? LambdaCase? OverloadedStrings? RankNTypes? ScopedTypeVariables? TypeApplications?

>%20 2019 takes out

DerivingVia? (>17%)

and adds

TypeFamilies?

2020 >25% net would add:

+37% -4% DerivingStrategies? +37% -4% MultiParamTypeClasses? +37% -4% TupleSections? +35% -7% DataKinds? +33% -4% KindSignatures? +32% -6% TypeFamilies? +30% -4% StandaloneDeriving?

all of which, except StandaloneDeriving? (between 15% and 13%) and TypeFamilies? (above 20%), were in between 20% and 15% in 2019

so i think we can stick with orig 34% list, minus DerivingVia?:

the following is >34% net in 2020 and >20% in 2019 State of Haskell surveys:

BangPatterns? DeriveFoldable? DeriveFunctor? DeriveGeneric? DeriveTraversable? FlexibleContexts? FlexibleInstances? GADTs GeneralizedNewtypeDeriving? LambdaCase? OverloadedStrings? RankNTypes? ScopedTypeVariables? TypeApplications?

all of these are in https://limperg.de/ghc-extensions/ 's "basic track" except the following which are in eis "Advanced Track":

BangPatterns? GADTs

So labeling those:

BangPatterns? (advanced in Limperg) DeriveFoldable? DeriveFunctor? DeriveGeneric? DeriveTraversable? FlexibleContexts? FlexibleInstances? GADTs (advanced in Limperg) GeneralizedNewtypeDeriving? LambdaCase? OverloadedStrings? RankNTypes? ScopedTypeVariables? TypeApplications?

considering http://dev.stephendiehl.com/hask/#language-extensions 's Benign/Advanced/Lowlevel lists):

and https://gist.github.com/mightybyte/6c469c125eb50e0c2ebf4ae26b5adfff (Beardsley's lists)

BangPatterns? (advanced in Limperg, lowlevel in Diehl; is in RWH) DeriveFoldable? (not in Diehl's Benign/Advanced/Lowlevel lists, not in PthariensFlame?'s list) DeriveFunctor? (not in Diehl's Benign/Advanced/Lowlevel lists, not in PthariensFlame?'s list) DeriveGeneric? (not in PthariensFlame?'s list) DeriveTraversable? (not in Diehl's Benign/Advanced/Lowlevel lists, not in PthariensFlame?'s list) FlexibleContexts? (not in PthariensFlame?'s list; is in RWH) FlexibleInstances? (not in PthariensFlame?'s list; is in RWH) GADTs (advanced in Limperg, Diehl, "More complex, but well understood" in Beardsley) GeneralizedNewtypeDeriving? (not in PthariensFlame?'s list; is in RWH) LambdaCase? (not in 24 Days of GHC Extensions) OverloadedStrings? RankNTypes? (advanced in Diehl) ScopedTypeVariables? TypeApplications? (advanced in Diehl, not in PthariensFlame?'s list, not in 24 Days of GHC Extensions)

and all were in Diehl's Benign list except for as labeled, and all were in Beardsley's "Use at will" list except GADTs which were in his "More complex, but well understood" as labeled. All were in https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/#any-flavor-you-like 's list of 34 extensions used by default. Those not in https://www.schoolofhaskell.com/user/PthariensFlame/guide-to-ghc-extensions are labeled. Those not in https://ocharles.org.uk/pages/2014-12-01-24-days-of-ghc-extensions.html are labeled.

now considering adding more:

other items in 2020 SOH >=20% net:

ConstraintKinds? DataKinds? DeriveLift? DeriveDataTypeable? DerivingStrategies? DerivingVia? InstanceSigs? KindSignatures? MultiParamTypeClasses? MultiWayIf? NumericUnderscores? StandaloneDeriving? TupleSections? TypeFamilies? TypeOperators? ViewPatterns?

other items in 2019 SOH >=14% removes:

ConstraintKinds? DeriveLift? InstanceSigs? NumericUnderscores?

leaving:

DataKinds? (Limperg advanced, Diehl advanced, Beardsley's lists as "Avoid unless you have a VERY good reason", not in 24 Days of GHC Extensions) DeriveDataTypeable? (Limperg notes "Recent GHCs derive instances of Typeable without you even writing a deriving clause, so you don’t need DeriveDataTypeable? for that anymore." and places in Misc; not in Diehl's Benign/Advanced/Lowlevel lists, not in lexi-lambda's list) DerivingStrategies? (Limperg advanced, Beardsley's "More complex, but well understood" list, not in 24 Days of GHC Extensions) DerivingVia? (Limperg advanced, Diehl advanced, not in Beardsley's lists, not in lexi-lambda's default list, not in 24 Days of GHC Extensions) KindSignatures? (Limperg advanced, Diehl advanced (implied by TypeFamilies?)) MultiParamTypeClasses? MultiWayIf? (not in Diehl's Benign/Advanced/Lowlevel lists, Beardsley hasn't decided where to put this yet, is in PthariensFlame?'s list, not in 24 Days of GHC Extensions) StandaloneDeriving? (Limperg advanced, not in Diehl's Benign/Advanced/Lowlevel lists, not in 24 Days of GHC Extensions) TupleSections? (is in PthariensFlame?'s list, not in 24 Days of GHC Extensions) TypeFamilies? (Limperg advanced, Diehl advanced, Beardsley's "More complex, but well understood" list) TypeOperators? (Diehl advanced, Beardsley's "More complex, but well understood" list)) ViewPatterns? (not in Diehl's Benign/Advanced/Lowlevel lists, not in lexi-lambda's default list, is in PthariensFlame?'s list)

all of these are in https://limperg.de/ghc-extensions/ 's "basic track" except as labeled and all were in Diehl's Benign list except for as labeled, and all were in Beardsley's "Use at will" list except GADTs which were in his "More complex, but well understood" as labeled. All were in https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/#any-flavor-you-like 's list of 34 extensions used by default except as labeled Those IN https://www.schoolofhaskell.com/user/PthariensFlame/guide-to-ghc-extensions are labeled. Only one on this list was in Real World Haskell: MultiParamTypeClasses?

So the following are >33% net in 2020 State of Haskell survey and >19% in 2019 State of Haskell survey, and on Diehl's Benign list, and in Beardsley's "Use at will list", and in lexi-lambda's list of extensions to use by default, and are on at least 2 of 3 of (PthariensFlame?'s list, Real World Haskell, 24 Days of GHC extensions):

FlexibleContexts? (not in PthariensFlame?'s list; is in RWH) FlexibleInstances? (not in PthariensFlame?'s list; is in RWH) GeneralizedNewtypeDeriving? (not in PthariensFlame?'s list; is in RWH) LambdaCase? (not in 24 Days of GHC Extensions) MultiParamTypeClasses? TupleSections? (not in 24 Days of GHC Extensions) OverloadedStrings? ScopedTypeVariables?

And the following are >33% net in 2020 State of Haskell survey and >19% in 2019 State of Haskell survey, and on Diehl's Benign or Advanced list (or with Diehl use classfication General/Deriving), and in Beardsley's "Use at will" list or "More complex, but well understood", and on at least one of (Diehl's Benign or Diehl's Lowlevel or Beardsley's "Use at will"), and in lexi-lambda's list of extensions to use by default, and are on at least 1 of 3 of (PthariensFlame?'s list, Real World Haskell, 24 Days of GHC extensions):

BangPatterns? (advanced in Limperg, lowlevel in Diehl; is in RWH) DeriveFoldable? (not in Diehl's Benign/Advanced/Lowlevel lists but General/Deriving, not in PthariensFlame?'s list) DeriveFunctor? (not in Diehl's Benign/Advanced/Lowlevel lists but General/Deriving, not in PthariensFlame?'s list) DeriveGeneric? (not in PthariensFlame?'s list) DeriveTraversable? (not in Diehl's Benign/Advanced/Lowlevel lists but General/Deriving, not in PthariensFlame?'s list) GADTs (advanced in Limperg, both benign and advanced in Diehl, "More complex, but well understood" in Beardsley; also in 24 Days of GHC Extensions) RankNTypes? (advanced in Diehl) TypeApplications? (advanced in Diehl, not in PthariensFlame?'s list, not in 24 Days of GHC Extensions)

And the following are >33% net in 2020 State of Haskell survey and >15% in 2019 State of Haskell survey and on the lists Limperg Advanced, Diehl's Benign or Advanced, Beardsley's "More complex, but well understood", lexi-lambda, PthariensFlame?:

DerivingStrategies? (Limperg advanced, Beardsley's "More complex, but well understood" list, not in 24 Days of GHC Extensions)

And the following are >20% net in 2020 State of Haskell survey and >14% in 2019 State of Haskell survey, and on at least one of Limperg's Basic list, Diehl's Benign list, or Beardsley's "Use at will list" and at least one of the other two out of (Limperg, Diehl, Beardsley) list as either basic/benign/use at will or advanced/more complex but well understood, and in lexi-lambda's list of extensions to use by default unless listed, and are on at least 1 of (PthariensFlame?'s list, Real World Haskell, 24 Days of GHC extensions):

KindSignatures? (Limperg advanced, Diehl advanced (implied by TypeFamilies?, is in 24 Days of GHC Extensions) TypeOperators? (Diehl advanced, Beardsley's "More complex, but well understood" list, is in 24 Days of GHC Extensions) ViewPatterns? (not in Diehl's Benign/Advanced/Lowlevel lists, not in lexi-lambda's default list, is in PthariensFlame?'s list and 24 days of GHC extensions)

And the following are >20% net in 2020 State of Haskell survey and >14% in 2019 State of Haskell survey, and on at least one of Limperg's Basic or Advanced list, Diehl's Advanced list, or Beardsley's "Use at will" or "More complex but still well understood", and in lexi-lambda's list of extensions to use by default unless listed:

DataKinds? (Limperg advanced, Diehl advanced, Beardsley's lists as "Avoid unless you have a VERY good reason") DerivingVia? (Limperg advanced, Diehl advanced, not in Beardsley's lists, not in lexi-lambda's default list) MultiWayIf? (not in Diehl's Benign/Advanced/Lowlevel lists, Beardsley hasn't decided where to put this yet; is in PthariensFlame?'s list) StandaloneDeriving? (Limperg advanced, not in Diehl's Benign/Advanced/Lowlevel lists) TypeFamilies? (Limperg advanced, Diehl advanced, Beardsley's "More complex, but well understood" list, is in 24 days of GHC extensions)

obsolete: DeriveDataTypeable? (Limperg notes "Recent GHCs derive instances of Typeable without you even writing a deriving clause, so you don’t need DeriveDataTypeable? for that anymore." and places in Misc; not in Diehl's Benign/Advanced/Lowlevel lists, not in lexi-lambda's list)

Others not above, but >10% in 2020 State of Haskell survey, and at least one of (Limperg Basic, Diehl Benign, Beardsley "Use at will"), and on at least two other lists (not counting "avoid" or "undecided" lists):

DeriveLift? (21% net in 2020 survey, <10% in 2019 survey, Limperg Advanced, not in Diehl's Benign/Advanced/Lowlevel lists, Beardsley Use at will, is in lexi lambda's list, not in PthariensFlame?'s list, not in 24 days) ExistentialQuantification? (15% net in 2020 survey, <10% in 2019 survey, Limperg Advanced, Diehl Advanced, Beardsley Use at will, is in lexi lambda's list, is in PthariensFlame?'s list, is in 24 days) ExplicitForAll? (18% net in 2020 survey, 11% in 2019 survey, Limperg Basic, Diehl Advanced (implied by ExistentialQuantification?), Beardsley Use at will, not in lexi lambda's list, is in PthariensFlame?'s list, not in 24 days) FunctionalDependencies? (17% net in 2020 survey, 12% in 2019 survey, Limperg Basic, Diehl Benign, Beardsley More complex, but well understood, is in lexi lambda's list, not in PthariensFlame?'s list, is in 24 days) GADTSyntax (18% net in 2020 survey, 11% in 2019 survey, Limperg Advanced, Diehl benign and advanced (implied by GADTs), Beardsley undecided, not in lexi lambda's list, is in PthariensFlame?'s list, not in 24 days) PatternSynonyms? (15% net in 2020 survey, 10% in 2019 survey, Limperg Basic, not in Diehl's Benign/Advanced/Lowlevel lists, Beardsley undecided, is in lexi lambda's list, is in PthariensFlame?'s list, not in 24 days)

In the above list, only FunctionalDependencies? is in RWH.

Others not above, but >10% in 2020 State of Haskell survey, and at least one of (Limperg Basic or Advanced, Diehl Benign or Advanced, Beardsley "Use at will" or "More complex, but well understood"), and on at least one other lists (not counting "avoid" or "undecided" lists):

BinaryLiterals? (18% net in 2020 survey, <10% in 2019 survey, Limperg Advanced, not mentioned by Diehl, Beardsley undecided, not in lexi lambda's list, is in PthariensFlame?'s list, not in 24 days) ConstraintKinds? (23% net in 2020 survey, 13% in 2019 survey, Limperg Advanced, not in Diehl's Benign/Advanced/Lowlevel lists, Beardsley Avoid unless you have a VERY good reason, is in lexi lambda's list, not in PthariensFlame?'s list, not in 24 days) DefaultSignatures? (15% net in 2020 survey, <10% in 2019 survey, Limperg Advanced, not in Diehl's Benign/Advanced/Lowlevel lists, Beardsley More complex, but well understood, is in lexi lambda's list, not in PthariensFlame?'s list, not in 24 days) DeriveAnyClass? (13% net in 2020 survey, 13% in 2019 survey, Limperg Advanced, Diehl Benign, Beardsley Avoid unless you have a VERY good reason, not in lexi lambda's list, not in PthariensFlame?'s list, not in 24 days) EmptyCase? (19% net in 2020 survey, 13% in 2019 survey, Limperg Advanced, not in Diehl's Benign/Advanced/Lowlevel lists, Beardsley undecided, is in lexi lambda's list, is in PthariensFlame?'s list, not in 24 days) InstanceSigs? (22% net in 2020 survey, 11% net in 2019 survey, Limperg Basic, not in Diehl's Benign/Advanced/Lowlevel lists, Beardsley undecided, is in lexi lambda's list, not in PthariensFlame?'s list, not in 24 days) NamedFieldPuns? (18% net in 2020 survey, 10% in 2019 survey, Limperg Basic, not in Diehl's Benign/Advanced/Lowlevel lists, not mentioned by Beardsley, is in lexi lambda's list, not in PthariensFlame?'s list, not in 24 days) PolyKinds? (10% net in 2020 survey, <10% in 2019 survey, Limperg Advanced, Diehl Advanced, Beardsley Avoid unless you have a VERY good reason, not in lexi lambda's list, not in PthariensFlame?'s list, not in 24 days) RecordWildCards? (13% net in 2020 survey, 13% in 2019 survey, Limperg Basic, not in Diehl's Benign/Advanced/Lowlevel lists, not mentioned by Beardsley, not in lexi lambda's list, not in PthariensFlame?'s list, is in 24 days)

In the above list, no items are in RWH.

Others not above, but >10% in 2020 State of Haskell survey:

NumericUnderscores? (21% net in 2020 survey, 10% in 2019 survey, Limperg Basic, not mentioned by Diehl, not mentioned by Beardsley, not in lexi lambda's list, not in PthariensFlame?'s list, not in 24 days)

In the above list, no items are in RWH.

TODO: Diehl general/specialized, both sets

---

So i think the most important Haskell GHC extensions, divided into tiers, are (look thru the above to figure out the defns of tiers):

Tier 0 (should clearly be added to language; net majority 'vote' in 2020 Haskell survey): LambdaCase? (not in 24 Days of GHC Extensions) OverloadedStrings?

Tier 1 (should probably be added to language; widely used and recommended; net >=33% 'vote' in 2020 Haskell survey):

BangPatterns? (advanced in Limperg, lowlevel in Diehl; is in RWH) DeriveFoldable? (not in Diehl's Benign/Advanced/Lowlevel lists but General/Deriving, not in PthariensFlame?'s list) DeriveFunctor? (not in Diehl's Benign/Advanced/Lowlevel lists but General/Deriving, not in PthariensFlame?'s list) DeriveGeneric? (not in PthariensFlame?'s list) DeriveTraversable? (not in Diehl's Benign/Advanced/Lowlevel lists but General/Deriving, not in PthariensFlame?'s list) FlexibleContexts? (not in PthariensFlame?'s list; is in RWH) FlexibleInstances? (not in PthariensFlame?'s list; is in RWH) GeneralizedNewtypeDeriving? (not in PthariensFlame?'s list; is in RWH) MultiParamTypeClasses? ScopedTypeVariables? (Diehl 'specialized') TupleSections? (not in 24 Days of GHC Extensions)

Tier 2 (should probably be added to language; widely used and recommended but somewhat advanced; net >=33% 'vote' in 2020 Haskell survey):

DerivingStrategies? (Limperg advanced, Beardsley's "More complex, but well understood" list, not in 24 Days of GHC Extensions; Diehl doesn't list general/specialized (but it's Diehl Benign)) GADTs (advanced in Limperg, both benign and advanced in Diehl, "More complex, but well understood" in Beardsley; also in 24 Days of GHC Extensions) RankNTypes? (advanced and specialized in Diehl; Limperg lists as Basic but only b/c it's required for the ST monad) TypeApplications? (advanced and specialized in Diehl, not in PthariensFlame?'s list, not in 24 Days of GHC Extensions)

Tier 3 (fairly widely used and recommended; net >=20% 'vote' in 2020 Haskell survey):):

KindSignatures? (Limperg advanced, Diehl advanced (implied by TypeFamilies?) and specialized, is in 24 Days of GHC Extensions) TypeOperators? (Diehl advanced and specialized, Beardsley's "More complex, but well understood" list, is in 24 Days of GHC Extensions) ViewPatterns? (not in Diehl's Benign/Advanced/Lowlevel lists, not in lexi-lambda's default list, is in PthariensFlame?'s list and 24 days of GHC extensions) DataKinds? (Limperg advanced, Diehl advanced and specialized, Beardsley's lists as "Avoid unless you have a VERY good reason") DerivingVia? (Limperg advanced, Diehl advanced (doesn't list general/specialized), not in Beardsley's lists, not in lexi-lambda's default list) MultiWayIf? (not in Diehl's Benign/Advanced/Lowlevel lists, specialized in Diehl, Beardsley hasn't decided where to put this yet; is in PthariensFlame?'s list) StandaloneDeriving? (Limperg advanced, not in Diehl's Benign/Advanced/Lowlevel lists) TypeFamilies? (Limperg advanced, Diehl advanced and specialized, Beardsley's "More complex, but well understood" list, is in 24 days of GHC extensions) DeriveDataTypeable? (Limperg notes "Recent GHCs derive instances of Typeable without you even writing a deriving clause, so you don’t need DeriveDataTypeable? for that anymore." and places in Misc; not in Diehl's Benign/Advanced/Lowlevel lists, not in lexi-lambda's list)

(note: in the above i added information to note whenever Diehl lists something as 'specialized')

so, based on the above, i might recommend the following 17 additions to the language/default extensions:

BangPatterns? (advanced in Limperg, lowlevel in Diehl; is in RWH) DeriveFoldable? (not in Diehl's Benign/Advanced/Lowlevel lists but General/Deriving, not in PthariensFlame?'s list) DeriveFunctor? (not in Diehl's Benign/Advanced/Lowlevel lists but General/Deriving, not in PthariensFlame?'s list) DeriveGeneric? (not in PthariensFlame?'s list) DeriveTraversable? (not in Diehl's Benign/Advanced/Lowlevel lists but General/Deriving, not in PthariensFlame?'s list) DerivingStrategies? (Limperg advanced, Beardsley's "More complex, but well understood" list, not in 24 Days of GHC Extensions; Diehl doesn't list general/specialized (but it's Diehl Benign)) FlexibleContexts? (not in PthariensFlame?'s list; is in RWH) FlexibleInstances? (not in PthariensFlame?'s list; is in RWH) GADTs (advanced in Limperg, both benign and advanced in Diehl, "More complex, but well understood" in Beardsley; also in 24 Days of GHC Extensions) GeneralizedNewtypeDeriving? (not in PthariensFlame?'s list; is in RWH) LambdaCase? (not in 24 Days of GHC Extensions) MultiParamTypeClasses? OverloadedStrings? RankNTypes? (advanced and specialized in Diehl; Limperg lists as Basic but only b/c it's required for the ST monad) ScopedTypeVariables? (Diehl 'specialized') TupleSections? (not in 24 Days of GHC Extensions) TypeApplications? (advanced and specialized in Diehl, not in PthariensFlame?'s list, not in 24 Days of GHC Extensions)

This is identical to the top 18 items in the https://taylor.fausak.me/2020/11/22/haskell-survey-results/#s2q5, except that that list includes DerivingVia? and my list does not.

The stats of the lowest item on that list (TupleSections?) are +37% -4%. The stats of the next item below it (DataKinds?) are +35% -7%. It's not that surprising that this is the 33% threshold b/c that's what i used above in making the tiers. However, that cutoff did fit in nicely with my analysis of the most basic and widely recommended extensions so I don't think it's totally arbitrary.

i wrote the following in plChHaskell:

The following extensions are within the top 18 items and are >= net 33% in the 2020 Haskell survey poll, and are in the top 22 items and are >= 15% in the 2019 Haskell survey poll, and are rated as Basic in https://limperg.de/ghc-extensions/, and are rated as Benign or General in http://dev.stephendiehl.com/hask/#language-extensions, and are rated as 'Use at will' on https://gist.github.com/mightybyte/6c469c125eb50e0c2ebf4ae26b5adfff , and are on the list of default extensions in https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/ , and are in at least one of https://www.schoolofhaskell.com/user/PthariensFlame/guide-to-ghc-extensions, https://ocharles.org.uk/pages/2014-12-01-24-days-of-ghc-extensions.html:

The following extensions are within the top 18 items and are >= net 33% in the 2020 Haskell survey poll, and are in the top 22 items and are >= 15% in the 2019 Haskell survey poll, and are rated as Basic or Advanced in in https://limperg.de/ghc-extensions/, and are rated as Benign or General or Advanced or Lowlevel in http://dev.stephendiehl.com/hask/#language-extensions, and are rated as 'Use at will' or "More complex, but well understood" on https://gist.github.com/mightybyte/6c469c125eb50e0c2ebf4ae26b5adfff , and are on the list of default extensions in https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/ , and are in at least one of https://www.schoolofhaskell.com/user/PthariensFlame/guide-to-ghc-extensions, https://ocharles.org.uk/pages/2014-12-01-24-days-of-ghc-extensions.html except as noted:

The union of the previous two lists is 17 items. The only extension in the top 18 items or with >= net 33% of the 2020 Haskell survey poll but not on either of these two lists is DerivingVia?.

---

in summary, i should look at/use the following 17 extensions with Haskell:

BangPatterns? DeriveFoldable? DeriveFunctor? DeriveGeneric? DeriveTraversable? LambdaCase? OverloadedStrings? FlexibleContexts? FlexibleInstances? GeneralizedNewtypeDeriving? MultiParamTypeClasses? ScopedTypeVariables? TupleSections?

advanced: DerivingStrategies? GADTs RankNTypes? TypeApplications?

after those, look at DerivingVia?, and then the ones between 20% and 33% net in the 2020 haskell survey:

DataKinds? KindSignatures? TypeFamilies? StandaloneDeriving? MultiWayIf? DeriveDataTypeable? ConstraintKinds? TypeOperators? ViewPatterns? InstanceSigs? DeriveLift? NumericUnderscores?

https://www.google.com/search?q=BangPatterns+DeriveFoldable+DeriveFunctor+%22DeriveGeneric%22+DeriveTraversable+%22LambdaCase%22+%22OverloadedStrings%22+FlexibleContexts+FlexibleInstances+GeneralizedNewtypeDeriving+MultiParamTypeClasses+ScopedTypeVariables+TupleSections+DerivingStrategies+GADTs+RankNTypes+TypeApplications doesn't turn up anything new (in the first 2 pages)

and in the future, just looking at the extensions with net 33%+ (2020; in 2019 the threshold would have been 20%) in the annual Haskell Survey is probably good enough. This is also interesting from a governance perspective; it adds weight to the idea that a procedure where a score -1/0/1 vote of 20%, 25%, or 33%+ is how things should be added to an agenda.

---

https://www.freepascal.org/docs-html/current/rtl/crt/index-5.html

---

https://janet-lang.org/api/index.html

---

btw looks like mutt is written in C and uses curses

https://en.wikipedia.org/wiki/Text-based_user_interface mentions curses, ncurses, newt, cdk

https://www.google.com/search?q=curses+ncurses+%22newt%22+cdk and some of those links also mention DIALOG, PDCurses, SMG$, Turbo Vision, early versions of visual basic (for DOS)

google suggests that the following subset is most popular: "curses" "ncurses" "newt" "cdk" "DIALOG"

and out of those: "ncurses" "newt" "cdk" "DIALOG"

on wikipedia, those pages also lead to: s-lang conio.h whiptail (related to Newt) zenity

note:

https://www.linuxquestions.org/questions/linux-software-2/is-there-a-library-for-creating-console-dialog-boxes-in-c-program-4175596822/ says: "is there a software library that can be used in a C program for creating dialog boxes in console without graphical environment (that is, not zenity or dialog)"... so i guess DIALOG is out? but i think that's incorrect; https://en.wikipedia.org/wiki/Dialog_(software) suggests no graphical environ is needed? i think zenity is gtk tho.

conio and whiptail aren't commonly mentioned on google. So mb:

"ncurses" "newt" "cdk" "DIALOG" "slang"

on slang vs ncurses: https://invisible-island.net/ncurses/ncurses-slang.html

https://www.opensourceforu.com/2011/11/spicing-up-console-for-fun-profit-2/

https://invisible-island.net/dialog/ says "Though similar in style to CDK, it is different, being a script-interpreter which provides a set of curses widgets. Widgets are objects whose appearance and behavior can be customized. There is a much-reduced variation of dialog, called lxdialog, which is used in Linux kernel configuration."

https://en.wikipedia.org/wiki/Dialog_(software) says "One might also consider lxdialog (part of menuconfig), except that it has been reduced to fragments that can no longer run dialog scripts. There are several programs inspired by dialog; not all read the same scripts. The most well-known are Xdialog and whiptail. "

https://linux.slashdot.org/story/01/05/09/0732219/developing-attractive-non-gui-apps-for-unix asks for GUI libs for POS systems and mentions (only comments with 3+ score):

picogui isn't as popular and elisp is obviously a different kind of solution. So we didn't add anything. So we're still at:

"ncurses" "newt" "cdk" "DIALOG" "slang"

https://www.opensourceforu.com/2011/11/spicing-up-console-for-fun-profit-2/ mentions newt and ncurses and also cdk, NDK++. It mentions that newt depends on slang. Dialog is also mentioned.

toread: https://www.opensourceforu.com/2011/11/spicing-up-console-for-fun-profit-2/

"Only a few well-known applications have been developed which could use either ncurses or slang. I have been involved with Lynx, Mutt and Midnight Commander. Most of the early discussion mentions the possibility of others, but provides no useful examples." -- https://invisible-island.net/ncurses/ncurses-slang.html

https://www.google.com/search?q=%22ncurses%22+%22newt%22+%22cdk%22++%22DIALOG%22+%22slang%22

this guy (Thomas E. Dickey) is involved with ncurses, cdk, dialog, and knows a lot about slang:

https://invisible-island.net/

https://invisible-island.net/ncurses/ncurses-slang.html has a table listing all of the ncurses and slang library functions used by each of 3 programs that can use either ncurses or slang: Lynx, Mutt and Midnight Commander. The table is: https://invisible-island.net/ncurses/ncurses-slang.html#symbol_usage . The rest of the page has a detailed discussion of some architectural differences and their history between ncurses and slang.

https://en.wikipedia.org/wiki/Newt_(programming_library) says that newt "also contains the shared library needed by programs built with newt, as well as an application whiptail, which provides the most commonly used features of dialog. Newt is based on the slang library. It abbreviates from Not Erik's Windowing Toolkit. "

" From the Linux Dictionary: whiptail is a "dialog" replacement using newt instead of ncurses. From its README: whiptail is designed to be drop-in compatible with dialog(1), but has fewer features: some dialog boxes are not implemented, such as tailbox, timebox, calendarbox, etc." [1]

So it looks like:

so:

---

just copying from https://invisible-island.net/ncurses/ncurses-slang.html#symbol_usage to here, and removing the other columns in each table (which are useful!), we have, in alphabetic order (note: better to browse the original page, b/c it has hyperlinks to ncurses docs):

curses/ncurses symbols COLORS COLS ESCDELAY LINES acs_map assume_default_colors baudrate beep cbreak clearok curs_set curses_version def_prog_mode define_key delscreen delwin derwin doupdate echo endwin flushinp getmouse has_colors init_pair initscr is_wintouched isendwin key_defined keypad meta mouseinterval mousemask napms newpad newterm newwin nl nocbreak nodelay noecho nonl noraw pair_content pnoutrefresh printw raw reset_prog_mode reset_shell_mode resizeterm scrollok start_color stdscr tgetstr tigetflag tigetstr typeahead ungetmouse use_default_colors use_extended_names use_legacy_coding vwprintw wadd_wch waddch waddnstr wattr_get wattr_off wattr_on wbkgd wbkgdset wborder wclear wclrtobot wclrtoeol werase wgetch whline wmove wnoutrefresh wrefresh wresize wtimeout wtouchln wvline Total: 83

slang symbols SLang_TT_Baud_Rate SLang_TT_Read_FD SLang_Version SLang_create_keymap SLang_do_key SLang_exit_error SLang_flush_input SLang_get_error SLang_getkey SLang_init_tty SLang_input_pending SLang_reset_tty SLang_undefine_key SLcurses_cbreak SLcurses_clearok SLcurses_delwin SLcurses_endwin SLcurses_getch SLcurses_has_colors SLcurses_initscr SLcurses_newwin SLcurses_nil SLcurses_printw SLcurses_start_color SLcurses_waddch SLcurses_waddnstr SLcurses_wattrset SLcurses_wclear SLcurses_wclrtobot SLcurses_wclrtoeol SLcurses_wmove SLcurses_wrefresh SLexpand_escaped_string SLkm_define_keysym SLsignal SLsmg_Display_Eight_Bit SLsmg_draw_box SLsmg_draw_hline SLsmg_draw_object SLsmg_draw_vline SLsmg_erase_eol SLsmg_erase_eos SLsmg_fill_region SLsmg_forward SLsmg_get_column SLsmg_get_row SLsmg_gotorc SLsmg_init_smg SLsmg_normal_video SLsmg_refresh SLsmg_reinit_smg SLsmg_reset_smg SLsmg_resume_smg SLsmg_set_char_set SLsmg_set_color SLsmg_suspend_smg SLsmg_touch_lines SLsmg_touch_screen SLsmg_vprintf SLsmg_write_char SLsmg_write_nstring SLsmg_write_string SLtt_Blink_Mode SLtt_Has_Alt_Charset SLtt_Ignore_Beep SLtt_Screen_Cols SLtt_Screen_Rows SLtt_Try_Termcap SLtt_Use_Ansi_Colors SLtt_add_color_attribute SLtt_beep SLtt_flush_output SLtt_get_screen_size SLtt_get_terminfo SLtt_set_color SLtt_set_color_object SLtt_set_cursor_visibility SLtt_set_mono SLtt_set_mouse_mode SLtt_tgetnum SLtt_tgetstr SLtt_write_string SLtty_set_suspend_state SLutf8_enable SLvsnprintf Total: 85

just the subset used by all 3 of the applications lynx, mutt, mc:

curses/ncurses symbols: cbreak clearok endwin has_colors init_pair keypad noecho start_color resizeterm use_default_colors waddch waddnstr wgetch wmove wrefresh

slang symbols: SLsmg_init_smg SLsmg_reset_smg SLtt_set_color

just the subset used by exactly 2 of the applications lynx, mutt, mc:

curses/ncurses symbols: beep curses_version doupdate flushinp initscr meta napms scrollok tigetstr wbkgdset wclear wclrtoeol wtouchln

slang symbols: SLang_getkey SLang_init_tty SLang_input_pending SLang_reset_tty SLsmg_fill_region SLsmg_get_column SLsmg_get_row SLsmg_gotorc SLsmg_refresh SLsmg_resume_smg SLsmg_set_color SLsmg_touch_lines SLsmg_write_char SLtt_add_color_attribute SLtt_beep SLtt_get_screen_size SLtt_get_terminfo SLtt_set_mono SLutf8_enable

---

dopu 1 day ago [–]

I'm a graduate student that's switched almost completely over to Julia. Prior to it I worked in both MATLAB (the IDE is so nice, and writing out matrix computations is just great) and Python (for ML). Julia is absolutely nicer to write in than either of the two. MATLAB is slow and at times feels less like a programming language and more like an incomplete and brittle interface with the JVM. Python is also slow, and it feels awkward to use given that it was not explicitly designed for scientific workflows. With Julia I get proper typing, incredible speed, easy parallelization, and a kick ass REPL.

The only thing I truly miss in using Julia is the plotting capacities of MATLAB. I haven't found an environment that can match it in terms of interactivity. Give me the ability to (easily) save interactive figures for later use and Julia would be perfect.

reply

darsnack 2 hours ago [–]

You should check out Makie. Getting it set up can be a bit frustrating if things don’t go right, and there is a small learning curve for using `@lift`, but it is an absolute joy to use once you ramp up.

I use it for my research by default. You can pan, zoom, etc. The subplot/layout system is frankly a lot better than Matlab (and I enjoyed Matlab for plotting!). The best part is that I can insert sliders and drop downs into my plot easily, which means I don’t need to waste time figuring out the best static, 2D plot for my experiment. I just dump all the data into some custom logging struct and use sliders to index into the correct 2D plot (e.g. a heat map changing over time, I just save all the matrices and use the slider to get the heat map at time t).

reply

superdimwit 1 day ago [–]

I would recommend Plotly.js in VSCode for interactive plotting.

reply

dopu 1 day ago [–]

Wow, I just tried it out. This is really great. And it solves my interactive plot saving requirement. Easy as doing `Plotly.savehtml(fig, "test_fig.html")` :). Thanks!

reply

skybrian 20 hours ago [–]

Could you elaborate? I see that Plotly.js is a JavaScript? library, but is there special integration with VSCode?

reply

superdimwit 19 hours ago [–]

yes, it integrates with the VSCode plotting pane. Not exactly sure where this happens, though.

reply

StefanKarpinski? 1 day ago [–]

Out of curiosity, have you tried using Plots.jl from VS Code? If so, what's missing from that experience?

reply

dopu 1 day ago [–]

I have, though I've mostly stuck with the plain PyPlot?.jl package due to the familiar syntax and interactivity. Perhaps things have changed, but I just recall being frustrated at the inability to zoom in/out, and again save interactive figs. Perhaps it was just due to the particular backend I was using. I'll give the VS Code experience another try!

reply

---

tui design references:

discussions:

lists:

turbovision library is often mentioned favorably

Tui ideas:

---

tui library lists:

https://news.ycombinator.com/item?id=24412687

---

picotui

https://community.hiveeyes.org/t/picotui-a-text-user-interface-tui-widget-toolkit-for-micropython/2652

---

https://github.com/vinibiavatti1/TuiCss

---

https://blog.ironmansoftware.com/tui-powershell/

---

" Programmers used to languages that did go through careful, deliberate design brought some of it to Emacs Lisp: Package For working with a.el alists, hash tables, and vectors dash.el lists f.el files ht.el hash tables map.el alists, hash tables, and arrays s.el strings seq.el sequences " [2]

---

bemmu 12 hours ago [–]

    mov ax, 13h
    int 10h

The two most important lines of asm for any teen trying to emulate their demoscene heroes.

reply

http://jlp.freeservers.com/mode13h/

---

https://www.willmcgugan.com/blog/tech/post/building-rich-terminal-dashboards/

---

https://github.com/tiangolo/typer

---

781 on Apr 27, 2019

parent favorite on: Could ImGUI? Be the Future of GUIs?

It's important to point out why games use immediate mode GUIs:

1. The GUI needs to be overlaid on the game image (OpenGL?/DirectX?). This is difficult with traditional GUIs like QT.

2. The GUI needs to be updated in sync with the game, again, it's difficult to integrate traditional GUIs event loops into the game loop, especially with stuff like double/triple buffering.

3. The GUI needs to be as fast as possible, games are severely CPU bound.

A retained mode GUI is typically easier to use, convenience is not why people use immediate mode GUIs.

It's worth pointing out that the immediate/retained split doesn't apply only to the GUI - there are retained mode graphical APIs - DirectX? used to have one. They are only used in low-demand games, they sacrifice a lot of speed for the convenience of using a retained mode.

invokestatic on Apr 27, 2019 [–]

I've written real-time game UIs before so I think I have some relevant experience here.

1. It is very possible to write a retained-mode GUI in a graphics API like DirectX? or OpenGL?. In fact, a retained GUI would typically wipe immediate GUIs in terms of performance in this context. In immediate mode, the GUI's vertex buffers need to be completely reconstructed from scratch every single frame, which is slow, CPU bound, and cannot be (easily) parallelized. It's like reconstructing the game world every frame -- that would be ludicrous for any non-trivial game.

2. I don't think there would be that much of a difference between the two UI models, since data updates can be dispatched from the event loop. It would be faster, too, because only UI components that need updating could be redrawn. This is far faster than updating the entire UI every single frame.

3. As mentioned earlier, immediate mode GUIs are going to be a lot slower than retained mode, when implemented properly. Immediate mode GUIs put most of the work on the CPU instead of offloading most of the work to the GPU like in the retained model.

I think developers that are using immediate mode GUIs are doing so because of their ease of use. I think retained mode is typically harder for a game developer to conceptualize because immediate mode is conceptually similar to a game loop. Also, I don't know of any free & open source retained mode GUIs for DirectX? and OpenGL? and the like.

Also, DirectX? at least (and probably OpenGL?) encourages a retained-like model for general rendering. The only way to get decent performance is to re-use vertex buffers between frames and only update them when something changes.

---

https://blog.wesleyac.com/posts/timezone-bullshit

---

https://www.arp242.net/go-easy.html

https://news.ycombinator.com/item?id=26220921

---

https://ahgamut.github.io/c/2021/02/27/ape-cosmo/

---

https://c4core.docsforge.com/ c4core - C++ core utilities

MIT Licensed

c4core is a library of low-level C++ utilities, written with low-latency projects in mind.

---

https://github.com/git/git/blob/master/banned.h

drfuchs 3 hours ago [–]

It would be nice if the error messages generated would suggest replacement functions that they deem appropriate. I see that I'm not supposed to use gmtime, localtime, ctime, ctime_r, asctime, and asctime_r; but what do they think I should use?

reply

cle 3 hours ago [–]

From the commit messages

> The ctime_r() and asctime_r() functions are reentrant, but have no check that the buffer we pass in is long enough (the manpage says it "should have room for at least 26 bytes"). Since this is such an easy-to-get-wrong interface, and since we have the much safer strftime() as well as its more convenient strbuf_addftime() wrapper, let's ban both of those.

(https://github.com/git/git/commit/91aef030152d121f6b4bc3b933...)

> The traditional gmtime(), localtime(), ctime(), and asctime() functions return pointers to shared storage. This means they're not thread-safe, and they also run the risk of somebody holding onto the result across multiple calls (where each call invalidates the previous result). All callers should be using their reentrant counterparts.

(https://github.com/git/git/commit/1fbfdf556f2abc708183caca53...)

reply

tinus_hn 2 hours ago [–]

Strangely there is no mention of strtok which has a similar issue.

reply

https://github.com/git/git/commit/c8af66ab8ad7cd78557f0f9f5ef6a52fd46ee6dd

 automatically ban strcpy()

There are a few standard C functions (like strcpy) which are easy to misuse. E.g.:

  char path[PATH_MAX];
  strcpy(path, arg);

may overflow the "path" buffer. Sometimes there's an earlier constraint on the size of "arg", but even in such a case it's hard to verify that the code is correct. If the size really is unbounded, you're better off using a dynamic helper like strbuf:

  struct strbuf path = STRBUF_INIT;
  strbuf_addstr(path, arg);

or if it really is bounded, then use xsnprintf to show your expectation (and get a run-time assertion):

  char path[PATH_MAX];
  xsnprintf(path, sizeof(path), "%s", arg);

which makes further auditing easier.

captainmuon 3 hours ago [–]

It would be interesting to see the rationale behind these bans, and what the suggested alternatives are. Some are obvious, like `strcpy`, but I can't remember what the problem with `sprintf` or the time functions are.

If you are doing something like `sprintf(buffer, "%f, %f", a, b)`, yes it is tricky to choose the size of buffer frugally, but if you replace that by `ftoa` and constructing the string by hand, you are likely to introduce more bugs.

Edit: as pointed out in another post, you can do git blame to see the rationale for each ban, quite interesing.

reply

Aanok 3 hours ago [–]

The trouble with printf-family functions is their variadic nature. If the arguments don't match the format string, you can wreak all sorts of havoc.

A fun exercise you can do is put a "%s" in the format string, omit the string argument and see what happens to the stack.

reply

anyfoo 3 hours ago [–]

That's however relatively easy to verify programmatically, and indeed any recent compiler will complain about that.

I'd say the usual trap is rather the size of the target buffer, because that requires bigger static analysis guns. (I'm ignoring things like "%n", because then you're playing with fire already.)

reply

Gibbon1 2 hours ago [–]

I think the big three C compilers have pragma's that you can tag printf/scanf with that will cause the compiler to verify the argument list.

reply

xxpor 27 minutes ago [–]

__attribute__((format(printf, x, y))) for GCC:

https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attribut...

There's options other than printf too.

reply

danaliv 3 hours ago [–]

There's that, but with sprintf/vsprintf specifically, there's no way to keep it from storing characters past the end of your buffer. For example:

    char buf[2];
    sprintf(buf, "%d", n);

This will happily write to buf[2] and beyond if n is negative or greater than 9.

reply

dahfizz 3 hours ago [–]

This was my reaction as well. Banning strncpy just encourages haphazard manual copying.

reply

smasher164 3 hours ago [–]

From the commit message:

If you're thinking about using it, consider instead:

reply

nwmcsween 2 hours ago [–]

strlcpy is safer but effectively running strlen(src) every call is a good wtf

reply

asdfasgasdgasdg 3 hours ago [–]

I think you're meant to use snprintf instead. It would be great to see documentation on the alternatives!

reply

azurezyq 3 hours ago [–]

maybe this https://github.com/git/git/blob/master/strbuf.h ?

reply

syncsynchalt 1 hour ago [–]

strncpy doesn't do what you think it does (it is not analogous to strncat). strncpy does not terminate strings on overflow. In C terms, it is not actually a string function and shouldn't be named with `str`.

snprintf or nul-plus-strncat do what you want, but snprintf has portability problems on overflow. Most projects I've been on rely on strlcpy (with a polyfill implementation where not available).

reply

ben_bai 3 hours ago [–]

strlcpy is the safe way, that is used by git.

reply

monocasa 3 hours ago [–]

snprintf will always terminate the string, and won't overflow the buffer.

reply

SloopJon? 2 hours ago [–]

sprintf() warnings have gotten pretty sophisticated these days. I discovered GCC's -Wformat-overflow the other day. It complained that the buffer for a date string wasn't big enough; e.g., sprintf(buf, "%04d-%02u-%02u", year, month, day), where year, month, and day are 16-bit shorts, and buf was probably eleven or twelve bytes.

It may actually be a bug that I got the warning, because the range of each input was checked, and I think the compiler is supposed to be smart enough to remember that.

reply

attractivechaos 3 hours ago [–]

I wonder how they copy strings with strcpy and strncpy both banned. strlcpy? But it is not conforming to major standards. Or just memcpy with extra code?

reply

dgentile 3 hours ago [–]

Edited: Looks like they have safe alternatives: "

reply

lights0123 3 hours ago [–]

https://github.com/git/git/commit/e488b7aba743d23b830d239dcc... Yes:

> we provide a compat version, so it's always available

reply

attractivechaos 3 hours ago [–]

This gets me interested. Link [1] below shows their implementation of strlcpy(). This is a questionable implementation. With strncpy, the source string "src" may not be NULL terminated IIRC. The git implementation requires "src" to be NULL terminated. If not, an invalid read. EDIT: according to the strlcpy manpage [2], "src" is required to be NULL terminated, so strlcpy imposes more restrictions and is not a proper replacement of strncpy.

Furthermore, imagine "src" has 1Mb characters but we only want to copy the first 3 chars. The git implementation would traverse the entire 1Mb to find the length first, but a proper implementation only needs to look at the first 3 chars. So, they banned strncpy and provided a worse solution to that.

[1]: https://github.com/git/git/blob/master/compat/strlcpy.c

[2]: https://linux.die.net/man/3/strlcpy

reply

kzrdude 2 hours ago [–]

You have found the answer - strlcpy is not a replacement for strncpy at all (it's arguably a safer version of strcpy), and git people didn't invent this, it's the existing BSD strlcpy interface.

reply

attractivechaos 2 hours ago [–]

Thanks for the confirmation. But my concern remains: they banned strncpy without a proper replacement. In addition, I didn't know the extra restriction of strlcpy until today (I have never used it before because it is not conforming to C99/POSIX). I might have fallen into this trap.

reply

notaplumber 2 hours ago [–]

The problem is the actually often the opposite, in the real world many treat strncpy as if it behaves like strlcpy. Note that strlcpy is equivalent to:

    snprintf(buf, sizeof(buf), "%s", string);

strlcpy is on track for future standardization in POSIX, for Issue 8, but even as a de facto standard, it exists in libc on *BSD, macOS, Android, Solaris, QNX, and even Linux using musl.

https://www.austingroupbugs.net/view.php?id=986#c5050

But you're correct in that it is not a replacement for strncpy because no code should be using strncpy.

reply

alcover 2 hours ago [–]

Agreed. It's O(n) inefficient. I guess looping though chars up to `size` would perform better on average.

I see this `strlcpy` recommanded everywhere.

reply

attractivechaos 1 hour ago [–]

A few days ago people here were discussing the quadratic sscanf() behavior. strlcpy() has the same problem.

reply

tedunangst 2 hours ago [–]

Take a step back and consider strlcpy isn't supposed to be a drop in replacement for strncpy (a function which already exists).

reply

syncsynchalt 1 hour ago [–]

strncpy is a dangerous function because it doesn't nul terminate on overflow. The danger is that it's named misleadingly (str* functions otherwise always work in nul-terminated strings).

(strcpy is just banned because there's no bounds check, and they want to force use of strlcpy instead).

reply

EdSchouten? 3 hours ago [–]

Funnily enough, strtok() is not listed :)

reply

raegis 1 hour ago [–]

This one has my vote for the weirdest library function ever.

reply

rightbyte 53 minutes ago [–]

The storing of state between calls is beautiful in all its wickedness.

reply

reply

abetusk 2 hours ago [–]

The Git Mailing List Archive on lore.kernel.org (found in the README from the git mirror on GitHub?) has more context [0] [1] [2]. From Jeff King on 2018-07-24:

  The strncpy() function is less horrible than strcpy(), but
  is still pretty easy to misuse because of its funny
  termination semantics. Namely, that if it truncates it omits
  the NUL terminator, and you must remember to add it
  yourself. Even if you use it correctly, it's sometimes hard
  for a reader to verify this without hunting through the
  code. If you're thinking about using it, consider instead:

I just did a search on the keywords 'banned' and 'strncpy' [2]

[0] https://lore.kernel.org/git/20180724092828.GD3288@sigill.int...

[1] https://lore.kernel.org/git/20190103044941.GA20047@sigill.in...

[2] https://lore.kernel.org/git/20190102093846.6664-1-e@80x24.or...

[3] https://lore.kernel.org/git/?q=banned+strncpy

reply

js2 2 hours ago [–]

Psst:

https://github.com/git/git/commits/master/banned.h

(Git development is done by emailing patches. Those patches include the git commit message, which we can see just by looking at the history of the file. Sometimes there's additional discussion on the ML, but the most important details are in the commit message because the git development team is very disciplined about that.)

reply

abetusk 1 hour ago [–]

Ha, yep, whoops

reply

1337_d00dZ 1 hour ago [–]

In compilers that implement GCC extensions (such as Clang), you can use the "poison" directive to achieve the same effect (but with a better error message):

  1. pragma GCC poison printf sprintf fprintf

[0] https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/Pragmas.html

reply

alexchamberlain 3 hours ago [–]

All the string functions have buffer overrun vulnerabilities if not used carefully. I'm not sure about the time functions though.

reply

edflsafoiewq 3 hours ago [–]

The time functions are either non-reentrant, or, for the _r versions, have the same problem with buffer overruns.

https://github.com/git/git/commit/1fbfdf556f2abc708183caca53...

https://github.com/git/git/commit/91aef030152d121f6b4bc3b933...

reply

trilinearnz 3 hours ago [–]

Very much this. I frequently write small games in C, and the number of times I have been bitten by baffling behaviour because a string somewhere was copied into an array that was too short, are many! Apart from that, I love the simplicity of the language and the stdlib, and it's definitely my preferred hobby programming environment.

It would be good to know what the commonly-accepted alternatives are.

reply

csours 3 hours ago [–]

I'm pretty sure you could google each of these with the word 'dangerous'

For example: https://lgtm.com/rules/2154840805/

reply

---

https://discourse.haskell.org/t/towards-a-prevalent-alternative-prelude/1986

---

(neo)mutt format strings:

" 29. Format Strings

29.1. Basic usage

Format strings are a general concept you'll find in several locations through the NeoMutt? configuration, especially in the $index_format, $pager_format, $status_format, and other related variables. These can be very straightforward, and it's quite possible you already know how to use them.

The most basic format string element is a percent symbol followed by another character. For example, %s represents a message's Subject: header in the $index_format variable. The “expandos” available are documented with each format variable, but there are general modifiers available with all formatting expandos, too. Those are our concern here.

Some of the modifiers are borrowed right out of C (though you might know them from Perl, Python, shell, or another language). These are the [-]m.n modifiers, as in %-12.12s. As with such programming languages, these modifiers allow you to specify the minimum and maximum size of the resulting string, as well as its justification. If the “-” sign follows the percent, the string will be left-justified instead of right-justified. If there's a number immediately following that, it's the minimum amount of space the formatted string will occupy – if it's naturally smaller than that, it will be padded out with spaces. If a decimal point and another number follow, that's the maximum space allowable – the string will not be permitted to exceed that width, no matter its natural size. Each of these three elements is optional, so that all these are legal format strings: %-12s, %4c, %.15F and %-12.15L.

NeoMutt? adds some other modifiers to format strings. If you use an equals symbol (=) as a numeric prefix (like the minus above), it will force the string to be centered within its minimum space range. For example, %=14y will reserve 14 characters for the %y expansion – that's the set of message keywords (formerly X-Label). If the expansion results in a string less than 14 characters, it will be centered in a 14-character space. If the X-Label for a message were “test”, that expansion would look like “     test     ”.

There are two very little-known modifiers that affect the way that an expando is replaced. If there is an underline (“_”) character between any format modifiers (as above) and the expando letter, it will expands in all lower case. And if you use a colon (“:”), it will replace all decimal points with underlines. " -- (neo)mutt manual

---

.NET Framework is the old, Windows-specific one .NET Core is the new, portable one .NET Standard is the intersection between .NET Framework and .NET Core

---

https://tailscale.com/blog/netaddr-new-ip-type-for-go/