[elm-discuss] Elm Visual Debugger/IDE Idea

[Will White]

Hi Conner. I'm interested in working on the debugger in this way, for starters:

https://github.com/elm-lang/elm-make/issues/138

 Having a great visualisation of what's going on could come after, and by then 
I'd like to help with it, but it might be just fine as it is. Would you like to 
help with the issue I've raised above? I just wanted to make you aware of it, 
given your interest in the debugger.

-- 
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: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Tuesday, December 6, 2016 at 7:32:49 PM UTC, Rupert Smith wrote:
>
> On Tuesday, December 6, 2016 at 5:18:04 PM UTC, Wil C wrote:
>>
>> So now, either I write a ports for commonmark.js, or I write it as a 
>> native module. I asked about it here 
>>  with 
>> no answers. 
>>
>
> I think if you write it as ports or native, you'll still need to map the 
> AST between javascript and Elm. As a native module that could be done with 
> a Decoder or by constructing the Elm AST in native code with Javascript. 
> Perhaps Decoders are not so bad?
>
> I don't think a parser is a side-effect. A parser is a pure function from 
> String -> Ast, with no side effects.
>

The thing about ports for something like this is it feels a bit unnatural 
to invoke the port resulting in a Cmd. Then you'll need a subscription port 
to get the result back in, and have that pass it to your update function 
from where you can take it and place it in the model. That doesn't feel 
like a good way to call a function : String -> Ast.

I'd say the best solution is to implemented your parser in pure Elm. But if 
that is too much work, just hack together a native module that calls out to 
commonmark.js. You won't be able to publish your native module to elm 
packages, but that's ok, perhaps no-one else really wants your markdown 
with embedded SQL anyway, and if they do there is always 
elm-github-install. Some time down the road when you really need to share 
this amazing library, redo it in pure Elm. 

-- 
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] Hiring An Elm Developer at BigSquid

[Michael Whitehead]

We are looking to add an elm developer to our team. This is a position that 
will involve leading other junior front end developers, so we would prefer 
someone who is a strong Elm developer. However, if you are skilled at 
design, and can help guide those who are less artistic, then that will make 
up for your lack of elm skills. We are based in SLC Utah, we prefer local 
candidates, but for the right person remote is not out of the question. 

Please email me directly for more information.

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] Using Elm with JSON when you do not know the names and types of the properties at compile time

[Nick H]

What sorts of widgets are we talking about?

If you know what sorts of widgets you are displaying, then you should also
know what types of data they need. If this is true, then you could decode
your JSON to simple "Dict String Json.Value". Then your widgets will have
more fine-grained decoders connected to them. You can pass them the values
for properties x, y, and z from the Dict, and the widgets will try to
decode further.

On Tue, Dec 6, 2016 at 11:50 AM, Hans Rune Bergheim 
wrote:

> Hi!
>
>
> I'd like to create a simple dashboard in Elm, that displays some graphs
> and numbers from json-data. The dashboard should be fully configurable,
> meaning that the users should have a config-file saying they would like to
> get data from service foo, and want to display widget a, b and c, using
> properties x,y, and z of the data. The names and contents of the properties
> may be any name and type, as the data source could be any webservice.
>
>
>
> I've been trying to wrap my head around how to do this in elm, but I'm
> coming up short. Is Elm a bad fit for this type of application, or am I
> just missing a clever way of doing it? I've seen multiple examples of
> dynamic JSON (like this: https://www.brianthicks.com/
> post/2016/10/03/decoding-json-with-dynamic-keys/) , but they all know
> what kind(s) of object(s) that's being decoded at compile time, which is
> not the case here.
>
>
>
> This is fairly straightforward to do in JavaScript, but I'm trying to get
> as much Elm-time as I can these days :-)
>
>
> PS: Coming from JS and .Net-land, I'm having a pretty hard time getting to
> know Elm, but a big shoutout to Richard Feldman and his Elm In Action-book!
> I am really enjoying each chapter so far :) Highly recommended!
>
>
> Hans
>
> --
> 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] Why not components?

