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

[Gage Peterson]

Totally agree. Reddit here I come. 

Also, I feel we really need to treat Evan like the awesome leader he is. Give 
the guy a break. He's making one of the best languages I've ever used. 

-- 
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: Support for binary data

[Duane Johnson]

My use case:

I have a compiled microcontroller file (a ".hex" file) delivered to the 
client browser. I use the data to draw a fancy SVG barcode that is 
subsequently displayed on the screen and scanned by a camera (like a QR 
Code).

I need a way to retrieve binary data from the server, and iterate over 
16-bit integer values.

-- 
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] Convert Char to Int?

[Duane Johnson]

Big picture:

I'm writing a visual display algorithm of a binary ".hex" file that is the
result of compiling code on the Arduino platform. I load the file into the
browser via HTTP.getString, and then attempt to display the values.

Problem:

I'm unable to find a way to represent this binary data stream as a series
of 16-bit integers. I've attempted String.toList which results in a (List
Char) type, but what should I do with Char? Char.toCode and Char.fromCode
seem specifically tuned for use with keyboard events.

Is there a way to handle a binary data series in Elm?

Thanks,
Duane Johnson

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Bob Zhang]

As I said, you already get convinced elm is better for you, then happy
coding in elm. I am not interested in a biased judgement.
On Thu, Jan 26, 2017 at 7:29 PM GordonBGood  wrote:

> On Thursday, 26 January 2017 21:13:33 UTC+7, Bob Zhang wrote:
>
> Hi Gordon,
>  I think it is inappropriate to discuss BuckleScript performances on this
> mailing list (people may feel unhappy about this), if you are interested,
> we can discuss on BuckleScript github issues(I will create a mailing list
> too).
>
>
> Yes, Hongbo, I considered that, but since the subject of this thread is
> speed, and BuckleScript has been brought up many times as a speedy
> alternative to Elm including by yourself as author, I just wanted to show
> that all is not roses in BuckleScript land.  I have done some more work in
> this issue and am beginning to think that the choice of JS Array's as the
> base data representation in BuckleScript as opposed to JS Object/Records in
> Elm/Fable may not have been a good one for consistency of performance
> across browsers but wonder what you think it is:  it seems that Chrome V8
> optimizes relative JS Array performance much better than other browsers,
> especially Firefox, which may be what is reflected here.  I also re-ran the
> functional primes benchmark on Firefox and again found the BS version very
> slow, in this case about five times slower than Elm.  If you want to open
> up an alternate means of communication about this issue, I will be happy to
> contribute further as to BuckleScript development.  Perhaps an issue should
> be filed in the BuckleScript repo?
>
> Now all is not roses in Elm land either, which IS the subject of this
> thread:  while as Robin Heggelund Hansen has pointed out, JS
> Objects/Records seem to be a fine efficient data representation across
> browsers, different browsers seem to do different quality jobs in interning
> the string tags, or at least Elms way of emitting them, with the Chrome way
> much more suited than that of FireFox or Edge (the worst) so that I believe
> that most of the performance issues I have in different browsers are due to
> this.  Of course, if the Elm back end were using the static type
> information that should be available to it (the actual subject of this
> thread), this this would not be a problem, as the use of any tag
> information could be minimized and reduced to identifying which of the set
> of union cases is in play.
>
> What I have learned (and which BS does very well) is that no tags are
> actually needed or desired except for ADT's/tagged unions (that's why tag
> is in the name) *if type information is used*, and that while BS uses
> numeric indices for JS Array's, string/s/symbols with Object/Records are
> likely at least as good *as long as we help the JS engine do string
> interning* in order to get better speed consistency across browsers.  I
> will be writing more about this shortly as soon as I complete some more
> benchmarks.
>
> Meanwhile, I now know why elm-lang/lazy is so slow on Chrome V8 when used
> in lazy lists:  they are implemented as nested functions, which sometimes
> get inlined but when not (as when part of lazy list definitions) are about
> 50 times slower than Immediately Invoked Function Expressions (IIFE's) on
> Chrome V8.  This is a problem unique to Chrome V8, as new Firefox doesn't
> have a problem with nested functions at all, and they have a relatively
> minor cost in Edge.  The use of nested functions is a common problem across
> JS language transpilers (for instance Fable), and although BS has a
> different implementation of Lazy that doesn't use nested functions, it is
> the cause of the huge slowdown I pointed out earlier for embedded closures,
> for which BS does use nested functions.  Here is a link to some
> performance tests and data.
>   I plan to re-write
> elm-lang/lazy to use IIFE's instead of nested functions, which should take
> care of the Elm speed discrepancy problem in Chrome.  While this is easily
> fixed for elm-lang/lazy because it is a library, it isn't so easy to fix
> for closures that are implemented as nested functions by the compiler
> itself; although they, too, can be "lifted" and implemented as IIFE's, this
> needs to be done by the compiler and not just a library.
>
>
>   A minor comment:
> > As Elm does not have mutable linear arrays, for the big_uint functions
> I created a Native JS based library into which I just inserted the same JS
> code as created by the BS compiler for fairness; other than that it uses
> the same algorithm as the BS code.
>
> This is seriously biased, it is similar to when benchmarking the perf of
> Python against JS, Python users rewrite the hot function in C and call it
> from Python due to the incapability of Python.
>
>
> While I agree that using a compiled library function in interpreted Python
> to benchmark Python speed is a fallacy, both Elm and BS are compiled
> 

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[GordonBGood]

On Thursday, 26 January 2017 21:13:33 UTC+7, Bob Zhang wrote:
>
> Hi Gordon, 
>  I think it is inappropriate to discuss BuckleScript performances on this 
> mailing list (people may feel unhappy about this), if you are interested, 
> we can discuss on BuckleScript github issues(I will create a mailing list 
> too).
>

Yes, Hongbo, I considered that, but since the subject of this thread is 
speed, and BuckleScript has been brought up many times as a speedy 
alternative to Elm including by yourself as author, I just wanted to show 
that all is not roses in BuckleScript land.  I have done some more work in 
this issue and am beginning to think that the choice of JS Array's as the 
base data representation in BuckleScript as opposed to JS Object/Records in 
Elm/Fable may not have been a good one for consistency of performance 
across browsers but wonder what you think it is:  it seems that Chrome V8 
optimizes relative JS Array performance much better than other browsers, 
especially Firefox, which may be what is reflected here.  I also re-ran the 
functional primes benchmark on Firefox and again found the BS version very 
slow, in this case about five times slower than Elm.  If you want to open 
up an alternate means of communication about this issue, I will be happy to 
contribute further as to BuckleScript development.  Perhaps an issue should 
be filed in the BuckleScript repo?

Now all is not roses in Elm land either, which IS the subject of this 
thread:  while as Robin Heggelund Hansen has pointed out, JS 
Objects/Records seem to be a fine efficient data representation across 
browsers, different browsers seem to do different quality jobs in interning 
the string tags, or at least Elms way of emitting them, with the Chrome way 
much more suited than that of FireFox or Edge (the worst) so that I believe 
that most of the performance issues I have in different browsers are due to 
this.  Of course, if the Elm back end were using the static type 
information that should be available to it (the actual subject of this 
thread), this this would not be a problem, as the use of any tag 
information could be minimized and reduced to identifying which of the set 
of union cases is in play.

What I have learned (and which BS does very well) is that no tags are 
actually needed or desired except for ADT's/tagged unions (that's why tag 
is in the name) *if type information is used*, and that while BS uses 
numeric indices for JS Array's, string/s/symbols with Object/Records are 
likely at least as good *as long as we help the JS engine do string 
interning* in order to get better speed consistency across browsers.  I 
will be writing more about this shortly as soon as I complete some more 
benchmarks.

