Zep, I think I have found a bug but I don't know whether you would agree.
First, here's what happens when I type the "dir" in the console:
> dir
directory: /test/
dirtest.p8
dirtest.p8.png
Which is what I expected, only this cart is saved. Here's the code entered into the editor to reproduce this bug:
x=dir()
cls()
print(x)
and the result is it prints (on a clear screen) the following:
nil
dirtest.p8
dirtest.p8.png
I suppose the value of x is nil because dir() doesn't return anything. And I suppose the dir contents are printed after because the threading model is weird.
Not sure if you realized this or not, but you can test all of this directly in the console without going into the editor. e.g.
> x = dir() directory: / .. -- other stuff > print(x) nil > |
dir() prints, doesn't return.
ETA: I'm curious what you're trying to do with this - I think it could be nice to have access to the working directory name from a running cart if we were able to do anything with the file system other than load and save carts.
Thanks for pointing out that the no-return-value behaviour of dir() is demonstrable in the console.
My other point about the execution order is supposed to highlight the fact that the execution of dir() in the program text results in the console output being deferred not only until after the screen is cleared, but also after the printing of the return value of the dir() call.
Although no-return-value is 80s 8bit culturally apropos I find it quite yucky in 2016. I find small effective programming systems such as those that come from the scheme tradition universally promote the idea that everything has an expression value.
There's a couple of matters rolled together in this post! Apologies if it makes the points less clear.
[Please log in to post a comment]
