Re: [elm-discuss] Writing tests on elm-lang/html data structures

[Noah Hall]

It has a native function to grab the internal node representation, so
you'll have to clone it and replace some of the refereneces to instead
talk about your package name.

One caveat is that I don't remember if it works with Markdown right
now, since Markdown uses a custom renderer which has a different
internal representation.

You might be better off writing tests using karma or something for
now, actually. Or just implement the representation of the call to the
markdown renderer.

On Sat, Jul 16, 2016 at 11:04 PM, Conrad Dean  wrote:
> oh this looks great!  how do i install/vendor it?
>
> On Sat, Jul 16, 2016 at 4:49 PM, Noah Hall  wrote:
>>
>> We've been using this ->
>> https://github.com/eeue56/elm-server-side-renderer for testing that in 0.17.
>>
>>
>> On Saturday, July 16, 2016, Conrad Dean  wrote:
>>>
>>> I want to write tests for https://github.com/evancz/elm-markdown , but
>>> I'm having problems comparing Html objects.
>>>
>>> There's something about the internals of a VirtualDom/Html object that
>>> are preventing me from testing if two html nodes are equal and I was
>>> wondering if someone could get me up to speed with how to strip that stuff
>>> out so that I'm just comparing either the raw HTML strings, or more basic
>>> Html type objects.
>>>
>>> Here's my test and error message from running my ElmTest suite:
>>>
>>> module MarkdownSpec exposing (all)
>>>
>>> import ElmTest exposing (..)
>>>
>>> import Html exposing (Html, Attribute)
>>> import Markdown exposing (toHtml)
>>>
>>> all : Test
>>> all =
>>> suite "MAKR DOEN"
>>> , test "simple html"
>>> <| assertHtmlEqual (Html.text "sup") (Html.text "sup")
>>> , test "basic MD"
>>> <| assertHtmlEqual (toHtml [] "sup") (Html.text "sup")
>>> ]
>>>
>>> assertHtmlEqual: Html msg -> Html msg -> Assertion
>>> assertHtmlEqual a b = assertEqual a b
>>>
>>>
>>> Error:
>>>
>>> $ elm make test/TestRunner.elm --output _build/test.js && node
>>> _build/test.js
>>> Success! Compiled 2 modules.
>>> Successfully generated _build/test.js
>>> /Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567
>>> throw new Error(
>>> ^
>>>
>>> Error: Ran into a `Debug.crash` in module `ElmTest.Runner.Console`
>>>
>>> This was caused by the `case` expression between lines 28 and 33.
>>> One of the branches ended with a crash and the following value got
>>> through:
>>>
>>> False
>>>
>>> The message provided by the code author is:
>>>
>>>   3 suites run, containing 5 tests
>>>   1 suites and 4 tests passed
>>>   2 suites and 1 tests failed
>>>
>>> Test Suite: very tests: FAILED
>>>   Test Suite: A Test Suite: all tests passed
>>>   Test Suite: MAKR DOEN: FAILED
>>> Addition: passed.
>>> simple html: passed.
>>> basic MD: FAILED. Expected: { type = "custom", facts = {}, model = {
>>> options = { githubFlavored = Just { tables = False, breaks = False },
>>> defaultHighlighting = Nothing, sanitize = False, smartypants = False },
>>> markdown = "sup" }, impl = { render = , diff =
>>>  } }; got: { type = "text", text = "sup" }
>>> at /Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567:9
>>> at _elm_community$elm_test$ElmTest_Runner_Console$runDisplay
>>> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:7778:9)
>>> at _elm_community$elm_test$ElmTest_Runner_Console$runSuite
>>> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:7793:11)
>>> at Object.
>>> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:8061:8)
>>> at Object.
>>> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:8096:4)
>>> at Module._compile (module.js:435:26)
>>> at Object.Module._extensions..js (module.js:442:10)
>>> at Module.load (module.js:356:32)
>>> at Function.Module._load (module.js:311:12)
>>> at Function.Module.runMain (module.js:467:10)
>>>
>>>
>>> --
>>> 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.
>
>
> --
> 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-di

