Lisplog

Blogging in Lisp

Search

Feed Aggregator Page 293

Rendered on Fri, 11 Jan 2019 17:01:57 GMT  newer latest older 

Type signature for update and view

via Elm Discourse - Latest posts by @Herteby Simon Herteby on Fri, 11 Jan 2019 16:13:08 GMT

The Model doesn’t have to be a record, it can be whatever you want. A record just tends to be the most practical.

Type signature for update and view

via Elm Discourse - Latest posts by @yadalis Suresh Yadali on Fri, 11 Jan 2019 16:04:59 GMT

Herteby is right, I made some changes, you can go from there, it compiles now, https://ellie-app.com/4qR8gh4dZGNa1, your model should be an alias type (record type), you defined your model as a custom type

Type signature for update and view

via Elm Discourse - Latest posts by @Herteby Simon Herteby on Fri, 11 Jan 2019 15:57:41 GMT

init should return (Model, Cmd Msg), not (Msg, Cmd Msg). For some reason the compiler error got a bit confusing.

Type signature for update and view

via Elm Discourse - Latest posts by @KasMA1990 Kasper on Fri, 11 Jan 2019 15:46:37 GMT

Hey everyone, I’ve been playing around with Elm, but I’m getting this compile error that I don’t understand: https://ellie-app.com/4qQRZhfJ6tLa1

Don’t mind if code seems a bit weird, I’ve been cutting things out unrelated to the error I’m getting. Can anyone explain why I get an error saying that view and update should only take Msg and no Model?

A PROD ready website developed in 100% elm

via Elm Discourse - Latest posts by @yadalis Suresh Yadali on Fri, 11 Jan 2019 15:40:35 GMT

Thanks, also quick question, do you know if there is any way to show spinner/loader to show the delay during exp/col, especially on check/uncheck on search filters which filters and loads the trucks on the right side ? Also, another point, what I noticed is, the less the data that browser has to deal with, the faster the clicks responses are, so if you apply more filters and get the trucks under may be 100, then exp/col should be faster.

A PROD ready website developed in 100% elm

via Elm Discourse - Latest posts by @G4BB3R Gabriel Torrecillas Sartori on Fri, 11 Jan 2019 15:05:11 GMT

Nice! Sorry, I should have said, I haven’t used any tool to measure, it was just a number from my head, maybe it’s a little less or a little more, but it’s nothing that would compromise the experience.

A PROD ready website developed in 100% elm

via Elm Discourse - Latest posts by @yadalis Suresh Yadali on Fri, 11 Jan 2019 14:54:50 GMT

Thanks for the feedback, yes, the entire site is done in 100% elm-ui, data endpoints are done in C# REST apis. As far as the slowness, you are right, if you use older browsers, it is slow when you exp/col or even clicking on filter check boxes, I am on Version 71.0.3578.98 (Official Build) (64-bit) and I don’t see any delay at all, just curious how did you get the ~250 ms number ? did you use any tools to measure the delay ?

A PROD ready website developed in 100% elm

via Elm Discourse - Latest posts by @G4BB3R Gabriel Torrecillas Sartori on Fri, 11 Jan 2019 14:50:30 GMT

It’s great to see elm-ui in production! Is the entire site in Elm, like the view truck and login? And what is the backend technology used?

I am accessing from a very old computer right now, on Google Chrome. When I expand/collapse any filter from the home page, I notice a ~250ms delay, and I am not sure if it can optimized or if its my computer that is slow.

Protocol Buffers using bytes: `elm-protocol-buffers`

via Elm Discourse - Latest posts by @adeschamps Anthony Deschamps on Fri, 11 Jan 2019 12:56:19 GMT

Ah, yes, I noticed there would be a challenge with recursive types. I decided to just leave out the recursive fields at first.

Checking for a new version of an Elm app

via Elm Discourse - Latest posts by @allanderek Allanderek on Fri, 11 Jan 2019 11:44:21 GMT

Thanks! I can’t see how I would have found that by searching.

Protocol Buffers using bytes: `elm-protocol-buffers`

via Elm Discourse - Latest posts by @eriktimmers Erik Timmers on Fri, 11 Jan 2019 09:53:47 GMT

Currently, I have an basic generator running (exactly the way you described). I can successfully decode a CodeGeneratorRequest, for which I had to write all decoders by hand initially. I am now working on generating modules from the request. Here I got delayed as a found out the API was missing a Decode.lazy for recursive structs (like DescriptorProto). Once it is mature enough I will make it public as it will support using elm-protocol-buffers.

I am not sure what you are referring to here: generating code or de/encoding ProtoBuf JSON? Feel free to ping me on slack @eriktim.

Checking for a new version of an Elm app

via Elm Discourse - Latest posts by @tgelu Gelu Timoficiuc on Fri, 11 Jan 2019 09:48:39 GMT

I think this presentation from elm europe is particularly relevant to your question https://www.youtube.com/watch?v=4T6nZffnfzg

Protocol Buffers using bytes: `elm-protocol-buffers`

via Elm Discourse - Latest posts by @klaftertief Jonas Coch on Fri, 11 Jan 2019 09:32:57 GMT

