[elm-discuss] Re: Looking for a reasonable way to conditionally handle an element and all of its childern losing focus

[Jon Zeppieri]

An update, in case anyone is interested: I ended up using 
`Html.Attributes.property` to set a distinguished property (rather than an 
attribute) on any of the menu's focusable descendants and then checked for 
the existence of that property on the event's relatedTarget. So I was able 
to avoid traversing the tree, and my solution was similar to Eric's.

On Thursday, April 6, 2017 at 4:12:39 PM UTC-4, Jon Zeppieri wrote:
>
> Thanks for your response. I think our cases are a bit different -- the 
> element that you're putting a blur handler on has no children -- but I 
> might be able to use a similar approach, nevertheless. -J
>
>
> On Thursday, April 6, 2017 at 3:17:22 PM UTC-4, Eric G wrote:
>>
>> I did this by requiring an id for the menu element in config, and then 
>> checking the id of relatedTarget against this, on blur.
>>
>> See: 
>> https://github.com/ericgj/elm-autoinput/blob/master/src/Autoinput.elm#L357
>>
>> I'm not convinced it's the best way but it worked for me for the moment.
>>
>>
>> On Thursday, April 6, 2017 at 2:30:52 PM UTC-4, Jon Zeppieri wrote:
>>>
>>> I have a menu that, when it loses focus, needs to generate an update 
>>> message to close the menu. Of course the menu is composed, at the DOM 
>>> level, of several nodes. If I attach a blur or focusout handler at the 
>>> menu's root element, it is fired whenever that particular element loses 
>>> focus, even if one of its descendants gains it.  But in that case I do not 
>>> want to close the menu. There are a few ways to handle this in the DOM, 
>>> perhaps the best of which (as far as I know) is to use a focusout handler 
>>> at the root of the menu that looks to see if the event's relatedTarget is a 
>>> descendant of the root.
>>>
>>> In Elm, I can define a Json decoder that will climb the DOM tree, but 
>>> equality isn't defined over Json.Decoder.Value(s) (I think), which suggests 
>>> that the root node would need to be tagged in some way that a Json decoder 
>>> can see. And now we're getting into very hacky territory.
>>>
>>> So... is there a better way to accomplish this? (By the way, yes, I 
>>> really do want to know if the menu loses focus, not just if someone has 
>>> clicked outside of 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: Looking for a reasonable way to conditionally handle an element and all of its childern losing focus

[Jon Zeppieri]

Thanks for your response. I think our cases are a bit different -- the 
element that you're putting a blur handler on has no children -- but I 
might be able to use a similar approach, nevertheless. -J


On Thursday, April 6, 2017 at 3:17:22 PM UTC-4, Eric G wrote:
>
> I did this by requiring an id for the menu element in config, and then 
> checking the id of relatedTarget against this, on blur.
>
> See: 
> https://github.com/ericgj/elm-autoinput/blob/master/src/Autoinput.elm#L357
>
> I'm not convinced it's the best way but it worked for me for the moment.
>
>
> On Thursday, April 6, 2017 at 2:30:52 PM UTC-4, Jon Zeppieri wrote:
>>
>> I have a menu that, when it loses focus, needs to generate an update 
>> message to close the menu. Of course the menu is composed, at the DOM 
>> level, of several nodes. If I attach a blur or focusout handler at the 
>> menu's root element, it is fired whenever that particular element loses 
>> focus, even if one of its descendants gains it.  But in that case I do not 
>> want to close the menu. There are a few ways to handle this in the DOM, 
>> perhaps the best of which (as far as I know) is to use a focusout handler 
>> at the root of the menu that looks to see if the event's relatedTarget is a 
>> descendant of the root.
>>
>> In Elm, I can define a Json decoder that will climb the DOM tree, but 
>> equality isn't defined over Json.Decoder.Value(s) (I think), which suggests 
>> that the root node would need to be tagged in some way that a Json decoder 
>> can see. And now we're getting into very hacky territory.
>>
>> So... is there a better way to accomplish this? (By the way, yes, I 
>> really do want to know if the menu loses focus, not just if someone has 
>> clicked outside of 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: Looking for a reasonable way to conditionally handle an element and all of its childern losing focus

[Eric G]

I did this by requiring an id for the menu element in config, and then 
checking the id of relatedTarget against this, on blur.

See: 
https://github.com/ericgj/elm-autoinput/blob/master/src/Autoinput.elm#L357

I'm not convinced it's the best way but it worked for me for the moment.


On Thursday, April 6, 2017 at 2:30:52 PM UTC-4, Jon Zeppieri wrote:
>
> I have a menu that, when it loses focus, needs to generate an update 
> message to close the menu. Of course the menu is composed, at the DOM 
> level, of several nodes. If I attach a blur or focusout handler at the 
> menu's root element, it is fired whenever that particular element loses 
> focus, even if one of its descendants gains it.  But in that case I do not 
> want to close the menu. There are a few ways to handle this in the DOM, 
> perhaps the best of which (as far as I know) is to use a focusout handler 
> at the root of the menu that looks to see if the event's relatedTarget is a 
> descendant of the root.
>
> In Elm, I can define a Json decoder that will climb the DOM tree, but 
> equality isn't defined over Json.Decoder.Value(s) (I think), which suggests 
> that the root node would need to be tagged in some way that a Json decoder 
> can see. And now we're getting into very hacky territory.
>
> So... is there a better way to accomplish this? (By the way, yes, I really 
> do want to know if the menu loses focus, not just if someone has clicked 
> outside of 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] Looking for a reasonable way to conditionally handle an element and all of its childern losing focus

[Jon Zeppieri]

I have a menu that, when it loses focus, needs to generate an update 
message to close the menu. Of course the menu is composed, at the DOM 
level, of several nodes. If I attach a blur or focusout handler at the 
menu's root element, it is fired whenever that particular element loses 
focus, even if one of its descendants gains it.  But in that case I do not 
want to close the menu. There are a few ways to handle this in the DOM, 
perhaps the best of which (as far as I know) is to use a focusout handler 
at the root of the menu that looks to see if the event's relatedTarget is a 
descendant of the root.

In Elm, I can define a Json decoder that will climb the DOM tree, but 
equality isn't defined over Json.Decoder.Value(s) (I think), which suggests 
that the root node would need to be tagged in some way that a Json decoder 
can see. And now we're getting into very hacky territory.

So... is there a better way to accomplish this? (By the way, yes, I really 
do want to know if the menu loses focus, not just if someone has clicked 
outside of 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: elmvm (Elm Version Manager)

[Rehno Lindeque]

I'm a little surprised that more people haven't tried nix for pinning their 
Elm tools... E.g. pop a shell.nix file like this into your project root and 
you'll have it pinned to elm 0.18 indefinitely:

{
  bootpkgs ? (import  {}).pkgs
}:


let
  pkgs =
import
  (bootpkgs.fetchFromGitHub {
owner = "NixOS";
repo = "nixpkgs";
rev = "6018464c49dc60b1779f10a714974dcb4eb21c30";
sha256 = "1fq9zarsanislnsn9vrn4k852qk1ygckxqdzf1iywgsbp2a5hkn1";
  })
  {
overlays = [
  (self: super:
let
  inherit (self) fetchurl fetchFromGitHub callPackage haskell;
  nodeEnv = callPackage 
"${self.path}/pkgs/development/node-packages/node-env.nix" {};
in
{
  elmPackages = super.elmPackages // {
elm-reactor =
  haskell.lib.overrideCabal super.elmPackages.elm-reactor
(drv:
  {
# I'm using my own fork of elm-reactor that enables 
ports, because productivity
src = fetchFromGitHub
  {
owner = "rehno-lindeque";
repo = "elm-reactor";
sha256 = 
"0jfhg8gsy3r1myzls5ilx4i87d52lfr05l5736jxvjq926bfv3a2";
rev = "9a1887d60ec3753e25c10084c7ad25f566e5f0a8"
;
  };
  }
);
elm-format =
  haskell.lib.overrideCabal super.elmPackages.elm-format
(drv:
  {
src = fetchFromGitHub
  {
owner = "avh4";
repo = "elm-format";
sha256 = 
"0lman7h6wr75y90javcc4y1scvwgv125gqqaqvfrd5xrfmm43gg8";
rev = "e452ed9342620e7bb0bc822983b96411d57143ef"
;
  };


postInstall =
  ''
  ln -s $out/bin/elm-format-0.18 $out/bin/elm-format
  '';
  }
);
elm-oracle =
  nodeEnv.buildNodePackage {
name = "elm-oracle";
packageName = "elm-oracle";
version = "1.1.1";
src = fetchurl {
  url = 
"https://registry.npmjs.org/elm-oracle/-/elm-oracle-1.1.1.tgz;;
  sha1 = "61f6d783221b4ad08e7d101d678b9d5a67d3961c";
};
  };
  };
}
  )
];
  };
in
  pkgs.stdenv.mkDerivation
{
  name = "shell";
  version = "0.0.0";
  buildInputs =
( with pkgs.elmPackages;
  [
elm-make
elm-package
elm-repl
elm-reactor
elm-format
elm-oracle
  ]
);
}


As a bonus you can get to add extra goodies like elm-format, elm-oracle, 
your own personalized fork of elm-reactor or other non-elm tools perhaps 
(grunt, webpack, nodejs, etc...).

Just a thought anyway :)


On Thursday, April 6, 2017 at 4:30:02 PM UTC, Nicholas Hollon wrote:
>
> There needs to be a better advertising of the ecosystem both in terms of 
>> tools and in terms of packages.
>>
>
> I agree with this, but the effort needs to start with the library authors.
>
> As far as I can tell (searching this list, Google, & r/elm), Erik is the 
> only one of these authors who has publicized their work in any way.
>
> If you invent a wheel, you need to tell people about it. You can't just 
> leave it lying in your front yard and hope that people walk by your house 
> :-)
>
>
>
> On Thursday, April 6, 2017 at 6:34:53 AM UTC-7, Peter Damoc wrote:
>>
>> On Thu, Apr 6, 2017 at 3:43 PM, Eirik Sletteberg  
>> wrote:
>>
>>> None of these tools are mentioned in the Elm documentation. It only 
>>> points to installers and the npm module.
>>
>>
>> Exactly my point. 
>> There needs to be a better advertising of the ecosystem both in terms of 
>> tools and in terms of packages. 
>>
>>
>> -- 
>> 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] Re: elmvm (Elm Version Manager)

