Re: [elm-discuss] D3js for 0.17??

[Duane Johnson]

On Tue, Oct 18, 2016 at 2:59 PM, Jakub Hampl  wrote:

> I wrote a library that is somewhat similar to d3 called
> gampleman/elm-visualization. It doesn't do any selections and doesn't
> contain all the "utilities" that d3 has (on purpose) and the number of
> visualisation tools available is limited (still working on expanding it).


Nice library!

Convenience link for anyone else:
https://github.com/gampleman/elm-visualization

-- 
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 Automaton "Step" src?

[Janis Voigtländer]

No, it has nothing to do with the scheduler. The constructor Step is
defined in this line
.
You probably should read up on union types, here
.
​

2016-10-19 0:19 GMT+02:00 Ben Greer :

> Hi All,
>
> I'm ned to Elm and trying to learn.
>
> I'm reading through the src of Automaton
>
> https://github.com/evancz/automaton/blob/master/src/Automaton.elm
>
> but I can't seem to find the definition to the all important "Step"
> function here. I've looked the Elm Core src and can't seem to find a
> matching built-in.
> Intuition tells me this is somehow related to Elm's scheduler stuff, but
> where does one look?
>
> -Ben
>
> --
> 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] D3js for 0.17??

[Jakub Hampl]

I wrote a library that is somewhat similar to d3 called 
gampleman/elm-visualization. It doesn't do any selections and doesn't contain 
all the "utilities" that d3 has (on purpose) and the number of visualisation 
tools available is limited (still working on expanding 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] How to model a transient state?

[Jacky See]

Here is a simplified scenario:

type alias Item = { text : String, readState : ReadState, ... }

type ReadState = Read | Unread

type alias Model = { items : List Item }

In the item list view, there is a filter switch: All or Unread.
When the 'Unread' switch is on, it lists all unread items.

Item can be marked as 'Read' by clicking on a item's button, 
but then the item immediately disappeared from the filtered list view, 
which brings bad user experience.

I'm thinking how should I model such that the just clicked 'unread' 
item remains on the filtered list until some other refresh happen?
How to model this 'to be Read' state?  

-- 
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: Standard practices for dynamic extension/plugins in Elm?

[OvermindDL1]

On Monday, October 17, 2016 at 6:07:45 PM UTC-6, Mario T. Lanza wrote:
>
> 1) due-dates: installing and activating this plugin causes a due date 
> field to be added to the Todo model.  The interface still provides only the 
> text input field for providing the next "What needs to be done?" entry.  In 
> the list portion of the view a due date column appears.  When the user 
> types in an @ followed by a date (e.g. @2016-11-01) the value is parsed out 
> of the text and included in the due date field in the list below.
>

Given that the plugin data has to reside somewhere, I'd probably add a set 
of plugin storages to the record, one for each possible plugin that may be 
enabled (you cannot generically store data in Elm due to lack of various 
features like HKT's, HPT's, polymorphic variants, etc...  Everything in elm 
is designed to be visible not hidden, thus you have to know all types ahead 
of time).  Each plugin data storage could easily be an option so it is 
either Nothing or Just depending on if enabled or disabled (since you said 
you do not care about storing it somewhere).

For the view you could go two ways, either just test for validity of each 
and display data depending in the view, very hard-coded, but also very 
Elm'y, or you could generate a set of record hooks depending on the plugin 
states and pass those around the view to call the right hooks at the right 
time, this is more generic and multiple plugins could be supported with 
ease, but you still have to store the model of each individually without a 
few more language features.
 

On Monday, October 17, 2016 at 6:07:45 PM UTC-6, Mario T. Lanza wrote: 

