[elm-discuss] Re: Elm events 2017

[Brian Hicks]

elm-conf 2017 is coming back on September 28. That one might qualify. ;)

Haven't announced more "formally" yet because we need to redo the website 
first to be more informative.

On Thursday, January 5, 2017 at 10:49:08 PM UTC-5, Michael B wrote:
>
> Hi Rupert,
>
> I'm the author of elm-events.org. As you can see, it's looking pretty 
> empty at the moment! I've been manually maintaining the upcoming talks and 
> workshops and go to some effort to find a conference logo, speaker images, 
> do cropping, etc, so it can't really be automated. This is an example of 
> what it looks like when there are actually upcoming events listed: 
> http://builtwithelm.co/data/images/elm-events.png.
> I was hoping to get pull requests, but that has rarely happened. I've 
> gotten pretty lazy with updating this website as it doesn't seem to get 
> much traffic. The github repo is at https://github.com/mbylstra/elm-events. 
> I'd be happy to help you contribute to that (it's basically a simple static 
> website written in Elm), but if you'd like to start something completely 
> new in a different format, I'm fine with that also.
>
> The Meetup events are courtesy of an API written by Phillip Poots for Elm 
> Weekly - these are automatically collected from the meetup.com API.
>
> cheers,
> Michael.
>
>
> On Friday, January 6, 2017 at 10:19:39 AM UTC+11, Rupert Smith wrote:
>>
>> Thinking of drawing up a list of events, dates and places where Elm will 
>> be on the menu in 2017. Would people be interested in contributing what 
>> they know to build up the list? Also, I have a feeling someone may already 
>> have done this, in which case point me to 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] Emphasizing /r/elm more

[Brian Hicks]

Here, if a newcomer posts a basic question, many people will ignore 
them, but the poster doesn't know that. Someone will post a solution, 
or a link to one, and they will be on their way. On /r/elm, they see 
their post sitting at 1,0 or -1 votes, and and up feeling like 
newcomer questions aren't welcome, and are more likely to try to find 
a tool with a more friendly community.


I’m planning to do a sticky post on /r/elm every week in the vein of 
the Rust “easy questions” post. You’re right that this happens, 
and this seems to be a nice way around it.


On 5 Jan 2017, at 18:18, Joey Eremondi wrote:

My main hesitation about reddit is that, even on the best-case subs 
like

/r/rust, newcomer posts tends to get downvoted or ignored.

Here, if a newcomer posts a basic question, many people will ignore 
them,
but the poster doesn't know that. Someone will post a solution, or a 
link

to one, and they will be on their way. On /r/elm, they see their post
sitting at 1,0 or -1 votes, and and up feeling like newcomer questions
aren't welcome, and are more likely to try to find a tool with a more
friendly community.

My vote would be for Discourse or something similar. I think being 
able to
sticky posts would remove a lot of the redundant messages we see on 
this
list, and being able to sort by subject would make it easier for 
people to

see what they're most interested in.



On Thu, Jan 5, 2017 at 3:14 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

On Wednesday, January 4, 2017 at 7:00:34 PM UTC, Martin DeMello 
wrote:


I'm a heavy reddit user, and I think it simply lacks the features
necessary to support mailing-list-style discussions:



You can't quote when replying.

I like newsgroups so much better then /r/elm. I like the old 
fashioned

feel of them, the anarchic style, the freedom to be conversational or
express myself however I like within the confines of ASCII. There is 
still
something of the old attitude of usenet alive in them that just seems 
to be

lacking on the alternatives. I take great pride in quoting carefully,
replying to multiple questions with responses in-line underneath, not 
top
posting and so on. In other words newsgroups or mailing lists take 
bit of
work and manners to operate successfully and that all contributes to 
making

a community.

A few thoughts for you:

Having a split community might actually be a good thing. For one, 
there
are enough people interested that >1 splinter of this community is 
alive
concurrently. That in itself is an achievement because something 
needs to
reach a certain size for that to happen. Also it makes the community 
as a