[Nicholas Hollon]

>
> There needs to be a better advertising of the ecosystem both in terms of 
> tools and in terms of packages.
>

I agree with this, but the effort needs to start with the library authors.

As far as I can tell (searching this list, Google, & r/elm), Erik is the 
only one of these authors who has publicized their work in any way.

If you invent a wheel, you need to tell people about it. You can't just 
leave it lying in your front yard and hope that people walk by your house 
:-)



On Thursday, April 6, 2017 at 6:34:53 AM UTC-7, Peter Damoc wrote:
>
> On Thu, Apr 6, 2017 at 3:43 PM, Eirik Sletteberg  > wrote:
>
>> None of these tools are mentioned in the Elm documentation. It only 
>> points to installers and the npm module.
>
>
> Exactly my point. 
> There needs to be a better advertising of the ecosystem both in terms of 
> tools and in terms of packages. 
>
>
> -- 
> 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] Re: ANN: TypedSvg

[Duane Johnson]

>
>
>> - separate out the Animation elements and attributes into their own module
>> - continue to add length-unit-specific modules like InPx and InEm (InPt,
>> InMm, etc.)
>> - move `text` element from Core to regular elements (TypedSvg)
>>
>
> These things sound fairly structural, so perhaps best left to you to do,
> as you have the vision for it.
>
>

