reflex-frp / reflex-frp.org Goto Github PK

We currently have a bunch of stuff in reflex-platform that stack users need to replicate in order to get a working setup. We should do something about this.

• For anything we're overriding, provide instructions, a stack yaml file, a stack resolver, or something like that; ideally, this should be generated automatically from the nix files so that it stays current
• Upstream as much as possible into nixpkgs, dependencies, etc.

This should be a package in lib with two main things:

1. A nix function that takes a single high-res input image and produces appropriate favicons for every platform
2. A Haskell function that emits many link tags referring to all those favicons.

Note that we will need to figure out a way to integrate this into the static asset pipeline.

SkillsMatter has this talk behind a log-in link: https://skillsmatter.com/skillscasts/12637-the-gonimo-architecture

Currently, all our talks are on youtube, so we'll need to modify the code slightly to integrate with the skillsmatter site.

@eskimor Just mentioning you here - probably best to let someone else in the community do the change, though (it's marked "good first issue")

Steps to reproduce:

1. Go to http://reflex-frp.org/
2. Click "Tutorials"
3. Click "reflex-dom-inbits"
4. Click your browser's back button

Actual results:

No handler accepted "/tutorials"

Expected results: I should see the tutorials page again.

The reflex-frp.org website contains a few broken links.

More specifically..

• The Server-Side Rendering refers to an example that 404s
• The DOM Input Elements Section refers to an input_widgets.hs, which also 404s

Is there still room for apps:

http://hexplore.mightybyte.net/
https://gitlab.com/mightybyte/hexplore/

For sure links are to be there but I guess there should be something else?
Probably reflex examples?
Probably some docs like reflex platform README?

From IRC: liftJSM $ eval ("console.log('a message to be shown at the console of a browser')")

It is sometimes handy and might fit in as another method at debugging/functionality.

Is there any chances to extend the example so that it would also show, how to apply the delay,
at hang-stack-overflow-section?

The delay eats NominalDiffTime and it is not outright obvious, what value it should be given.

I had a this kind of situation, where ev2 <- delay 0 ev1 worked and was required. The runtime errors at ghci referred to "bag -problems in Spider/Internal" and once to "ghc loop" when I was doing changes / trying to find a working combination.

So,

• If there are typical symptons that can be seen, say in ghci, maybe mention those?
• Is it possible to describe, why the given example needs delay? I mean, why the rec-block isn't enough as such as shown at the moment?
• What parameter to give to delay? Is 0 ok?

BTW: it seems that those delays area needed every now and then. If 0 is ok and enough in this kind of situations, is there room for frameDelay = delay 0 in the reflex-lib? (With the idea that it wouldn't confuse the user? The proposed name here probably isn't good.)

Right now, this link is broken. We should change it so that it is http://reflex-frp.org#tutorials instead. Also, in the case of home, there should be no fragment at all.

The header links as currently deployed are broken

I'm getting an error when I try to build this package:

Configuring linux-namespaces-0.1.3.0...
Dependency base >=4.6 && <5: using base-4.11.1.0
Dependency bytestring >=0.10: using bytestring-0.10.8.2
Dependency unix >=2.6: using unix-2.7.2.2
Namespaces.hsc:79:16: error: use of undeclared identifier 'CLONE_NEWIPC'
    hsc_const (CLONE_NEWIPC);
               ^
Namespaces.hsc:79:16: error: use of undeclared identifier 'CLONE_NEWIPC'
Namespaces.hsc:79:16: error: use of undeclared identifier 'CLONE_NEWIPC'
Namespaces.hsc:80:16: error: use of undeclared identifier 'CLONE_NEWNET'
    hsc_const (CLONE_NEWNET);
               ^
Namespaces.hsc:80:16: error: use of undeclared identifier 'CLONE_NEWNET'
Namespaces.hsc:80:16: error: use of undeclared identifier 'CLONE_NEWNET'
Namespaces.hsc:81:16: error: use of undeclared identifier 'CLONE_NEWNS'
    hsc_const (CLONE_NEWNS);
               ^
Namespaces.hsc:81:16: error: use of undeclared identifier 'CLONE_NEWNS'
Namespaces.hsc:81:16: error: use of undeclared identifier 'CLONE_NEWNS'
Namespaces.hsc:82:16: error: use of undeclared identifier 'CLONE_NEWPID'
    hsc_const (CLONE_NEWPID);
               ^
Namespaces.hsc:82:16: error: use of undeclared identifier 'CLONE_NEWPID'
Namespaces.hsc:82:16: error: use of undeclared identifier 'CLONE_NEWPID'
Namespaces.hsc:83:16: error: use of undeclared identifier 'CLONE_NEWUSER'
    hsc_const (CLONE_NEWUSER);
               ^
Namespaces.hsc:83:16: error: use of undeclared identifier 'CLONE_NEWUSER'
Namespaces.hsc:83:16: error: use of undeclared identifier 'CLONE_NEWUSER'
Namespaces.hsc:84:16: error: use of undeclared identifier 'CLONE_NEWUTS'
    hsc_const (CLONE_NEWUTS);
               ^
Namespaces.hsc:84:16: error: use of undeclared identifier 'CLONE_NEWUTS'
Namespaces.hsc:84:16: error: use of undeclared identifier 'CLONE_NEWUTS'
18 errors generated.
compiling dist/build/System/Linux/Namespaces_hsc_make.c failed (exit code 1)
command was: /nix/store/2gdwhdzhy4iwkp7fh8v6gy6nxj1zi9pv-clang-wrapper-5.0.2/bin/clang -c dist/build/System/Linux/Namespaces_hsc_make.c -o dist/build/System/Linux/Namespaces_hsc_make.o -fno-stack-protector -fno-stack-protector -D__GLASGOW_HASKELL__=804 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -I/nix/store/qjmqrzk8nhn5maa093fhl3finczz72lw-libc++-5.0.2/include -I/nix/store/jd065p28z3ar0q6nljz479f9mm35v5qn-libc++abi-5.0.2/include -I/nix/store/llafcziny4071gkahynh9348yqfwvych-compiler-rt-5.0.2-dev/include -I/nix/store/567l21pfpvjb3lr5c6hgshasn589raal-libiconv-osx-10.11.6/include -I/nix/store/qjmqrzk8nhn5maa093fhl3finczz72lw-libc++-5.0.2/include -I/nix/store/jd065p28z3ar0q6nljz479f9mm35v5qn-libc++abi-5.0.2/include -I/nix/store/llafcziny4071gkahynh9348yqfwvych-compiler-rt-5.0.2-dev/include -I/nix/store/567l21pfpvjb3lr5c6hgshasn589raal-libiconv-osx-10.11.6/include -Idist/build/autogen -Idist/build/global-autogen -include dist/build/autogen/cabal_macros.h -I/nix/store/450ic2j8nbnl6jyjw10cihmj2ka0xvq1-ghc-8.4.3/lib/ghc-8.4.3/unix-2.7.2.2/include -I/nix/store/450ic2j8nbnl6jyjw10cihmj2ka0xvq1-ghc-8.4.3/lib/ghc-8.4.3/time-1.8.0.2/include -I/nix/store/450ic2j8nbnl6jyjw10cihmj2ka0xvq1-ghc-8.4.3/lib/ghc-8.4.3/bytestring-0.10.8.2/include -I/nix/store/567l21pfpvjb3lr5c6hgshasn589raal-libiconv-osx-10.11.6/include -I/nix/store/450ic2j8nbnl6jyjw10cihmj2ka0xvq1-ghc-8.4.3/lib/ghc-8.4.3/base-4.11.1.0/include -I/nix/store/450ic2j8nbnl6jyjw10cihmj2ka0xvq1-ghc-8.4.3/lib/ghc-8.4.3/include -I/nix/store/450ic2j8nbnl6jyjw10cihmj2ka0xvq1-ghc-8.4.3/lib/ghc-8.4.3/include/
[1 of 1] Compiling Obelisk.Generated.Static ( src/Obelisk/Generated/Static.hs, dist/build/Obelisk/Generated/Static.o )
builder for '/nix/store/b81c0m59x7cw1zxgbp11k96ihxwwbfvm-linux-namespaces-0.1.3.0.drv' failed with exit code 1

Current text at
http://docs.reflex-frp.org/en/latest/overview.html#architecture-of-a-reflex-dom-application
refers to the question on how to structure a reflex application. There is also a question about the use of giant dynamic and on how well reflex apps scale.

On one hand

One little rule of thumb or idea about individual widgets is that quite often, you will want the inputs to a widget to be Dynamics that tell you the ground truth about what the state of the widget ought to be, and the outputs from the widget to be Events that tell you how the user interacted with it. This leaves the decisions about how to maintain the state of the widget up to some higher level thing -- you can immediately cap that off by introducing a foldDyn or holdDyn and using recursion to create a self-contained widget that maintains its own state (but might hide some of it from the outside), or you can combine together a bunch of such things and make all the decisions about how the state ought to change farther up.

Deciding where the holds ought to go requires insight into how your application works. If you leave them all for the top level of the application, you end up with something kind of like Elm's prescribed architecture, which usually means you end up with this top level part of your application needing to "know" too much about every little widget. If you tie things off too early, you make it a little harder for separate parts of the application to interact with each other. Generally, you want the holds to be at some point above all the things their state will affect, and no higher.

and on the other hand

Some general pointers are to break up your events and behaviors as finely grained as possible. It is often good structure to pass in Events and Behaviors to components which return Dynamics or, preferably, Behaviors. It is often a warning sign when you're passing Dynamics in or Events out.

Sorry if I quoted without enough context: former is talking about widgets while latter is about large scale apps, thus not exactly about the same thing.

Anyhow, while thinking of the current text at
http://docs.reflex-frp.org/en/latest/overview.html#architecture-of-a-reflex-dom-application,
in addition to it, it might could compose somehow both of the above recommendations. There could be notes about potential caveats of the chosen approach as well as the benefits and other implications it entails. And maybe even some picture / schematic example code how to manage states and where etc. Or a separate section?

This section could be extended a bit.

Maybe an example (either link or directly).

And maybe some links to background material to be better equipped when using mfix (and fix, too), like

• MonadFix is Time Travel
• Haskell wiki on MonadFix
• Typeclassopedia on MonadFix
• Recursive do on 24d on GHC exts
• Grokking fix
• A reddit thread on fix
• More on reddit

At http://reflex-frp.readthedocs.io/en/latest/guide_to_event_management.html
on the Manipulation section, it should be 'manipulating', 'filtering'

https://reflex-frp.org/resources

The linked site (qfpl) is not existent anymore.

They currently blend in perfectly, meaning you have to hover hunt for links

See #3 (comment)

Hi

I have building difficulties with a project and it seems that turning off the haddock generation is needed. The current docs don't show, how to do this. Maybe add something about it to local haddoc. Even thought this is about nix-confs

• this can be hard those who are new for both nixos and frp
• the nix-things on frp-platform build on top of nix-libs: it is not obvious, how to do things to get them working on frp-platform/ob
• it might not be that obvious for some things, should the mod made into the cabal- or default.nix-files

These "things" include

• turning on and off the documentation generation
• passing parameters to the compilation and linking, and for ghc and ghcjs
• if the system tries to compile external lib, and it is, say too new (version clash), then what is the recommended way to solve this. (Sometimes, I just get the source and refer to the local version, which probably is a bad way to do things, and sometimes I have referred to older version. The problem with that is that I cannot remember, how to do the referral to the older version and somehow I cannot find easily, where I have applied it. Both would be the default.nix-modifications.)

Further, it's probably not easy to decide, what is the right place for the above things. (Somewhere in the docs as that is the place people tend to look and not in the related project-readme-files??)

ref reflex-frp/reflex#161

Looks like we need to twiddle some settings with the new https gh pages. :)