Meanwhile, I now know why elm-lang/lazy is so slow on Chrome V8 when used 
in lazy lists:  they are implemented as nested functions, which sometimes 
get inlined but when not (as when part of lazy list definitions) are about 
50 times slower than Immediately Invoked Function Expressions (IIFE's) on 
Chrome V8.  This is a problem unique to Chrome V8, as new Firefox doesn't 
have a problem with nested functions at all, and they have a relatively 
minor cost in Edge.  The use of nested functions is a common problem across 
JS language transpilers (for instance Fable), and although BS has a 
different implementation of Lazy that doesn't use nested functions, it is 
the cause of the huge slowdown I pointed out earlier for embedded closures, 
for which BS does use nested functions.  Here is a link to some performance 
tests and data.   I plan to 
re-write elm-lang/lazy to use IIFE's instead of nested functions, which 
should take care of the Elm speed discrepancy problem in Chrome.  While 
this is easily fixed for elm-lang/lazy because it is a library, it isn't so 
easy to fix for closures that are implemented as nested functions by the 
compiler itself; although they, too, can be "lifted" and implemented as 
IIFE's, this needs to be done by the compiler and not just a library.
 

>   A minor comment:
> > As Elm does not have mutable linear arrays, for the big_uint functions 
> I created a Native JS based library into which I just inserted the same JS 
> code as created by the BS compiler for fairness; other than that it uses 
> the same algorithm as the BS code. 
>
> This is seriously biased, it is similar to when benchmarking the perf of 
> Python against JS, Python users rewrite the hot function in C and call it 
> from Python due to the incapability of Python.
>

While I agree that using a compiled library function in interpreted Python 
to benchmark Python speed is a fallacy, both Elm and BS are compiled 
languages with the primary difference that Elm strictly enforces 
immutability of all data structures at the language level whereas OCaml/BS 
does not.  Now, I could have fairly easily used the current Elm Array type 
to implement the big_uint type and operators and it 

Re: [elm-discuss] Using Elm on the server (full stack Elm webapps )

[Noah Hall]

I've already done this. Full stack elm is not a feasable option right now.
You can use elm to drive your logic if you want but the amount of
boilerplate and overhead from the runtime make it inefficent for a server.
For full stack elm, with the server code in elm, youll find yoyrself
fighting nodemore than anything else. See the readme of
https://github.com/noredink/take-home

On Thursday, January 26, 2017, Peter Damoc  wrote:

>
>
> On Thu, Jan 26, 2017 at 6:40 PM, 'Rupert Smith' via Elm Discuss <
> elm-discuss@googlegroups.com
> > wrote:
>
>> Still, its a long way from there to a full stack...
>>
>> Every journey has to start somewhere. Can you share a set of requirements
> for a full-stack? Like, how would a checklist for your must have and nice
> to have features would be?
>
>
>
> --
> 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.

Re: [elm-discuss] Re: Using Elm on the server (full stack Elm webapps )

[Peter Damoc]

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

> Still, its a long way from there to a full stack...
>
> Every journey has to start somewhere. Can you share a set of requirements
for a full-stack? Like, how would a checklist for your must have and nice
to have features would be?



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

[elm-discuss] Re: Using Elm on the server (full stack Elm webapps )

['Rupert Smith' via Elm Discuss]

On Thursday, January 26, 2017 at 3:47:12 PM UTC, Peter Damoc wrote:
>
> I took the websockets example and turned it into a stand alone webapp. 
> https://github.com/pdamoc/elm-sapling
>

I see, as websockets are symetrical in the sense of being the same on 
client and server side, they make this easy. I had only previously 
considered that elm-lang/http is geared towards the client side of REST, 
and that a server would need an equivalent server-side version to listen 
for incoming requests. 

Still, its a long way from there to a full stack...

-- 
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 on the server (full stack Elm webapps )

[Peter Damoc]

Hello community,

I thought that using elm on the backend would be hard but it turns out that
it is easy.

I took the websockets example and turned it into a stand alone webapp.
https://github.com/pdamoc/elm-sapling

The approach that I used is to describe an API between the client and the
server.

This API uses types for Requests that the client sends to the server and
for Responses that the server replies with. The types are imported in both
the server and the client.
The API file also takes care of serialization of the communication.

The server code is then compiled to a js file that is launched with the
help of a small express+ws wrapper.

The client code is compiled into an index file that will be served by
express.

What do you think?

I'm wondering if there is any interesest in creating a full-stack solution
for Elm.
I'm not able to do this alone but maybe a small SIG could create such a
thing.





-- 
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] Module / Payload Splitting - Such a thing?

[Dave Rapin]

Great news. Thanks for the quick response Peter. Amazing community!

On Thursday, January 26, 2017 at 10:25:14 AM UTC-5, Peter Damoc wrote:
>
> On Thu, Jan 26, 2017 at 5:00 PM, Dave Rapin  > wrote:
>
>> Just wondering if there's a good approach for this in Elm? Is there a way 
>> to split framework code & app code, or are we stuck with adding 100k to our 
>> payload every time we iterate?
>>
>> This is being worked on right now and something will be available in 0.19
>
> Also, it is worth notting that a gzipped minified "Hello, World" that 
> contains the runtime is around 20k (minified and gzipped). 
>
>
>
> -- 
> 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] Module / Payload Splitting - Such a thing?

[Peter Damoc]

On Thu, Jan 26, 2017 at 5:00 PM, Dave Rapin  wrote:

> Just wondering if there's a good approach for this in Elm? Is there a way
> to split framework code & app code, or are we stuck with adding 100k to our
> payload every time we iterate?
>
> This is being worked on right now and something will be available in 0.19