> 2) tags: installing and activating this plugin causes a tags field to be 
> added to the Todo model.  The interface still provides only the text input 
> field for providing the next "What needs to be done?" entry.  In the list 
> portion of the view a tags column appears.  When the user types in a # 
> followed by a contiguous word or group of words (e.g. #finance #2016-taxes) 
> the values are parsed out of the text and included in the tags field in the 
> list below. 
>
 
>
When a plugin is deactivated the columns are simply dropped from the model. 
>  I am not worried about persistence. 
> 
>

Basically doing what I suggested above should work, verbose and explicit, 
but it works and is obvious to readers of the code 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.

Re: [elm-discuss] List.filter -> List.keep?

[Janis Voigtländer]

If you wonder if this has been discussed before, why not, like, search the
mailing list archive for whether this has been discussed before? :-)

https://groups.google.com/d/msg/elm-discuss/s4ciEzTvhvU/HkkDZqrkzdMJ
​

2016-10-18 21:35 GMT+02:00 Duane Johnson :

> I saw @_chunglou's tweet
>  yesterday and
> wondered if this had been discussed before:
>
> "I can never, ever remember whether `filter` needs `true` or `false`.
> `keep` would be a nicer name."
>
> I agree `keep` would remove the ambiguity. Thoughts?
>
> -- 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.
>

-- 
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: List.filter -> List.keep?

[Martin DeMello]

I like ruby's "select" and "reject", for precisely the same reason.

martin

On Tue, Oct 18, 2016 at 1:39 PM, Kasey Speakman 
wrote:

> I believe filter is a pretty standard name for this. Even Javascript has
> Array.filter
> 
> with the same semantics.
>
> In .NET Linq uses `.Where`, but I believe that is mainly to have
> similarity with SQL.
>
>
> On Tuesday, October 18, 2016 at 2:35:45 PM UTC-5, Duane Johnson wrote:
>>
>> I saw @_chunglou's tweet
>>  yesterday and
>> wondered if this had been discussed before:
>>
>> "I can never, ever remember whether `filter` needs `true` or `false`.
>> `keep` would be a nicer name."
>>
>> I agree `keep` would remove the ambiguity. Thoughts?
>>
>> -- 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.
>

-- 
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.filter -> List.keep?

[Kasey Speakman]

I believe filter is a pretty standard name for this. Even Javascript has 
Array.filter 

 
with the same semantics.

In .NET Linq uses `.Where`, but I believe that is mainly to have similarity 
with SQL.

On Tuesday, October 18, 2016 at 2:35:45 PM UTC-5, Duane Johnson wrote:
>
> I saw @_chunglou's tweet 
>  yesterday and 
> wondered if this had been discussed before:
>
> "I can never, ever remember whether `filter` needs `true` or `false`. 
> `keep` would be a nicer name."
>
> I agree `keep` would remove the ambiguity. Thoughts?
>
> -- 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.

[elm-discuss] List.filter -> List.keep?

[Duane Johnson]

I saw @_chunglou's tweet
 yesterday and
wondered if this had been discussed before:

"I can never, ever remember whether `filter` needs `true` or `false`.
`keep` would be a nicer name."

I agree `keep` would remove the ambiguity. Thoughts?

-- 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] Why aren't doc PRs merged?

[Duane Johnson]

On Tue, Oct 18, 2016 at 7:51 AM, Eric Thomas 
wrote:

> Why is it that the language is entirely dependent on one person? I get
> that Evan is the BDFL but there should be a core community that can approve
> these without his approval.
> As for the book, I do remember that he had an issue with people modifying
> the book from his keynote at Elm-Conf. However, this is the primary
> learning resource people will use to pick up Elm. Nobody wants to sift
> through hundreds of 3rd party blog posts, etc. Elm's success is dependent
> on how good the official guides are.
> If Evan does not want people to make changes to the book, then he should
> host it on his own website.
>

I admit to being torn by Evan's objectives. I do understand the importance
of ownership and authorship--it's his work and his voice. On the other
hand, I agree that the community's needs are sometimes in conflict with an
ownership model.

Would it make sense to fork the guide and host a "community edition" that
incorporates feedback quickly while Evan pursues his (sometimes separate)
goals?

-- 
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] Why aren't doc PRs merged?

[Eric Thomas]