[Wouter In t Velt]

Thanks for solving this mystery for us David.
It probably is sensible to avoid anyway:

if someMaybe == ... then

And use

case someMaybe of

(Or .map)
instead. Gives us more protection from the compiler to get all branches 
covered...

-- 
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 not components?

[David Andrews]

They have equality but not comparison.  They can't be used as a Dict key,
for instance.

On Dec 5, 2016 5:39 PM, "Peter Damoc"  wrote:

> This is weird.
> For some reason I got it into my head that tags are not comparable.
> Now I can't remember when or why.
>
> The code seams to work on my end too and for my sanity I checked it on
> 0.17 and 0.16 and it works in those versions too.
> weird.
>
>
>
>
> On Mon, Dec 5, 2016 at 11:59 PM, Wouter In t Velt <
> wouter.intv...@gmail.com> wrote:
>
>> Op maandag 5 december 2016 22:51:02 UTC+1 schreef Peter Damoc:
>>>
>>> You cannot use comparison on tags.
>>>
>>
>> I can see your version is cleaner.
>> Do you mean a comparison with a maybe is not allowed? Like this?
>> -- is this not allowed?
>> if someMaybe == Just 42 then
>>  ...
>>
>> The original change I made did seem to work at my end, and the compiler
>> didn't complain..
>> Or is it convention rather than rule?
>>
>> --
>> 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.
>

-- 
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] Using Elm with JSON when you do not know the names and types of the properties at compile time

[Hans Rune Bergheim]

Hi! 


I'd like to create a simple dashboard in Elm, that displays some graphs and 
numbers from json-data. The dashboard should be fully configurable, meaning 
that the users should have a config-file saying they would like to get data 
from service foo, and want to display widget a, b and c, using properties 
x,y, and z of the data. The names and contents of the properties may be any 
name and type, as the data source could be any webservice. 

 

I've been trying to wrap my head around how to do this in elm, but I'm 
coming up short. Is Elm a bad fit for this type of application, or am I 
just missing a clever way of doing it? I've seen multiple examples of 
dynamic JSON (like this: 
https://www.brianthicks.com/post/2016/10/03/decoding-json-with-dynamic-keys/) 
, but they all know what kind(s) of object(s) that's being decoded at 
compile time, which is not the case here. 

 

This is fairly straightforward to do in JavaScript, but I'm trying to get 
as much Elm-time as I can these days :-) 


PS: Coming from JS and .Net-land, I'm having a pretty hard time getting to 
know Elm, but a big shoutout to Richard Feldman and his Elm In Action-book! 
I am really enjoying each chapter so far :) Highly recommended! 


Hans

-- 
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: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Tuesday, December 6, 2016 at 5:18:04 PM UTC, Wil C wrote:
>
> So now, either I write a ports for commonmark.js, or I write it as a 
> native module. I asked about it here 
>  with no 
> answers. 
>

I think if you write it as ports or native, you'll still need to map the 
AST between javascript and Elm. As a native module that could be done with 
a Decoder or by constructing the Elm AST in native code with Javascript. 
Perhaps Decoders are not so bad?

I don't think a parser is a side-effect. A parser is a pure function from 
String -> Ast, with no side effects.

-- 
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] width of message history in debugger

[Wil C]

Is there a way to expand the width of the message history pane in the 
debugger? I can't seem to see my entire message, since the pane doesn't 
appear to be resizable.

Wil

-- 
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: Stance on native APIs for 0.18?

[Wil C]

I'm building a document editor with executable code in it. So far, I have 
SQL embedded in Markdown. 

For markdown, I needed flexibility in changing the output from the standard 
HTML output, like adding extra info around a code block. I looked at 
elm-markdown, and found it didn't have this flexibility. In addition, it 
embedded a minified version of marked.js inside of it. 

Looked into parsing markdown briefly, and discovered it's not even a BNF, 
and would probably spend a lot of time writing the parser. I found 
commonmark.js. 

So now, either I write a ports for commonmark.js, or I write it as a native 
module. I asked about it here 
 with no 
answers. 

