[elm-discuss] Elm Bootstrap v2.0.0

[Magnus Rundberget]

Hi All, 

I have already posted on slack and reddit, but just in case some people 
have missed it...

Yesterday I released elm-bootstrap version 2.0.0. Elm Bootstrap is an Elm 
package for working with the upcoming Twitter Bootstrap 4 
 CSS framework in a fairly type safe 
manner.
Version 1.0.0 already covered quite a lot of the "components/widgets" in 
Twitter Bootstrap, so v2.0.0 isn't a huge release 

What's new:
- Popover/Tooltip support
- Input groups (inputs with addons)
- Support for radio buttons and checkbox buttons
- Html.Keyed support in Grids, Tables and List groups 
- and a few other minor improvements


Docs: http://elm-bootstrap.info
Repo: https://github.com/rundis/elm-bootstrap

There is also the #elm-bootstrap channel on Slack if you have any 
questions/issues etc 

cheers and have a lovely weekend
-magnus

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

[Magnus Rundberget]

Nice !

-magnus

On Thursday, 30 March 2017 17:35:32 UTC+2, Duane Johnson wrote:
>
> Hi all,
>
> I've been working on a TypedSvg package here:
>
> http://package.elm-lang.org/packages/canadaduane/typed-svg/2.0.1
>
> Its intent is to replace `elm-lang/svg` with a fully typed and documented 
> SVG package. There's still a lot of work to do (the SVG spec is huge) but 
> I'm pretty happy with the progress that's been made. I'm announcing this 
> now so that if others are interested in a similar package, we can 
> consolidate effort and help one another rather than duplicate effort.
>
> Thanks,
> Duane Johnson
>
>

-- 
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: Guidance for using "type alias" vs. single-constructor union types

[Magnus Rundberget]

Hi, 

I haven't given it too much though, but I do think there is some very nice 
benefits to using single constructor union types.
In you case, you might avoid some of the noise by adding helper functions 
to work on values of the type (maybe you need a mapFoo helper function).
I found this blog post quite enlightening : 
https://robots.thoughtbot.com/lessons-learned-avoiding-primitives-in-elm

cheers
- magnus



On Monday, 16 January 2017 09:40:13 UTC+1, Austin Bingham wrote:
>
> I recently had to chase down a bug where I was calling a function with the 
> arguments in the wrong order. The function's declared argument types were 
> each an alias for string, so the compiler happily let me swap them. In 
> order to avoid this in the future, I'm experimenting with using 
> single-constructor union types in place of aliases, e.g. instead of "type 
> alias Foo = String" I'm using "type Foo = Foo String". 
>
> This seems to work well for helping me enforce the kind of type safety I'm 
> looking for. However, it seems to force me to do a lot more 
> de/restructuring of function arguments, and it feels a bit graceless. For 
> example, a (contrived) function that was originally like this:
>
> aFunc : Foo -> Foo
> aFunc f = 
> let
> x = somethingWithAString f
> in
> somethingWithAFoo x f
>
> becomes:
>
> aFunc : Foo - > Foo
> aFunc (Foo f) =
> let
> x = somethingWithAString f
> in
> -- Have to "repack" f into a Foo
> somethingWithAFoo x (Foo f)
>
> That is, if I want to thread something of type "Foo" through calls while 
> also using its data, I have to "repack" it.
>
> So my question is: are there better ways to do this? Are there better 
> patterns for a) adding the type-safety I want while b) avoiding the extra 
> noise? I know some languages (e.g. clojure) let you destructure bindings 
> *and* bind a name to the un-destructured thing. Something like that might 
> help.
>
> Any advice (including "you're doing it wrong!") would be appreciated.
>
> Austin
>

-- 
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] elm-lang/Navigation with hash and query string

[Magnus Rundberget]

You could do something like this:
https://github.com/rundis/albums/blob/master/frontend/src/Routes.elm#L84
Use it like this 
https://github.com/rundis/albums/blob/master/frontend/src/ArtistListing.elm#L100
And wire it up like this.
https://github.com/rundis/albums/blob/master/frontend/src/Main.elm#L96
And https://github.com/rundis/albums/blob/master/frontend/src/Main.elm#L136

Cheers
-magnus

-- 
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] Proposed addition for Task package

[Magnus Rundberget]

I'm definately with Wouter on this one.

Using tasks to do something that isn't a side-effect sounds much more like 
a code smell than using plain old function calls and function return values 
to compose your logic (when that is possible, which I would imagine would 
be true most of the time, if not all the time when there aren't any 
side-effects involved). 