So that people can conveniently figure out how to contribute. Maybe we should have one of those "fork me on github" banners.

Nix does not work on certain platforms (at least: Windows and Arch Linux). For users of those platforms, try-reflex isn't useful, so we should provide a docker image, an OVA file, or something like that for them to use.

• We already can build an OVA from reflex-platform by running nix-build -A demoVM

Hi,
The example section at docs/examples does not refer to the ob-examples at ob-examples.

Maybe add a link to those as well?

comparison to Elm architecture

there are a few other FRP around. in particular I had a lot of confusion moving from Elm to Reflex. One difference, possibly is that Reflex, being written in Haskell is monadic. The web page is a side effect of other computations. Although Elm compiler is written in Haskell, Elm is it's own separate language and an architectures. All the HTML , SVG, CSS and other DOM elements have been turned into functions that fit into " the Elm architecture". These are not side effects there are no monads.

Finally while all elements are instances of el or elAttr in Reflex, there's some distinction between dynamic and static elements, elements with attributes and elements without. I found it easier to just use element and lenses and define my own methods.

There's also confusion with ghcjs which is almost completely separate.

From the teaching point of view, it will be helpful to review monads and the Haskell arrows as they play out specifically in Reflex. These are just my thoughts and I'm writing about it on my own GitHub.

I think it would be good to have haddock hosted on github and may be updated nightly, so that we have an easy access to the latest haddock.

I intend to link haddock to the docs, so need a proper place to have the latest version.

The project description currently reads "web design for reflex-frp.org htttps://reflex-frp.org/"

"htttps://reflex-frp.org/" should be "https://reflex-frp.org/"