Sounds quite reasonable :)


> - fill in missing documentation on all elements and attributes
>> - add helpful functions as we go to the TypedSvg.Extra module (currently
>> only `centeredImage` resides there)
>>
>
> These sound more like the things that I could contribute to at the moment.
> I see lots of empty doc comments. :-)
>
>
Perfect!

Thanks,
Duane

-- 
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: ANN: TypedSvg

['Rupert Smith' via Elm Discuss]

On Thursday, April 6, 2017 at 3:44:56 PM UTC+1, Duane Johnson wrote:
>
> On Thu, Apr 6, 2017 at 8:03 AM, 'Rupert Smith' via Elm Discuss <
> elm-d...@googlegroups.com > wrote:
>
>> What are the immediate todos that need worked on? Is there a list of 
>> issues on the github project, for example?
>>
>
> That's a good idea. I should write that up. For now, here's what I'm 
> thinking:
>
> - separate out the Animation elements and attributes into their own module
> - continue to add length-unit-specific modules like InPx and InEm (InPt, 
> InMm, etc.)
> - move `text` element from Core to regular elements (TypedSvg)
>

These things sound fairly structural, so perhaps best left to you to do, as 
you have the vision for it.
 

> - fill in missing documentation on all elements and attributes
> - add helpful functions as we go to the TypedSvg.Extra module (currently 
> only `centeredImage` resides there)
>