Also, it is worth notting that a gzipped minified "Hello, World" that
contains the runtime is around 20k (minified and gzipped).



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

[Bob Zhang]

Hi Gordon,
 I think it is inappropriate to discuss BuckleScript performances on this
mailing list (people may feel unhappy about this), if you are interested,
we can discuss on BuckleScript github issues(I will create a mailing list
too).
  A minor comment:
> As Elm does not have mutable linear arrays, for the big_uint functions I
created a Native JS based library into which I just inserted the same JS
code as created by the BS compiler for fairness; other than that it uses
the same algorithm as the BS code.

This  is seriously biased, it is similar to when benchmark the perf of
Python against JS, Python users *rewrite the hot function *in C and call it
from Python due to the incapability of Python.


On Thu, Jan 26, 2017 at 4:31 AM, GordonBGood  wrote:

> On Wednesday, 25 January 2017 19:25:40 UTC+7, Bob Zhang wrote:
>>
>> I cannot help replying when I see some inexact arguments... elm is a
>> reasonably fast language, I think it might run even faster than purescript,
>> enjoy your work!
>
>
> I think Elm and PureScript might run at about the same speed plus/minus,
> but ran into problems trying to use PureScript Lazy List Libraries.  I've
> stopped working with it because although it is about as powerful and type
> safe as Haskell/GHCJS, it seemed to be overkill as an alternative to Elm
> and it seemed that it would carry quite an overhead in library functions
> even reduced for production.
>
> Here's a problem I know you will find interesting as it definitely applies
> to BuckleScript:  I've been trying my functional benchmarks across
> different browsers since it seems there is such a range of performance for
> the same code output on different JS engines.  I expected BuckleScript to
> be very consistent across browsers, and indeed it is between the latest
> versions of Chrome and Edge, running just a little slower on Edge than on
> Chrome as expected.  However, the output BuckleScript JS code runs over
> twice as slow as either of these on Firefox and in fact runs slower than
> the Elm output for the same algorithm when also run on FireFox also by
> about a factor of two.
>
> I'll post the full BuckleScript test code here for ready reference and so
> you can copy and paste it to try it, as follows:
>
> type big_uint = int array
>
> external copy_array : 'a array -> 'a array =
>   "slice" [@@bs.send]
>
> external int2str : int -> string = "toString" [@@bs.send]
>
> external preadd_array : 'a array -> 'a -> unit =
>   "unshift" [@@bs.send]
>
> let zero_big_uint = [|0|]
>
> let one_big_uint = [|1|]
>
> let lt_big_uint (bu : big_uint) (othr : big_uint) =
>   let lenbu = Array.length bu in
>   let lenothr = Array.length othr in
>   if lenbu <> lenothr then (if lenbu < lenothr then true else false) else
>   let rtn = ref false in
>   let i = ref 0 in
>   while not !rtn && !i < lenbu do
> let v1 = bu.(!i) in
> let v2 = othr.(!i) in
> let s1 = v1 land 0x8000 in
> let s2 = v2 land 0x8000 in
> i := !i + 1;
> rtn :=
>   if s1 <> s2 then ( (* remember negative signs are neg numbers!!! *)
> i := lenbu; if s1 > s2 then true else false ) else
>   if v1 <> v2 then (
> i := lenbu; if v1 < v2 then true else false ) else false;
>   done;
>   !rtn
>
>
> (* works only for 2 to 5 incl. *)
> let mul_big_uint_byint (bu : big_uint) (m : int) =
>   let odd = (m land 1) <> 0 in
>   let shft = (m lsr 1) land 3 in
>   let cshft = 32 - shft in
>   let msk = (1 lsl shft) - 1 in
>   let mbu = copy_array bu in
>   let strt = Array.length bu - 1 in
>   let cry = ref ((if odd then mbu.(strt) else 0) land msk) in
>   for i = strt downto 0 do
> let v = mbu.(i) in
> let x = if i > 0 then mbu.(i - 1) else 0 in
> let mlt = (v lsr shft) + (x lsl cshft) in
> let p = (if odd then mlt else 0) + v in
> let ps = p lsl shft in
> let pc = ps + !cry in
> (*Js.log !cry;*)
> cry := (((if odd then
> (mlt land v) lor ((mlt lxor v) land (p lxor -1))
>   else 0) lsr 31) lsl shft) +
>((ps land (pc lxor -1)) lsr 31) +
>(p lsr cshft);
> mbu.(i) <- pc;
>   done;
>   (*Js.log !cry;*)
>   if !cry <> 0 then preadd_array mbu !cry;
>   mbu
>
> let string_of_big_uint bu =
>   let os = ref "" in
>   let mbu = copy_array bu in
>   let lng = Array.length bu - 1 in
>   let strt = ref 0 in
>   while !strt <= lng do
> let rem = ref 0. in
> for i = !strt to lng do
>   let v =
> let x = float_of_int mbu.(i) in
> if x >= 0. then x else 4294967296. +. x in
>   let dvd = !rem *. 4294967296. +. v in
>   let q = floor (dvd /. 10.) in
>   rem := dvd -. q *. 10.;
>   mbu.(i) <- int_of_float q;
> done;
> os := (!rem |> int_of_float |> int2str) ^ !os;
> while !strt <= lng && mbu.(!strt) == 0 do
>   strt := !strt + 1;
> done;
>   done;
>   !os
>
> type 'a lazy_list =
>   | EmptyLL
>   | ConsLL of 'a * 'a lazy_list Lazy.t
>
> let hammings() =
>   let rec 

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Bob Zhang]