whole more resilient - if one splinter dies out, others may carry on.

Removing duplication is a good thing for code - but for community 
growth

and engagement, perhaps it isn't.

So I'm just going to keep on posting here, because it is the best 
place

for me and I've had plenty interesting and helpful responses.

Also, what about this:

http://elm-news.com/

Perfect for keeping up-to-date with multiple channels. All it needs 
is
user accounts or to use local storage so it can keep track of what 
you have

read or not.

--
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 a topic in the 
Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/elm-discuss/rg3fzdyG_VU/unsubscribe.
To unsubscribe from this group and all its topics, 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] Elm events 2017

['Rupert Smith' via Elm Discuss]

Thinking of drawing up a list of events, dates and places where Elm will be 
on the menu in 2017. Would people be interested in contributing what they 
know to build up the list? Also, I have a feeling someone may already have 
done this, in which case point me to it.

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

Re: [elm-discuss] Re: Emphasizing /r/elm more

[Joey Eremondi]

My main hesitation about reddit is that, even on the best-case subs like
/r/rust, newcomer posts tends to get downvoted or ignored.

Here, if a newcomer posts a basic question, many people will ignore them,
but the poster doesn't know that. Someone will post a solution, or a link
to one, and they will be on their way. On /r/elm, they see their post
sitting at 1,0 or -1 votes, and and up feeling like newcomer questions
aren't welcome, and are more likely to try to find a tool with a more
friendly community.

My vote would be for Discourse or something similar. I think being able to
sticky posts would remove a lot of the redundant messages we see on this
list, and being able to sort by subject would make it easier for people to
see what they're most interested in.



On Thu, Jan 5, 2017 at 3:14 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Wednesday, January 4, 2017 at 7:00:34 PM UTC, Martin DeMello wrote:
>>
>> I'm a heavy reddit user, and I think it simply lacks the features
>> necessary to support mailing-list-style discussions:
>>
>
> You can't quote when replying.
>
> I like newsgroups so much better then /r/elm. I like the old fashioned
> feel of them, the anarchic style, the freedom to be conversational or
> express myself however I like within the confines of ASCII. There is still
> something of the old attitude of usenet alive in them that just seems to be
> lacking on the alternatives. I take great pride in quoting carefully,
> replying to multiple questions with responses in-line underneath, not top
> posting and so on. In other words newsgroups or mailing lists take bit of
> work and manners to operate successfully and that all contributes to making
> a community.
>
> A few thoughts for you:
>
> Having a split community might actually be a good thing. For one, there
> are enough people interested that >1 splinter of this community is alive
> concurrently. That in itself is an achievement because something needs to
> reach a certain size for that to happen. Also it makes the community as a
> whole more resilient - if one splinter dies out, others may carry on.
>
> Removing duplication is a good thing for code - but for community growth
> and engagement, perhaps it isn't.
>
> So I'm just going to keep on posting here, because it is the best place
> for me and I've had plenty interesting and helpful responses.
>
> Also, what about this:
>
> http://elm-news.com/
>
> Perfect for keeping up-to-date with multiple channels. All it needs is
> user accounts or to use local storage so it can keep track of what you have
> read or not.
>
> --
> 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: Emphasizing /r/elm more

['Rupert Smith' via Elm Discuss]

On Wednesday, January 4, 2017 at 7:00:34 PM UTC, Martin DeMello wrote:
>
> I'm a heavy reddit user, and I think it simply lacks the features 
> necessary to support mailing-list-style discussions:
>

You can't quote when replying.

I like newsgroups so much better then /r/elm. I like the old fashioned feel 
of them, the anarchic style, the freedom to be conversational or express 
myself however I like within the confines of ASCII. There is still 
something of the old attitude of usenet alive in them that just seems to be 
lacking on the alternatives. I take great pride in quoting carefully, 
replying to multiple questions with responses in-line underneath, not top 
posting and so on. In other words newsgroups or mailing lists take bit of 
work and manners to operate successfully and that all contributes to making 
a community.

