[elm-discuss] Curious about nested updates

[Alex Lew]

The rules are that in a record update, neither the record being updated (the 
thing to the left of the bar) nor the field names can have dots in them. In 
order to do nested record updates, you'll have to use `let...in...` to give 
simpler names to all your record's nested fields.

I believe the logic here is that nested records are generally bad design, but 
I'd love to see this explored more, as obviously, in other programming 
languages, we are all quite used to building data types out of other data 
types. Perhaps nested records are OK but trying to update multiple levels of a 
record at once is a sign of bad design?

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Linear algebra for 2d geometry?

[Ian Mackenzie]

You're exactly right - if you construct a function like the following, I 
think it will almost certainly result in four separate transformations 
every time it's called:

compositeTransformation1 : Point3d -> Point3d
compositeTransformation1 =
Point3d.scaleAbout Point3d.origin 5 >> Point3d.rotateAround Axis3d.z 
(degrees 
90) >> Point3d.translateBy (Vector3d ( 1, 2, 3 )) >> Point3d.mirrorAcross 
Plane3d.xy

In many cases that's fine (if you're only doing it for a handful of points, 
for instance), but if you need a more efficient version you can do it using 
frames:

transformedFrame : Frame3d
transformedFrame =
Frame3d.xyz |> Frame3d.rotateAround Axis3d.z (degrees 90) |> 
Frame3d.translateBy 
(Vector3d ( 1, 2, 3 ) |> Frame3d.mirrorAcross Plane3d.xy

compositeTransformation2 : Point3d -> Point3d
compositeTransformation2 =
Point3d.scaleAbout Point3d.origin 5 >> Point3d.placeIn transformedFrame

You still need to apply the scaleAbout separately since you can't scale a 
Frame3d, but at least scaling is a relatively cheap operation.

In general, yes, using matrices would likely be a bit more efficient, but 
you can get pretty close using techniques like the above, and I think the 
expressiveness/clarity/flexibility is better. Precision should also be 
improved - even disregarding the fact that the linear-algebra package uses 
single-precision floats internally (via Float32Array), specialized 
transformation functions like scaleAbout can do things like subtract the 
given center point, then scale, then re-add the given center point. This 
has better numerical stability than the equivalent transformation matrix, 
which will effectively scale everything about the origin and then apply a 
(potentially large) translation to drag everything back to where it should 
be. (Several of these tradeoffs are probably affected by my own goals - I 
want opensolid/geometry to be a great general-purpose geometry library, but 
I'm personally more focused on stuff like computer-aided design apps where 
precision is critical than things like games that have much more strict 
performance requirements.)

By the way, the interop package I mentioned earlier has now been published: 
http://package.elm-lang.org/packages/opensolid/linear-algebra/latest.

On Monday, 8 May 2017 05:22:05 UTC-4, Rupert Smith wrote:
>
> On Sunday, May 7, 2017 at 10:02:43 PM UTC+1, Rupert Smith wrote:
>>
>> On Friday, May 5, 2017 at 7:55:22 PM UTC+1, Ian Mackenzie wrote:
>>>
>>> So, nice library with lots of features, missed chance to work with a 
 better abstraction.

>>>
>>> Ouch =) I've done lots of work with matrix-based libraries, and I've 
>>> personally found matrices (and related stuff like quaternions) very 
>>> powerful and flexible but also confusion- and error-prone. The OpenSolid 
>>> libraries are my attempt to provide a better, more geometrically meaningful 
>>> abstraction that still allows you to get good performance.
>>>
>>
>> Sorry, my bad and thanks for the explanation. I guess I was a little 
>> fixated on the matrix approach, but with your explanation it is clear that 
>> your approach is at least as good.
>>
>
> There is potentially an advantage with matrices versus functions. A matrix 
> could be thought of as a function, in the sense that its values capture a 
> particular function that can be applied by multiplying by it. So you have 
> captured the function as a lambda. Lambdas are opaque though, and when 
> chained together to produce a new function, there is no way to guarantee 
> that they will combine in such a way that they reduce to the simplest or 
> most efficient representation; the compiler may do a good job though.
>
> Suppose you have a complex chain of transformations like: scale, rotate, 
> translate (requires 3x3 matrix for 2d work), mirror. Represent this with 
> matrices M1, .., M4. The entire transformation can then be captured as a 
> single matrix Mt = M1 . M2 . M3 . M4. As lambdas, my assumption is the 
> compiler will not be smart enough to reduce it so neatly, and it will 
> always be applied as 4 separate operations.
>
> I guess you already know this... :-)
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Best practices to create examples for an elm package?