I decided to write it as a native module with elm-markdown.js as a 
template. It's a bit messy in there, because 1) I'm proving out a concept, 
but also, 2) I'm not sure what is considered good practice. I had looked at 
a few other libs with native modules, and it seemed like they were using an 
API of some sort, rather than directly using namespaces like 
"_elm_lang$virtual_dom$Native_VirtualDom"

That's why I was asking. In cases where it's an integration library, like 
talking to the twitter API, I think it makes sense to write it entirely in 
Elm. Might be boring work, but it's doable. But what about things like 
parsers? If you find a parser in JS (ie. code above a certain complexity 
threshold) for a language, should you try to rewrite it in Elm? My guess is 
ideally, yes. But often times, I'm under a time crunch, or I'm more 
interested in proving out a concept to myself, so diving down to take the 
time to write a parser didn't make sense for me this time.

Wil

On Monday, December 5, 2016 at 9:22:42 AM UTC-8, Richard Feldman wrote:
>
> No new thinking on that as far as I'm aware...what are you looking to 
> build?
>
> On Mon, Dec 5, 2016, 8:37 AM Wil C > wrote:
>
>> Do you know if there's going to be a guide on native modules? I just used 
>> elm-markdown as a guide, but I saw there were other conventions in other 
>> libraries with native modules.
>>
>> I understand the hesitation in giving a guide on an escape hatch to 
>> native, since people will instinctively reach for it. Just was wondering if 
>> there was new thinking on it.
>>
>>
>> On Monday, December 5, 2016 at 8:19:14 AM UTC-8, Richard Feldman wrote:
>>>
>>> Looking at the evancz/elm-markdown 
>>>  parser, that seems like a case 
>>> that warrants it, yeah.
>>>
>> -- 
>> 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/nuR4NnCVcMs/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] Re: Elm Visual Debugger/IDE Idea

[Conner Ruhl]

I'm mainly trying to see if people would find this useful or potentially 
fun to work on :)


On Tuesday, December 6, 2016 at 10:42:41 AM UTC-6, Conner Ruhl wrote:
>
> Hello!
>
> Recently I've been thinking a lot about the debugger... The potential for 
> time travel and replaying program state across browsers is absolutely 
> massive. It's been the most sellable quality of Elm in my experience.
>
> I've been on the hunt for an open source project and I'm considering 
> attempting to write a really slick visualizer based on the 0.18 debugger. 
> I'd love to see messages passing into update functions and the model 
> reacting in a highly visual way. Eventually it would be really cool if 
> there was a visualization of the entire program you could interact with to 
> make code changes.
>
> Anyway, I think the idea of prettying up the debugger into a tree-like 
> structure could be fun on its own. Could anyone see themselves using such a 
> project?
>
> 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.

[elm-discuss] Re: One month with Elm, two questions

[Max Goldstein]

Oops, that second annotation should be

viewHelper : { a | name : String } -> Html Msg 

-- 
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] Elm Visual Debugger/IDE Idea

[Conner Ruhl]

Hello!

Recently I've been thinking a lot about the debugger... The potential for 
time travel and replaying program state across browsers is absolutely 
massive. It's been the most sellable quality of Elm in my experience.

I've been on the hunt for an open source project and I'm considering 
attempting to write a really slick visualizer based on the 0.18 debugger. 
I'd love to see messages passing into update functions and the model 
reacting in a highly visual way. Eventually it would be really cool if 
there was a visualization of the entire program you could interact with to 
make code changes.

Anyway, I think the idea of prettying up the debugger into a tree-like 
structure could be fun on its own. Could anyone see themselves using such a 
project?

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] What ways are there of running Elm server side?

['Rupert Smith' via Elm Discuss]

On Tuesday, December 6, 2016 at 10:43:07 AM UTC, Rupert Smith wrote:
>
> Will go with the port for now.
>

There is something slightly annoying about the port, and that is that 
processing the Cmd to call the port happens through setTimeout(function, 
millis). This needs polyfilled on Nashorn, and uses Platform.runLater() 
which runs it in an internal thread on the JavaFX engine.