A few thoughts for you:

Having a split community might actually be a good thing. For one, there are 
enough people interested that >1 splinter of this community is alive 
concurrently. That in itself is an achievement because something needs to 
reach a certain size for that to happen. Also it makes the community as a 
whole more resilient - if one splinter dies out, others may carry on.

Removing duplication is a good thing for code - but for community growth 
and engagement, perhaps it isn't.

So I'm just going to keep on posting here, because it is the best place for 
me and I've had plenty interesting and helpful responses.

Also, what about this:

http://elm-news.com/

Perfect for keeping up-to-date with multiple channels. All it needs is user 
accounts or to use local storage so it can keep track of what you have read 
or not.

-- 
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] Emphasizing /r/elm more

[Wojciech S. Czarnecki]

Dnia 2017-01-04, o godz. 19:44:41
"Brian Hicks"  napisał(a):

> >>- Moderation to avoid spam is more difficult. All new users are

> As one of the people who approves every post 
> from a new author manually

OK. I misread. First post must be checked anyway and that can be a burden
with a volume.

I went a bit ballistic, because all these BB based venues are abysmal and
gobble time. Take my sincere apologies.

-- 
Wojciech S. Czarnecki
   ^oo^ OHIR-RIPE

-- 
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: Feature: 'where' expressions (continued from GitHub)

[Colin Woodbury]

@Bob H & @Andrew R: Thank you.

@Janis: It's likely that we could continue to produce extensions/refactors 
to each other's examples for eternity (which isn't a bad thing, I don't 
think this is a waste of time at all). In the case of such a `munge` in 
your example, yeah, following a "factor out common behaviour" maxim, I'd 
default to a new (likely non-exported) function as I did 
here: https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-103349671

@Richard F:

>> That said, conflict breeds evolution and improvement.
> It also slows down projects. If Evan spent time seriously considering 
every possible syntax improvement, Elm still wouldn't even have a virtual 
DOM system.

Slippery slope. Wanting to not rock the boat under any circumstance creates 
echo chambers. Honest question: Do you know if Evan believes that conceding 
on `where` would mean "opening the floodgates", and he's concerned he'd 
never hear the end of proposals for improvements (from "the Haskell people" 
or otherwise)?

> This is not a pain point for the overwhelming majority of the Elm 
community

If the "target audience" is JS devs who have never heard of `where`, then 
of course it isn't, because they don't know what they're missing. We've 
seen a few non-Haskell Elm users here say "hey I'd like that". 

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

Re: [elm-discuss] Re: Game entities design question

[John Mayer]

I'm a fan of ECS, not too difficult to roll your own. Doesn't rely on any
fancy types.

On Jan 5, 2017 9:50 AM, "Martin Cerny"  wrote:

Hi Andrew,
I don't think there are any direct obstacles to doing the same with
extensible records, but I think extensible records also have no advantages,
produce code that is IMHO slightly harder to read, and could introduce some
problems in larger codebases.

Note that OOP game engines I've worked with (Unity most notably, but also
bits of Cry and Unreal) prefer encapsulation over inheritance. In Unity a
game object is a collection of components (Collision, AI, etc.), instead of
objects inheriting the individual components. This is why I felt the
proposed solution to be better.

A possible counter-argument would be that the nature of Elm's records means
that multiple inheritance (nested extension of records)  is not an issue as
would be in OOP [1]. However, with extensible records, you cannot reuse the
same field name across the different components - or, more precisely, when
you do it, compiler will either merge the fields (if they have the same
type) and your components will likely not work the way you expect or the
compiler will produce confusing error messages if the fields have the same
name but differ in type.

[1] With type aliases, (Positioned (WithAI x) ) is equivalent to (WithAI
(Positioned x))