Hmm, compare uglify with google closure is really misleading .. ( I am not
a fan of google or even remotely close, but as a compiler engineer , we
should respect basic facts)
On Thu, Jan 26, 2017 at 7:37 AM Robin Heggelund Hansen 
wrote:

> I was mostly talking about size. I know Closure very well, and I'm well
> aware of what code must look like in order to get the most out of advanced
> opts. The way Elm is compiled makes it easy for uglify to get the same
> results in mangling and dead-code elimination, but of course it won't do
> inlining. Still, there is a very small difference between uglify and google
> closure with advanced_opts. If Elm had been compiled into modules, then
> uglify would have done much worse.
>
>
> torsdag 26. januar 2017 02.37.59 UTC+1 skrev Bob Zhang følgende:
>
> Not really, closure has very very advanced optimizations that uglify does
> not even come close . If you feed bad code to it , of course it won't help
> too much. There are limitations to closure and its limitations are
> documented unclearly, so you have to be very careful
>
> On Wed, Jan 25, 2017 at 8:09 PM Robin Heggelund Hansen 
> wrote:
>
> Uglify essentially removes functions that are not added to objects (how
> you export functions from "namespaces"). Since Elm adds all functions to a
> single local-scope, and then only exports ports and the main function, it's
> very easy for uglify to see what functions are unused, and can therefore
> remove them. Google Closure can do the same thing but, as you said, breaks
> on advanced compilation. Fortunately, advanced optimization doesn't give
> you that much in Elm due to the way it compiles to JS. The difference
> between uglify and google closure (w/advanced opts) was perhaps 3-4kb last
> I checked. Advanced opts breaks because of four lines in Elm's runtime that
> checks for a specific key in certain cases (string tagging). More
> information here: https://github.com/elm-lang/core/pull/734
>
>
> onsdag 25. januar 2017 16.56.12 UTC+1 skrev OvermindDL1 følgende:
>
> I use browserify for some code via brunch, rollup for others, I run both
> of those through uglify + closure when building a 'prod' release.
>  browserify and rollup and both blazing fast in compile time with very
> large bases of code, but rollup prunes based on functions called (meaning
> it can break on dynamic name access, but that is rare) and browserify just
> prunes based on module importing (which can break on dynamic module name
> access, but that is also rare).  uglify is just a minimizer but it does few
> optimizations but runs fast, however Google's closure runs *very* slow, but
> optimizes well, however higher optimization levels will ruin any code that
> does any kind of dynamic key access that is not dict-like (it breaks elm
> pretty hard last I tried it, but it works on my bucklescript code 'so far').
>
>
> On Wednesday, January 25, 2017 at 8:45:12 AM UTC-7, GordonBGood wrote:
>
>
>
> On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote:
>
> Sent too soon.
>
> Also, uglify is a minimizer, it does a *lot* more than tree shaking.
>
>
> On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote:
>
> Tree Shaking as implemented by Brunch and Webpack default setups at least
> only prune based on if a module is accessed or not (which is also why it is
> easy to fool if you use a non-static string for the name).  I've not seen
> any tree shaking yet that does otherwise.  Although the fascinating
> rollup.js does a lot better by pruning functions very effectively, I need
> to try that one with Elm.  :-)
>
>
> On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund Hansen
> wrote:
>
>
> Actually tree shaking will do absolutely nothing for Elm code as Elm
> compiles everything into a single module that all highly indirectly
> references itself.  It would help with bucklescript as it outputs modules,
> but bucklescript already tree-shakes as part of its compiler optimizations
> anyway.
>
>
> This is false. You are correct that Elm compiles everything into a single
> module, but this means that tree-shaking becomes *easier*, not harder. It
> also makes name-mangling much easier, as everything is local-scope. With
> Elm code, tree-shaking can be done with Uglify.js. Just tell uglify to warn
> you when it removes a function, and you'll see it removes *a lot* of code.
>
>
> I see there is the old Google Web Compiler, Browserify, Uglify, Rollup and
> I don'e know how many others.  Has anyone compared them all and has any
> recommendations on which to use?  If some such as Uglify and Rullup do so
> much more than just Tree Shaking, what are the disadvantages in their use,
> speed of "compilation"?
>
> --
> 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/Um7WIBTq9xU/unsubscribe.
>
> To 