[Matthieu Pizenberg]

>
> - Use elm-doc-test for examples whereever possible
> - If you have views, use elm-html-test.
>

Thanks Noah, I didn't know about those for lack of using tests. Thank you 
everyone for your feedback. So if I sum up, the main ideas are:

1. Keep in sync doc examples by using doc tests.
2. For more advanced examples, use a dedicated `elm-package.json` to avoid 
unnecessary package dependencies and integrate them in a test suite.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Missing json decoding tool to decode multitouch events cleanly

[Matthieu Pizenberg]

On Monday, May 8, 2017 at 11:36:13 PM UTC+8, Erik Lott wrote:
>
> Yeah, I think you spotted my bad logic. You're talking about functions 
> like this, right?
>

Yep that was it :) 

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Local third-party packages

['Rupert Smith' via Elm Discuss]

On Monday, May 8, 2017 at 8:39:57 PM UTC+1, Rupert Smith wrote:
>
> On Friday, May 5, 2017 at 11:52:09 AM UTC+1, Gusztáv Szikszai wrote:
>>
>> I've been working on this in the last few days, and published 1.0.0 
>>  
>> of *elm-github-install* which handles using a fork (or any other git 
>> repository for a package) and using a local directory. If anyone tries this 
>> out some feedback would be nice.
>>
>
> I forked another elm package and hacked it, and just want to be able to 
> reference it without tagging a release version or publishing. Will be a 
> very useful feature I think. I will try it out now, thanks.
>

Was able to work around the npm installer issue by installing as a ruby gem 
instead. Works nicely, and I was able to substitute a branch containing 
work in progress - many thanks for these additions to elm-install. :-) 

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Local third-party packages

['Rupert Smith' via Elm Discuss]

On Monday, May 8, 2017 at 8:39:57 PM UTC+1, Rupert Smith wrote:
>
> On Friday, May 5, 2017 at 11:52:09 AM UTC+1, Gusztáv Szikszai wrote:
>>
>> I've been working on this in the last few days, and published 1.0.0 
>>  
>> of *elm-github-install* which handles using a fork (or any other git 
>> repository for a package) and using a local directory. If anyone tries this 
>> out some feedback would be nice.
>>
>
> I forked another elm package and hacked it, and just want to be able to 
> reference it without tagging a release version or publishing. Will be a 
> very useful feature I think. I will try it out now, thanks.
>

The installer seems to fail:

sudo npm install elm-github-install -g

> npm WARN deprecated node-uuid@1.4.8: Use uuid module instead

> /usr/local/bin/elm-github-install -> 
/usr/local/lib/node_modules/elm-github-install/scripts/run.js

> /usr/local/bin/elm-install -> 
/usr/local/lib/node_modules/elm-github-install/scripts/run.js

> > elm-github-install@1.0.1 install 
/usr/local/lib/node_modules/elm-github-install

> > node scripts/install.js

> Downloading and extracting the binary from: 
https://github.com/gdotdesign/elm-github-install/releases/download/v1.0.1/elm-install-1.0.1-linux-x86_64.tar.gz

> events.js:163

>   throw er; // Unhandled 'error' event

>   ^

> Error: EACCES: permission denied, mkdir 
'/root/.elm-install/elm-install-1.0.1-linux-x86_64'

