v0.6.2 release fails with "maximum call stack size exceeded"

Question

v0.6.2 release fails with "maximum call stack size exceeded"

fredcy opened this issue 8 years ago · comments

The elm-lang.org home page links to http://ravichugh.github.io/sketch-n-sketch/releases/latest/ which redirects to http://ravichugh.github.io/sketch-n-sketch/releases/v0.5.2/. The latter fails for me almost immediately with the error "Maximum call stack size exceeded" when I run it from Chrome (53.0.2785.116) on Mac OS X on a machine with 16GB RAM. When run from Firefox on the same machine it works, or at least starts up OK.

Ed. note: Duplicate of #56, #93.

Brian Hempel · Answer 1 · Mon Sep 19 2016 23:34:02 GMT+0800 (China Standard Time)

Thanks. I think we plan to spend a bit of time on this after we upgrade to Elm 0.17 sometime around December. For now, we just use a little script to boot Chrome with a bigger stack:

#!/usr/bin/env bash
open -a "Google Chrome" --args --js-flags="--stack-size=5000" &

Carl-Erik Kopseng · Answer 2 · Mon Dec 26 2016 02:24:01 GMT+0800 (China Standard Time)

Still crashing

Justin Lubin · Answer 3 · Mon Dec 26 2016 10:58:26 GMT+0800 (China Standard Time)

Hi! Yep—it's still crashing without the script Brian mentioned. I was actually just looking into this issue yesterday, and it turns out that what causes the slow load time and the stack overflow error is the parser for the language. We're still working on / aware of this issue, but thanks for the feedback!

Andrew Zukoski · Answer 4 · Sat Mar 11 2017 15:28:58 GMT+0800 (China Standard Time)

So in attempting to get unit-tests compiling (and passing!) again, I pulled @jlubi333 's fix-tests branch referenced here down and started porting the tests over to the apparently standard elm-test package. Sort of intriguingly, the first test I ported explodes with the maximum call stack size exceeded.

If anyone is interested, the base changes are here: amzuko@1b297d3 .

Intriguingly, some googling revealed elm/compiler#1521, which would point towards long list literals potentially generating this behavior. I haven't found any examples of that in the parser, which previous comments in this thread point towards as a culprit.

The other suspect I considered is the prelude; this is fairly substantial little program that then passes through the parser combinator defined src/OurParser2.elm. I definitely have not grokked the various combinators defined in OurParser, but it seems at least plausible that there's some recursion going on there that depends on the length of the program, rather than expression depth -- does this match the core maintainers' intuition over where the problem lies?

This is further reinforced by the simple experiment in amzuko@c93299e, which tears out the prelude and replaces it with a dummy. With this substitution, simple parsing tests pass, and we can reliably generate a stack explosion by passing a large program into the parser.

Glancing through src/LangParser2.elm, it seems that there is a high level of coupling between language constructs (control statements), syntactic extensions to basic s-expressions (widgets, freezing), and the contents of the prelude. Intuitively, I would have expected this to be broken into a few stages of tokenization/lexing, and parsing into an AST then passed on for type checking and execution. Out of curiosity, is there a conscious design choice behind this, or is this coupling more the result of rapid organic growth?

My next guess on debugging this would be to inspect the individual combinators in OurParser2 that the little parser is built on to see if one or more is behaving badly and could be fixed. Failing that, I would probably attempt to blanket the little parser in tests and migrate it to a multi-stage parser that would let us better isolate individual operations. Any thoughts?

Justin Lubin · Answer 5 · Sat Mar 11 2017 15:51:31 GMT+0800 (China Standard Time)

Thank you very much for your investigative work!

Regarding the long list literals: this is what I suspect is causing the problem as well. A couple weeks ago, I tried paring down the prelude file (which is loaded each time Sketch-n-Sketch starts), and the stack overflow error went away. This leads me to believe that it is definitely based on the length of the program. It's great to hear that someone else arrived at the same conclusion!