Re: [elm-discuss] Super-unimportant request for Google Closure Compiler.js compatibility

[Ahmed Fasih]

On Thursday, January 26, 2017 at 7:43:13 AM UTC-5, Robin Heggelund Hansen 
wrote:
>
> Advanced opts won't work with Elm. Check 
> https://github.com/elm-lang/core/pull/734
> Also, I'm surprised that uglify gives so bad results. As you can see in 
> the PR, my results didn't show that big a difference.
>

Oh my goodness, thanks for warning me about this—I’m sorry I didn’t find 
this PR when researching this!

I will for now use simple compilation to avoid this edge case, and 
periodically check if advanced makes things noticeably faster or if it 
breaks anything.

It would have been wonderful if the Elm compiler and the Google Closure 
Compiler had snapped together like Legos, but I appreciate that was 
unlikely without the former being designed to work with the latter.

Elm is insanely nice, thank you everyone.

-- 
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] Super-unimportant request for Google Closure Compiler.js compatibility

[Robin Heggelund Hansen]

Advanced opts won't work with Elm. 
Check https://github.com/elm-lang/core/pull/734
Also, I'm surprised that uglify gives so bad results. As you can see in the 
PR, my results didn't show that big a difference.

torsdag 26. januar 2017 12.53.31 UTC+1 skrev Ahmed Fasih følgende:
>
> On Thursday, January 26, 2017 at 3:30:25 AM UTC-5, Peter Damoc wrote:
>>
>> You need the --assume_function_wrapper flag. 
>>
>  
> Thank you Peter!!! That was all that was necessary, no need for the 
> compiler to emit anything special. I updated the build script and am 
> proceeding happily.
>
> I am hearing what you’re saying about the relative importance of 
> compression vs light minification vs aggressive compilation. I’m actually 
> more hopeful about optimizations. I had a somewhat math- and SVG-intensive 
> app in ClojureScript (where the Google Closure Compiler is baked into the 
> most minimalistic workflow) and the framerate improvement between 
> whitespace-only minification and advanced compilation was very pleasant. 
> Alas my current tiny app is network-bound, so no noticeable speed 
> improvements .
>
> Again, many thanks for pointing out this flag !
>

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

[Robin Heggelund Hansen]

I was mostly talking about size. I know Closure very well, and I'm well 
aware of what code must look like in order to get the most out of advanced 
opts. The way Elm is compiled makes it easy for uglify to get the same 
results in mangling and dead-code elimination, but of course it won't do 
inlining. Still, there is a very small difference between uglify and google 
closure with advanced_opts. If Elm had been compiled into modules, then 
uglify would have done much worse.