> npm ERR! Linux 3.16.0-4-amd64

> npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" 
"elm-github-install" "-g"

> npm ERR! node v7.10.0

> npm ERR! npm  v4.2.0

> npm ERR! code ELIFECYCLE
npm ERR! errno 1

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Feedback requested: crowdsourcing big computations with Elm

[Carlos De la Guardia]

Howdy folks, 

Here's a tentative idea I'd like to get some feedback on. 

I like the idea of crowdsourcing big computations (e.g. Folding@Home 
). If you have a large problem to solve, you 
can distribute bits of work to a network of people. Your program can then 
run cheaply on the excess capacity of people's machines. Elm makes 
distributing 'untrusted' code simple, since you can guarantee the purity of 
the code being used. 

Here's how it might work. 
1. You have a large, parallelizable computation
2. You upload a package exposing a 'run' function that accepts and emits 
JSON, along with a list of JSON records to be used as inputs. 
3. The platform compiles your code
4. Users come to the site, and a scheduler presents them with a constant 
stream of work for each browser tab they open. 
5. You download a list of JSON results. 

At this point, I'm really interested in hearing about potential use cases, 
dangers, or existing work in this area I should check out. 

Thanks!
Carlos

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Local third-party packages

['Rupert Smith' via Elm Discuss]

On Friday, May 5, 2017 at 11:52:09 AM UTC+1, Gusztáv Szikszai wrote:
>
> I've been working on this in the last few days, and published 1.0.0 
>  of 
> *elm-github-install* which handles using a fork (or any other git 
> repository for a package) and using a local directory. If anyone tries this 
> out some feedback would be nice.
>

I forked another elm package and hacked it, and just want to be able to 
reference it without tagging a release version or publishing. Will be a 
very useful feature I think. I will try it out now, thanks.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Docker image for create-elm-app tasks - kraklin/elm-app-ci

[Tomas Latal]

Hello,

I needed to execute elm-app tests and build on CI server (GitLab). To make 
this simple and reusable, I have created a Docker image with create-elm-app 
in it. You can pull it from here 
https://github.com/kraklin/docker-elm-create-app

I was unable to create an Alpine Linux image with working elm-make so the 
image is quite big. If anyone has a hint or want to help me, PR's are more 
thane welcome here https://github.com/kraklin/docker-elm-create-app

Enjoy it ;)

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Tour of an open-source 4,000 LoC Elm SPA

[Richard Feldman]

Agreed! That does sound like a useful (albeit separate) demo project. :D

On Mon, May 8, 2017 at 10:03 AM Marek Fajkus  wrote:

>  It's clearly great contribution to educative materials around Elm. I've
> seen your tweet before and was really pleased you've found time to build it
> - give it your likes folks.
>
> About web-pack - even though we're using it with elm in company project I
> never used it for any of my hobby project so far. Simply it makes sense to
> build from ground up not other way around. Also I think it's reasonable to
> stay focused so when the goal is to show Elm code then there's no need for
> unnecessary noise (webpack & env config). That's being said it still might
> make sense to create demo on "building webpack environment for Elm" which
> than can use rather simple Elm app and demo just setup of more complex
> environment (dev/test/prod) with SCSS for instance. That would be great too.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/hqO3P6uJiew/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Best practices to create examples for an elm package?

[Marek Fajkus]

My thoughts:


   - Most packages don't depend on `elm-lang/html`
   - Most examples do depent on `elm-lang/html`
   - It's good to enforce examples compatibility <-> library compatibility 
   in CI (compiling examples in some step)

Solution?


   - have `elm-package.json` without `elm-lang/html` in root
   - have another `elm-package.json` with `elm-lang/html` in examples
   - Ci should compile examples
  - If you have more examples in folders of them it's maybe good idea 
  to have `Main.elm` where you import all of them and compile that Main in 
CI
  - If you have single example jusut ensure it really compiles (not 
  just pull packages) in CI.
   
