Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
StaSh updated for 1.6 beta with ObjC functions
-
@ywangd I followed your instructions and the problem persists. I am running v1.6 (160033) on an iPad 3.
-
@Phuket2 I mean literally
.stash_config
. It can be tricky to create this file just using Pythonista editor because it does not like files without extension. You can create as a regular python file, saystash_config.py
in~/Documents
. Then from inside stash, rename it by runningmv stash_config.py site-packages/stash/.stash_config
. -
@ihf I am not sure if it has anything to do with 32bit vs 64 bit devices. As I remember, iPad3 is 32 bit. Unfortunately I don't have a 32bit device around to do any tests. I'll try add some debug loggings so the launching process can be recorded into a file. I'll let you know once it is ready. Sorry for the inconvenience.
-
i have ipad 3, and have launched it no problem. I might be a few commits behind, will try updating later tonight.
I did have a crash once recently, while i had another view opened. also cancelling during the launch, then running again is likely to cause a crash.
-
@ywangd , I really can't work it out. I tried many things and get weird results. I have a feeling that the preceding dot is the problem.
Even i do this in the site-packages/stash/ dir_settings = '''[display] \n TEXT_FONT_SIZE=10''' with open('.stash_config', 'w') as f: f.write(_settings)
As far as I can see the file does not show up in the browser. If I remove the preceeding dot, the above works as expected. But I suspect it's there, but not visible. Look maybe not my place to say, but would it make more sense to create a file like stash.cfg on start up if it didn't exist and write your defaults to it.
-
@Phuket2 Yes files with names start with a dot are hidden files. It is an Unix convention. I agree it could be confusing for people not familiar with Linux/Unix. Also the Pythonista builtin browser and editor are not designed to take care of this type of files.
So I modified the code and now it also reads a
stash.cfg
file under the installation root (thanks for the idea). Could you please try again with this file? You can get the changes by runningselfupdate.py beta16
from within the shell.Apparently there are multiple ways you can create this file. As a demo, you can do this from within StaSh by running following command:
echo "[display]\nTEXT_FONT_SIZE=20" > $STASH_ROOT/stash.cfg
You need to restart stash afterwards for changes to take effect.
-
@JonB Thanks for the test. Please do let me know the results with the latest push. I just did one about half an hour ago.
If it works for your iPad3, I really have no idea what exactly could cause the crash for @ihf . Though it is most likely due to usage of the objc_util module. A single error on text range etc can crash the entire app. But exactly where I don't know ... -
beta16 (installed via git clone) worked fine on IPad 3. I also tried via getstash.py.
-
@ywangd, thanks your mod works perfectly, as well as your selfupdate
-
@ihf
I have created a new branch beta16-log with detailed logging statements for debugging the launch process. Could you please give it a go?- First delete any existing stash folders and launch scripts
- Run
import urllib2; exec urllib2.urlopen('http://bit.ly/gsb16').read() in {'_br': 'beta16-log'}
to get the new branch. please note the trailing dict for selecting the correct branch - Unload Pythonista completely and restart
- Tap to run
launch_stash.py
found inside~/Documents
folder. - If Pythonista crashes during the process, restart it and you should be able to find a log file as
~/Documents/stash.log
. - Please copy contents of the log file and create a new ticket at the GitHub repo (better not flood this thread with logging outputs)
Thanks!
-
-
@ywangd Done. Ticket #136. Thanks very much.
-
@ywangd , i know the git distrib is not yours , but would also be nice if they didn't use '.git' for a dir name.
-
@ihf I updated the ticket with steps for further debug. Thanks for taking time to work on this!
-
@Phuket2 said:
@ywangd , i know the git distrib is not yours , but would also be nice if they didn't use '.git' for a dir name.
@JonB is the author of the
git
command. But here are my takes on the.git
folder:-
It is consistent with the original (PC) version git.
-
Often a hidden file/folder indicates that it is not supposed to be directly edited by users. This is the case of
.git
. This folder stores the version control information and is the internal working directory of the command. If you look inside the folder, there is little information that is human readable. -
Many Unix/Linux tools use .hidden files/folders as resource files and working directories. It is a convention. For an example, both PC version
pip
andipython
create hidden folders (.pip
and.ipython
) under your home directory to store their working states. -
With StaSh, you can list hidden files by
ls -a
and you usecd
to get inside a hidden folder, i.e.cd .git
.
-
-
@ywangdk thanks for nice complete definition. Personally, I think the days of hidden dirs and files should be over. Maybe I am wrong, but it just seems to me in this day and age , not required. I would think if you have files that should not be edited, better just to set the read only flag. If people go out of their way to change that flag, well...better still at the OS level, files could have a imbedded password to change the flags. That's why I still love the old idea of the old mac files. Resource fork and data fork. I know this was a trick by the OS. But in my idea, every file should have a header. .txt or whatever. If every OS supported it, would not be a problem.
Yes, I am dreaming :) -
@Phuket2 Keep in mind that "hidden" files are much less hidden in shell environments than on a desktop system like Windows or OSX. In the shell there are no hidden files as such, it's just that
ls
by default doesn't show files starting with a dot, which are by convention "hidden". Desktop systems like Windows or OSX have a different concept of "hidden", namely an extra file flag that has nothing to do with Unix dot files. To see that kind of hidden files on a desktop system, you often need to change some hard to find setting. Which is probably a good thing, considering how many users (want to) know nothing about how their OS works internally and would be worried about all those desktop.ini files that they never created. -
ls .*
will show you hidden files and directories on the commandline. -
@dgelessus and @ccc, I really do get your points. But we are in 2015 now. I know in some way it's very easy to have hidden files. I just think the days of hiding things should be over. But I also think every file known to man should have a Json style header which every OS adheres to. I know we need another committee to make that happen. But pure text files etc... Are just an idea in the past based on transmission speeds , storage space etc. is a old idea.
Every single file could have a header (binary or text) with a set of attributes. So whatever the committee come up with , they will be there regardless. Then of course you should be able to extend it for app specific use. I am not really smart, but I could see how this could help revolutionise mobile/desktop computing. -
Think of the period like a leading _ in python, which is a way of signalling something is intended to be private. like in python, if you dare you can still use or modify it, but by default it won't be shown by some dir type commands. But it is very easy to see (i believe in stash we have the alias la defined which lists all files, basically ls -la), and nothing prevents you from modifying anything in the folder, though you are likely to completely break your repo unless you know what you are doing. Like python, these are often poorly documented or likely to change... you can use the files, but dont't depend on them.
i don't quite get what you mean about a json file for every file in the system. what would go in such a header? for instance, for git, a file in /refs/heads/branches is the name of the branch, and the contents is a 20 character sha1 pointing to a commit in the object store, which makes branch creation basicslly free. what would the header say for such a file, and how would that help you muck about in the .git folder? How many bytes are you going to spend documenting the format of a 20 byte file? While HD space is cheap, device space is not....