Martin


On Wednesday, 4 January 2017 20:46:44 UTC+1, Andrew Radford wrote:
>
> Martin are there any pros/cons to using extensible records for the game
> entities? i.e closer conceptually to an OOP model where an entity might
> inherit Collision/Physics properties from a common base class?
>
> Andrew
>
>
>>> --
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: Game entities design question

[Martin Cerny]

Hi Andrew,
I don't think there are any direct obstacles to doing the same with 
extensible records, but I think extensible records also have no advantages, 
produce code that is IMHO slightly harder to read, and could introduce some 
problems in larger codebases. 

Note that OOP game engines I've worked with (Unity most notably, but also 
bits of Cry and Unreal) prefer encapsulation over inheritance. In Unity a 
game object is a collection of components (Collision, AI, etc.), instead of 
objects inheriting the individual components. This is why I felt the 
proposed solution to be better. 

A possible counter-argument would be that the nature of Elm's records means 
that multiple inheritance (nested extension of records)  is not an issue as 
would be in OOP [1]. However, with extensible records, you cannot reuse the 
same field name across the different components - or, more precisely, when 
you do it, compiler will either merge the fields (if they have the same 
type) and your components will likely not work the way you expect or the 
compiler will produce confusing error messages if the fields have the same 
name but differ in type.  

[1] With type aliases, (Positioned (WithAI x) ) is equivalent to (WithAI 
(Positioned x))

Martin

On Wednesday, 4 January 2017 20:46:44 UTC+1, Andrew Radford wrote:
>
> Martin are there any pros/cons to using extensible records for the game 
> entities? i.e closer conceptually to an OOP model where an entity might 
> inherit Collision/Physics properties from a common base class?
>
> Andrew
>
>
>>>

-- 
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 "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Bob Zhang]

Indeed,  in OCaml native backend, `for loop` still dominates the
performance critical code since most optimizations does not work across
function boundaries.
   There is still a long way for optimizing compiler to catch up with
carefully tuned code, but BuckleScript does not get in your way, you can
still write low level code with type safe guarantee  in it when performance
matters

On Thu, Jan 5, 2017 at 12:32 AM, GordonBGood  wrote:

> On Wednesday, 4 January 2017 21:05:58 UTC+7, Bob Zhang wrote:
>>
>> Hi Gordon,
>>   As you can see, BuckleScript already did a very good good job here, of
>> course, there are still places for improvement. To write extremely high
>> performance code, you should avoid creating a closure in a tight loop, here
>> you can lift the `nxtc` into the top level, in the future, we will do this
>> inside the compiler. Lets take further discussions off the list -- Hongbo
>>
>
> Hi Hongbo, yes, BuckleScript did a very good job other than 1) mistakenly
> determining that the closure was necessary, then 2) not automatically
> lifting the closure, and then 3) not inlining the resulting (non-closure)
> function call away (see Haskell join points optimizations).  I'm just
> sayin' ;)  In case you needed adding to your TODO list...
>
> In fact, BuckleScript *already does* catch most cases of these, and
> didn't in this one case because the enclosing loop has been tail call
> optimized (manually in case of the code I showed) so become a "ugly
> imperative code" loop internally, and the compiler then treats the binding
> `p` derived from an impure loop variable as impure and thus needing closure
> treatment, which seems to cause the resulting function to be invalidated as
> a candidate for inlining.  The compiler needs to see that the the binding
> `p` is invariant (in fact guaranteed as the compiler injected a let on the
> loop variable) during the whole creation and execution of the `nxtc`
> function, therefore doesn't need the closure and thus can be inlinee.
>  (BTW, it seems that BuckleScript ignores the [@@inline] and [@inlined]
> OCaml extensions?)
>
> If  the `nxtc` function is lifted to the top level, then it needs to be
> written so that the otherwise free bindings are arguments (`p` and `cmpsts`
> in this case) and thus it is no longer a closure, and even if there were an
> inner worker closure, BuckleScript already inlines and tail calls when
> captured bindings are arguments or derived from arguments of a function
> call, recognizing that they are pure.  There will still be a function call
> to the lifted `nxtc` where there wouldn't be if it were inlined however,
> which means that inlining would be better, although the function call has
> negligible cost relative to the rest of the work in this case.
>
> The only reason this was noticeable here is that it turns out that the
> time cost is not so much in the creation of the closure but much more the
> cost of binding a function (a closure in this case) to a variable.  It's
> interesting how incredibly slow JavaScript/V8 is at creating a function
> binding rather than just calling one - I calculate 10's of thousands of CPU
> clock cycles; it must be dropping back to evaluating the expression each
> loop rather than JIT compiling it plus the expected time of creating a
> function object on the heap.  This isn't BuckleScript's problem, just that
> BuckleScript can help avoid it for the unwary.
>
> Stepping back, I don't have much to complain about, as before I met
> BuckleScript I would have been writing TypeScript/JavaScript mostly
> imperatively and BuckleScript/OCaml offers the option to do the same, if
> necessary for extremely time critical code!  I've just gotten used to
> avoiding that paradigm.
>
> Yes, let's move the discussion somewhere else as it isn't relevant here. I
> just want to say thanks for the heads-up on BuckleScript, which I am quite
> enjoying in spite of its OCaml syntax foibles.  Now I can develop both Elm
> and BuckleScript inside similar development environments using the Visual
> Studio Code plugins. - Gordon
>
>
>> On Wed, Jan 4, 2017 at 1:17 AM, GordonBGood  wrote:
>>
>>> Hi Bob/Hongbo,
>>>
>>> I've run into my first speed problem with BuckleScript:  When it decides
>>> it needs to form a closure of captured free binding(s), it creates a
>>> "function returning a function" with the outer function's arguments being
>>> the current state of the "pure" captured bindings, and the inner returned
>>> function the actual closure code.  When this happens anywhere near an inner
>>> loop, the code gets very slow, although sometimes the compiler is smart
>>> enough to infer that the closure is not necessary is when the binding value
>>> is an argument of an enclosing function; however, this does not happen for
>>> local `let` bindings even when they are in the same scope as the
>>> callee/caller sites.
>>>
>>> For example, the following bit-packed Sieve of Eratosthenes 

Re: [elm-discuss] How does evancz.Markdown work?

['Rupert Smith' via Elm Discuss]

On Wednesday, January 4, 2017 at 11:24:31 PM UTC, Noah Hall wrote:
>
> It does support custom and supports markdown as a special case - 
>
> https://github.com/eeue56/elm-server-side-renderer/blob/master/src/ServerSide/Markdown.elm
>
> However, it doesn't convert it to html on the server side. That should be 
> trivial to add - just a called to marked, but I haven't needed it yet.
>

To try it out I call a native markdown render in the 'nodeTypeToString' 
function:

MarkdownNode record ->
Native.Markdown.render record.model

Which calls this:

function render(model) {
var html = marked(model.markdown, formatOptions(model.options));
return html;
}
 
But this differs from what gets rendered when running in the browser, as I 
took the document.createElement('div') part out:

https://github.com/evancz/elm-markdown/blob/3.0.1/src/Native/Markdown.js#L23

The Mardkown is supposed to render in a div, and that div gets a copy of 
any attributes set on the Markdown:

Markdown.toHtml [ {- These attributes here get set on the div -} ] makdown

How would you recommend handling this? 

Make the nodeTypeToString function more sophisticated so it includes the 
logic from nodeRecordToString to set the attributes on the resulting div? 

OR change decodeMarkdownNodeRecord, so that it returns a NodeType 
descirbing a div with the correct attributes set, that wraps the "custom" 
markdown NodeType as a child?

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