I've seen this argument a while back related to people using a super nested 
TEA and getting tiered of boiler-plate (function calls and function return 
values), and using Tasks as a get out of jail card (for "child-parent", 
"child-sibling" etc communication).   Resorting to tasks might be Easy (at 
hand), but it's certainly not Simple (especially considering the 
asynchronous scheduler).

I respectfully disagree. Depending on the application, this either may not 
> be possible or would be a terrible code smell. I honestly think the above 
> suggestion would be worse than chaining another Cmd msg. Sending another 
> Cmd msg is clean and follows the Elm architecture.
>

It would be interesting to see some concrete examples of were it would not 
be possible or a code smell to use functions (rather than tasks) for 
non-side effecty things. Maybe I can be convinced.
  

Another case that wouldn't work out so well for is the init function. The 
> init function returns a (model, Cmd msg). I think it'd be much cleaner for 
> the init function to call sendMsg (or equivalent) instead of the init 
> function calling either my update function or the function that would be 
> called for that msg.
>

Why do you think that ? 

> ​
>>
>

-- 
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: Errors when using Chart.js in a port subscription

[Magnus Rundberget]

I'm guessing that you are contructing the div inside your Elm app and that 
the virtual dom might not have completed rendering/updating the div in 
question before you try using it on the js side of things.
Maybe just try to introduce a setTimeOut on the js sider or something to 
that effect, so that you allow elm time to render the div ?

-magnus



On Wednesday, 9 November 2016 09:11:06 UTC+1, Austin Bingham wrote:
>
> I'm trying to use Chart.js from my elm app, and I'm running into some 
> errors that I can't sort out. In short, I've got a elm-to-javascript port 
> that takes in a data structure describing the chart I want to draw. Then on 
> the javascript side I've got a subscription to that port that renders that 
> chart. A trimmed version of that function looks like this:
>
> var brooksChart = null;
>
> function chart(val) {
>  var datasets = ... // calculate data sets from `val`
>
>  var ctx = document.getElementById("bark-spider-canvas");
>
>  if (brooksChart) {
>  brooksChart.destroy();
>  }
>
>  brooksChart = new Chart(ctx, {
>  type: 'line',
>  data: {
>  datasets: datasets
>  },
>  options: {
>  scales: {
>  xAxes: [{
>  type: 'linear',
>  position: 'bottom'
>  }]
>  }
>  }
>  });
>  };
>  
> When I run this and pass data into the port, the chart is rendered 
> correctly. But, at some point after the "new Chart(...)" call completes, I 
> get errors in the javascript console like this:
>
> bark_spider.js:8139 Uncaught TypeError: Cannot read property 'childNodes' 
> of undefined(…)addDomNodesHelp @ bark_spider.js:8139addDomNodesHelp @ 
> bark_spider.js:8147addDomNodesHelp @ bark_spider.js:8147addDomNodesHelp @ 
> bark_spider.js:8147addDomNodesHelp @ bark_spider.js:8147addDomNodes @ 
> bark_spider.js:8066applyPatches @ bark_spider.js:8195updateIfNeeded @ 
> bark_spider.js:7232
>
> The fallout of this seems to be that the elm runtime gets confused, at 
> least insofar as I don't receive Msgs that I ought to be receiving. In 
> fact, if I take the call to "new Chart(...)" out, then my app works just 
> fine (except of course that charts aren't rendered).
>
> So, does anyone have any idea what I'm going wrong? This seems like pretty 
> standard use of both ports and chart.js, but clearly I'm missing something.
>

-- 
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: Ecto enforce unwanted "sort by" when "distinct" is used

[Magnus Rundberget]

I'm sure someone on here can answer your question, I'm just curious how 
this relates to Elm ? Isn't this an Elixir related question ?

cheers
-magnus

On Monday, 31 October 2016 01:30:36 UTC+1, Jaroslaw Zabiello wrote:
>
> Why Ecto is  adding sort by rule for the column used in distinct?
>
> Repo.all(from b in Book, select: b.name, distinct: b.name, order_by: b.sort)
>
>
> SELECT DISTINCT ON (b0."name") b0."name" FROM "books" AS b0 ORDER BY 
> *b0."name",* b0."sort" []
>
>
> Repo.all(from b in Book, select: b.name, distinct: b.name, order_by: [b.sort, 
> b.name])
>
>
> SELECT DISTINCT ON (b0."name") b0."name" FROM "books" AS b0 ORDER BY* 
> b0."name"*, b0."sort", b0."name"
>
> It looks like a bug, isn't it?
>
> --
> JZ
>

-- 
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: Which text editor do you prefer for Elm?

[Magnus Rundberget]

Hi 

Author of elm-light  the Elm plugin 
for Light Table here. I'm not 100% sure, but I think I might be right when 
saying that currently my plugin provides the widest range of Elm related 
features at the moment.
A lot of folks have never heard of Light Table and understandably so, it's 
probably most known in the Clojure community.  Light Table's biggest 
strength is that it's super hackable (like emacs hackable), that's what got 
me interested in the first place. However it's not as polished as say 
VSCode or Atom (which is build on a similar architecture). It is written in 
ClojureScript, which is a dynamically typed languge Personally I think that 
it is a great functional language. (Btw if someone ever considers writing a 
modern editor in Elm, count me in.)  I think it's awesome to be able to 
tweak the most important tool I use everyday, but of course I also 
understand that most people probably aren't interested in optimizing their 
editor and wants more an out of the box experience. Hence why I created the 
plugin in the first place.

Anyways I'm straying.  Choosing to learn a new editor is a leap of faith 
and obviously requires some investment. Number of features is probably not 
the most important metric for selecting an editor, but to the degree it 
carries some weight it might be worth at least checking out/skimming the 
Docs  for elm-light :-)