These sound more like the things that I could contribute to at the moment. 
I see lots of empty doc comments. :-) 

-- 
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: ANN: TypedSvg

[Duane Johnson]

On Thu, Apr 6, 2017 at 8:03 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Saturday, April 1, 2017 at 5:15:47 AM UTC+1, Duane Johnson wrote:
>>
>> The short term goal is to make a typed SVG library (as mentioned earlier,
>> fully typed and documented). Medium-term, I'd like to adopt some sensible
>> module partitions that help segregate functionality into logical units
>> (e.g. core graphics, animations, filters). The long term goal is to create
>> a pleasant and intuitive SVG library, something that will come from seeing
>> how we all use this in practice.
>>
>
> What are the immediate todos that need worked on? Is there a list of
> issues on the github project, for example?
>

That's a good idea. I should write that up. For now, here's what I'm
thinking:

- separate out the Animation elements and attributes into their own module
- continue to add length-unit-specific modules like InPx and InEm (InPt,
InMm, etc.)
- move `text` element from Core to regular elements (TypedSvg)
- fill in missing documentation on all elements and attributes
- add helpful functions as we go to the TypedSvg.Extra module (currently
only `centeredImage` resides there)


> I've set myself up an elm-reactor project to start having a play around
> with it. Will be aiming to render some of the various diagrams I need, and
> happy to start filling in the blanks once I run off the end of the road...
>

Awesome! I look forward to your feedback and help.

Duane

-- 
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: ANN: TypedSvg

['Rupert Smith' via Elm Discuss]

On Saturday, April 1, 2017 at 5:15:47 AM UTC+1, Duane Johnson wrote:
>
> The short term goal is to make a typed SVG library (as mentioned earlier, 
> fully typed and documented). Medium-term, I'd like to adopt some sensible 
> module partitions that help segregate functionality into logical units 
> (e.g. core graphics, animations, filters). The long term goal is to create 
> a pleasant and intuitive SVG library, something that will come from seeing 
> how we all use this in practice.
>

What are the immediate todos that need worked on? Is there a list of issues 
on the github project, for example?

I've set myself up an elm-reactor project to start having a play around 
with it. Will be aiming to render some of the various diagrams I need, and 
happy to start filling in the blanks once I run off the end of the road...

-- 
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] How to generate an html select using Dict.foldl

[Brian Carroll]

The smallest change to fix this is to replace a pair of parentheses with 
brackets around the `option`, as below.

import Dict
import Html exposing ( .. )
import Html.Attributes exposing ( .. )


data = Dict.fromList [ ( 1, "Cat"), ( 2, "Jerry" ), ( 3, "Hat" ) ]


type Message = Message


listing : Html Message
listing =
select [ multiple False, size 10 ]
( Dict.foldl ( \key val html -> html ++ [ option [ value ( toString 
key ) ] [ text val ] ] ) [] data )

The `++` operator takes two lists, and this fix turns its second argument 
into a list containing just one item.
(It works differently from the `::` operator, which takes a single item and 
a list, which trips me up sometimes.)

So that answers your direct question. *BUT* I think it's better practice 
here to use `foldr` and `::` instead of `foldl` and `++`. The `::` operator 
doesn't have to create a whole new list on every iteration, whereas `++` 
does. Good idea to get into the habit of spotting this. I try to avoid `++` 
inside an iteration because it contains an iteration itself.

So I would do this:


import Dict
import Html exposing ( .. )
import Html.Attributes exposing ( .. )


data = Dict.fromList [ ( 1, "Cat"), ( 2, "Jerry" ), ( 3, "Hat" ) ]


type Message = Message


listing : Html Message
listing =
select [ multiple False, size 10 ]
( Dict.foldr ( \key val html -> ( option [ value ( toString key ) ] 
[ text val ] ) :: html ) [] data )