[elm-discuss] html formatting words in string

[Wayne Choi]

What's the best way to bold words in a sentence? Let's way you have the 
sentence "@john like apples but not the seeds" and you want it formatted 
like so "*@john* likes apples but not seeds". I tried using Regex replace 
with the match operator but that only formats the string. It seems as if 
you have to split the sentence into words and return a list of doms (i 
think?). I can't figure out how you would do that and was wondering if 
there was an easier way I'm missing at the moment. 

Thanks.

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

Re: [elm-discuss] Writing tests on elm-lang/html data structures

[Conrad Dean]

oh this looks great!  how do i install/vendor it?

On Sat, Jul 16, 2016 at 4:49 PM, Noah Hall  wrote:

> We've been using this ->
> https://github.com/eeue56/elm-server-side-renderer for testing that in
> 0.17.
>
>
> On Saturday, July 16, 2016, Conrad Dean  wrote:
>
>> I want to write tests for https://github.com/evancz/elm-markdown , but
>> I'm having problems comparing Html objects.
>>
>> There's something about the internals of a VirtualDom/Html object that
>> are preventing me from testing if two html nodes are equal and I was
>> wondering if someone could get me up to speed with how to strip that stuff
>> out so that I'm just comparing either the raw HTML strings, or more basic
>> Html type objects.
>>
>> *Here's my test and error message from running my ElmTest suite:*
>>
>> module MarkdownSpec exposing (all)
>>
>> import ElmTest exposing (..)
>>
>> import Html exposing (Html, Attribute)
>> import Markdown exposing (toHtml)
>>
>> all : Test
>> all =
>> suite "MAKR DOEN"
>> , test "simple html"
>> <| assertHtmlEqual (Html.text "sup") (Html.text "sup")
>> , test "basic MD"
>> <| assertHtmlEqual (toHtml [] "sup") (Html.text "sup")
>> ]
>>
>> assertHtmlEqual: Html msg -> Html msg -> Assertion
>> assertHtmlEqual a b = assertEqual a b
>>
>>
>> *Error:*
>>
>> $ elm make test/TestRunner.elm --output _build/test.js && node
>> _build/test.js
>> Success! Compiled 2 modules.
>> Successfully generated _build/test.js
>> /Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567
>> throw new Error(
>> ^
>>
>> Error: Ran into a `Debug.crash` in module `ElmTest.Runner.Console`
>>
>> This was caused by the `case` expression between lines 28 and 33.
>> One of the branches ended with a crash and the following value got
>> through:
>>
>> False
>>
>> The message provided by the code author is:
>>
>>   3 suites run, containing 5 tests
>>   1 suites and 4 tests passed
>>   2 suites and 1 tests failed
>>
>> Test Suite: very tests: FAILED
>>   Test Suite: A Test Suite: all tests passed
>>   Test Suite: MAKR DOEN: FAILED
>> Addition: passed.
>> simple html: passed.
>> basic MD: FAILED. Expected: { type = "custom", facts = {}, model = {
>> options = { githubFlavored = Just { tables = False, breaks = False },
>> defaultHighlighting = Nothing, sanitize = False, smartypants = False },
>> markdown = "sup" }, impl = { render = , diff =
>>  } }; got: { type = "text", text = "sup" }
>> at /Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567:9
>> at _elm_community$elm_test$ElmTest_Runner_Console$runDisplay
>> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:7778:9)
>> at _elm_community$elm_test$ElmTest_Runner_Console$runSuite
>> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:7793:11)
>> at Object.
>> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:8061:8)
>> at Object.
>> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:8096:4)
>> at Module._compile (module.js:435:26)
>> at Object.Module._extensions..js (module.js:442:10)
>> at Module.load (module.js:356:32)
>> at Function.Module._load (module.js:311:12)
>> at Function.Module.runMain (module.js:467:10)
>>
>>
>> --
>> 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.
>