I do want to voice a slight concern regarding a feature comparison matrix 
though. We have to be careful that we don't end up comparing apples and 
oranges. Example
- Autocomplete : *check*. What does that mean, are their implementation/use 
equally good because they all have it ? Some editors might have context 
sensitive completions, but others might just use a more generic completions 
engine that only covers 3.rd party packages and no or little context 
awareness. Both are useful, but maybe they shouldn't be equally weighted ?

It's hard to convey these nuances in a feature comparison matrix. Worth 
keeping in mind if nothing else. 

*Editor future:*
- There is work in progress to create an Elm AST (some implementations are 
out there already), but I'm talking about an community / "official" one 
probably powered/enriched by the Elm compiler. It's going to take some 
time, but I think this will allow for some really awesome editor features 
and lots of innovation going forward. We just need a bit of patience in the 
tooling space, Elm is still a young language !
- Lot's of editors are using https://github.com/ElmCast/elm-oracle to drive 
Elm features. It's a great first step, but eventually I believe that or 
something similar might evolve into something a lot more powerful that will 
benefit all editors.

Editor support for Elm is not fantastic today, but it's steadily improving 
and I'm confident the future is bright !

If you do decide to give Light Table a try. Let me know how it went. 
(@mrundberget on slack)

cheers 
-magnus








- 














On Tuesday, 4 October 2016 18:46:13 UTC+2, Keith Lazuka wrote:
>
> I use (and contribute to) the Elm plugin for IntelliJ 
> . It has rename support 
> (although not for modules/files yet). Detects unresolved references and 
> suggests a quick fix that adds the correct import for you. Has great 
> go-to-definition support. I have elm-format setup as an external tool and 
> bound to a keybinding in the editor.
>
>
> On Tuesday, October 4, 2016 at 7:24:09 AM UTC-7, Dénes Harmath wrote:
>>
>> I created a Google Spreadsheet for this, feel free to edit it: Elm 
>> editor plugin comparison 
>> 
>>
>> 2016. okt. 4. dátummal, 16:12 időpontban OvermindDL1  
>> írta:
>>
>> Are there a set of wiki pages that such a table could be set up at? 
>>  Perhaps at the elm-lang.github.io or so?  This would be a good setup to 
>> add.  I know Atom plugins have all the below features for Elm (and more 
>> features).
>>
>>
>> On Tuesday, October 4, 2016 at 6:35:38 AM UTC-6, Andrew Radford wrote:
>>>
>>> I'm also using this, but one thing that I can't figure out is how to 
>>> copy code to the elm repl. Never works if you copy more than one line...
>>>
>>> Would love to see a matrix of capabilities for common editors, covering 
>>> things like
>>>
>>> * Intellisense
>>> * Send to Repl
>>> * Go to definition
>>> * Rename Refactor
>>> * Elm-format 
>>>
>>> etc etc.
>>>
>>> I think it would be a good tool for beginners (like me) to get going 
>>> faster. They won't need to 'survey the landscape' as much.
>>>
>>> On Tuesday, 4 October 2016 12:57:15 UTC+1, Witold Szczerba wrote:

 Recently I've tried the VS Code. Installed the elm plugin and it works 
 like a charm. I'm positively surprised. 