Downsides:

   - From my experience some future contributors will ask how they can 
   compile (or run elm-reactor to work with) examples.
   

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Tour of an open-source 4,000 LoC Elm SPA

[Marek Fajkus]

 It's clearly great contribution to educative materials around Elm. I've 
seen your tweet before and was really pleased you've found time to build it 
- give it your likes folks.

About web-pack - even though we're using it with elm in company project I 
never used it for any of my hobby project so far. Simply it makes sense to 
build from ground up not other way around. Also I think it's reasonable to 
stay focused so when the goal is to show Elm code then there's no need for 
unnecessary noise (webpack & env config). That's being said it still might 
make sense to create demo on "building webpack environment for Elm" which 
than can use rather simple Elm app and demo just setup of more complex 
environment (dev/test/prod) with SCSS for instance. That would be great too.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: File Uploads - as simple as I could manage

[Kasey Speakman]

That was one of the first things I found. I'm uploading to S3 too. But the 
API was a bit larger than I wanted to take on for my meager needs. Props to 
simonh1000 for leading the way.

On Sunday, May 7, 2017 at 8:25:23 AM UTC-5, Erik Lott wrote:
>
> You may want to see "file-reader" if you haven't seen it already:
> https://github.com/simonh1000/file-reader 
> 
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Best practices to create examples for an elm package?

[Noah Hall]

Best practice:

- Use elm-doc-test for examples whereever possible, don't just write
documentation examples. They easily fall out of sync. If your
doc-tests start to look too crazy, it's possible your API could be
simplified.
- Have a test suite. Depending on your problem, your test suite may
need to be large and complex, in order to ensure all edge cases are
matched. If your package is mostly just glue code, there's not so much
need for that.
- If you have views, use elm-html-test. You can now also test events with this.
- If you are exposing something which is browser-dependant, e.g mouse,
touch, event decoders. You should have an integration test set up that
runs your code in a real browser

On Mon, May 8, 2017 at 4:38 PM, Eirik Sletteberg
 wrote:
> Maybe write an example in the form of an integration test - then you know 
> your example will be up to date with the actual code, and it may even 
> discover bugs!
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Tour of an open-source 4,000 LoC Elm SPA

[Erik Lott]

A great many folks are going to be thankful for this SPA example... You are 
a saint good sir.

On Monday, May 8, 2017 at 3:59:16 AM UTC-4, Richard Feldman wrote:
>
> I get asked if there are any sizeable open-source Elm SPA examples out 
> there...so I made one!
>
> Hope it's useful: https://dev.to/rtfeldman/tour-of-an-open-source-elm-spa
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: List of all members of a union type

[OvermindDL1]

OCaml has a set of extension points.  You can write OCaml code, add it to 
an extension point (`derived` is precisely the use case of this) and it 
receives the AST of the expression and can transform it or add new code or 
whatever as you wish.  Like a very common one for auto-json conversion 
works like (example taken from docs):
```ocaml
type geo = {
  lat : float;
  lon : float;
}
[@@deriving yojson]
```
And this generates two functions in the module with the types of:
```ocaml
val geo_of_yojson : Yojson.Safe.json -> (ty, string) Result.result
val geo_to_yojson : ty -> Yojson.Safe.json
```
And they have a set of options so you can override the key names in the 
json or override the variant names or change the encoding of things like, 
oh, integers or specify a default value if it is missing and so forth. 
 Extension points like this in Elm would save on *so* much manually made 
code in so many cases...