-- 
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] Writing tests on elm-lang/html data structures

[Noah Hall]

We've been using this -> https://github.com/eeue56/elm-server-side-renderer
for testing that in 0.17.

On Saturday, July 16, 2016, Conrad Dean  wrote:

> I want to write tests for https://github.com/evancz/elm-markdown , but
> I'm having problems comparing Html objects.
>
> There's something about the internals of a VirtualDom/Html object that are
> preventing me from testing if two html nodes are equal and I was wondering
> if someone could get me up to speed with how to strip that stuff out so
> that I'm just comparing either the raw HTML strings, or more basic Html
> type objects.
>
> *Here's my test and error message from running my ElmTest suite:*
>
> module MarkdownSpec exposing (all)
>
> import ElmTest exposing (..)
>
> import Html exposing (Html, Attribute)
> import Markdown exposing (toHtml)
>
> all : Test
> all =
> suite "MAKR DOEN"
> , test "simple html"
> <| assertHtmlEqual (Html.text "sup") (Html.text "sup")
> , test "basic MD"
> <| assertHtmlEqual (toHtml [] "sup") (Html.text "sup")
> ]
>
> assertHtmlEqual: Html msg -> Html msg -> Assertion
> assertHtmlEqual a b = assertEqual a b
>
>
> *Error:*
>
> $ elm make test/TestRunner.elm --output _build/test.js && node
> _build/test.js
> Success! Compiled 2 modules.
> Successfully generated _build/test.js
> /Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567
> throw new Error(
> ^
>
> Error: Ran into a `Debug.crash` in module `ElmTest.Runner.Console`
>
> This was caused by the `case` expression between lines 28 and 33.
> One of the branches ended with a crash and the following value got through:
>
> False
>
> The message provided by the code author is:
>
>   3 suites run, containing 5 tests
>   1 suites and 4 tests passed
>   2 suites and 1 tests failed
>
> Test Suite: very tests: FAILED
>   Test Suite: A Test Suite: all tests passed
>   Test Suite: MAKR DOEN: FAILED
> Addition: passed.
> simple html: passed.
> basic MD: FAILED. Expected: { type = "custom", facts = {}, model = {
> options = { githubFlavored = Just { tables = False, breaks = False },
> defaultHighlighting = Nothing, sanitize = False, smartypants = False },
> markdown = "sup" }, impl = { render = , diff =
>  } }; got: { type = "text", text = "sup" }
> at /Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567:9
> at _elm_community$elm_test$ElmTest_Runner_Console$runDisplay
> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:7778:9)
> at _elm_community$elm_test$ElmTest_Runner_Console$runSuite
> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:7793:11)
> at Object.
> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:8061:8)
> at Object.
> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:8096:4)
> at Module._compile (module.js:435:26)
> at Object.Module._extensions..js (module.js:442:10)
> at Module.load (module.js:356:32)
> at Function.Module._load (module.js:311:12)
> at Function.Module.runMain (module.js:467:10)
>
>
> --
> 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: I dislike the names of certain standard library functions.

[Nick H]

If you are interested in contributing to Elm development, I would recommend
checking out the projects page , as
well as subscribing to elm-dev

On Sat, Jul 16, 2016 at 12:12 AM, John Bugner  wrote:

> What is the "web platform"? Is there a way I can contribute to this
> project?
>
> On Friday, July 15, 2016 at 10:41:05 PM UTC-5, Nick H wrote:
>>
>> One big focus right now is adding support for the rest of the Web
>> Platform to the standard library.
>>
>> If you haven't yet, you can subscribe to the elm-dev mailing list to keep
>> abreast of what Evan is up to at the moment.
>>
>> On Fri, Jul 15, 2016 at 8:16 PM, John Bugner  wrote:
>>
>>> I don't mean to sound pushy, but if "That's what people are familiar
>>> with." is taken as a valid reason, then why not bring back 'atoi' and such
>>> names then? Why not make the syntax more JS-like? Why not just make Elm yet
>>> another imperative OO language?
>>>
>>> This is an opportunity for Elm to show that it takes seriously the task
>>> of making programming easier. The fact that the world of programming has
>>> for so long made itself arbitrarily difficult by having incomprehensible
>>> function names (among many other sins) is something that programmers should
>>> be ashamed of, not proud of.
>>>
>>>
>>> On Wednesday, July 13, 2016 at 11:34:45 PM UTC-5, Max Goldstein wrote:

 It's great that Elm can appeal to new programmers, but it's mainly
 targeting web developers. As such, things like max/min, ||/&&, and "string"
 are going to stick around. No need to reinvent what's been standard(-ish)
 since C.

 The biggest name annoyance, IMHO, is *filter*. It doesn't immediately
 convey whether you're selecting in or out. For my money, Ruby got this one
 right: *select* and *reject*. They sound similar and they are similar,
 and the names convey which way the predicate goes. I wouldn't be adverse to
 stealing a few other Ruby or near-Ruby names; perhaps List.includes instead
 of member, and reduce to replace foldl (dropping foldr and renaming it fold
 could also work).

 That said, I'm not convinced much of this will happen. Evan is a "big
 picture" guy, and this would break a lot of code, although deprecation
 (having both copies for awhile) could help.

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

-- 
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] Fingertree used to make priority queue and deque

[Nick H]

Thank you for sharing!

I think it would be worth the trouble of fleshing out the documentation a
bit. For instance, it's not clear what a Monoid is. It appears that you
need a Monoid to construct an AnnotatedFingerTree, but there's no
indication of how to construct a Monoid. Some example code of how to use
the library would be a big help!

On Fri, Jul 15, 2016 at 8:42 AM, Matthew Heath  wrote:

> I have made a fingertree package
>  
> and
> used it to make a persistent priority queue and a deque with random acces.
> I hope these are of use to someone
>
> --
> 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] Collaboration experiment proposal

[Justin]

Hi Peter,
I definitely agree that this would be very interesting to try. Although I don't 
think it would be enough to really enable the community as a living system. 
Peter Hintjens talks about remix ability and free entry being critical 
components of a design community 
https://hintjens.gitbooks.io/social-architecture/content/chapter1.html and then 
later talks about the freedom of forking (one way of sharing remixed code) 
being crucial for a healthy living system 
https://hintjens.gitbooks.io/social-architecture/content/chapter6.html.

My hope with the approach that I outlined is that it would foster the 
design/development environment to enable the community to develop great 
solutions.
This would definitely introduce the problems described by Evan in his blog post 
and Joey above but in my opinion through curation and the official 
implementations we would solve it and be able to take advantage of both worlds.

That being said I would rather try something then nothing and if the approach 
you outline is considered safer and less disruptive then I am all for 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] Looking for feedback on a Date extra library

[Aaron VonderHaar]

In general, I believe the best approach is to have a module roughly
correspond to a data type, and to have both the type definition and all the
relevant functions in that single module.

In your case, Date is already defined in elm-lang/core, but I do think it
would be better to have all the extra functions in a single module (or at
least all the things that a normal user of your package might want to
use).  It's better both for the reason you mentioned (to avoid having to
import a bunch of modules just to work with Dates), and also to avoid users
of your package having to remember what is in each of the submodules.

My only other suggestion would be to check in with rluiten and/or
elm-community and see if there's any possibility of combining the existing
elm-date-extra packages into a single package.

Best,
--Aaron V.



On Sat, Jul 16, 2016 at 7:30 AM, Justin Mimbs 
wrote:

> Hello Elm Discuss,
>
> I published an elm-date-extra
> 
> package last week, where around 50 things are organized into 5 modules.
>
> Date.Convert - convert dates to other types (mainly formatted strings)
> Date.Create - create dates from other types
> Date.Extract - additional extractions to those in the core library
> Date.Facts - lookups and constants
> Date.Math - operations for dates (e.g. floor, add, clamp, range)
>
>
> So far when I use the library, I find I'm usually importing at least 3 of
> its modules, and aliasing them all as `Date`. This has given me the feeling
> that the library might be easier to use if it just exported everything from
> a single Date.Extra module. Do you think this library benefits from being
> split up, or would it be nicer in a single module?
>
> I'd be interested in any other suggestions on the API as well. If I'm to
> make breaking changes by reorganizing the package, I'd be happy to include
> other changes at the same time.
>
> Thanks!
>
> Justin
>
> --
> 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] Writing tests on elm-lang/html data structures

[Conrad Dean]

I want to write tests for https://github.com/evancz/elm-markdown , but I'm
having problems comparing Html objects.

There's something about the internals of a VirtualDom/Html object that are
preventing me from testing if two html nodes are equal and I was wondering
if someone could get me up to speed with how to strip that stuff out so
that I'm just comparing either the raw HTML strings, or more basic Html
type objects.

*Here's my test and error message from running my ElmTest suite:*

module MarkdownSpec exposing (all)

import ElmTest exposing (..)

import Html exposing (Html, Attribute)
import Markdown exposing (toHtml)

all : Test
all =
suite "MAKR DOEN"
, test "simple html"
<| assertHtmlEqual (Html.text "sup") (Html.text "sup")
, test "basic MD"
<| assertHtmlEqual (toHtml [] "sup") (Html.text "sup")
]

assertHtmlEqual: Html msg -> Html msg -> Assertion
assertHtmlEqual a b = assertEqual a b


*Error:*