torsdag 26. januar 2017 02.37.59 UTC+1 skrev Bob Zhang følgende:
>
> Not really, closure has very very advanced optimizations that uglify does 
> not even come close . If you feed bad code to it , of course it won't help 
> too much. There are limitations to closure and its limitations are 
> documented unclearly, so you have to be very careful
> On Wed, Jan 25, 2017 at 8:09 PM Robin Heggelund Hansen  > wrote:
>
>> Uglify essentially removes functions that are not added to objects (how 
>> you export functions from "namespaces"). Since Elm adds all functions to a 
>> single local-scope, and then only exports ports and the main function, it's 
>> very easy for uglify to see what functions are unused, and can therefore 
>> remove them. Google Closure can do the same thing but, as you said, breaks 
>> on advanced compilation. Fortunately, advanced optimization doesn't give 
>> you that much in Elm due to the way it compiles to JS. The difference 
>> between uglify and google closure (w/advanced opts) was perhaps 3-4kb last 
>> I checked. Advanced opts breaks because of four lines in Elm's runtime that 
>> checks for a specific key in certain cases (string tagging). More 
>> information here: https://github.com/elm-lang/core/pull/734
>>
>>
>> onsdag 25. januar 2017 16.56.12 UTC+1 skrev OvermindDL1 følgende:
>>>
>>> I use browserify for some code via brunch, rollup for others, I run both 
>>> of those through uglify + closure when building a 'prod' release. 
>>>  browserify and rollup and both blazing fast in compile time with very 
>>> large bases of code, but rollup prunes based on functions called (meaning 
>>> it can break on dynamic name access, but that is rare) and browserify just 
>>> prunes based on module importing (which can break on dynamic module name 
>>> access, but that is also rare).  uglify is just a minimizer but it does few 
>>> optimizations but runs fast, however Google's closure runs *very* slow, but 
>>> optimizes well, however higher optimization levels will ruin any code that 
>>> does any kind of dynamic key access that is not dict-like (it breaks elm 
>>> pretty hard last I tried it, but it works on my bucklescript code 'so far').
>>>
>>>
>>> On Wednesday, January 25, 2017 at 8:45:12 AM UTC-7, GordonBGood wrote:



 On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote:
>
> Sent too soon.
>
> Also, uglify is a minimizer, it does a *lot* more than tree shaking.
>
>
> On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote:
>>
>> Tree Shaking as implemented by Brunch and Webpack default setups at 
>> least only prune based on if a module is accessed or not (which is also 
>> why 
>> it is easy to fool if you use a non-static string for the name).  I've 
>> not 
>> seen any tree shaking yet that does otherwise.  Although the fascinating 
>> rollup.js does a lot better by pruning functions very effectively, I 
>> need 
>> to try that one with Elm.  :-)
>>
>>
>> On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund 
>> Hansen wrote:
>>>
>>>
>>> Actually tree shaking will do absolutely nothing for Elm code as Elm 
 compiles everything into a single module that all highly indirectly 
 references itself.  It would help with bucklescript as it outputs 
 modules, 
 but bucklescript already tree-shakes as part of its compiler 
 optimizations 
 anyway.

>>>
>>> This is false. You are correct that Elm compiles everything into a 
>>> single module, but this means that tree-shaking becomes *easier*, not 
>>> harder. It also makes name-mangling much easier, as everything is 
>>> local-scope. With Elm code, tree-shaking can be done with Uglify.js. 
>>> Just 
>>> tell uglify to warn you when it removes a function, and you'll see it 
>>> removes *a lot* of code.
>>>
>>
 I see there is the old Google Web Compiler, Browserify, Uglify, Rollup 
 and I don'e know how many others.  Has anyone compared them all and has 
 any 
 recommendations on which to use?  If some such as Uglify and Rullup do so 
 much more than just Tree Shaking, what are the disadvantages in their use, 
 speed of "compilation"?

>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from 

Re: [elm-discuss] Super-unimportant request for Google Closure Compiler.js compatibility

[Ahmed Fasih]

On Thursday, January 26, 2017 at 3:30:25 AM UTC-5, Peter Damoc wrote:
>
> You need the --assume_function_wrapper flag. 
>
 
Thank you Peter!!! That was all that was necessary, no need for the 
compiler to emit anything special. I updated the build script and am 
proceeding happily.

I am hearing what you’re saying about the relative importance of 
compression vs light minification vs aggressive compilation. I’m actually 
more hopeful about optimizations. I had a somewhat math- and SVG-intensive 
app in ClojureScript (where the Google Closure Compiler is baked into the 
most minimalistic workflow) and the framerate improvement between 
whitespace-only minification and advanced compilation was very pleasant. 
Alas my current tiny app is network-bound, so no noticeable speed 
improvements .

Again, many thanks for pointing out this flag !

-- 
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: Html.Attributes.none

['Rupert Smith' via Elm Discuss]

On Thursday, January 26, 2017 at 3:45:24 AM UTC, Robert Lee wrote:
>
> The following fits in good enough for me.
>
> filterDiv : List (Maybe (H.Attribute msg)) -> List (Maybe (H.Html msg)) -> 
> H.Html msg
> filterDiv a n =
> H.div (List.filterMap identity a) (List.filterMap identity n)
>

Yes, or even:

filterNode :
(List (H.Attribute msg) -> List (H.Html msg) -> H.Html msg)
-> List (Maybe (H.Attribute msg))
-> List (Maybe (H.Html msg))
-> H.Html msg
filterNode node a n =
node (List.filterMap identity a) (List.filterMap identity n)

