Infinite Loops - not the Cupertino Kind

[Timoti]

Getting quite a lot of:

Infinite Import Loop Detected

"_components.scss" and "_header.scss" import each other. You must fix this before compiling can continue. (Note that the loop may be indirect. For example: A imports B imports C imports A.)

This happens across several projects which were loop free prior (when using comandline ruby sass), and I can't find any specific 1st or 2nd level loops. It's also random - happens probably about half of the time. And annoyingly I have to step through about 5 separate error modals for each compile.

Is this a codekit thing or a libsass thing?

Also, if I'm remembering right, ruby messages used to be more specific as to import issues - as in identifying where any loops were occuring. If this isn't libsass controlled, is there any way to get more specific error messages or logs?

(PS - I'd previously [as emailed] struggled with being able to use CK2 because of very specific compass and susyone ruby-related dependencies (and waiting for libsass to support . I bit the bullet and migrated to bourbon and neat and oh the relief! Lighter is soo much nicer - there's nothing I'm missing from compass and susy and my compiling has going down from 20-50sec to 0.5sec. )

[Timoti]

I should add - after clearing the dialogs, the log reports that compiling was successful. if so perhaps there is some way I could quieten down the errors?

[bdkjones]

Hey Tim,

Yea; there appears to be a bug here but I can’t duplicate it on my machine yet. Do you have a set of files that *always* shows the dialogs when you save? If so, please post a link to download them here. 

On 11 Jun 2014, at 08:54, Tim Gummer notifications@github.com wrote:

Getting quite a lot of:

Infinite Import Loop Detected

"_components.scss" and "_header.scss" import each other. You must fix this before compiling can continue. (Note that the loop may be indirect. For example: A imports B imports C imports A.)

This happens across several projects which were loop free prior (when using comandline ruby sass), and I can't find any specific 1st or 2nd level loops. It's also random - happens probably about half of the time. And annoyingly I have to step through about 5 separate error modals for each compile.

Is this a codekit thing or a libsass thing?

Also, if I'm remembering right, ruby messages used to be more specific as to import issues - as in identifying where any loops were occuring. If this isn't libsass controlled, is there any way to get more specific error messages or logs?

(PS - I'd previously [as emailed] struggled with being able to use CK2 because of very specific compass and susyone ruby-related dependencies (and waiting for libsass to support . I bit the bullet and migrated to bourbon and neat and oh the relief! Lighter is soo much nicer - there's nothing I'm missing from compass and susy and my compiling has going down from 20-50sec to 0.5sec. )

— Reply to this email directly or view it on GitHub.

[Timoti]

Ah good to hear it's not just me. Thanks for getting back so soon.

https://www.dropbox.com/s/e78fkq4jraupetd/BEB%20infinite%20loop%20bug%20testcase.zip

This a bourbon/neat based set of scss - the CK config is currently set to ruby compiling - which is also showing the bug. Loop doesn't happen 100% of the time, but I'd say at least 50%.

(there is a possible normalize dependency - hence the sass-libs folder, otherwise this refers to the CK bourbon and neat.

Oh and the ruby compile is down to 4 sec - so I over attributed the improvement to libsass. Looks like a lot of the previous latency was coming off of Susy. All the more thanks to the thoughtbots then.

[bdkjones]

Thanks. I’ll take a look at this tonight. And still, 4 second compiling times really add up when you save frequently. Libsass is amazing. On 11 Jun 2014, at 09:57, Tim Gummer notifications@github.com wrote:

Ah good to hear it's not just me. Thanks for getting back so soon.

https://www.dropbox.com/s/e78fkq4jraupetd/BEB%20infinite%20loop%20bug%20testcase.zip

This a bourbon/neat based set of scss - the CK config is currently set to ruby compiling - which is also showing the bug. Loop doesn't happen 100% of the time, but I'd say at least 50%.

(there is a possible normalize dependency - hence the sass-libs folder, otherwise this refers to the CK bourbon and neat.

Oh and the ruby compile is down to 4 sec - so I over attributed the improvement to libsass. Looks like a lot of the previous latency was coming off of Susy. All the more thanks to the thoughtbots then.

— Reply to this email directly or view it on GitHub.

[Timoti]

hi bryan

This is that test project again from a month ago (early bourbon/neat migrate from susyone starter)

This thing is really driving me bonkers - happening all the time these days Almost worse than the ~40sec susy compile delay https://github.com/ericam/susy/issues/325 i just escaped from.

Happy to do some beta testing for the upcoming release if that would help.

Tim

https://www.dropbox.com/s/e78fkq4jraupetd/BEB%20infinite%20loop%20bug%20testcase.zip

one planet, one chance

[bdkjones]

Hi Tim,

Well, I’ve finally got around to looking at this issue.

No offense, but what you’ve got in the demo project you sent me is a giant mess. Stuff is imported all over the place with lots of duplication.

For example, you have “_variables.scss” which imports “variables/layout”, which brings in bourbon and bourbon neat. But then in your main styles.scss file, you bring in “base”, which ALSO imports bourbon and neat. These tangled webs of imports are all over the place and short of spending two hours drawing out a huge diagram on paper, I have no clue what the overall structure looks like.

I’m not sure if you’re doing this because Rails requires it or you’re using a build system that’s doing funky stuff. The correct way to do imports for a complex project like this is to have ONE master file that imports things in a specific order. ONLY this master file compiles to CSS. All other files are simply imported into the master one at a specific time.

For example, you might write this in your master file:

@import “bourbon”; @import “neat”; @import “variables”;

Now, EVERYTHING in “variables” and below has access to bourbon and neat — you do NOT re-import bourbon and neat into “variables.scss” or any sub-files thereof, because when the master file compiles, bourbon and neat are already imported AND “variables” and all of its sub-files are NEVER compiled on their own, so they have no need to import bourbon; it will always be available.

Of course, you might have more than one master file (say, a stylesheet that only applies to a blog page or a storefront), but you follow the same logic: don’t import stuff in sub-files that will already be available when your top-level files compile. 

Now, all of that being said, I *think* the reason you’re seeing these false “infinite loop” import alerts is because you have files with the same name in different folders. You have “typography.scss” in both the variables and base folders, for instance. When CodeKit checks for infinite loops, it’s looking at just the filenames rather than the full paths. I haven’t *verified* this, but I’m 90% sure that’s what’s going on. 

I can and will update CodeKit to look at full paths so that it doesn’t throw false warnings, but the real solution is a cleaner, leaner structure for your stylesheets. 

On 9 Jul 2014, at 08:18, Tim Gummer notifications@github.com wrote:

hi bryan

This is that test project again from a month ago (early bourbon/neat migrate from susyone starter)

This thing is really driving me bonkers - happening all the time these days Almost worse than the ~40sec susy compile delay https://github.com/ericam/susy/issues/325 i just escaped from.

Happy to do some beta testing for the upcoming release if that would help.

Tim

https://www.dropbox.com/s/e78fkq4jraupetd/BEB%20infinite%20loop%20bug%20testcase.zip

one planet, one chance — Reply to this email directly or view it on GitHub.

[bdkjones]

Well, I was not correct about the filenames. Turns out, I wrote this code in an intelligent way and it actually compares links between files using full paths.

What's happening is that when you save "variables.scss" in your editor, CodeKit is walking through the @import chain to determine which other files import "variables.scss" so that it can figure out which files need to re-compile to capture the changes you just made.

Critically, we don't recompile every file that imports "variables.scss" --- only those that are themselves set to create an output CSS file (so other files that are imported elsewhere don't get compiled).

What's happening here is that your chain is so messy, we end up getting back to the same file multiple times. When this happens, CodeKit assumes that you've created an infinite import loop. It doesn't abort the compiling, but it does show you an alert. As it turns out, that was a bad assumption on my part. It is indeed possible to structure a chain of imports in a way that's not an infinite loop, but is still really, really redundant.

So, I'm going to have to fix my assumption and put some additional checks in place.

If you fix this messy structure, however, I think you'll find that your compile times go way, way down. This is one of the slowest-compiling projects I've ever received!

[bdkjones]

Okay. After lots of work and many diagrams drawn on paper, I've got this one resolved.

Version 2.1 is now smarter about detecting infinite loops and will no longer warn about them when they aren't actually happening.

Release coming soon.

[Timoti]

Bryan thanks.

Looks like I'm the acid test for loopiness then huh? Glad to have provided the opportunity to make CK even better.

In all seriousness (and no offence taken) - heck yes I didn't know that imports need only be made at the top of the stylesheet tree, and I've been writing sass for a while now. I actually looked for information on how to structure imports many times and never found it, but somewhere along the way have had apparent mixin / variable dependencies that didn't work without adding in a specific import - plus I think I saw quite a few frameworks with lower stylesheet tree imports, so it's always seemed rather confusing arbitrary to me.

And that's great if I don't have to actually declare so many imports.

The code I sent was the beginning of a project that had gotten mired in compiling latency issues, (for good reason, I hear you cry!) and had had a ruby contractor in to work over it for a while. It now seems that the latency was a combo of that real issue with sass affecting susy (a still very active issue which I originally filed https://github.com/ericam/susy/issues/325), and my own overcooked imports. That said I don't think I had any real loops in my code.

On my current projects - haven't purged all the low level internal variable and base imports but def the framework imports. Still have loop errors, but i haven't yet had a chance to go through this properly.

I guess this just highlights an apparent lack of documentation on how to structure imports. This may have seemed really dumb, but heck, its not like I haven't stretched out to learn anything I can about sass fundamentals (I have almost ALL the books). Praps more then anything though it shows how isolated we can get if we're not showing our code to others (by which i don't mean ruby devs…! or back end coders for that matter).

So thanks for that. I'm seriously looking forward to 2.1 whatevs.

TIM

one planet, one chance