On Monday, March 27, 2017 at 10:45:21 AM UTC+1, Witold Szczerba wrote:
>
> Here you are, working solution:
> https://runelm.io/c/4r0
>
> In case runelm.io becomes unavailable:
>
> module Main exposing (..)
>
> import Dict
> import Html exposing (..)
> import Html.Attributes exposing (..)
>
>
> data =
> Dict.fromList [ ( 1, "Cat" ), ( 2, "Jerry" ), ( 3, "Hat" ) ]
>
> listing : Html msg
> listing =
> select [ multiple False, size 10 ]
> (data
> |> Dict.toList
> |> List.map
>  (\( k, v ) -> option [ value (toString k) ] [ text v ])
> )
>
>
> main : Html msg
> main =
> listing
>
>
>
> Regards,
> Witold Szczerba
>
>
> On Mon, Mar 27, 2017 at 12:45 AM, jadski  > wrote:
>
>> I'm trying to render an html select from a Dict in Elm 0.18, and the 
>> compiler complains because Html Msg is not appendable:
>>
>>
>> 12| html ++ ( option [ value ( toString key ) ] [ text val ] 
>> ^^
>> (++) is expecting the right side to be a:
>> appendable
>> But the right side is:
>> Html msg
>>
>>
>> This should be simple but it's proving frustrating and not obvious - can 
>> anyone provide the correct solution for the sample file below? Thanks in 
>> advance.
>>
>>
>>
>> import Dict
>> import Html exposing ( .. )
>> import Html.Attributes exposing ( .. )
>>
>>
>> data = Dict.fromList [ ( 1, "Cat"), ( 2, "Jerry" ), ( 3, "Hat" ) ]
>>
>>
>> type Message = Message
>>
>>
>> listing : Html Message
>> listing =
>> select [ multiple False, size 10 ]
>> ( Dict.foldl ( \key val html -> html ++ ( option [ value ( 
>> toString key ) ] [ text val ] ) ) [] data )
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> 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...@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] Responsive/Mobile styles for package.elm-lang.org

[Martin Liberg]

Hello!

I'd like to make package.elm-lang.org more nice to view on a mobile device. 
Is this something we want?


 

*Background*

I have been looking for ways to contribute to the Elm community and have 
found that making the package site more mobile friendly would be something 
nice.

I found some older posts addressing the website:

   - 
   
https://groups.google.com/forum/#!searchin/elm-discuss/website|sort:relevance/elm-discuss/yjOEhxbQAlM/sexA7n2O9goJ
   - 
   
https://groups.google.com/forum/#!searchin/elm-discuss/website%7Csort:relevance/elm-discuss/nDpuEMEOazA/u7qjleRQwbAJ
   
I guess what's being discussed here has already been implemented or canned?

My idea is to make a smaller improvement to the package site only: making 
it slightly nicer to view on smaller screens.


-- 
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: elmvm (Elm Version Manager)

[Peter Damoc]

On Thu, Apr 6, 2017 at 3:43 PM, Eirik Sletteberg 
wrote:

> None of these tools are mentioned in the Elm documentation. It only points
> to installers and the npm module.


Exactly my point.
There needs to be a better advertising of the ecosystem both in terms of
tools and in terms of packages.


-- 
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] Re: elmvm (Elm Version Manager)

[Eirik Sletteberg]

None of these tools are mentioned in the Elm documentation. It only points to 
installers and the npm module.

-- 
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: elmvm (Elm Version Manager)

[Peter Damoc]

On Thu, Apr 6, 2017 at 2:00 PM, Richard Wood  wrote:

> Very healthy having competing options in the ecosystem
> :)
>
> No, this is against Elm philosophy as I understand it.
Elm aims to have one, excellent option rather than a plethora of slightly
different libraries/tools.

The fact that there are so many tools for this simple task is actually
indicative of problems in the ecosystem.
It seams that people interested in a certain functionality don't find it
even if it exists.





-- 
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] Re: Elm events 2017

[Noah Hall]

Mine is going to be different, and the CFP is open, so I doubt there
will be much duplication :) Luke is also going to be talking in Oslo,
and they're not going to speak at ElmEurope. The goal is to have a
complementary conference to ElmEurope, so people can go to both :).
You can check out the call for papers here if you're interested in
submitting one, too ->
https://docs.google.com/forms/d/e/1FAIpQLSdgMw1ymqiM92UtrYEAVBGisbJBuv9ers8Q36qIAQSga9dX5A/viewform?c=0=1

On Thu, Apr 6, 2017 at 12:58 PM, Richard Wood  wrote:
> Hi Noah
>
> Is Oslo likely to be the same talks as the speakers did at Elm Europe?
> If not I'll come to that as well.
>
> Cheers
> Richard
>
> --
> 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.

Re: [elm-discuss] Re: elmvm (Elm Version Manager)

[Richard Wood]

Very healthy having competing options in the ecosystem
:)

-- 
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: Elm events 2017

[Richard Wood]

Hi Noah

Is Oslo likely to be the same talks as the speakers did at Elm Europe?
If not I'll come to that as well.

Cheers
Richard

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