>
>> -- 
>> You received this message because you are 

[elm-discuss] Re: Can anyone get linter-elm-make working on Atom?

[Magnus Rundberget]

Hi !

Have you tried running `elm-make src/elm/Main.elm --output /dev/null` on 
your project ? 
I'm getting all kind of errors due to erroneous module naming all over the 
place.

in Main.elm you try to import Main.Types, but Types.elm lives in the root 
folder (src/elm) so it should be named Types in it's module declaration and 
when importing it from Main it should be import Types.
... and so on and so on

Maybe you used to have a Main folder at some point ? 


bottom line. Make sure your project can build on the command line, then I'm 
sure the atom plugin will be much more cooperative !

-magnus



On Thursday, 29 September 2016 11:24:30 UTC+2, Rupert Smith wrote:
>
> On Wednesday, September 28, 2016 at 4:42:32 PM UTC+1, OvermindDL1 wrote:
>>
>> It works fine for me (also get Atom's elmjutsu plugin, made by same 
>> person as linter-elm-make and they work wonderfully together).
>>
>> So first of all the src directory in elm-package.json should be as it 
>> normally is in elm-package.json, the root directory of all your elm source, 
>> mine for example is:
>> ```json
>> "source-directories": [
>> "web/elm"
>> ],
>> ```
>> In linter-elm-make I also have 'Lint as you type' enabled, 'Always 
>> compile main' enabled (be sure to set your project main file(s) as per 
>> linter-elm-make instructions!  I.E. open the file, open command pallete, 
>> type 'main' and choose "Linter Elm Make: Set Main Paths".  With that it 
>> works wonderfully and real-time for me (and again, get elmjutsu).
>>
>
> Thanks for the advice. I tried all the above, also setting a 'work 
> directory'. It still doesn't work... perhaps I just need to add more stuff 
> to Main Paths? or can one even set /src/**/*.elm as the main path?
>
> Here is an example project set up with linter-elm-make that is not working:
>
> https://github.com/rupertlssmith/thesett_style_lab 
>

-- 
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] ANN: elm-light 0.4.0 - AST driven Elm features in Light Table

[Magnus Rundberget]

Hi !

After quite a few weeks of working evenings and nights I'm finally ready to 
announce the 0.4.0 release of the Elm language plugin for Light Table 
.
I guess the big thing is that I've created a parser (using a parser 
generator, PEG.js) to give me the possibility to let ASTs drive various 
features.
(I don't see my parser as a long term solution, I believe that the best 
solution for the Elm community would be to help out with exposing the AST 
stuff already done in elm-format !
I just wanted to get started and learn stuff to gather some experience and 
discover use cases for what a proper AST might give)

A feature hightlight includes:
- Context aware auto-completion
- Feature to expose/unexpose top level declarations (and get visual 
feedback in your editor on what is being exposed from you module)
- A quick import shortcut feature
- Of course find usages and jump to definition
- The docs have now moved to a GitBook 
 
 
If you are interested in a demo and/or read a little more in-depth about my 
journey towards 0.4.0 here's a combined BlogCast:
http://rundis.github.io/blog/2016/elm_light_ast.html

I'm not running out of ideas for features going forward, but if you have 
some pet ideas (that are achievable without the elm compiler and it's type 
inferencer :-), do let me know here or in the github issue tracker.


cheers
-magnus

-- 
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: How to order imports?

[Magnus Rundberget]

Haha funny this question popped up here now.

Yesterday I was implementing a "sort imports" feature for elm-light (Elm 
plugin for Light Table). I was pondering the same thing.
Ended up implementing it like this:
- Project modules first (sorted alphabetically)
- The External modules sorted alphabetically

I guess I need to make this configurable until a de-facto std emerges.


