[elm-discuss] Re: elm-make commands fails on Freebsd while working on MacOS

[Daniel Wehner]

I would recommend you to jump into slack (http://elmlang.herokuapp.com/) 
next time. Such questions can be potentially answered much quicker there.
Folks, especially in the beginners channel, have helped me a lot already. 
It is super friendly!

On Wednesday, 29 November 2017 21:01:06 UTC, Julien Wazné wrote:
>
> Thanks a lot Daniel ! 
>
> That was indeed a lowercase/uppercase issue...
>
> => I've renamed the folder to meet the module name and all has been 
> perfectly compiled
>
>
> On Tuesday, November 28, 2017 at 10:57:55 AM UTC+1, Daniel Wehner wrote:
>>
>> Hi!
>>
>> Everytime someone has a problem with X is working on MacOS, but it is not 
>> working on Linux, my intuition is: A file/folder is named in the wrong case.
>> HFS+, unlike most other file systems, doesn't make a difference between 
>> lowercase and uppercase. If you look at your folder, its called "users", 
>> while the module is using "Users".
>>
>> Maybe this is just a dump guess and the problem you have cannot be solved 
>> that easy :)
>>
>> On Monday, 27 November 2017 21:09:45 UTC, Julien Wazné wrote:
>>>
>>> Hello,
>>>
>>>
>>> I've having a problem to compile ELM code on Freebsd server while 
>>> everything is OK on my laptop (MacOS Sierra).
>>>
>>>
>>> Here's the command that fails on freebsd : elm-make --yes --output 
>>> ../static/vendor/app.js App.elm
>>>
>>>
>>> The error message is :
>>>
>>>
>>>
 *I cannot find module 'Users.Model'.*
 *Module 'Types' is trying to import it.*
 *Potential problems could be:*
 ** Misspelled the module name*** Need to add a source directory or new 
 dependency to elm-package.json*
>>>
>>>
>>> Application structure looks like this:
>>> [image: image] 
>>> 
>>>
>>> users/Model.elm starts like this:
>>> module Users.Model exposing (..)
>>>
>>>
>>> Types.elm starts like this:
>>> module Types exposing (..)
>>>
>>> import Users.Model exposing (..)
>>>
>>>
>>> elm-package.json like this:
>>> {
>>> "version": "1.0.0",
>>> "summary": "helpful summary of your project, less than 80 characters",
>>> "repository": "https://github.com/user/project.git;,
>>> "license": "BSD3",
>>> "source-directories": [
>>> "."
>>> ],
>>> "exposed-modules": [],
>>> "dependencies": {
>>> ...
>>> },
>>> "elm-version": "0.18.0 <= v < 0.19.0"
>>> }
>>>
>>>
>>> I've installed ELM on freebsd using the following commands:
>>> *as root*
>>> $ pkg install ghc hs-cabal-install
>>> *Change Path to 
>>> PATH="$PATH:/usr/local/elm/Elm-Platform/0.18/.cabal-sandbox/bin"*
>>>
>>>
>>> $ curl 
>>> https://raw.githubusercontent.com/elm-lang/elm-platform/master/installers/BuildFromSource.hs
>>>  > 
>>> BuildFromSource.hs
>>>
>>>
>>> $ runhaskell BuildFromSource.hs 0.18
>>>
>>>
>>> Any help would be appreciated.
>>>
>>>
>>> Thks !
>>>
>>

-- 
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: Approval Queue and Moderation Slowdowns

['Rupert Smith' via Elm Discuss]

On Wednesday, November 29, 2017 at 8:06:58 PM UTC, Brian Hicks wrote:
>
> The current candidate is Discourse.
>

It sounds like a great idea. There is a need for slower and less chat based 
discussion than Slack, that maintains a free searchable history. If you are 
putting in the work to give us that with a much better user experience than 
we get here, then thanks and I think it will be a success.

-- 
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] Approval Queue and Moderation Slowdowns

[Brian Hicks]

It looks neat, but first-release functionality from GitHub is always 
limited. Discourse is a known quantity at this point.

Of course, if you've used both and can make a fair comparison between them, 
I'd really love to hear your thoughts. If that's the case, could you 
contact me off-list so we can keep discussion in this thread focused?

-- 
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: Randoms as LazyLists

['Rupert Smith' via Elm Discuss]

On Thursday, November 30, 2017 at 10:29:42 AM UTC, Rupert Smith wrote:
>
> I need to use Decode.lazy to do this. Is that memoized? Is that how 
> decoders can create recursive values? Other than that, I don't see how they 
> could.
>