Regarding the parser: it is indeed a bottleneck. I've only been working on Sketch-n-Sketch for ~3 months, so I don't know the origin story of the parser, but I believe that its structure is due to "rapid organic growth" :-) The reason for this is that the focus of this project is not so much on the particular implementation of Little (we, in fact, wish to transition to a "real" programming language like Elm one day for our editor), but rather on the high-level manipulation and interface between code and output. In other words, the parser has been working Good Enough™ for our purposes.

Anyway, I actually am going to be completely re-writing the parser (hopefully) in about a week or so. However, I have final exams right now, so unfortunately I am just the slightest bit preoccupied :-)

Thanks again!

Sean Aubin · Answer 6 · Sat Jun 10 2017 15:42:50 GMT+0800 (China Standard Time)

The reason for this is that the focus of this project is not so much on the particular implementation of Little (we, in fact, wish to transition to a "real" programming language like Elm one day for our editor), but rather on the high-level manipulation and interface between code and output.

Learning a new syntax is one of the frustrating aspects of starting to work with Sketch-n-Sketch is the custom language of Little. I would be delighted by a pivot to Elm, however being new to the language, I'm not clear on how hard this would be. From what I can tell, the Little language requires the following macros (I think they're called macros?):

! for freezing and thawing variables
x{x1-x2} slider range notation

How hard would it be to parse these as part of a DSL of Elm? How much additional friction would it cause to replace these with normal function calls like freeze() and slider()?

I guess another problem would be dealing with the fact that Elm is strongly typed?

P.S. you should probably change the title of this issue to note that this issue still occurs in version 6.0

Justin Lubin · Answer 7 · Sun Jun 11 2017 03:27:10 GMT+0800 (China Standard Time)

We are aware that learning Little is one of the biggest hurdles in using Sketch-n-Sketch, and will hopefully be transitioning to Elm soon. It is most certainly on our radar, but it would actually be quite a large project due to the program synthesis backend.

And thanks—I will update the title of the issue!

Andrew Zukoski · Answer 8 · Sun Jun 11 2017 03:37:56 GMT+0800 (China Standard Time)

@jlubi333 How's that parser rewrite going, by the way?

Justin Lubin · Answer 9 · Sun Jun 11 2017 03:47:49 GMT+0800 (China Standard Time)

Almost completed! You can check it out in the elm-tools-parser branch. I had it working very fast and with no stack size error... but then I added one more feature (tracking the position of each expression) and it requires a slightly larger stack than the default for the additional nesting of functions. I'm unsure exactly why it's going through the stack so quickly, but I have a couple of ideas in mind for how to fix it. Anyway, In the upcoming week or so, I should be able to finish off the project and incorporate it into the master branch.

Andrew Zukoski · Answer 10 · Sun Jun 11 2017 04:30:48 GMT+0800 (China Standard Time)

Great to hear!
To throw some peanut gallery comments over the wall that you might just want to ignore:

Fast parser looks like a step up in organization from the previous parser. I can halfway understand what's going on ;)
FastParser appears to be handling both tokenization and syntactic analysis -- with a lot of smarts built in (eg, what operators are defined in the runtime). Did you consider separating these two concerns into two passes over the program? While I'm not certain, I suspect that decomposing the parsing algorithm into distinctly testable stages will make it easier to uncover the origin of otherwise mysterious issues such as the one that you're seeing in regards to expression position.
It's concerning that you're bumping into the javascript stack limit at all -- over time, the prelude (likely the longest little program that anyone will want to parse for a while) seems to grow. This means that even if you can tune stack usage to fall below this number now, in a few months we may be back in the same situation. To avoid this problem, it would be best to target solutions whose javascript call stack usage will scale with scale with the depth of the resulting expression tree, not it's overall size. You could also engineer something that doesn't rely at all on the js call stack to store state, but that might be significantly more work ;)
During development, and mostly for my edification, how are you testing the new parser?

Justin Lubin · Answer 11 · Sun Jun 11 2017 04:52:52 GMT+0800 (China Standard Time)

I'll address each of your comments individually :-)