Why is it that the language is entirely dependent on one person? I get that 
Evan is the BDFL but there should be a core community that can approve 
these without his approval.
As for the book, I do remember that he had an issue with people modifying 
the book from his keynote at Elm-Conf. However, this is the primary 
learning resource people will use to pick up Elm. Nobody wants to sift 
through hundreds of 3rd party blog posts, etc. Elm's success is dependent 
on how good the official guides are.
If Evan does not want people to make changes to the book, then he should 
host it on his own website.

On Tuesday, October 18, 2016 at 1:42:04 AM UTC-6, Peter Damoc wrote:
>
> Evan works by batching requests and then handling multiple relevant ones 
> in one go. So, some of the pulls might get through at one point. 
>
> Also, the guide is basically Evan's book. The book is in a state of flux, 
> changing and being rewritten. Pull requests make less sense there. 
>
> On Tue, Oct 18, 2016 at 1:47 AM, Eric Thomas  > wrote:
>
>> At both https://github.com/evancz/guide.elm-lang.org/pulls and 
>> https://github.com/elm-lang/elm-lang.org/pulls there's a decent number 
>> of PRs that would be useful if merged.
>> A lot of these are simple gotchas that can save a beginner a lot of time.
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> 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] Re: Toward a Tree UI Component

[Tom Kidd]

Hey Jonathan,

Thanks for the kudos, it's nice that this library is actually useful to 
people because I wrote it last year and it sat for a while.

I know you said you solved the problem you were having, I just figured I'd 
share a github repository of the prototype work I was doing on a UI Tree 
component in case you wanted to compare it to another idea. Again, I wrote 
this code a year ago so I don't know if it will be useful to you, but I was 
able to get a functioning UI tree that I was happy with.

https://github.com/tomjkidd/elm/tree/master/practice/tree-work

best,
Tom

On Tuesday, October 18, 2016 at 5:21:41 AM UTC-4, Jonathan Fishbein wrote:
>
> Actually might have gotten it to work!  Thanks again for making the library
>
> On Thursday, November 26, 2015 at 10:01:05 AM UTC-5, Tom Kidd wrote:
>>
>> I am working on creating a Tree UI Component that would eventually use 
>> the Elm Architecture. In doing this work, I uncovered the need to be able 
>> to update and navigate tree data structures, and found Huet zippers as a 
>> reasonable starting point. I searched the the elm packages and didn't find 
>> an implementation, so I created one.
>>
>> So far, the implementation is not complete (have not implemented 
>> attach/delete), but I believe it is still useful.
>>
>> I am looking for feedback because I intend to use this code as a basis 
>> for the Tree Component, which I also intend to share when it is ready. This 
>> is my first package, so before I submitted it, I wanted to get some 
>> feedback. Anyone who is interested in this, please review at the following:
>>
>> https://github.com/tomjkidd/elm-multiway-tree-zipper
>>
>>
>> *Resources*
>>
>> *LYAH Zippers (used for tree updates)*
>> http://learnyouahaskell.com/zippers
>>
>> *Elm Maybe Monad (needed for possible errors with traversal)*
>> https://groups.google.com/forum/#!topic/elm-discuss/hEvS6DgNbwM
>> https://github.com/maxsnew/Scramble/blob/master/Scramble/Utils.elm#L12-L27
>>  `andThen`, or &> could be used with Zipper a -> Maybe (Zipper a) to 
>> compose them together.
>>
>> *Huet Zipper*
>>
>> https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/huet-zipper.pdf
>> I still would need to implement the attach and remove functions in order 
>> to create a useful library.
>>
>>
>>

-- 
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: Toward a Tree UI Component

[Jonathan Fishbein]

Actually might have gotten it to work!  Thanks again for making the library