I started the same some time ago, but using the canonical JSON representation. The code is not public at the the moment. Maybe it’s time to go back to it. I’m happy to chat about that.

I always get a strange feeling when I start thinking about being able to round trip, generating Google/Protobuf/Descriptor.elm :slight_smile:

Checking for a new version of an Elm app

via Elm Discourse - Latest posts by @allanderek Allanderek on Fri, 11 Jan 2019 08:45:11 GMT

Thanks, that’s an interesting idea of just reloading every N days rather than try to determine whether a reload is necessary, that might actually be the most appropriate thing for us. It’s also interesting that some people are checking the version on every API call. We actually have a requirement that inactive users must be logged out after a certain amount of time with no interaction, because some interactions don’t involve the API we send a “don’t-log-me-out” ping and we could easily use that to also check for a version update. The downside would mean that it wouldn’t work for non-logged-in users. Nice thread.

Checking for a new version of an Elm app

via Elm Discourse - Latest posts by @allanderek Allanderek on Fri, 11 Jan 2019 08:36:33 GMT

Thanks that’s very useful. The scheme we had in mind was very similar. To avoid the parsing we thought that when we generate the MAGIC_NUMBER, we could update the index.html and generate a file version-MAGIC_NUMBER.text. Then the front-end just needs to make a static-file request for that file and if it gets a 404 then it knows it should prompt the user to update/refresh. This means that if you make small changes you don’t need to delete the previous magic-number files, when you do want an update to prompt the user you just delete all the previous magic-number files.

I guess the specifics aren’t really all that important, I just didn’t want to go down this path and do all the implementation only to find that there is a standard way of doing this. Thanks again.

Integer division by zero

via Elm Discourse - Latest posts by @Y0hy0h on Fri, 11 Jan 2019 07:15:31 GMT

An issue with having division by 0 fail, is that the // function could not return Int. It would need to return Maybe Int to capture that case, making it very inconvenient to use.

I therefore think that this behavior is a compromise for practicality.

Checking for a new version of an Elm app

via Elm Discourse - Latest posts by @catz Catz on Fri, 11 Jan 2019 05:27:34 GMT

Checking for a new version of an Elm app

via Elm Discourse - Latest posts by @matt.cheely Matt Cheely on Fri, 11 Jan 2019 04:28:38 GMT

I don’t know of any standard approaches to this, but I can share how we do it where I work, or at least how we did it last time I looked at the relevant code. This is mostly a JS (Ember) app, so there’s no Elm involved in this process, but the same techniques should work fine in Elm.

When we generate the app, we embed a unique identifier for that version in index.html, as a meta tag in the document’s head. Then in the app, we fetch index.html on a 30-minute interval, parse the version out of the header, and if it’s different than what’s currently running, prompt the user to refresh.

One nice thing about this approach is that index.html is the browser’s entry point, and all CSS and JS assets get a new URL on each release, so there’s no way for the detected version to be out of sync with the reality of what’s deployed. The downsides are that we’re fetching more data than is strictly necessary, since there’s a bunch of other information in the HTML unrelated to the version, and that pulling the data out of the HTML is a bit more complicated than it would be if we were just fetching some JSON. That said, since we have fully control over the structure of the document, we could almost certainly get away with using a regex to pull out the version rather than a full HTML parser (we might actually do that, I don’t recall).

Hopefully that’s helpful, but feel free to follow up if you’re interested in more details. I’ll be back in the office tomorrow where it’ll be easier to look up the actual code involved.

Protocol Buffers using bytes: `elm-protocol-buffers`

via Elm Discourse - Latest posts by @adeschamps Anthony Deschamps on Fri, 11 Jan 2019 04:24:16 GMT

I’m very excited to see this! The API feels quite natural.

I decided to take a stab at writing a compiler plugin (https://github.com/adeschamps/protoc-gen-elm). I started by sending stdin/stdout across ports and handwriting a minimal subset of the types, decoders, and encoders from plugin.proto and descriptor.proto. I now have a protoc plugin that can read a CodeGeneratorRequest and generates a CodeGeneratorResponse by using https://package.elm-lang.org/packages/stil4m/elm-syntax/latest/ to construct and write an Elm syntax tree. It works for simple messages - there are still plenty of protobuf features that it doesn’t handle. I’m curious how much/little work would have to be done before it can generate the encoders and decoders that I was writing by hand.

Is your code generator available to contribute to? I haven’t put too much time into this yet, and if you already have something going then it would be nice to collaborate on that.

Integer division by zero

via Elm Discourse - Latest posts by @jwoLondon Jo Wood on Thu, 10 Jan 2019 23:09:01 GMT

I think the key statement in the link @folkertdev provides that refutes your ‘inverse’ definition is that “0 does not have a multiplicative inverse”, so does not apply in this case.

I was always taught at school that the division operator is simply undefined for a denominator of 0, so any argument that states what the “mathematical” value should be is dubious at best. Better I think is to evaluate the implications of assigning a value (0 in the case of Elm’s //0) for this undefined operation, as @folkertdev’s link does.

 newer latest older