Thanks! I really like the elm-tools/parser library that Evan has created. It was very fun to use!
I'm not exactly sure why operators being built in are really that "smart"? And isn't it normal for functional parsing libraries to just do lexing/tokenization/parsing all in one go? I also am unsure that breaking up the parsing library will help. When I said I was "unsure" of why it was overflowing the stack, I suppose that was a little big imprecise... I know for a fact that when I wrap the code in an additional trackInfo call (which tracks the position of each expression), it overflows the stack because too many functions are being nested (in other words, it's not the state that is the issue, but the number of function calls). This brings me to your next comment!
Yea, it is kind of concerning! Technically, the current parser does scale with the depth of the resulting expression tree, and not the overall size of the program. However, Little programs are actually represented as one big expression! In other words, the size of the program IS the depth of the tree :-) For example, defs are parsed using the rule (def p e1) e2, where e2 is pretty much just the rest of the program. This is not the ideal situation, but there is a ton of back-end code that relies on this, and we can't really change that at this time. I think I will be able to implement a workaround that will work for much, much larger programs than the prelude before it runs out of stack space, and I'm pretty sure that will be the extent of the work on the parser in the foreseeable future. Our main goals with the new parser are to get it working on Firefox and Chrome with no issues, and to be as fast as possible (in that order).
I can easily change which parser is run during development, so if I change something in the "pattern" parser, I just have the program parse patterns only, and I can copy/paste any text files that contain patterns into the text box (or just mess around and type some small things in manually). Any time I change something, though, I always make sure to run it against the prelude file. Basically, if it parses the prelude correctly, we consider it to be working as intended :-)

Thanks for your input on this!

Sean Aubin · Answer 12 · Sun Jun 11 2017 12:43:00 GMT+0800 (China Standard Time)

@jlubi333 thank you so much for your effort and please let me know when you've completed this overhaul! I would like to build something on top of Sketch-n-Sketch (no points talking about the project when I don't have code) and a better parser would make the undertaking much easier.

Justin Lubin · Answer 13 · Sun Jun 11 2017 12:45:56 GMT+0800 (China Standard Time)

That's awesome! We'd love to hear about what you make if you do end up building off of Sketch-n-Sketch! :-)

Justin Lubin · Answer 14 · Thu Jun 15 2017 11:52:33 GMT+0800 (China Standard Time)

Hi everyone — this is fixed in v0.6.1. It only took an entire parser rewrite! :-)

Kamil Chmielewski · Answer 15 · Thu Dec 07 2017 06:39:21 GMT+0800 (China Standard Time)

I'm getting similar recursion problems in FF 57.0.1 and Chromium (SnS 0.6.1 and 0.6.2).
Firefox log:

too much recursion[Learn More] sns.js:91:3
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:91:3
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_user$project$Lang$flattenExpTree http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:15608:7
	_elm_lang$core$List$map</< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2245:11
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	foldr http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:1971:9
	A3 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:98:7
	_elm_lang$core$List$map< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2239:10
	A2 http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:92:7
	_elm_lang$core$List$concatMap< http://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/sns.js:2343:4

Chromium logs:

ravichugh.github.io/:1 Uncaught RangeError: Maximum call stack size exceeded

Justin Lubin · Answer 16 · Thu Dec 07 2017 06:48:41 GMT+0800 (China Standard Time)

Well this is strange... it's not working for me either now. I'm reasonably confident that it was working a couple of days ago. Out of curiosity, when did you first try to load Sketch-n-Sketch and get that error?

Kamil Chmielewski · Answer 17 · Thu Dec 07 2017 07:04:48 GMT+0800 (China Standard Time)

I started today and I couldn't get it working at all

Justin Lubin · Answer 18 · Thu Dec 07 2017 07:06:45 GMT+0800 (China Standard Time)

Okay, thank you. We will look into this ASAP!

Justin Lubin · Answer 19 · Tue Dec 12 2017 05:56:46 GMT+0800 (China Standard Time)

