I'm maintaining an app that is required to support Macs running 10.5 and above. With Twitter's switch to version 1.1 of their API I've been unable to locate a solid library that supports these older systems.
I've tried STTwitter, oauthconsumer, and gtm-oauth to no avail.
My only requirement is that I be able to GET three tweets from a user's public timeline. I was previously using this end point :
NSString *urlString = [NSString stringWithFormat:#"http://api.twitter.com/1/statuses/user_timeline.json?exclude_replies=true&count=10&screen_name=%#", [_prefs objectForKey:#"twitterHandle"]];
Is it time to kick my 10.5.x users to the curb?
OS X 10.5 comes installed with Ruby. You can call the ruby gem "twurl" (using a command line call and parsing the results).
Plenty of example are available here: https://github.com/marcel/twurl
I used something like this for a Python project before the popular Python libraries had been updated to support API v1.1.
Good luck!
Related
I have the Pepper robot running NAOqi 2.9, which is meant to use the QiSDK for its Android tablet. Things have been going well, but the photo capture rate is surprisingly slow (at most 2 fps), so I've got to use the C++ (or Python) SDKs available for NAOqi 2.5 for this particular task.
I've been trying to get it to work for a few days with no success. I have setup both the C++ and Python SDKs up and running, but the problem I'm facing is connection to the robot.
I've run the simple following code (using the robot's IP) found on the official website here
from naoqi import ALProxy
tts = ALProxy("ALTextToSpeech", "<IP of your robot>", 9559)
tts.say("Hello, world!")
and I'm getting the following output stream
after the second line
The connection problem occurs running either C++ on Ubuntu, or Python on Windows.
I can connect to the robot via SSH, FTP, QiSDK in Android Studio, but not in any way through the NAOqi 2.5 SDKs for C++ or Python. Since QiSDK was most probably build on top of the C++ SDK, there surely has to be a way to make this to work.
Any information will help immeasurably.
As far as I know, in NAOqi 2.5, the tablet (JavaScript) and the "brain" (Choregraphe i.e. Python / C++) of the robot were two independent devices and had to communicate and cooperate with each other. In NAOqi 2.9, the "brain" was moved to the tablet and the only way to program Pepper is by using Android Studio.
On the download page for Pepper NAOqi 2.9 (https://www.softbankrobotics.com/emea/en/support/pepper-naoqi-2-9/downloads-softwares), there is a comment regarding the Python SDK:
This is for old NAOqi 2.5.10 and NAOqi 2.5.5.
And the following is stated for NAOqi 2.9 / Pepper SDK Plugin [for Android Studio]:
This is all you need for Pepper NAOqi 2.9.
Therefore, according to Softbank Robotics' documentation, using Python / C++ to program a NAOqi 2.9 Pepper is not possible.
I hope this information answers your question.
Edit
There's another way, you can use the qi Python library inside Pepper's head, in order to use services, such as ALTextToSpeech or ALMotion, with a simple example here. One could also only use SSH to start a Python server, which would give access to these functionalities through endpoints.
import qi
app = qi.Application()
app.start()
session = app.session
tts = session.service("ALTextToSpeech")
tts.say("Hello Word")
If you run the above snippet inside Pepper's head it produces the expected output(saying Hello world). There are almost all the services that are documented here. You can also list them all by calling .services() on the session object
End of Edit
I finally found a way to hack into it. If you connect to the robot via SSH you can use the qicli binary. Its documentation is here
qicli info lists all services available, for example ALVideoDevice or ALMotion
qicli info ALMotion displays the available methods of that service
qicli info ALMotion.setAngles displays info about that method's parameters
qicli call ALMotion.setAngles HeadYaw 0.7 0.3 calls the function in the module with given parameters
So one could write a wrapper to this binary and call it programmatically via SSH, it seems like a lot of work for this kind of task but I haven't found anything else.
I've got Python's Paramiko library to work:
import paramiko
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.connect(hostname='ip-of-robot', username='nao', password='your-pass')
stdin, stdout, stderr = client.exec_command('pwd')
print(stdout.read())
client.exec_command('qicli call ALMotion.setAngles HeadYaw -0.7 0.2')
client.close()
I've also tried .NET's SSH.NET library, with little to no success.
I have NVIDIA driver v 378.92 installed, and according to the nvidia website since driver version 377.14, driver supports vulkan api 1.0.42.1. My vulkan SDK api version is 1.0.42.2. However when I check for my device support info, using vkjson_info.exe in the vulkan SDK, there's stated that only apiVersion 1.0.37 is supported.
I'm a bit confused how this works, can anyone enlighten this?
The reported version could be limited by the Vulkan Loader/Runtime it finds. First is this Windows or Linux?
If you have the Vulkan SDK 1.0.42.2 installed, can you run the VIA tool? It should generate an HTML output. If you look at the "Runtimes" section, you should see which ones are available and which one it's using. For best results, try running it from the same folder as vkjson_info.exe. But, it should give you a good idea if you just run it anywhere.
"1.0.42.1" is not a Vulkan version. Vulkan only has three levels (i.e. major.minor.patch). So the "1.0.37" is likely correct and the "1.0.42.1" is likely the version of some LunarG Vulkan SDK or possibly Vulkan Runtime that comes with it.
There are usually several types of versions flying around:
The Vulkan driver version. It is of the major.minor.patch format and it is in VkPhysicalDeviceProperties::apiVersion or can be obtained by a tool such as VHCV.
Optionally SDK/Layers version on the runtime machine. LunarG Vulkan SDK versioning of the form vulkan_major.vulkan_minor.vulkan_patch.optionally_SDK_patch.
Vulkan Runtime of the runtime machine — It is basically The Vulkan Loader dll (if the application uses that). Both SDK and drivers install this (and coexist) and they use their own versioning scheme. The SDK version also installs the Validation Layers to the system.
SDK/Header on the application developer machine. Versioning as described above. The vulkan.h header is always 1.0 and so has only single number version — VK_HEADER_VERSION (which matches the Vulkan patch version — but does not have to in the future)
SDK/Header on the driver developer machine. Versioning as described above. Should really be the same as Vulkan driver version. And most likely the Vulkan RT installed by the driver will be the same version. But I think I have seen this to differ.
It should not matter, because all patch versions are supposed to be both-ways compatible (in reality not really — there were some changes, but driver makers seem to keep up so far providing updated drivers, so it is not an issue). And in fact that is the only thing I could find in the driver documentation: "Vulkan 1.0" support.
I hope you are so enlightened now that you reached the ultimate state of boredom.
377 is a beta version driver from https://developer.nvidia.com/vulkan-driver . There is no guarantee that beta feature will be carried over to the subsequent release version. And according to http://vulkan.gpuinfo.org/listreports.php it didn't (378 indeed have 1.0.37 and 377 have 1.0.42 and more importantly has the extensions you want to try). Continue to use the beta for now if you want the features within it. As for Layers and other SDK features you should not need newer drivers — in fact you should always use the latest to benefit from Validation Layer bugfixes and improvements.
I have created a cocoa application which used the base SDK OS X 10.10. Some APIs which only exists in 10.10 are called. So it doesn't run correctly in the system which version is lower than 10.10.
So, i wan't to know is there any way can make my application run correctly in OS X 10.9 except rewrite it use lower SDK.? If not, What is the value of these new API. because i can't use it. If i used it application can't work in lower system.
Thanks!
You should use 10.10 as your Base SDK, and set your deployment platform to 10.9. You can then use respondsToSelector: and NSClassFromString to know if the class/method you're trying to use is available on the current OS, and degrade gracefully (for example, only make a feature available if you're running on the latest OS).
No, you'd have to rewrite it to use API calls which are available in 10.9.
The point of adding new calls to the API is because eventually everyone will have a device running the newer software - especially with Apple products - and then you'll be able to use it. Also, some people don't mind not being able to run on an older device. If they never added anything to the API then we would still be using the same things from 20 years ago.
If you think this is bad then try writing software for Android. The majority of devices are still running old API versions.
Essentially the answer is NO. You can't make an app which is built using the latest API's for 10.10 run in 10.9.
What the value of using the latest API's is depends on what you want to achieve. If you want to take advantage of the latest Apple technologies like iCloud Drive and CloudKit then you need 10.10. However, if your project doesn't need the these technologies then it may be worth making your app using a lower SDK.
It's worth noting that OS X 10.10 is free so you probably won't be alienating anyone by using the latest SDK. It's a different story for iOS where usually only the latest few iPhone and iPad models can be upgraded (e.g. iOS 8 from iPhone 4S and upwards).
Hope this helps.
Question 1
If I want to build an application with OpenCL support, do I have any guarantees that the OpenCL.lib implementation from my vendor is able to work with all devices from other Vendors? If yes what's the difference between the implementation?
Question 2
Is it possible to use different OpenCL versions in the same application? For example AMD has released a preview driver for OpenCL 2.0 support. On the other hand the lovely company called Nvidia is still trying to ignore everything past OpenCL 1.1. It would be nice if I could write platform specific code in different versions.
1: On Windows, OpenCL.lib is a static wrapper around OpenCL.dll, which is the ICD loader, and exposes all of the available platforms. It is provided by Khronos and redistributed by the OpenCL platform vendors. So go ahead and link to it; it will work with whatever is installed (although if nothing is installed your application won't run because it can't find OpenCL.dll; this is solved other ways).
2: Yes. As long as the ICD loader is the latest, you can get at the newer API on newer platforms / devices. Just don't use new API on old devices; that will crash or worse.
I've noticed that all betas for Dropbox are released simultaneously for Windows, Mac and Linux. How do they do that? Anyone knows which platform they're using? I'm aware that there are many native -very impressive, actually- functions in each of the platform clients, but they seem to release critical bug fixes efortlessly for all platforms.
So any idea of which GUI platform they're using?
The Linux version includes files such as wx._windows_.so, libwx_gtk2*.so, etc. (I haven't checked the others), so I suspect Dropbox uses wxWidgets.
Qt is a popular cross-platform application and GUI framework with native look-and-feel.
I don't know what Dropbox uses for all its supported platforms, but it looks like its linux client uses at least Gtk: Dropbox linux System Requirements.