Lisplog

Elm playground: how to act at the beginning or end of an animation loop?

via Elm - Latest posts by @hans-helmut Hans-Helmut on Sat, 27 Nov 2021 17:13:36 GMT

Hello, made this for you: Ellie

I introduced a flag to avoid double counting.

A process for core library fixes and improvements

via Elm - Latest posts by @PascalLeMerrer Pascal Le Merrer on Sat, 27 Nov 2021 12:38:22 GMT

By giving a direct access to JavaScript, you would loose the guarantees the Elm compiler offers (no runtime errors) and probably its ability to make a so aggressive tree shaking.

Analysis of Elm core issues and patches

via Elm - Latest posts by @rupert Rupert Smith on Sat, 27 Nov 2021 09:39:56 GMT

That is sort of the function of the Change to API Behaviour and API Addition checks - changes to a core API might be one way to fix those, but external package might be a better way, especially if the core API is arguably not broken in the first place.

This one is a good example of that; is not allowing 4. to parse as an Int a bug or a feature?

deadEndsToString would be fine in an external package, if it were not for the fact that it already exists in elm/parser and throws a runtime exception. Fixing it in an external package would still leave that broken code in place.

But yes, good idea, I will add a column for Fixable in Non-Core Package.

A process for core library fixes and improvements

via Elm - Latest posts by @berend Berend de Boer on Sat, 27 Nov 2021 01:54:57 GMT

I think nobody wants to change Elm, but would like to use Elm in more cases. Supporting certain JavaScript browser APIs requires the ability to use JavaScript more directly. I.e. it would be good if you could write core libraries more easily to allow for experimentation.

Analysis of Elm core issues and patches

via Elm - Latest posts by @matt.cheely Matt Cheely on Sat, 27 Nov 2021 01:01:06 GMT

I was looking through these and one thing that might be worth adding to the analysis is a “fixable in external package” check. As an example, elm/parser's missing deadEndsToString doesn’t use any private information that I can see, so it would be feasible to implement it in a parser-extras or parser-patch library, and share that through the community. I suspect that could be true for most of these that don’t involve bugs in native code or re-implementation of operators.

Android app skeleton

via Elm - Latest posts by @AvailableUsername on Fri, 26 Nov 2021 20:10:35 GMT

Update: as planned, I’ve created a helper library that makes the gesture events from Hammer.js easy to use with Elm.

https://package.elm-lang.org/packages/leforestier/elm-hammer-events/latest/

Hammer.js is actually doing all the work of gesture detection, and it’s pretty good at it. Now you can use events attributes such as onSwipe, onSwipeLeft, onPress, onRotate etc… in your Elm application and it’s as easy as using onClick.

Introducing Elm Editor - a web-based IDE for Elm programs

via Elm - Latest posts by @PascalLeMerrer Pascal Le Merrer on Fri, 26 Nov 2021 07:30:30 GMT

I hosted a new workshop a few days ago.
I made a new attempt with Codesanbox.io and it was quite satisfying. I assume the issues I encountered the first time I give it a try were temporary or have been fixed.

pros:

• the compiler output is immediately visible (that was not the case with Glitch)
• syntax coloring;
• VScode based editor;
• the invitation process worked smoothly; everybody was able to access the shared code and edit it;

cons:

• you have to find a template in the community ones to start a project, and identify the ones with a recent elm version and nice tooling —the first I tried used an old elm version and I failed to upgrade it; otherwise you have to create your own template, and I imagine it would require a couple of hours in order to understand of it works and to tune it)
• it was frequent the source code changes were not detected by elm-live; we had to restart the container often.
• (minor) the elm debugger is available only when you display the app in another tab, outside of the codeanbox editor

State of Elm Packages

via Elm - Latest posts by @system system on Thu, 25 Nov 2021 22:39:14 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

A process for core library fixes and improvements

via Elm - Latest posts by @Janiczek Martin Janiczek on Thu, 25 Nov 2021 14:19:53 GMT

Just to further the points in 3. a little, in addition to @pdamoc 's proof of concept with patching ELM_HOME linked above I’ve started dreaming up a format of how these “patched” snapshots could be described declaratively and applied.