On Friday, May 5, 2017 at 11:57:35 PM UTC-6, Simon wrote:
>
> I had a different use case for the same basic idea. With GraphQL we have a 
> sort-of typed query language that returns clearly defined json structures. 
> In an ideal world therefore you should be able to define an Elm data 
> structure (sum or union type) and for library functions to be able to 
> create the query string and the json decoder for you. I may be over 
> optimistic, and such things may not even be possible in other ML-family 
> languages, but it felt like something that should be automatable
>
>
>
> On Thursday, 4 May 2017 04:14:03 UTC+2, Matt Hughes wrote:
>>
>> At first I wondered if a type is really what you need for this 
>> application, as opposed to say a list of strings. Anyway one idea is to 
>> write a function to explicitly convert the type to a string. I think this 
>> is better than simply taking the type name and making it a string because 
>> the string representation may need spaces or other punctuation. Using an 
>> explicit case means the compiler won't let you forget if you add a new 
>> type. 
>>
>> module Main exposing (..)
>>
>> import Html exposing (Html, text)
>>
>> type Province = Alberta | BritishColumbia | Saskatchewan
>>
>> toString : Province -> String
>> toString p =
>> case p of
>> Alberta -> "Alberta"
>> BritishColumbia -> "British Columbia"
>> Saskatchewan -> "Saskatchewan"
>>
>> main : Html a
>> main =
>> text (toString Alberta)
>>
>> mch
>>
>> On Tuesday, May 2, 2017 at 9:44:34 PM UTC-6, Matthew Buscemi wrote:
>>>
>>> I have run into a problematic use case a couple of times, and based on 
>>> Slack discussions earlier today, it seems I'm not alone.
>>>
>>> The situation occurs when, for some reason, I need to maintain a list of 
>>> all constructors of a union type. The example given in Slack by mltsy:
>>>
>>> type State = Alabama | Alaska | Arizona | Arkansas | ...
>>>
>>> allStates = [ Alabama, Alaska, Arizona, Arkansas, ...]
>>>
>>> stateSelectBox : List State -> Html Msg
>>> stateSelectBox states =
>>>   let stateValues = List.map toString states
>>>   in ...
>>>
>>> In the example above, simply turning allStates into a list of strings 
>>> would be fine for this particular use case, but in the context of a larger 
>>> system, it could be inadequate–other functions besides stateSelectBox may 
>>> want to utilize the power of performing a case over the union type. 
>>> However, the above solution is also structurally undesirable–if a new type 
>>> is added to State, then the programmer must also remember to update 
>>> allStates separately. The duplication and tight coupling are disconcerting, 
>>> and yet I can't see a viable alternative that preserves the power of types 
>>> without incurring the duplication.
>>>
>>> I have wondered if a language-level construct that takes a union type 
>>> and returns a list of all constructors for that type would be appropriate 
>>> for Elm. Just a thought.
>>>
>>> - Matt
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Best practices to create examples for an elm package?

[Eirik Sletteberg]

Maybe write an example in the form of an integration test - then you know your 
example will be up to date with the actual code, and it may even discover bugs!

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Best practices to create examples for an elm package?

[Eric G]

Good question, I'd like to hear what other people do as well. Just to add 
two other options to the mix:

5. Link to an example that uses the package in Ellie 
(https://ellie-app.com/)
6. Deploy an example to the Github project page 
(https://username.github.io/package/ )

5. Is quick and painless assuming you want to use a published version of 
the package.  
6. Is a bit of a pain to set up, but it can be scripted. I guess this is 
"on top of" the options you list below, since you'll still have to decide 
how you want to build the example.  

I tend towards (3), and "cheat" and access src/ , and just take care not to 
access internal modules, I have never found that a problem. 

On a somewhat related note, it would be nice to have something like 
bl.ocks.org  for displaying examples together with code from Github gists. 

On Sunday, May 7, 2017 at 11:58:26 PM UTC-4, Matthieu Pizenberg wrote:
>
> Exploring a bit the packages repository, I've come accross the following 
> options:
>
> 1. no examples/ dir, all in readme and documentation. 
> (elm-array-exploration, ...)
> 2. examples/ dir with nothing more than `.elm` files (elm-decode-pipeline, 
> elm-monocle, ...)
> 3. examples/ dir with an `elm-package.json` file (elm-transducers, ...)
> 4. examples/ dir with a `package.json` node builder (elm-kinto, ...)
>
> I personally have a mix of (2) and (3). However I feel like they all have 
> issues.
>
> 1. Sometimes, having a "ready to build" example is useful.
> 2. It relies on building from the root directory of the package (where the 
> `elm-package.json` file lives). It also means that the example file can 
> "cheat" by accessing non exposed modules.
> 3. If you add your `src/` dir in the json, then you can also "cheat" like 
> in 2. If you do not, and you use your package as if it was loaded from elm 
> packages, then you cannot verify that your latest modifications (not pushed 
> yet) are working with your examples.
> 4. Well, it's a bit too heavy of a machinery most of the times. Plus it 
> also requires an `elm-package.json` file anyway so the same issues as (2) 
> and (3) apply.
>
> *Do you think there is a best practice? Are there alternatives to those 
> four?*
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Tour of an open-source 4,000 LoC Elm SPA

[Richard Feldman]

>
> Can you comment on why you did not use the elm-webpack-loader? 
> I'm trying to understand if we are moving towards a better approach or if 
> there are other considerations. 
>

It honestly did not occur to me that I might do that!

If I have the choice between using Webpack and not using Webpack, I 
gravitate towards not using Webpack. It hasn't exactly been the most 
delightful piece of software I've ever used. ;)

The main advantage to using the loader would be to show a way to integrate 
> Elm with the rest of the web tech especially SCSS and to provide a 
> development/deployment build environment.  


I suppose, but that wasn't my goal here. I understand your point, but I'd 
rather keep it decoupled from JS build tools...everybody's existing setup 
is going to be a bit different, and I would rather not give people the 
impression that they need anything special to build this application. :)

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Tour of an open-source 4,000 LoC Elm SPA

[Robin Heggelund Hansen]

This is great Richard! I've already shown it to several people who've asked 
me how I structure my Elm apps :)

mandag 8. mai 2017 09.59.16 UTC+2 skrev Richard Feldman følgende:
>
> I get asked if there are any sizeable open-source Elm SPA examples out 
> there...so I made one!
>
> Hope it's useful: https://dev.to/rtfeldman/tour-of-an-open-source-elm-spa
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Linear algebra for 2d geometry?

['Rupert Smith' via Elm Discuss]

On Sunday, May 7, 2017 at 10:02:43 PM UTC+1, Rupert Smith wrote:
>
> On Friday, May 5, 2017 at 7:55:22 PM UTC+1, Ian Mackenzie wrote:
>>
>> So, nice library with lots of features, missed chance to work with a 
>>> better abstraction.
>>>
>>
>> Ouch =) I've done lots of work with matrix-based libraries, and I've 
>> personally found matrices (and related stuff like quaternions) very 
>> powerful and flexible but also confusion- and error-prone. The OpenSolid 
>> libraries are my attempt to provide a better, more geometrically meaningful 
>> abstraction that still allows you to get good performance.
>>
>
> Sorry, my bad and thanks for the explanation. I guess I was a little 
> fixated on the matrix approach, but with your explanation it is clear that 
> your approach is at least as good.
>

There is potentially an advantage with matrices versus functions. A matrix 
could be thought of as a function, in the sense that its values capture a 
particular function that can be applied by multiplying by it. So you have 
captured the function as a lambda. Lambdas are opaque though, and when 
chained together to produce a new function, there is no way to guarantee 
that they will combine in such a way that they reduce to the simplest or 
most efficient representation; the compiler may do a good job though.

Suppose you have a complex chain of transformations like: scale, rotate, 
translate (requires 3x3 matrix for 2d work), mirror. Represent this with 
matrices M1, .., M4. The entire transformation can then be captured as a 
single matrix Mt = M1 . M2 . M3 . M4. As lambdas, my assumption is the 
compiler will not be smart enough to reduce it so neatly, and it will 
always be applied as 4 separate operations.