To make it work over all Html nodes not just divs. Then filterDiv = 
filterNode div, and so on.

I went for a slightly different approach which is to define:

when : Bool -> a -> Maybe a
when condition value =
if (condition) then
Just value
else
Nothing


required : a -> Maybe a
required value =
Just value


optional : List (Maybe a) -> List a
optional =
Maybe.Extra.values

Then I can make just the attributes or the child nodes optional. For 
example:

div []
  (optional
[ contentView model content |> required
, slideButton model |> required
, sideNav model |> required
, clickPlane |> when model.menuOpen
]
  )

I could use Just directly instead of 'required' but it has a certain visual 
appeal in that I can scan down the list and see what is always there and 
what is toggled by a condition.

P.S. I like your "List.filterMap identity", I was using Maybe.Extra.values 
for the same thing. At first I was scratching my head, why does the 
identity function make a filter over a list? Buit then I see the type of 
filterMap and how it works. I can drop Maybe.Extra now...

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

Re: [elm-discuss] Build iOS apps with Elm

[Rudolf Adamkovič]

Thank you and sorry for the second message. I thought I forgot to click 
“Submit”.

Have a nice, nice day!

R+

> On 26 Jan 2017, at 04:46, Duane Johnson  wrote:
> 
> (Note from list admin: Rudolf, I didn't approve your second message because 
> it seemed like a duplicate attempt. We've had problems with spam in the past, 
> so first-time posts require moderator approval. Your future posts will not 
> need moderation.)
> 
> On Wed, Jan 25, 2017 at 4:13 PM, Rudolf Adamkovič  > wrote:
> In case anyone is interested, I set aside 2 days and created a small 
> framework that allow to build iOS apps with Elm:
> 
> https://github.com/salutis/swift-elm 
> 
> It can drive both 100% native and web UI. One can also mix and match the two.
> 
> P.S. It's very early and there're no unit tests yet.
> 
> 
> 
> -- 
> 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] Super-unimportant request for Google Closure Compiler.js compatibility

[Peter Damoc]

You need the --assume_function_wrapper flag.

Also, if you have more troubles you could also drop the compilation level
to SIMPLE. The difference should be no larger than few kb in gzipped form.

It is worth mentioning that at such small sizes, even the unminified output
gzips to very tiny sizes.
In other words, having gzip enabled on the webserver would do more for the
transfer size than even the most aggressive minimizer.





On Thu, Jan 26, 2017 at 9:56 AM, Ahmed Fasih  wrote:

> This is a super-low-priority request: could the Elm compiler emit the
> following line at the end of its JS output:
>
> window['Elm'] = Elm;
>
> I’m used to using Google Closure Compiler after Clojure so I tried it with
> my tiny ~400 LOC Elm app, and without this line above, the `Elm` object
> gets renamed and unavailable in the browser. The line functions as an
> “export” Closure Compiler lingo [1].
>
> With this in place, if I run
>
> $ elm-make Main.elm --output=main.js
> $ yarn add google-closure-compiler-js -dev
> $ yarn run google-closure-compiler-js --compilationLevel ADVANCED main.js
>
> and pipe the result to a minified file, the original Elm-produced JS goes
> from 268 KB to an 80 KB file and my app works flawlessly. (Another data
> point: uglify-js produces a 164 KB minified file.)
>
> --
>
> A couple of further notes, if anyone else is interested in adding Google
> Closure Compiler to their workflow.
>
> It takes 30~ seconds to run advanced compilation on my little app, so I
> have two HTML files: (1) an ephemeral dev.html that loads the original
> Elm-emitted JS and (2) a real index.html that loads the compiled version.
> During development, I just look at dev.html to see my changes quickly.
>
> Besides the compilation time, another reason not to use the compiled code
> during development is that record field names get minified. E.g., I have a
> quick `text (toString model)` and:
>
> - original: `{ err = "", token = "eyJ...", target = Just { target = "冫",
> pos = 1` ...
> - compiled: `{ ba = "", S = "eyJ...", target = { a = "Just", b = { target
> = "冫"` ...
>
> I have a little build script that tacks on the export to the Elm-emitted
> JS, makes the dev.html out of index.html, and kicks off the Closure
> Compiler. It sounds heavy but the script is really short: see [2].
>
> [1] https://developers.google.com/closure/compiler/docs/api-
> tutorial3#export
> [2] https://github.com/fasiha/kanji-abecedario/blob/gh-pages/build.sh and
> the `min` task is of course in `package.json` but it’s not bad either.
>
> --
> 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.