About "dofile"

[Citrus]

So, the documentation states that "dofile()" is not supported. However, in my experimentation, the "dofile" function is in the global table, and calling it does appear to work. The "require" function is missing, as I expected, and there's no "package" table either.

So, what gives? Does anyone know why these things are missing/unsupported? And, why is dofile actually there when it's not supposed to be? Is there an intentional reason why it's been omitted? Or, are these things missing because the devs haven't been able to get them to work consistently?

It certainly is a pain in the neck, incorporating existing libraries without having these things. Especially given the "batteries not included" philosophy behind Lua. Is there a "right" way to include scripts that are intended to be referenced using "require"? I hope that there's a better solution than just concatenating everything into one file.

[jsmorley]

I'm not an expert on how Lua is integrated with Rainmeter, but the long and the short of it is that you in fact can use dofile, but there can be bleed-over between scripts that share a dofile include. You can get conflicts with variables set in the file and other problems. That is why in general we do not recommend using it. When you just paste the code into the main script, then it runs in the tablespace for that individual script and conflicts are avoided.

Since our Lua implementation does not run in a separate thread, and problems with Lua can crash, hang or otherwise make unstable Rainmeter itself, we are cautious about how much "extensibility" we try to support. We have looked at "require" and "dofile" to see if we can support them in a safe, reliable way, but have not yet found the approach we are happy with.

It is on the radar, but probably not in the near-term.

[Citrus]

That's interesting. And, perhaps good news for me. Ultimately, what I want to do is load up some pre-existing utilities, without having to keep them all in one mega-file. I wouldn't be writing into any variable that was loaded from these files. In each case, it would just build a table full of functions, which I would call as needed.

If I have one Lua source file, called once, which used dofile to bring in a few others once, then none of the bugs should come into play, correct?

Or, would it work, and make more sense, to use a combination of io.open and loadstring to accomplish the handling of multiple source files? Thinking about it, would that end up causing the same basic problem? I wouldn't think that it would.

[thatsIch]

That's interesting. And, perhaps good news for me. Ultimately, what I want to do is load up some pre-existing utilities, without having to keep them all in one mega-file. I wouldn't be writing into any variable that was loaded from these files. In each case, it would just build a table full of functions, which I would call as needed.

If I have one Lua source file, called once, which used dofile to bring in a few others once, then none of the bugs should come into play, correct?

Or, would it work, and make more sense, to use a combination of io.open and loadstring to accomplish the handling of multiple source files? Thinking about it, would that end up causing the same basic problem? I wouldn't think that it would.

just wondering but have you got it to work? I assume the new UTF16-LE with BOM is making problems for me.

[Citrus]

Unfortunately, I haven't really run this to completion. I was all set to use some of google's APIs to read calendar data, and they went and deprecated pretty much every one that I would have used. So, I put the whole effort down.

From my experimentation, "dofile" would read in the files just fine, thus allowing modularity. But, I hadn't run into a case where jsmorley's warnings would have come into play. Basically, if you use Lua's mechanisms for sourcing external files, you get a possible leakage of scope between scripts. Since this was the only skin that I was trying to run that used any Lua scripts, the point was moot. In fact, I'm not even 100% sure how I would test to see if it was happening or problematic.

I hope this helps a little.

[jsmorley]

Unfortunately, I haven't really run this to completion. I was all set to use some of google's APIs to read calendar data, and they went and deprecated pretty much every one that I would have used. So, I put the whole effort down.

From my experimentation, "dofile" would read in the files just fine, thus allowing modularity. But, I hadn't run into a case where jsmorley's warnings would have come into play. Basically, if you use Lua's mechanisms for sourcing external files, you get a possible leakage of scope between scripts. Since this was the only skin that I was trying to run that used any Lua scripts, the point was moot. In fact, I'm not even 100% sure how I would test to see if it was happening or problematic.

I hope this helps a little.

Mostly you just have to be really careful that any variables you create are done in a way that is very "local" or passes them back and forth between the .dofile and the .lua in very specific parm / return way. I found a fun little library .dofile that did some spiffy stuff with dates / timestamp in Lua, and while it worked fine in one skin, as soon as I used it in two that used the same .dofile code, I ran into a bunch of hideous "scope" issues.

[thatsIch]

Mostly you just have to be really careful that any variables you create are done in a way that is very "local" or passes them back and forth between the .dofile and the .lua in very specific parm / return way. I found a fun little library .dofile that did some spiffy stuff with dates / timestamp in Lua, and while it worked fine in one skin, as soon as I used it in two that used the same .dofile code, I ran into a bunch of hideous "scope" issues.

oh that was a good tip with the "as local as possible"
Thank you very much