I guess you already know this... :-)

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Announce: new package (elm-mouse-events), major update (elm-touch-events)

[Matthieu Pizenberg]

Hi all,

Since I often need coordinates of mouse events and was getting tired of 
recoding the
json encoders / decoders for each project, I made a package for this: 
mpizenberg/elm-mouse-events 
.

The main differences from mbr/elm-mouse-events 
 are:
- mbr's is better fit to handle mouse "behaviors" like click, double click, 
... while I'm focused on the three main events (down, move, up).
- mbr's provides client, and target positions. I chose to provide client, 
offset positions and the movement since those better fit my usage.
- I also provides the status of the alt, ctrl and shift keys.

In the meantime, after multiple months of usage of my elm-touch-events 
package, and feedback from Ian (thanks) I rewrote completely the package. 
The new API is much simpler than previously and more intuitive, I hope.

The main difference with knledg/touch-events 
 is that 
mpizenberg/elm-touch-events 
 
supports multitouch interactions.

Don't hesitate to give me feedback on any of those two here, through slack 
(user mattpiz) or github issues.
Thanks :)

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Tour of an open-source 4,000 LoC Elm SPA

[Peter Damoc]

another advantage to a build system (webpack) is that you could create a
`docs` folder where to output the current build, mount that folder to be
used by the project as its Github Pages root and link it from the
README.md.


-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Tour of an open-source 4,000 LoC Elm SPA

[Peter Damoc]

First, thank you so much for taking time from your already busy schedule to
solve this for the community!
I think it is an amazingly useful project as it short-circuits a lot of the
potentially time-hungry decisions.

Can you comment on why you did not use the elm-webpack-loader?
I'm trying to understand if we are moving towards a better approach or if
there are other considerations.

The main advantage to using the loader would be to show a way to integrate
Elm with the rest of the web tech especially SCSS and to provide a
development/deployment build environment.




On Mon, May 8, 2017 at 10:59 AM, Richard Feldman <
richard.t.feld...@gmail.com> wrote:

> I get asked if there are any sizeable open-source Elm SPA examples out
> there...so I made one!
>
> Hope it's useful: https://dev.to/rtfeldman/tour-of-an-open-source-elm-spa
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Tour of an open-source 4,000 LoC Elm SPA

[Richard Feldman]

I get asked if there are any sizeable open-source Elm SPA examples out 
there...so I made one!

Hope it's useful: https://dev.to/rtfeldman/tour-of-an-open-source-elm-spa

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Poll for Intermediate to Advanced topics that people struggle with

[Richard Feldman]

This open-source Elm SPA uses JWT authentication...maybe it's 
useful? https://dev.to/rtfeldman/tour-of-an-open-source-elm-spa

On Tuesday, May 2, 2017 at 1:18:56 PM UTC-7, Erik Lott wrote:
>
> For the folks who are struggling with authentication, are you having 
> issues with authentication in general (elm, javascript, other), or is there 
> an issue implementing authentication specifically in Elm? 
>
> On Tuesday, May 2, 2017 at 10:10:03 AM UTC-4, Alan McCann wrote:
>>
>> I echo Peter Damoc's entry + authentication (e.g. JWT)
>>
>> On Monday, April 24, 2017 at 10:06:53 AM UTC-4, Jeff Schomay wrote:
>>>
>>> Hello,
>>>
>>> I am considering doing some training material on working with Elm in 
>>> production.  I want to focus on areas that people struggle with after they 
>>> are already familiar with Elm.  What concepts continue to confuse you? 
>>>  What product requirements have been difficult to achieve with Elm?  What 
>>> is most painful about your Elm codebase?
>>>
>>> Some topics I have already thought of:
>>>
>>> - decoders
>>> - debouncing (http autocomplete input field for example)
>>> - scroll to element
>>> - testing
>>> - unwieldy update functions
>>> - api design
>>>
>>> If you have anything you'd like me to consider, please add it to the 
>>> list.  Thank you!
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.