simulator activating fonts from all over my disk

Solar2D General Questions/Discussion
#21

I’m finding this exceptionally interesting and am looking forward to hearing what the cause is.

Question: Is this for a particular version of OS X or does it happen on multiple versions?

#22

I’m not sure about the student’s OS version. I’ll ask him to check. But, I’ve seen the issue on at least 1 student’s Windows machines as well, which makes it more of a puzzle. If it was Mac only, I’d suspect something like a corrupt preference file. Or a file permission issue, but those aren’t supposed to happen anymore.

I ran disk util on my laptop just now and it didn’t find any errors.

In any case, this clearly isn’t affecting a lot of people. For me, only 2-3 students out of 40. And either restarting the simulator and moving the project into a more sensible folder seem to be working. Thanks for the help and suggestions. When I learn more I’ll update here. 

#23

Can I get some more information that the engineers are going to want to know.

  1. What version of Corona SDK are you running?

  2. At least for you, what version of macOS are you running?

  3. Can you try messing with some of our sample apps, like HelloWorld and make sure it’s not project related?

  4. Can you produce a simple test case including config.lua and build.settings that triggers this?

Thanks

Rob

#24

I’ve played with it a bit on 2 computers, both running macOS 10.12.3 and Corona SDK 2016.2992. 

I can get the simulator to try to load all the fonts when the main.lua file is stored in my user root folder (~). Tried a couple of simple tests. Did it with and without config.lua and build.settings.

However, when I move the project elsewhere – to the desktop or documents folder – it stops doing it and behaves normally. No simulator restart required. So it seems to be dependant on the location of the file, not the contents of the script.

This is weird since I don’t usually put stuff in user root and the project that I first noticed this behavior with was on the desktop – I thought. However, looking back at the console output (pasted earlier above), it looks like the file that was actually launching was in user root (~). Apparently, I was undercaffeinated and not running the file I thought it was.

So, bottom line is that I can only get the simulator to behave badly if I am loading a project from ~. It doesn’t seem to matter what the contents of the script are or what editor I use. Also, the presence or absence of a config.lua and build.settings don’t seem to matter.

I think this is consistent with what I saw on my student’s laptop yesterday as well. I’ll just caution them against putting files in user root.

#25

Good, we have a work around and this is great information. I can explain this behavior.

When you put your project in a folder, we scan that folder and children folder’s looking for .lua files, fonts and more. Your system fonts are at ~/Library/Fonts. So placing a main.lua in ~/ would cause us to scan the the entire ~/ tree which includes ~/Dropbox too.

I doubt we can fix this.

Rob