On Thursday, November 26, 2015 at 10:01:05 AM UTC-5, Tom Kidd wrote:
>
> I am working on creating a Tree UI Component that would eventually use the 
> Elm Architecture. In doing this work, I uncovered the need to be able to 
> update and navigate tree data structures, and found Huet zippers as a 
> reasonable starting point. I searched the the elm packages and didn't find 
> an implementation, so I created one.
>
> So far, the implementation is not complete (have not implemented 
> attach/delete), but I believe it is still useful.
>
> I am looking for feedback because I intend to use this code as a basis for 
> the Tree Component, which I also intend to share when it is ready. This is 
> my first package, so before I submitted it, I wanted to get some feedback. 
> Anyone who is interested in this, please review at the following:
>
> https://github.com/tomjkidd/elm-multiway-tree-zipper
>
>
> *Resources*
>
> *LYAH Zippers (used for tree updates)*
> http://learnyouahaskell.com/zippers
>
> *Elm Maybe Monad (needed for possible errors with traversal)*
> https://groups.google.com/forum/#!topic/elm-discuss/hEvS6DgNbwM
> https://github.com/maxsnew/Scramble/blob/master/Scramble/Utils.elm#L12-L27
>  `andThen`, or &> could be used with Zipper a -> Maybe (Zipper a) to 
> compose them together.
>
> *Huet Zipper*
>
> https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/huet-zipper.pdf
> I still would need to implement the attach and remove functions in order 
> to create a useful library.
>
>
>

-- 
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: Toward a Tree UI Component

[Jonathan Fishbein]

Hi Tom,
   Thank you for creating the MultiwayTreeZipper.  I am attempting to wrap 
my head around it.  My understanding of recursion and recursion on trees 
has always been spotty.  I think I understand how to update a datum when a 
Forest/Tree is your elm model.  However, I have been scratching my head the 
past couple days trying to figure out how to display the model?  I am 
attempting to use the MuliwayTreeZipper to display comments & responses so 
I am hoping to have the responses be indented from the comments.  Any ideas 
on how to accomplish that?  Thanks
Jonathan

On Thursday, November 26, 2015 at 10:01:05 AM UTC-5, Tom Kidd wrote:
>
> I am working on creating a Tree UI Component that would eventually use the 
> Elm Architecture. In doing this work, I uncovered the need to be able to 
> update and navigate tree data structures, and found Huet zippers as a 
> reasonable starting point. I searched the the elm packages and didn't find 
> an implementation, so I created one.
>
> So far, the implementation is not complete (have not implemented 
> attach/delete), but I believe it is still useful.
>
> I am looking for feedback because I intend to use this code as a basis for 
> the Tree Component, which I also intend to share when it is ready. This is 
> my first package, so before I submitted it, I wanted to get some feedback. 
> Anyone who is interested in this, please review at the following:
>
> https://github.com/tomjkidd/elm-multiway-tree-zipper
>
>
> *Resources*
>
> *LYAH Zippers (used for tree updates)*
> http://learnyouahaskell.com/zippers
>
> *Elm Maybe Monad (needed for possible errors with traversal)*
> https://groups.google.com/forum/#!topic/elm-discuss/hEvS6DgNbwM
> https://github.com/maxsnew/Scramble/blob/master/Scramble/Utils.elm#L12-L27
>  `andThen`, or &> could be used with Zipper a -> Maybe (Zipper a) to 
> compose them together.
>
> *Huet Zipper*
>
> https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/huet-zipper.pdf
> I still would need to implement the attach and remove functions in order 
> to create a useful library.
>
>
>

-- 
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] Why aren't doc PRs merged?

[Peter Damoc]

Evan works by batching requests and then handling multiple relevant ones in
one go. So, some of the pulls might get through at one point.

Also, the guide is basically Evan's book. The book is in a state of flux,
changing and being rewritten. Pull requests make less sense there.

On Tue, Oct 18, 2016 at 1:47 AM, Eric Thomas 
wrote:

> At both https://github.com/evancz/guide.elm-lang.org/pulls and
> https://github.com/elm-lang/elm-lang.org/pulls there's a decent number of
> PRs that would be useful if merged.
> A lot of these are simple gotchas that can save a beginner a lot of time.
>
> --
> 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.