An easy option would be if elm-format did it, but elm-format doesn't to the 
best of my knowledge (and IMHO shouldn't have to) have knowledge about your 
project. So sorting alpahbetically no problem.

I'd vote for something simple, you probably won't and shouldn't have a ton 
of imports in a module anyway.







On Friday, 2 September 2016 01:54:35 UTC+2, John Bugner wrote:
>
> Is there a "right" (de-jure or de-facto) way to order imports? If not, 
> then how do you order them?
>
> As I see it, there's two kinds of imports:
> (1) local imports (Main, Engine, EnginePart, etc)
> (2) and standard imports (List, Dict, Maybe, etc)
>
> I put the local imports first, then an empty line, then the standard 
> imports.
>
> And, is there a right way to order each import within its set? That is, 
> should one try to "logically" order them, like having 'import List' come 
> before 'import Array', because the former is more "basic" than the latter? 
> Or should they just be in alphabetical order?
>
> I prefer to logically order imports; I try to order them consistently in 
> every project, but it doesn't always happen.
>
>

-- 
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: Will server side elm be a game changer?

[Magnus Rundberget]

My bad I read server side *rendering• in my mind. server side elm is a 
different beast alltogether and who knows.

-- 
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: Will server side elm be a game changer?

[Magnus Rundberget]

Check out this thread :
https://groups.google.com/forum/m/#!topic/elm-dev/u66_K3AbqIM

-- 
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: Child model change propagation problem in elm architecture

[Magnus Rundberget]

Hi, 

I would suggest reading through this thread, in particular the answers 
provided by Richard.
https://groups.google.com/forum/#!topic/elm-discuss/_cfOu88oCx4

my tldr in your case: Seriously consider whether you really need to 
separate things as components vs just separating out functions and keeping 
your model flatter.
(your calculate functions should not take in a nested model imho, that's a 
sure way to make it brittle !) 

-magnus



On Wednesday, 17 August 2016 04:51:15 UTC+2, Jacky See wrote:
>
>
> Hi, I'm a new comer to elm. I try to build application using elm and have 
> some problem on component.
>
> Suppose I'm building an BMI calculator, initially I have a model
>
> type alias Model = { weight:Int, height:Int }
>
> The rendering is just an two input[type=number].
> The result is rendered by a pure function at the main app:
>
> calclulate model = 
>   let 
> h = (toFloat model.height) / 100
> w = toFloat model.weight
>   in
> toString (round (w / (h*h)))
>
>
> One day a decision made to change those two inputs into a component of its 
> own (BmiConfig). 
> So the models become
>
> --at main app 
> type alias Model = { bmiConfig: BmiConfig.Model ... }
>
> --at BmiConfig
> type alias Model = {weight:Int, height:Int}
>
> We need to to the work of connecting Msg, etc. The calculate function 
> becomes
>
> calclulate model = 
>   let 
> h = (toFloat model.config.height) / 100
> w = toFloat model.config.weight
>   in
> toString (round (w / (h*h)))
>
>
> Another a change comes and requesting add +/- button to the number input. 
> We try to make a small generic component NumberInput. Models become:
>
> --at main app 
> type alias Model = { bmiConfig: BmiConfig.Model ... }
>
> --at BmiConfig
> type alias Model = {weight:NumberInput.Model, height:NumberInput.Model}
> 
> --at NumberInput
>  type alias Model = {value:Int, max:Int, min:Int,  }
>
> The calculate function needs to be changed again:
>
> calculate model =
>   let 
> h = (toFloat model.config.height.value) / 100
> w = toFloat model.config.weight.value
>   in
> toString (round (w / (h*h)))
>
> It seems to me that every refactoring to extract component would lead to a 
> propagation
> of change all the ways from child to its parents. Parents need to know the 
> data
> structure of child to do calculation too. Is that the correct way of 
> applying the elm architecture?
> Have I missed something?
>  
>
>
>
>

-- 
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] Elm Brackets extension

[Magnus Rundberget]

Readme is at the plugin home page : https://github.com/rundis/elm-light
(I've also created a gitter room).

with regards to the docs preview feature I think you mean the docs that 
atom gets from packages using elm-oracle. AFAIK it doesn't currently have 
package doc preview for docs of packages that you yourself author. Ie. 
something you can achieve through : 
http://package.elm-lang.org/help/docs-preview, but in elm-light you can do 
it wysiwyg style in the editor.

Anyways if you read through the readme you'll see more features (none of 
which are things you'd use very often, but still I've found them useful 
from time to time).

oh and finally, I think we'll have to agreed to disagreed on 
clojure(/clojurescript) !

cheers
-magnus