$ elm make test/TestRunner.elm --output _build/test.js && node
_build/test.js
Success! Compiled 2 modules.
Successfully generated _build/test.js
/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567
throw new Error(
^

Error: Ran into a `Debug.crash` in module `ElmTest.Runner.Console`

This was caused by the `case` expression between lines 28 and 33.
One of the branches ended with a crash and the following value got through:

False

The message provided by the code author is:

  3 suites run, containing 5 tests
  1 suites and 4 tests passed
  2 suites and 1 tests failed

Test Suite: very tests: FAILED
  Test Suite: A Test Suite: all tests passed
  Test Suite: MAKR DOEN: FAILED
Addition: passed.
simple html: passed.
basic MD: FAILED. Expected: { type = "custom", facts = {}, model = {
options = { githubFlavored = Just { tables = False, breaks = False },
defaultHighlighting = Nothing, sanitize = False, smartypants = False },
markdown = "sup" }, impl = { render = , diff =
 } }; got: { type = "text", text = "sup" }
at /Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567:9
at _elm_community$elm_test$ElmTest_Runner_Console$runDisplay
(/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:7778:9)
at _elm_community$elm_test$ElmTest_Runner_Console$runSuite
(/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:7793:11)
at Object.
(/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:8061:8)
at Object.
(/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:8096:4)
at Module._compile (module.js:435:26)
at Object.Module._extensions..js (module.js:442:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:311:12)
at Function.Module.runMain (module.js:467:10)

-- 
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 feedback on a Date extra library

[Justin Mimbs]

Hello Elm Discuss,

I published an elm-date-extra 
 
package last week, where around 50 things are organized into 5 modules.

Date.Convert - convert dates to other types (mainly formatted strings)
Date.Create - create dates from other types
Date.Extract - additional extractions to those in the core library
Date.Facts - lookups and constants
Date.Math - operations for dates (e.g. floor, add, clamp, range)


So far when I use the library, I find I'm usually importing at least 3 of 
its modules, and aliasing them all as `Date`. This has given me the feeling 
that the library might be easier to use if it just exported everything from 
a single Date.Extra module. Do you think this library benefits from being 
split up, or would it be nicer in a single module?

I'd be interested in any other suggestions on the API as well. If I'm to 
make breaking changes by reorganizing the package, I'd be happy to include 
other changes at the same time.

Thanks!

Justin

-- 
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 not for my use case

[Noah Hall]

Next time come onto slack and ask there. We can help.

On Saturday, July 16, 2016, barmin  wrote:

> There are utilities to help automate that:
>> https://github.com/eeue56/json-to-elm
>>
>
> Thanks for the link, but...
>
> I had tried http://noredink.github.io/json-to-elm/ but the generated code
> does not compile.
> Just to be sure I tried with the code from the repo, but it does not work
> either.
>
> I spent some time correcting the most obvious errors, but it still doesn't
> work.
>
> I feel that debugging 100+ lines of generated code is not much easier than
> writing the code myself, and both are more work than should be needed for
> decoding json.
>
> Matthieu
>
> --
> 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: Elm not for my use case

[barmin]

There are utilities to help automate that: https://github.com/eeue56/json-to-elm


Thanks for the link, but...

I had tried http://noredink.github.io/json-to-elm/ but the generated code does 
not compile.
Just to be sure I tried with the code from the repo, but it does not work 
either.

I spent some time correcting the most obvious errors, but it still doesn't work.

I feel that debugging 100+ lines of generated code is not much easier than 
writing the code myself, and both are more work than should be needed for 
decoding json.

Matthieu

--
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: Elm not for my use case

[Matthew Griffith]

There are utilities to help automate that: 
https://github.com/eeue56/json-to-elm

On Saturday, July 16, 2016 at 7:24:32 AM UTC-4, Rex van der Spuy wrote:
>
> On Friday, July 15, 2016 at 5:24:48 AM UTC-4, Matthieu Amiguet wrote:
>>
>>  I realized that writing proper parsers for my json files would be at 
>> least as much work, and probably twice as much code, as the rest of the 
>> project. 
>>
>  
> This is also my biggest hurdle with Elm at the moment.
>
>

-- 
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: Elm not for my use case

[Rex van der Spuy]

On Friday, July 15, 2016 at 5:24:48 AM UTC-4, Matthieu Amiguet wrote:
>
>  I realized that writing proper parsers for my json files would be at 
> least as much work, and probably twice as much code, as the rest of the 
> project. 
>
 
This is also my biggest hurdle with Elm at the moment.

-- 
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: Inter-Component Communication in 0.17

[Max Goldstein]

...well, I suppose at that size it makes sense :)

Just don't go componentizing every little text field or icon. 

-- 
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: I dislike the names of certain standard library functions.

[Peter Damoc]

This is the Web Platform
https://platform.html5.org/

and, currently, the expansion of the support for the web-platform in Elm is
proceeding in a very intentional and well-thought manner.
The idea is to have one solid, well thought library for each component of
the platform instead of a bunch of mutually incompatible, partial
implementations.





On Sat, Jul 16, 2016 at 10:12 AM, John Bugner  wrote:

> What is the "web platform"? Is there a way I can contribute to this
> project?
>
> On Friday, July 15, 2016 at 10:41:05 PM UTC-5, Nick H wrote:
>>
>> One big focus right now is adding support for the rest of the Web
>> Platform to the standard library.
>>
>> If you haven't yet, you can subscribe to the elm-dev mailing list to keep
>> abreast of what Evan is up to at the moment.
>>
>> On Fri, Jul 15, 2016 at 8:16 PM, John Bugner  wrote:
>>
>>> I don't mean to sound pushy, but if "That's what people are familiar
>>> with." is taken as a valid reason, then why not bring back 'atoi' and such
>>> names then? Why not make the syntax more JS-like? Why not just make Elm yet
>>> another imperative OO language?
>>>
>>> This is an opportunity for Elm to show that it takes seriously the task
>>> of making programming easier. The fact that the world of programming has
>>> for so long made itself arbitrarily difficult by having incomprehensible
>>> function names (among many other sins) is something that programmers should
>>> be ashamed of, not proud of.
>>>
>>>
>>> On Wednesday, July 13, 2016 at 11:34:45 PM UTC-5, Max Goldstein wrote:

 It's great that Elm can appeal to new programmers, but it's mainly
 targeting web developers. As such, things like max/min, ||/&&, and "string"
 are going to stick around. No need to reinvent what's been standard(-ish)
 since C.

 The biggest name annoyance, IMHO, is *filter*. It doesn't immediately
 convey whether you're selecting in or out. For my money, Ruby got this one
 right: *select* and *reject*. They sound similar and they are similar,
 and the names convey which way the predicate goes. I wouldn't be adverse to
 stealing a few other Ruby or near-Ruby names; perhaps List.includes instead
 of member, and reduce to replace foldl (dropping foldr and renaming it fold
 could also work).

 That said, I'm not convinced much of this will happen. Evan is a "big
 picture" guy, and this would break a lot of code, although deprecation
 (having both copies for awhile) could help.

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



-- 
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] Collaboration experiment proposal

[Peter Damoc]

There is a middle-ground solution to this: have *only one* extra source of
Native and have a solid contract that prevents duplication or haphazard
implementation of the Web API.

The main challenge here is what C4 calls
*"Evolution of Public Contracts"*
https://hintjens.gitbooks.io/social-architecture/content/chapter4.html
If the implementation of the Web API is done in a haphazard fashion, then
this kind of extra repository will potentially create more problems than
solutions.

If a group of people joins in an effort like this,* they have to first lay
down the rules and the rules have to be very strict. *
There needs to be a large and visible *checklist for any extension of the
public contracts*.
There have to be a series of hoops through which each new extension needs
to pass in order to *slowly* ascend to being present in this extra
repository.

These being said, I think it can be done and if it is done with a solid
contract that facilitates productive reasoning, it can be a boon for Elm.

With a project like this in active development, I imagine that some of the
pressure that is now being put on Evan could disappear as instead of
bombarding him with requests, people could bombard this new project with
requests.
It could act as a lightning rod.




On Fri, Jul 15, 2016 at 10:49 PM, Joey Eremondi 
wrote:

> This seems to run very counter to Evan's goals for Native:
>
> * The purpose of Native is to expose the Web API to Elm
> * We only want one, quality implementation for each API access
>
> Having code that's dependent on "unnoficial packages" and facing breakage
> is what we're trying to avoid. Likewise, having a poorly made unofficial
> package floating around that everyone is dependent on, and having nobody
> adopt the new but better versions when they come out, is something we want
> to avoid. Just look at Python 2 vs Python 3 for how hard it is to get
> people to change once you've given them something.
>
> The majority of libraries ever released for langauges are labelled as
> alpha, work in progress, or unstable, and that doesn't stop people from
> using them, depending on them, and getting mad when they break.
>
> On Fri, Jul 15, 2016 at 11:48 AM, Justin  wrote:
>
>> ahh let me rephrase,
>> What I am proposing is removing the requirement for sign-off when
>> submitting a native module to the package repo. These packages would be
>> considered 'unofficial' by default. To make them 'official' would require
>> the existing sign-off. Packages from elm-lang would all be considered
>> 'official'.
>>
>> Each of these packages could then have their own PR approval process
>> which would allow for the experimentation that I talk about. Elm-lang would
>> continue to have its existing PR process until its determined that a better
>> approach should be taken (hopefully based on the results of PR experiments
>> from the un-offical modules).
>>
>> On Friday, July 15, 2016 at 11:33:55 AM UTC-7, Nick H wrote:
>>>
>>> OK, thank you for clarifying!
>>>
>>> Submitting a PR to the official libraries is a very different thing to
>>> submitting a native module to the package repo. I don't think that the
>>> process you are proposing would make any sense for PRs to elm-lang.
>>>
>>> - They are official libraries, so putting an "unofficial" disclaimer on
>>> bits of them would be confusing.
>>> - What do you envision the PR approval process to look like? It sounds
>>> like you are suggesting that all PRs be approved automatically.
>>>
>>>
>>> On Fri, Jul 15, 2016 at 11:13 AM, Justin  wrote:
>>>
 I am afraid I don't understand this definition at all. Are you talking