This appears to be a platform-specific issue. In my tests, Sketch-n-Sketch appears to work on macOS and Linux, but not on Chrome OS. I don't have a Windows machine to test the program right now, but I suspect that it does crash on Windows. We'll do our best to fix this issue! Thanks for the helpful feedback, everyone.

Kamil Chmielewski · Answer 20 · Tue Dec 12 2017 06:06:44 GMT+0800 (China Standard Time)

I tried Google Chrome 62 and it works on the same machine where it hangs in FF and custom built Chromium.

Justin Lubin · Answer 21 · Tue Dec 12 2017 06:14:12 GMT+0800 (China Standard Time)

Interesting, thank you. May I ask what operating system you are running these browsers in?

Kamil Chmielewski · Answer 22 · Tue Dec 12 2017 06:17:49 GMT+0800 (China Standard Time)

I'm on NixOS 18.03.git.a455d93

Justin Lubin · Answer 23 · Tue Dec 12 2017 06:21:07 GMT+0800 (China Standard Time)

Thanks! We'll try to isolate the issue and fix it.

Mikaël Mayer · Answer 24 · Thu Dec 28 2017 06:40:30 GMT+0800 (China Standard Time)

I managed to isolate and fix this bug in the branch I'm on.

eea5ed7

To solve this error, I had to split two long list literals in two that were in the file ColorNum.elm.
How I found them? I did manual dichotomy of the generated file sns.js to find out when the file was accepted, and when it caused the crash.

Which branch should I push this bug fix to in priority?

Brian Hempel · Answer 25 · Thu Dec 28 2017 06:43:31 GMT+0800 (China Standard Time)

Nice find. You can put the fix on master (or any branch, really) and we'll cherry-pick it as needed.

Mikaël Mayer · Answer 26 · Thu Dec 28 2017 06:56:23 GMT+0800 (China Standard Time)

Fixed in 4db23af

Brian Hempel · Answer 27 · Thu Dec 28 2017 09:11:14 GMT+0800 (China Standard Time)

Prior issues were with our little parser (not the browser's). Going to leave this open for a bit longer until we are confident those problems are also resolved...

Justin Lubin · Answer 28 · Sat Dec 30 2017 11:11:02 GMT+0800 (China Standard Time)

For what it's worth, Sketch-n-Sketch still doesn't load on Chrome OS version 62.0.3202.97 (64-bit).

Mikaël Mayer · Answer 29 · Sat Dec 30 2017 12:18:23 GMT+0800 (China Standard Time)

at the same time, nobody pushed the version of master to https://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/ (I investigated sns.js there and it was not updated with the fix) Did you try it locally? Le ven. 29 déc. 2017 à 21:11, Justin Lubin <notifications@github.com> a écrit :

…

For what it's worth, Sketch-n-Sketch still doesn't load on Chrome OS version 62.0.3202.97 (64-bit). — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#84 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADbyt_e8FTqO2LDCYLzQetXgJBFT-vN_ks5tFanHgaJpZM4KAluQ> .

Justin Lubin · Answer 30 · Sat Dec 30 2017 12:43:18 GMT+0800 (China Standard Time)

Oof! I'm so silly, I didn't try it locally. It actually does work on Chrome OS now, thanks Mikaël / sorry to bother! :-)

Mikaël Mayer · Answer 31 · Sat Dec 30 2017 12:49:18 GMT+0800 (China Standard Time)

You're welcome ! Le ven. 29 déc. 2017 à 22:43, Justin Lubin <notifications@github.com> a écrit :

…

Oof! I'm so silly, I didn't try it locally. It actually *does* work on Chrome OS now, thanks Mikaël / sorry to bother! :-) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#84 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADbyt1yYq3zq_8VXj3KQSLP1zGe2PRUcks5tFb9mgaJpZM4KAluQ> .

Mikaël Mayer · Answer 32 · Wed Mar 28 2018 22:46:29 GMT+0800 (China Standard Time)

I consider this thread as closed. The following two links now work.

https://ravichugh.github.io/sketch-n-sketch/releases/v0.6.2/
https://ravichugh.github.io/sketch-n-sketch/releases/v0.6.3/