On Friday, 22 July 2016 17:10:08 UTC+3, OvermindDL1 wrote:
>
> Inline
>
> On Friday, July 22, 2016 at 2:24:34 AM UTC-6, Magnus Rundberget wrote:
>>
>> elm-light author here. Shouldn't really contribute anymore to the 
>> off-topicness here, but can't resist commenting this bit;
>>
>> On Thursday, 21 July 2016 19:26:49 UTC+3, OvermindDL1 wrote:
>>>
>>> I just tried out LightTable (never seen it before), it has support for 
>>> almost no language that I use other than Elm, 
>>>
>> fair enough
>>
>  
> Yeah I am surprised at the lack of plugins actually, is it really new?
>
>
> On Friday, July 22, 2016 at 2:24:34 AM UTC-6, Magnus Rundberget wrote: 
>
>>  
>>
>>> and the Elm support did not auto-complete well, did not auto-format, and 
>>> did not auto-lint as I typed, thus I am unsure what is has over Atoms 
>>> plugins?
>>>
>>
>> Maybe you didn't that much time with the readme ? The readme explains how 
>> to set it up to lint as you save, which I personally find a lot less 
>> annoying, but if someone submits a request for "lint as you type" I'll 
>> consider it. Auto format depends on elm-format. Again the readme explains 
>> how to set it up on save. 
>> Auto completions works fine, but as the readme tries to explain it 
>> requires that the editor is connected to a project  (reasoning being I 
>> wouldn't want auto completion firing off downloading deps and whatnot for 
>> any old random elm file you might want to look at). As for all editors 
>> (except maybe intellij) autocompletion relies on elm-oracle which is far 
>> from perfect but it's a start.
>>
>
> Hmm, I see no readme or documentation in the plugin search area (see 
> attached image) nor any place to configure it.  I may be used to Atom or my 
> VI plugin manager that show the descriptions, settings, and more of the 
> plugins that can be installed, but I am not seeing where to do so here?  I 
> would love to switch editors even if only for Elm work because Atom has a 
> fairly crashy tendency (not its fault admittedly but rather a few plugins 
> that I shall keep nameless but that I require...  >.<).
>
>
> On Friday, July 22, 2016 at 2:24:34 AM UTC-6, Magnus Rundberget wrote:
>
>> Auto completion, linting and format is what you would use mostly. I would 
>> say there isn't much difference here when comparing elm-light, atom or 
>> visual studio code.
>> Elm-light has some features that some might find useful from time to time 
>> like; quick fixes for certain errors and warnings, doc preview in the 
>> editor for elm package authors, dependency visualization etc.  
>>
>
> Cool, yeah in Atom there are quick fixes (press a key combo and the errors 
> that elm-make report are auto-fixed if auto-fixable, like type declarations 
> on functions and such for example).  I have the docs up in Atom as well. 
>  I've not needed dependency viewing yet so I've not looked around for that.
>
>  
> On Friday, July 22, 2016 at 2:24:34 AM UTC-6, Magnus Rundberget wrote:
>
>> Short story is, it appears (to me) you ruled out an alternative after 
>> trying it out for a few minutes and perhaps not spending  that much time on 
>> the readme and perhaps not with a very open mindset to things working 
>> slightly diffrently ? 
>>
>
> I never saw where LightTable showed the readme (see attached image).  :-)
> But if you can point out where the readme is for elm-light in Light Table 
> and where the plugin configuration (I had a hell of a time finding any kind 
> of non-text-file settings, which were very much undocumented, at all in 
> Light Table... at least in vim I could type :help, plus I am not a fan of 
> clojure, had some very bad experiences embedded it in a larger project, it 
> has an utterly horrible, and I mean *horrible* abstraction layer on the JVM 
> that makes it so very painful to bind with in a generic way

[elm-discuss] Re: Beginner: 3 input fields for dates

[Magnus Rundberget]

Sure! I was being flippant. 3 dropdowns , now thats a dufferent story. Anyways 
good luck !

-- 
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: How to refactor Context with multiple addresses in 0.17?

[Magnus Rundberget]

here's a short post/example for solving child -> parent communication using 
plain old return values from the child component to the parent component.
http://folkertdev.nl/blog/elm-child-parent-communication


On Tuesday, 14 June 2016 15:27:50 UTC+2, Adam Waselnuk wrote:
>
> This is the exact thing I am stuck on right now in my upgrade to 0.17. It 
> is great to see three approaches outlined here, but would it be possible 
> for anyone to share some code examples? I am struggling to follow the 
> conversation a little bit but seeing some code could clear things up.
>
> On Friday, June 10, 2016 at 1:02:32 PM UTC-4, Andrew Volozhanin wrote:
>>
>> Hey everyone,
>>
>> Does anybody know what’s the preferred way to refactor passing context 
>> with addresses into child components during migration from Elm 0.16 to 0.17?
>>
>> In particular, I have *Filter* component that takes context with 2 
>> addresses: 
>> one for internal actions (Tagged with *UpdateFilter*) and one for 
>> “external” action (*Submit*) that is handled outside of the component.
>>
>> With 0.16, it looked something like this:
>>
>> type alias Context = { actions: Address Action, submit: Address () }
>>
>> update action model =
>>   case action of
>> UpdateFilter value ->
>>   { model | query = value }
>>
>> view : Context -> Model -> Html
>> view = context model
>>   form [onSubmit context.submit ()]
>> [ input_ model.query context.actions (\value -> UpdateFilter value)
>>   ]
>>
>>
>> But 0.17 doesn’t have addresses anymore, and I’m a bit lost at how should 
>> I implement this.
>>
>> I’ve found example app that is in the middle of the refactoring, that 
>> imports necessary “external” actions into the child components directly and 
>> sends them, 
>> but I don’t like that because it breaks the principle that child 
>> shouldn’t know anything about its parent. 
>> (See: 
>> https://github.com/rogeriochaves/elm-peer-tweet/blob/master/src%2FNewTweet%2FView%2FNewTweet.elm
>> )
>>
>> What’s the best practice in such cases now?
>>
>

-- 
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: Improving collaboration - part 2

[Magnus Rundberget]

I have only been part of the Elm community for something like 7-8 months, 
but i'll still take the chance and say a few words.
I hadn't seen part 1 of this topic 
https://groups.google.com/forum/#!msg/elm-discuss/np3BO9X5rEc/jG3AIiU2zYEJ 
before, but found it enlightening.

- I'm not worried about the pace of the language, I love that everything is 
thorough and really well thought through
- I'm fine with Elm maybe not being ready for *me or my projects* in 
production. Of course that might be me misjudging what I perceive I feel is 
missing but in reality there are alternatives to solving those concerns. If 
indeed it's not suitable for my cases maybe it will be in 0.18 or 0.19 or 
whatever. I'm totally cool with that. I'm still having a blast playing with 
Elm regardless and I'm having trouble not sharing my growing enthusiasm. 
- I also realize that there are many considerations and priorities that I'm 
not privy to and don't need to or have no entitlement in knowing about

Like any enthusiastic Elm community member I've invested lots of time 
learning the language, trying to understand the philosophy behind it, 
contributing where I can and sharing with the rest of the community and 
beyond. I have learned tons, had a great time and I'm thankful for Elm in 
so many ways. That's a really big reward in itself. 

Evan: 
I think what you have done and keep doing is amazing. My only really big 
concern is what I wish that I was able to see more signs that other people 
in the community were being trusted. And if sometimes people fail to live 
up to that trust, because they are humans and make mistakes, that's 
something you can live with. To me as an outsider (sort of, mostly I 
guess), it seems every minute little issue in the Elm repos, even tiny 
spelling mistake issues have to go through you. It's difficult for me to 
understand why this needs to be the case or even why it's taking time to 
address. Surely there must be a few others in the community that have shown 
they are worthy and could at least be allowed to resolve the simpler 
issues. Process bots and issue templates might help reduce the number of 
issues and hopefully improve the quality of issues. But I don't see 
automation as the solution to the bigger things that needs addressing, one 
of which I feel is the bus factor the other probably a little more open 
communication on where things are going forward. 

Before the release of 0.17 I felt at one point that I had unknowingly 
signed some sort of NDA for a Company with business critical secrets that 
would somehow destroy a competitive advantage if even the tiniest leak 
should happen . It came to a point where I wasn't even sure I could use Elm 
and 0.17 in the same sentence. That's  obviously not a rational response 
for your call to keep things under the lid from my side. But at that time I 
remember thinking : "hey this doesn't feel like being part of an Open 
Source Community". I hope I don't end up feeling this way in the future, 
then I guess I might be better off staying away from any "Do not share" 
info altogether. To contradict myself to a degree and to empathize with the 
wish/need for secrecy, I compare with what recently happened with Clojure 
Spec recently being announced. I had no clue (and I do follow the community 
there too, although not nearly as much as Elm), but the big difference 
being it didn't break anything, had no impact on any of our production apps 
and it was  just really a nice addition which is an option for us to use. 
You've already elaborated your reasoning behind the secrecy, I'm just 
giving you some feedback how I feel/felt for whatever that's worth. I'm not 
saying I'm right, consider it another data point if you like.


I'm encouraged by Noah's reply above, even though I'm perhaps being 
unfairly impatient hoping for more clear visible signs sooner rather than 
later.

cheers
-magnus






 





On Friday, 3 June 2016 17:01:01 UTC+2, Noah Hall wrote:
>
> > I must say one of the main reasons I'm not using Elm today nor do I plan 
> to use it on the medium term is how slow paced, constraining and tightly 
> controlled it is. 
>
> I disagree that it's slow paced. I agree that it is constrained and 
> tightly controlled. Part of this is the focus on delivering Elm as an 
> entire, functional product that you can use and trust. There are some 
> negatives to this, like Evan doing all the work alone. I agree that 
> this is not ideal. But look at the end result we have - Elm is a 
> language that I can trust and work with day in, day out. With less 
> control over core, this wouldn't be possible to the same extent. That 
> isn't to say that it's not possible to still have a fully furnished 
> product without the control - but there is a process shift that needs 
> to happen in _the right way_ to make that happen. 
>
> > All this to say, Elm has been created 3 years ago, I sincerely hope it 
> will start to solve problems at a faster pace and be more 

Re: [elm-discuss] Re: what's the preferred way to implement the submit mentioned in elm guide?

[Magnus Rundberget]

Looks a lot better to me, nice and testable too ! 

- You could consider having Error as a generic tag and let it take a  String. 
That way you could populate with an error message in your validate function. 
That would make the viewValidation function slightly simpler.

Btw you probably don't want to print out the password when displaying the error 
msg :-) sort of defeats the purpose of using input type password to hide 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: Announcing elm-lang/navigation for "routing in single-page apps"