Do you need to start with a recursive object in Javascript, then decode 
into Elm using Decode.lazy, to produce a recursive value in Elm? 

Approximately:

var rec = { field : rec };

myapp.ports.myport.send(rec);



type Rec = 

Rec
{
field : Rec
}


port myport : (Rec -> msg) -> Sub msg



But of course, that isn't going to compile as ports won't decode tagged 
union types, and you need a tagged union type to define a recursive type.

-- 
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: Randoms as LazyLists

['Rupert Smith' via Elm Discuss]

On Monday, November 27, 2017 at 9:06:38 PM UTC, Mark Hamburg wrote:
>
> Recursive decoders have the same issues.
>

I'll see if I can get my head around that. I use recursive decoders to 
decode JSON into recursive types, but the values I output from this are not 
recursive. I did not realize it is possible to build a recursive value with 
decoders? Do you have an example?

These are mutually recursive types from a content model that I have been 
working with. If the server sends me some content with a list of 
relationships, and one of the relationships refers to the original content, 
I will end up with multiple copies of the original content in the structure 
decoded into Elm. 

I need to use Decode.lazy to do this. Is that memoized? Is that how 
decoders can create recursive values? Other than that, I don't see how they 
could.

type Content =
Content
{
slug : Maybe String
, path : Maybe String
, contentType : Maybe (ContentType)
, model : ContentModel
, relationships : Maybe (List Relationship)
, container : Maybe (List Content)
, id : Maybe String
}


type Relationship =
Relationship
{
subject : Maybe (Content)
, predicate : Maybe PredicateType
, object : Maybe (Content)
, id : Maybe String
}




-- 
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] Pointer (mouse/touch/pointer) events community coordination attempt

[Matthieu Pizenberg]

PS: duplicate of reddit for people not using reddit 
(https://www.reddit.com/r/elm/comments/7gksya/pointer_mousetouchpointer_events_community/)

Hi folks,

I've been browsing the elm packages repository in search of packages 
dealing with pointer events in general, mouse / touch / pointer. My 
conclusion is that we are all doing more or less the same things over and 
over. The timeline is the following:

First publication:

* 2016-08: knledg/touch-events
* 2016-10: mbr/elm-mouse-events
* 2016-11: mpizenberg/elm-touch-events
* 2017-05: mpizenberg/elm-mouse-events
* 2017-06: Elm-Canvas/element-relative-mouse-events
* 2017-07: zwilias/elm-touch-events
* 2017-10: mpizenberg/elm-pointer-events

Last update:

* 2017-05: 1.0.4 of mbr/elm-mouse/events
* 2017-05: 2.1.2 of knledg/touch-events
* 2017-06: 3.0.1 of mpizenberg/elm-touch-events
* 2017-06: 1.0.0 of Elm-Canvas/element-relative-mouse-events
* 2017-10: 1.0.4 of mpizenberg/elm-pointer-events
* 2017-11: 1.1.1 of mpizenberg/elm-mouse-events
* 2017-11: 1.1.0 of zwilias/elm-touch-events

As you can see, I'm partially (mpizenberg) responsible for starting 
additional mouse and touch packages. Of course, I had reasons to do so at 
the time, but now, I feel that it would be a good time to coordinate and 
have a united approach before the switch to 0.19.

To start this coordinating discussion, if you have been using some of 
these, could you explain why? for what needs? Please provide examples if 
possible. I will start with myself.

* *mpizenberg/elm-touch-events*:
  That's the first package I created. I needed multitouch support, which 
was not available in knledg/touch-events.
* *mpizenberg/elm-mouse-events*:
  My main need was to get the reliable relative positions of mouse move 
events, the most efficient way possible. It meant using the 
"offsetX/offsetY" properties of mouse events, which are not exposed by 
mbr/elm-mouse-events. Example usage was a user study, demo still available 
at http://mm17-otis.pizenberg.fr .
* *mpizenberg/elm-pointer-events*:
  Eventually, after having implemented both mouse and touch behaviors for 
each of my projects, I got tired of doing the job twice each time. So this 
library is to support the web pointer events API, that inherit from mouse 
events but support mouse, touch, and others (pens, ...) pointer events. 
Unfortunately, the API is not well supported by Safari and Firefox yet 
(https://caniuse.com/#feat=pointer) so I also made a minimalist polyfill, 
compatible with elm (https://github.com/mpizenberg/elm-pep). Example usage 
at http://elm-image-annotation.pizenberg.fr/ (code at 
https://github.com/mpizenberg/demo-elm-image-annotation).

-- 
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.