Is there a way to re-load the init.rb file other than quitting and restarting SPI?
Not currently. It’s on the wishlist though
Interesting - out of interest, what’s your use case for wanting to do this?
Also, I was probably not quite awake when I wrote my initial reply
There is a way, though of course it is not like a dedicated menu item for example: you can use
The thing I’m working on has long since exceeded the buffer size so that I’ve accumulated about 200 lines into my init.rb. I still sometimes tweak things, so then I swap stuff in from init.rb and out of the main file via copy/paste to make room in the buffer to test the tweaks. That requires me to re-start SPI after I save the changed init.rb. Sometimes I just want to un-comment a print statement that I’ve left inside init.rb to make sure of things when working on something in the buffer, and even that small change requires re-starting SPI.
When I put all the stuff from my init.rb into a file mylibrary.rb, then do
run_file on that file at the top of my buffer, I get a runtime error at the first encounter of a constant that’s now declared in mylibrary.rb instead of init.rb.
Sure - you need to make sure that the constants are only declared once
I simply cut the constants out of my init.rb and pasted them into mylibrary.rb. I don’t see why they wouldn’t still be declared once.
They still exist in memory though
OK, but what do I do to make them available to the code I’m running in the buffer?
ADDED to clarify: Of course, after cutting the stuff out of init.rb and putting it into mylibrary.rb, I re-started SPI before running the code with the
run_file statement in it. Those constants shouldn’t still exist in memory when the
run_file is run, correct?
ADDED: @ethancrawford I’ve done a few tests now, and it seems that the
run_file never takes effect until the second time it’s run, causing an error to always be thrown the first time. Here’s what I did:
I left all the constants in init.rb and moved the rest of the stuff to mylibrary.rb, and then I got the runtime error that the first encountered function wasn’t found. Then I escaped out of the error condition and ran the buffer again, and this time it worked. I have a print statement inside mylibrary.rb, so I do verify every time SPI loads it.
Is this a known issue with
It’s always helpful to provide some test code if you can - is there a small enough example we can reproduce this with?
Same behavior with this toy data. The first screenshot shows the contents of my test.rb file. The second screenshot shows the first time I run the buffer, which throws the uninitialized constant error. The third screenshot is the next run of the buffer, which shows correct results and no error.
Aaah. Now I see.
Yes, this I can see how this is a little unintuitive.
I’m not sure I can explain it correctly, so Sam may wish to chime in, but
run_file is not synchronous - so if I understand this correctly, it’s (probably?) because the
print(TEST) is executed before the code in test.rb has managed to declare
If this is the case, then you may want to have something like a loop waiting for
TEST to be defined, before using it properly later.
Cool—I get the gist, and I don’t really need to know the nuts and bolts. I just wanted to make sure there’s not a problem.
More importantly, though, isn’t it better from a performance standpoint to store my collection of stable routines in init.rb rather than some
get_file file? When I do M-r in a live situation, the
get_file stuff will all get re-loaded unnecessarily, but stuff in init.rb won’t.
So it’s back to the wish list for “don’t restart to reload init.rb.” It’s too bad because using a file in one of my regular paths automatically backs it up via iCloud. I’m not sure I can include .sonic-pl in iCloud without capturing a whole lot of other stuff that I wouldn’t want taking up my iCloud space.
If it helps: if the contents of your external file are functions that do not depend on local variables in the same scope, or the external file just sets things in Time-State, there is no need to have the
run_file command executed in the same buffer as your main code, since these things are buffer-independent.
So I keep the
run_file command persistently on hand in one of the buffers, then I always have to be sure to run that buffer before working on my main stuff. I guess manually asynchronously loading my library is a somewhat better chore than dealing with the consequences of putting the
run_file in my main buffer. I might like a re-load init.rb feature better, but then there’s the iCloud issue I mentioned, requiring the even more easily forgotten chore of backing it up manually. I guess my additional request would be to allow the user to specify the location of init.rb.
Fair enough! Without knowing the exact nature of your code, it’s hard to be sure that we have worked out the best way for you to handle your particular composition, but we did at least clear up your original question