[Magnus Rundberget]

Tx for this !


The final piece I've been waiting for before upgrading one of my apps. I 
think I'll go ahead and rip out the existing router package I'm using 
(which has served me well enough btw) and see if I can't manage fine with 
just these two building block.

shame it's 01:30 over here, but there's always tomorrow :-)

cheers
-magnus



On Thursday, 26 May 2016 00:02:03 UTC+2, Evan wrote:
>
> On Friday, Noah and I worked on "updating elm-history" so that folks can 
> do "routing" with Elm 0.17. The results are these libraries:
>
>- elm-lang/navigation 
>
>- evancz/url-parser 
>
>
> I think they will cover the core functionality in a way that also promotes 
> healthy architecture. If you disagree, I ask that you *use* these 
> libraries before you share your opinion (or ideally the particular scenario 
> you are having trouble with).
>
>
> Details
>
> The elm-lang/navigation library is the core thing. It lets you get 
> notified about changes to the address bar. This may be the user typing in 
> there or pressing the forward and back buttons on the browser. It also lets 
> you "navigate to new URLs" so you can go to new URLs without reloading any 
> assets.
>
> The elm-lang/navigation library is designed such that you can parse URLs 
> however you want. You can see a basic example of that here 
> . The 
> evancz/url-parser library is meant to handle more complex cases. You can 
> see a bit of that in this example 
> .
>
> My URL parser is intended to be a baseline for exploration. There are 
> probably cases it does not cover well. My goal right now is to point us 
> towards good API design, not to be *the* URL parser.
>
>
> Thanks
>
> Big thanks to Noah for working through all this with me! And thank you to 
> Aaron who helped review and talk through the API we ended up with. These 
> were fun to work on :D
>