> specifically about the official elm-lang libraries? Or are you using it as
> a synonym for the package repo?
>
 Thanks for letting me know,
 I am talking about both the official elm-lang libraries and anything
 that needs approval to be published to the package repo (any Elm package
 with native js code, which from what I can tell are mostly non-existent
 outside of elm-lang packages in 0.17, an old example would be
 elm-console
 ).

 The example problem you describe under "Why?" -- four different
> packages that do routing in different ways -- How would this situation be
> any different if people could submit native code?

  I was hoping to communicate here that this is an advantage, now
 different approaches can be taken to solve the problem (and existing
 approaches can be remixed) and the best approach can be rolled into the
 official elm package (which in this case would be
 http://package.elm-lang.org/packages/elm-lang/navigation/1.0.0/).

 thanks for reading!

 On Friday, July 15, 2016 at 10:46:18 AM UTC-7, Nick H wrote:
>
> I define core here to be any project with native Elm code and the
>> compiler.
>
>
> I am afraid I don't understand this definition at al

Re: [elm-discuss] Re: I dislike the names of certain standard library functions.

[John Bugner]

What is the "web platform"? Is there a way I can contribute to this project?

On Friday, July 15, 2016 at 10:41:05 PM UTC-5, Nick H wrote:
>
> One big focus right now is adding support for the rest of the Web Platform 
> to the standard library.
>
> If you haven't yet, you can subscribe to the elm-dev mailing list to keep 
> abreast of what Evan is up to at the moment.
>
> On Fri, Jul 15, 2016 at 8:16 PM, John Bugner  > wrote:
>
>> I don't mean to sound pushy, but if "That's what people are familiar 
>> with." is taken as a valid reason, then why not bring back 'atoi' and such 
>> names then? Why not make the syntax more JS-like? Why not just make Elm yet 
>> another imperative OO language?
>>
>> This is an opportunity for Elm to show that it takes seriously the task 
>> of making programming easier. The fact that the world of programming has 
>> for so long made itself arbitrarily difficult by having incomprehensible 
>> function names (among many other sins) is something that programmers should 
>> be ashamed of, not proud of.
>>
>>
>> On Wednesday, July 13, 2016 at 11:34:45 PM UTC-5, Max Goldstein wrote:
>>>
>>> It's great that Elm can appeal to new programmers, but it's mainly 
>>> targeting web developers. As such, things like max/min, ||/&&, and "string" 
>>> are going to stick around. No need to reinvent what's been standard(-ish) 
>>> since C.
>>>
>>> The biggest name annoyance, IMHO, is *filter*. It doesn't immediately 
>>> convey whether you're selecting in or out. For my money, Ruby got this one 
>>> right: *select* and *reject*. They sound similar and they are similar, 
>>> and the names convey which way the predicate goes. I wouldn't be adverse to 
>>> stealing a few other Ruby or near-Ruby names; perhaps List.includes instead 
>>> of member, and reduce to replace foldl (dropping foldr and renaming it fold 
>>> could also work).
>>>
>>> That said, I'm not convinced much of this will happen. Evan is a "big 
>>> picture" guy, and this would break a lot of code, although deprecation 
>>> (having both copies for awhile) could help.
>>>
>> -- 
>> 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.