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.
Pythonista 1.6 Beta
-
@OMZ: Is it possible to change the ui editor's color picker to alternatively manually enter the color code?
-
Is it possible to change the ui editor's color picker to alternatively manually enter the color code?
I'll see what I can do, currently not possible.
There does not seem to be a way to set a tint or background color to transparent in the ui editor's new color picker.
Yes, that's currently not possible either (unless you want a fully-transparent background, in which case you can use the "⧄" button). I'll think about how to add the possibility of setting an alpha value in the new UI.
Selecting an action from the action menu closes the keyboard and clears the cursor position. I have a number of scripts that use editor.get_selection() that do not work correctly now as when they run this value is not set. I suspect this is also causing some of my scripts that use the selection to crash pythonista. Not to mention that it is annoying to have to re-open the keyboard after performing an action.
Are you referring to the iPhone or iPad version? I would also be very interested in a script that reproducibly crashes when using the editor selection.
-
Today I decided to switch from my Bean BLE device to a MIDI interface. I figure that a MIDI keyboard should really stress out the system since it can easily generate one shot data or whole streams. Luckily the device seems to work well and I can send and receive MIDI data to it from a script and the cb module.
I have noticed one with this device. You can pretty easily get the "connection" into a bad state by exiting the script and not formally closing it. I added the following code to the sample and it seems to cure the problem.
try: while True: pass except KeyboardInterrupt: print 'keyboard interrupt - resetting' if mngr.peripheral != None: cb.cancel_peripheral_connection(mngr.peripheral) cb.reset()
I have been assuming that cb.reset would close any open connections but that must not be the case. Does the Peripheral object have logic to close an open connection?
Also - I am not yet an expert on Bluetooth LE, but I have read up enough on it to know that the whole concept of connections and how they work is complex. There are various timeouts in place to close down open connections that you may have to set as you work with the core api's. Might be a good idea to review that.
-
Here is my script that crashes unless I remove any reference to sel. So that's just a guess by me of the cause.
import editor import os from time import sleep dbname = 'swap.txt' if __name__ == '__main__': fname = editor.get_path() sel = editor.get_selection() try: dbfile = open(dbname,'r') newf = dbfile.readline().strip() #strip off the newline character. poss = dbfile.readline() pos = int(poss) dbfile.close() editor.open_file(newf) sleep(0.5) #wait a bit for the file to open. editor.set_selection(pos, pos) except: pass pos = 0 if sel == None else sel[0] data = [fname, '\n', str(pos)] dbfile = open(dbname,'w') dbfile.writelines(data) dbfile.close()
-
@Gcarver I see, thanks! Does it also crash if you increase the sleep interval to something like 1.5 or 2.0 seconds (just to be sure). It obviously shouldn't crash either way, but if it goes away with a longer interval, that would confirm the suspicion I have about the reason for this.
-
Before I descend down the rabbit hole, I am warned I might lose my data. True or false? If true, how to back up my goodies?
-
Sorry to say any sleep amount still crashes. However commenting out the set_selection call removes the crash.
-
@polymerchm, I don't think you should lose any data, mine survived the beta upgrade. It's still a good idea to make a backup, ideally a manual one on your computer, before getting the beta, in case something should go wrong.
-
Indeed, it did not clobber anything. On to exploring. Guess I need to buy some BLE thingie to exercise it. BLE MIDI controller on the way!!!! (always the musician).
-
I have some questions about the cb implementation. I have noticed that there is no support for Descriptors or Advertisement info.
Descriptors of characteristics would be nice if they are actually implemented by the BLE device manufactures. It would make it possible to write a nice generic BLE browser app.
Advertisement data is probably more important since this seems to be the way you get access to the signal strength of the remote device. It can also be the main way that all of the data a device produces is transmitted. This is the way that beacons are suppose to work. There is no connection ever made since all the data comes across as part of the advertisement.
Also, looking at the apple sdk, I notice that they have both a central manager and peripheral manager while your implementation rolls them into one. This keeps things simple, but it also makes managing multiple peripherals difficult.
The issue of persistence is an additional concern. I have read that the design of BLE encourages the persistence of service and characteristic uuids after they are discovered so that you don't need to rescan for them every time your app runs. The apple sdk seems to have support for this with calls you can make to do scans for connected peripherals or for specific services.
Is Apple still messing around with all this and changing their APIs a lot? In reading through the online docs, I keep seeing lots of crossed out functions and new ones so it looks kinda rough. I can't even find a mention of how MIDI is suppose to be implemented despite the fact it suppose to already be part of ios8.
-
I think I may have found a few bugs in the
dialogs
andconsole
modules:dialogs
I've only really played with the import_file() function, and I've noticed several things. However, I can't seem to find a way to reliably produce one exact problem but whatever the cause it either: crashes the app (jump to homescreen) OR unexpectdly closes the dialog.
So far this has happened when I:
<li> 1. switch from tile view to list view
<li> - this one's a bit longer
<li> 1. Switch to list view
<li> 2. Open external source menu
<li> 3. Set google drive toon
</li>console
I've only noticed one thing with this module and I'm not really sure how to reproduce it, I get varying results every time.
It has to do with the set_color() function, I use it in a script I run at least 3 times a day (its a calculator using sympy, <b>GREAT</b> for math class). I call `set_color(0.36458m 0.0, 1.0) and print the following:
<li>Imported:
<li> console, canvas, random,
<li> fmath as fm, numpy as np, decimal as d,
<li> * from sympy, * from database.prefixes, Dynamic from containers, ctype from type.ctype, <li>division+generators from future
<li>Assigned:
<li> a, b, c as norm
<li> k, i, n as int
<li> f, g, h as func
<li>Reassigned:
<li> fm.m -> m, fm.fr -> frac, fm.cm -> cm<li>Loading constants...</blockquote>
(I apolgogize for the bullet points; couldnt get the string to work any other way)And then the script continues.
For some reason, the "fm.fr" two lines from the end of the string appears as a lighter blue. I have no clue why. I can provide the rest of the script if you would like but it won't work as I import a bunch of custom modules.
-
Regarding
dialogs.import_file
: Yes, I've noticed a few issues as well (mostly the dialog closing unexpectedly), but I don't think there's much I can do about this. Basically everything that happens inside the document picker happens in an entirely different process, so Pythonista isn't actually doing anything while you navigate there... I might be wrong, but it seems to me that those are either iOS 8 or Google Drive bugs.As for the
set_color
thing, I think this has to do with a new feature in the console that tries to highlight URLs automatically.frm.fr
looks like a URL, so it gets a blue color (and you could tap it to open the browser). Obviously, this is not what you want in this case – I'll definitely consider making this feature optional. -
I have a question about the cb callbacks that I could use some insight on. I have been writing various test scripts and noticing that did_update_value seems to drop values if they are coming in too fast. I can use MIDI devices to generate a LOT of events and noticed that many of them are never logged by my script. It is obvious now that having any print statements or anything else that is slow in there is an issue and can cause data loss and other problems.
So how do I deal with this during script development and determine what is actually going on if I can't log using print statements?
How do I determine what is actually going on in the callback? Is the callback run in just one thread and events serialized and buffered by the os or is there no buffering and events that come in while my script is handling the callback simply dropped?
I am thinking that I need to implement a special logger that sends the info to a queue like in QueueHandler in 3.0. This might be fast enough to support development and debug.
Any ideas, thought, and suggestions are welcome.
-
Look at my chordcalc repository. The class debugStream allows you to acculumate depug output without calling print to slow things down. You can create multiple streams and dump each separtely when done.
-
Thanks polymerchm for the suggestion. I remember seeing this now as part of your app.
class debugStream(): """ create buffered output to speed up console printing""" def __init__(self): self.out = '' def push(self,string,*args): self.out += string.format(*args) + '\n' def send(self): print self.out self.out = ''
In my case I am in a callback handling a constant stream of MIDI data in the form of "time tick" events. This makes it difficult to know when to push and when to send. I guess I could just add some simple auto flushing logic to this based on the string length.
Thanks for the simple and practical suggestion.
-
A minor suggestion: the gui doesn't have presets for iPhone 6 or 6+. I haven't been able to run too much, though my standard scripts seem to work fine.
-
Potential bug
in betaView.present(style='full_screen', orientation=('landscape'))
Does not prevent rotation. With or without parens around 'landscape'
IPad Air 2
-
Potential bug in beta
View.present(style='full_screen', orientation=('landscape'))First off, it should be
orientations
(plural), notorientation
, but I assume that's just a typo (you'd get an error otherwise). More importantly, you should pass a sequence of valid orientations, not a single orientation. It looks like you're trying to pass a tuple, but tuples that only contain a single item must contain a trailing comma, like this:('landscape',)
. The method accepts your single string because it expects a sequence, and strings are actually sequences (of characters), but you won't get the proper behavior this way. -
Thanks. Didn't know about the trailing comma formalism in a in a tuple of text strings. Works just fine now. Sorry for false alarm.
-
Any chance of getting lxml in Pythonista 1.6 (and the next version of Editorial too, while I'm at it)? I would really, really like to use openpyxl (or python-xlsx) and python-docx to read/edit Excel and Word docs in my Dropbox but they have lxml as a dependency and, as a C-based library, it's not user-installable.