-- 
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] WebSocket and Phoenix Channels

[Magnus Rundberget]

I know I sound like a party pooper, but I thought/hoped that packages in 
Elm was about providing one really good lib/package for a particular 
concern (at least as a general rule). 
Maybe you could help each other out and make the "awesomest ever" phoenix 
package for Elm.

A quick peak on reddit and I find this too: 
https://www.reddit.com/r/elm/comments/4kkjly/elmphoenixsocket_a_pure_elm_implementation_of_the/

I think it's super that folks are enthusiastic about providing Phoenix 
integration support in Elm. So if people still go ahead and do their own 
thing (which of course they are entitled too), it would be great as a 
end-user/consumer to get a rationale about why their package was created 
and how it differs/improves on what's already there.  


cheers
-magnus






On Monday, 23 May 2016 11:05:26 UTC+2, Simon wrote:
>
> Actually no, and it looks like Noah has put more effort into the helpers, 
> and faced the same complexity in actually extracting messages incoming
> On 23 May 2016 12:14 a.m., "Magnus Rundberget" <mru...@gmail.com 
> > wrote:
>
>> Did you notice this before you set out on your quest ?
>> http://package.elm-lang.org/packages/NoRedInk/elm-phoenix/1.0.0/
>>
>> Cheers
>> -magnus
>>
>> --
>> 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/n06mRcIiesI/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] HTML5 push state router for Elm 0.17

[Magnus Rundberget]

For now you are probably best of using one of the existing route parsers and 
use ports to handle history/push state
This might be a good read : https://github.com/etaque/elm-routing-example

Cheers
-magnus

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