I’m sure there is a bunch of other prior art in all of the elm-git-install and shelm-like tools that we could explore.

Here’s my noodling:

elm-patchwork.json

{
  "elmVersion": "0.19.1",
  "packages": {
    "elm/core": {
      "version": "1.0.5",
      "base": {
        "gitRepoUrl": "https://github.com/elm/core",
        "gitCommitHash": "84f38891468e8e153fc85a9b63bdafd81b24664e"
      },
      "patchPlan": [
        {
          "name": "List.concatMap performance improvements",
          "filePath": "./patches/elm-core-1.0.5-list-concatmap.patch"
        }
      ]
    }
  }
}

consumed by some tool into types like:

{-| The top-level type corresponding to the elm-patchwork.json file
-}
type alias Project =
    { elmVersion : String -- "0.19.1"
    , packages : List Package
    }


type alias Package =
    { name : String -- "elm/core"
    , version : String -- "1.0.5"
    , base : PackageBase
    , patches : List Patch
    }


type PackageBase
    = BaseFromGit
        { gitRepoUrl : String -- not strictly GitHub?
        , gitCommitHash : String -- this is how we'll download that package
        }
    | BaseFromFilesystem
        { folderPath : String -- "./patchwork/bases/elm/core/hacked-1.0.5"
        }


type alias Patch =
    { name : String -- "List.concat: performance improvement"
    , contents : PatchContents
    }


type PatchContents
    = PatchFromGit
        { gitRepoUrl : String -- not strictly GitHub?
        , gitCommitHash : String -- this is how we'll download that patch
        , filePath : String -- "patches/elm-core-1.0.5-list-concat.patch"
        }
    | PatchFromFilesystem
        { filePath : String -- "./patches/elm-core-1.0.5-list-concat.patch"
        }

Tim Bradshaw: The endless droning: corrections and clarifications

via Planet Lisp by on Thu, 25 Nov 2021 13:05:57 GMT

It seems that my article about the existence in the Lisp community of rather noisy people who seem to enjoy complaining rather than fixing things has atracted some interest. Some things in it were unclear, and some other things seem to have been misinterpreted: here are some corrections and clarifications.

First of all some people pointed out, correctly, that LispWorks is expensive if you live in a low-income country. That’s true: I should have been clearer that I believe the phenonenon I am describing is exclusively a rich-world one. I may be incorrect but I have never heard anyone from a non-rich-world country doing this kind of destructuve whining.

It may also have appeared that I am claiming that all Lisp people do this: I’m not. I think the number of people is very small, and that it has always been small. But they are very noisy and even a small number of noisy people can be very destructive.

Some people seem to have interpreted what I wrote as saying that the current situation was fine and that Emacs / SLIME / SLY was in fact the best possible answer. Given that my second sentence was

[Better IDEs] would obviously be desirable.

this is a curious misreading. Just in case I need to make the point any more strongly: I don’t think that Emacs is some kind of be-all and end-all: better IDEs would be very good. But I also don’t think Emacs is this insurmountable barrier that people pretend it is, and I also very definitely think that some small number of people are claiming it is because they want to lose.

I should point out that this claim that it is not an insurmountable barrier comes from some experience: I have taught people Common Lisp, for money, and I’ve done so based on at least three environments:

• LispWorks;
• Something based around Emacs and a CL running under it;
• Genera.

None of those environments presented any significant barrier. I think that LW was probably the most liked but none of them got in the way or put people off.

In summary: I don’t think that the current situation is ideal, and if you read what I wrote as saying that you need to read more carefully. I do think that the current situation is not going to deter anyone seriously interested and is very far from the largest barrier to becoming good at Lisp. I do think that, if you want to do something to make the situation better then you should do it, not hang around on reddit complaining about how awful it is, but that there are a small number of noisy people who do exactly that because, for them, no situation would be ideal because what they want is to avoid being able to get useful work done. Those people, unsurprisingly, often become extremely upset when you confront them with this awkward truth about themselves. They are also extremely destructive influences on any discussion around Lisp. (Equivalents of these noisy people exist in other areas, of course.) That’s one of the reasons I no longer participate in the forums where these people tend to exist.

(Thanks to an ex-colleague for pointing out that I should perhaps post this.)