All I want is an evaluation of a function from Value -> String (input Json 
output rendered Html as a String). I don't really need to make use of the 
event driven side of Elm at all.

To avoid doing this, I think I will go the route of defining some new 
program types for static rendering server side. I may also want static 
program types that produce Strings or Json. Once I've got rendering of 
static Html working, I will look into moving all my code generation 
templates over to Elm from StringTemplate. I really like having Elm as a 
functional language for templating, it beats any crappy templating engine 
I've ever tried.

I'm just now writing a constructor for StringPrograms, that will apply 
htmlToString. I'm sticking with the Platform.Program type to provide the 
structure to my Programs, 'flags' is taken as the input type, 'model' as 
the output type, and 'init' is a function from the input to output types. 
The msg type is Never, and subsciptions and updates are filled in with 
noops.

I'll need to crank some javascript for my program types to provide a 
convenient way to get hold of them in javascript land. Using a trick 
similar to how Platform.program makes itself reachable from the outwith the 
Elm compiled code:

function program(impl)
{
return function(flagDecoder)
{
return function(object, moduleName)
{
object['worker'] = function worker(flags)
{

'object' is the elm module, and I can set whatever fields I want on it when 
constructing a program. I just need to set up a function to pass in the 
input type and get back the output type.

Here are my Program types and the constructor signature that I am working 
on for programs that render Html to a String:

type alias HtmlProgram =
Program Value (Html Never) Never


type alias JsonProgram =
Program Value Value Never


type alias StringProgram =
Program Value String Never

htmlToStringProgram : { init : Value -> Html Never } -> StringProgram

I've been able to get Elm running on Nashorn now. Its not fast... I think 
Nashorn can be pretty quick, its just that it takes a long time for JIT to 
kick in and optimize things and the first passes through the code are slow 
with default settings. It took a minimal amount of polyfilling on Nashorn 
to support it. All code is on github:

https://github.com/rupertlssmith/elm-server-side-renderer

-- 
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: One month with Elm, two questions

[Max Goldstein]

I see now. You want to see a UI widget in many possible states for the 
purposes of seeing a visual regression. (By "widget", I mean some piece of 
HTML generated by a function, not the loaded word "component", which 
usually implies state. Although it could be either.) Without saying too 
much, I know there is some programmatic HTML-based testing in the pipeline 
but actually seeing the rendered output would be a nice complement to that.

If all you want to do is generate a random value of the Model type, you 
should be fine with Random, not fuzzers. All of the map functions for 
fuzzers have versions in the core Random library, and I'd be happy to go 
into more detail here if you need it.

The other possibility is to randomly generate many Msg values, and run 
update on them. This has the potential benefit of testing the update 
function, and avoiding some weird mode state that update would never 
produce (though as much as possible such states should be made 
unrepresentable).

But back to fuzzers: a fuzzer is just a random number generator plus a way 
to shrink the value generated. There *might* be value in shrinking those UI 
widget examples. Imagine devcards, except when you see a visual regression, 
you can hit a button to generate a model that is in some way "smaller" than 
the previous one. You can keep doing this (and rejecting changes that "fix" 
the problem) until you get to a minimal reproduction of the error. This 
would likely give insight into the root cause, and ideally, the example can 
be saved as a regression test.

This has an impact on how I was planning to expose fuzzers. I think for 
this use case, you'd want to take a fuzzer and say, "give me a random 
value, and a way to say that it does or does not reproduce an error." It 
would also have an impact on how view functions are written. It's common to 
write

viewHelper : Model -> Html Msg

indicating that the function consumes the entire model, which could be a 
very large record. If you wrote instead

viewHelper : { a | name : String }

this indicates that any record with a name field of type string is 
acceptable. It will accept a larger record, such as model, but also just 
{name : "Steve"}. This means shrinking can target the fields the view is 
using, and not the ones it is ignoring, to produce a much better result. It 
also means that you'd need to produce a special fuzzer for this function, 
and expose it from its module (typically the View module hides its helpers).

So, I might be getting ahead of myself here. If it's worthwhile to be able 
to shrink models that cause visual glitches, than this is a road we can 
pursue further. If not, and even if it is but in the short term, I think 
you will be able to randomly generate a model with the random libraries, 
not fuzzers.

-- 
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: Error Repository?

[Luke Westby]

Can you (a) see if your issue has been reported and (b) if not, submit a 
new issue at https://github.com/elm-lang/error-message-catalog?

On Tuesday, December 6, 2016 at 6:40:39 AM UTC-6, John Orford wrote:
>
> Where do I send an, as a suggestion to improve the error message output?
>
> I accidentally swapped the inputs of a fold lambda,
>
> e.g. 
>
> foldr (\ a c -> ... ) 
>
> instead of
>
>  foldr (\ c a -> ... )
>
> which started complaining about infinite types etc, rather than(in this 
> context at least) nudge me towards having the variables in the wrong order 
> (switching back and forth between languages, does this to you...)
>
>
>

-- 
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: Error Repository?

[OvermindDL1]

https://github.com/elm-lang/error-message-catalog is the place to report 
needing better error messages.  It is generally best to talk about it here 
first.  When reporting there be sure it does not already exist in another 
issue (even if closed one as issues can be aggregated together).


On Tuesday, December 6, 2016 at 5:40:39 AM UTC-7, John Orford wrote:
>
> Where do I send an, as a suggestion to improve the error message output?
>
> I accidentally swapped the inputs of a fold lambda,
>
> e.g. 
>
> foldr (\ a c -> ... ) 
>
> instead of
>
>  foldr (\ c a -> ... )
>
> which started complaining about infinite types etc, rather than(in this 
> context at least) nudge me towards having the variables in the wrong order 
> (switching back and forth between languages, does this to you...)
>
>
>

-- 
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] elm-doc-test syntax

[Christoph Hermann]

Hey!
I'm currently working on elm-doc-test 
https://github.com/stoeffel/elm-doc-test.
Elm-doc-test is a tool that turns doctests (like python's doctest) into 
elm-tests and you can then run them using elm-test.
There are some advantages with this approach, like nice assertion messages 
and compiler errors for broken doctests (see readme for examples).
Richard, Noah and I had a discussion about the syntax for writing doctests 
(in https://github.com/stoeffel/elm-doc-test/pull/10) and I opened an issue 
to take the discussion further 
(https://github.com/stoeffel/elm-doc-test/issues/12).

the current syntax is:
`>>> ` for an assertion, `... ` if the assertion needs more than 
one line and the following lines indented with 4 spaces is the expectation.

{-|
>>> indexOfLineWithEquals
...  <| Array.fromList
...  <| String.lines "a\nb\nc = d\nf = d\n"
2

>>> indexOfLineWithEquals
...  <| Array.fromList
...  <| String.lines ""
0
-}

There are some alternatives in the issue using only one `>`. 
As I stated in that issue I would like to keep the current syntax, because 
it's more obvious that `>>>` is not part of the example and not elm code, 
where `>` could easily be confused for a `gt` sign.


I would love to hear what the community thinks about the syntax.


Thanks Stöffel

-- 
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] elm-doc-test syntax

[Christoph Hermann]

Hey!
I'm currently working on elm-doc-test 
https://github.com/stoeffel/elm-doc-test.
Elm-doc-test is a tool that turns doctests (like python's doctest) into 
elm-tests and you can then run them using elm-test.
There are some advantages with this approach, like nice assertion messages 
and compiler errors for broken doctests (see repo for examples).
Richard, Noah and I had a discussion about the syntax for writing doctests 
(in https://github.com/stoeffel/elm-doc-test/pull/10) and I opened an issue 
to continue the discussion 
(https://github.com/stoeffel/elm-doc-test/issues/12).

the current syntax is:
`>>> ` for an assertion, `... ` if the assertion needs more than 
one line and the following lines indented with 4 spaces is the expectation.

```
{-|
>>> indexOfLineWithEquals
...  <| Array.fromList
...  <| String.lines "a\nb\nc = d\nf = d\n"
2

>>> indexOfLineWithEquals
...  <| Array.fromList
...  <| String.lines ""
0
-}
```

There are some alternatives in the issue using only one `>`. 
As I stated in that issue I would like to keep the current syntax, because 
it's more obvious that `>>>` is not part of the example and not elm code, 
where `>` could easily be confused for a `gt` sign.


I would love to hear what the community thinks about the syntax.


Thanks Stöffel

-- 
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] Error Repository?

[John Orford]

Where do I send an, as a suggestion to improve the error message output?

I accidentally swapped the inputs of a fold lambda,

e.g.

foldr (\ a c -> ... )

instead of

 foldr (\ c a -> ... )

which started complaining about infinite types etc, rather than(in this
context at least) nudge me towards having the variables in the wrong order
(switching back and forth between languages, does this to you...)

-- 
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: One month with Elm, two questions

[Frankie Sardo]

Thanks for your answer Max,

When I think about using fuzzers outside elm-test one of the use cases I 
have in mind is something à la devcards https://github.com/bhauman/devcards

If you don't know about it it's a very useful tools used by the 
clojurescript community to mount a UI using different snapshots of its 
state and observe how it changes. I wrote an article not so long ago about 
using generative models to observe your UI under edge cases 
(https://juxt.pro/blog/posts/generative-ui-clojure-spec.html) (live example 
here https://frankiesardo.github.io/speccards/#!/speccards.app). Because 
Elm is strictly typed this should actually be a lot easier to implement :)

Faker is good, but actually using randomly generated data derived from your 
type system ensures you have chosen the good type representation in the 
first place


On Tuesday, December 6, 2016 at 3:09:20 AM UTC, Max Goldstein wrote:
>
> Hi Frankie, thanks for trying Elm, glad you like it!
>  
>
>> But why isn't the ability to create fuzzy records/data available outside 
>> that package? What I usually do is to stub out the UI given a certain model 
>> type. Being able to call fuzzy generators in my Main namespace to populate 
>> the model makes it easier iterate on an initial design and can still be 
>> very useful to run the application in 'mock mode'. Any chance we can see 
>> the generators extracted in their own library?
>
>
> I'm the co-author of elm-test. We're going to add a way to run fuzzers 
> outside of elm-test  
> but that's probably not what you want. The fuzzers are designed to produce 
> edge cases, and most of the work that goes into them is around being able 
> to shrink values into smaller forms to obtain a minimal test failure. Test 
> data is fundamentally different from mocked data, especially if you want to 
> be able to do UI design or take screenshots (i.e. for documenting your UI). 
> I think you may want random-extra 
>  
> which 
> includes a lot of similar helper functions, though it's still fairly 
> primitive.
>
> Long-term, I would love for someone to port part of faker 
>  to Elm.
>
>

-- 
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] What ways are there of running Elm server side?

['Rupert Smith' via Elm Discuss]

On Wednesday, November 23, 2016 at 9:35:21 PM UTC, Noah Hall wrote:
>
> You'll need to set up a port to pull the generated string out, but 
> it's trivial bit of work to do with the elm-server-side-renderer 
> project. Just take a look at how something like elm-test pulls values 
> out through a port. 
>

I should have read this more closely, because I spent ages looking at 
elm-test and wondering how it runs the test Program, and gets results out. 
In particular it uses testModule.worker to pass the start flags into the 
program, but I was finding that myModule.worker was undefined. Well of 
course it is, I was using Html.programWithFlags, when I should have been 
using Platform.programWithFlags.

Platform.programWithFlags is headerless, so there is no view. Then I look 
in an elm-test example, and I see that it is indeed using a port to return 
the results.

I suppose another approach might be to use a Program type that does have a 
view, set up the javascript environment in such a way that it polyfills 
enough of the browser environment that the 'normalRenderer' will be able to 
work. Then render the HTML to the view and extract it from there? It might 
make server side rendering more naturally fit into Elm to define a 
particular Program type for it, that has a view.

Will go with the port for 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.