I know the Wordnet webpage cites that it comes with a C interface included. However, I am having significant trouble adding it to my project. My question is two fold.
First: Does a machine need to have wordnet installed to utilize the API (or can the data be read a runtime from the dict files? and thus distributed to machines that do not have wordnet installed)
Second: How can you include Wordnet in a C project. I've tried adding the source files directly, but it crashes on init(). I've stepped through the debugger and it looks like it is looking to load the files from my local drive rather than the included files in the project. Is there a way to prevent this for machines that do not have Wordnet installed (from part 1).
Thank you for the help,
Unless I'm mistaken and you're referring to a different WordNet, there has been a Cocoa front-end available for years here.
Just found this today. Might be helpful, as it only requires adding the sqlite.db file of WordNet and provides a super super thin Objective-C wrapper on the sqlite call to talk to the database. Using this as a template for your understanding should allow you to extend it to allow various queries.
https://gist.github.com/atduskgreg/c30a5fb167f4c35d6f89
EDIT: With the above example, you can see the format the query takes. With that knowledge, you could grab the sqlite file for the WordNet database from:
https://code.google.com/p/synonym/downloads/detail?name=wordnet30.1.tar.gz&can=2&q=
then either just use the C calls for sqlite or pick a more robust Objective-C wrapper like:
https://github.com/ccgus/fmdb
Related
MTA Subway data (among other data) is formatted in GTFS-realtime. In order to convert the protobuf into a string representation I must run it through some Google protobuf tools using gtfs-realtime.proto. The only problem is that, as can be seen here, the gtfs-realtime-bindings are available only for
NET
Java
JavaScript / Node.js
PHP
Python
Ruby
Golang
Additionally,
We don't provide generated code for C++, use the official protoc compiler for that (from here or here)
None of these are Swift or Objective C. While there is an open issue/request for a Swift/Objective C version from 2016, I was wondering what I can do currently in order to do this. As of now, the only viable solution I see is to have a server parse the data and then GET the parsed data (JSON encoded?) from that server instead of directly from the MTA.
Here is the Google page for protocol buffers. I am not sure, but is there some way to use what is there to read the GTFS-realtime data.
Is that the best path forward? Are there any other possibilities?
As noted by Tony Laudig, having your app directly communicate with the MTA is a breach of their terms and conditions which you almost definitely would have had to agree to in order to get an api key.
Breaking terms and conditions is generally a pretty bad idea. In the case of this API, it seems like your key will be revoked.
Thus, I would not suggest using the library in Tony’s answer. Instead, do what you proposed:
Have a server parse the data and then GET the parsed data (JSON encoded? [—sounds good]) from that server instead of directly from the MTA.
Any of the languages you listed will do the job, it’s just a matter of which you’re most comfortable with.
There is an official library in Objective C for parsing Protobuf. You can compile classes from the GTFS-rt standard and the MTA extension .proto files.
It looks like your planned usage, having the app connect to the MTA directly, doesn't conform to the MTA terms and conditions:
In developing your app, you will provide that the MTA data feed is
available to others only from a non-MTA server. Accordingly, you will
download and store the MTA data feed on a non-MTA server which users
of your App will access in order to obtain data. MTA prohibits the
development of an app that would make the data available to others
directly from MTA's server(s).
I'm new to objective-c & osx architecture. I started playing with building a framework and then using it. I followed this great tutorial.
During the tutorial, I had to set the framework's target's Dynamic Library Install Name to #rpath/MyFramework.framework/Versions/A/MyFramework. My understanding is that #rpath will expand to the loader's (consumer's) run-path search paths.
It seems as if the responsibility of loading the framework is split between the framework author and the consumer author. Could someone please explain why the author of the framework needs to be concerned with the consumer's run-path search path? For example, if the framework-author set the Dynamic Library Install Name to point to some random directory (instead of #rpath) how would the client be able to consume the framework?
Thanks in advance.
It depends a lot on how the framework is being used. And it's important to remember that the framework construct has existed for a long time on the platform.
For a system framework, such as the ones that Apple creates, you're going to be quite happy that they keep the frameworks in a known location. In those cases, the paths that they use are fixed for the OS, and it guarantees that you don't accidentally load the wrong one. Further, as indicated in the Framework documentation, these frameworks are loaded only once on the machine, regardless of how many times they are used (see Apple:What Are Frameworks) . The benefit here is performance and it is for both the code and the resources in many cases.
Due to the recent move to randomize framework locations,and Apple's comments in the release notes that "Mountain Lion randomly relocates the kernel, kexts, and system frameworks at system boot," it certainly appears they're still sharing these resources, and thus still gaining from this benefit.
For embedded frameworks, the situation is a lot more tedious, and Apple has moved through a variety of methods over the years to make it easier to find frameworks wherever they may be. Due, again, to the shared nature, it would make sense for Applications which share common library requirements to share them on the machine, both for purposes of efficiency, and to make sure they're at the same version if they're sharing data. So, for example, if you have two separate apps that use the same framework to work with shared data, you might put the shared framework in /Library/Frameworks and have both apps explicitly look for that, making sure that some other (possibly older) version of the framework, that has been loaded by another App, is not used instead.
In the end, there's a lot of flexibility for the Framework producer and consumer the way that it currently works. It means that the developer can decide to share a framework, include a private copy of the framework, or even do both, depending upon whether the framework exists on the machine or not. However, the price for that flexibility is the complexity that we have today.
Another example of a reason you might not want to use #rpath specifically is for tightly-linked embedded frameworks (yes, people embed frameworks within other frameworks). In these cases, you don't know where the first framework is loaded, but you want to put the embedded framework inside of it, so that they stay together. In this case #loader_path is relative to the code that is loading it, so that your plug-in's framework can find its resources correctly.
In answer to your specific example about somebody setting the Dynamic Library Install Name
to a "random" location. In this case, you'd have to know that location. There might be many reasons for somebody doing this, such as wanting to discourage reuse by other programs, or because there are large resources within the framework that should only be installed in a known shared location.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Objective-C Code Obfuscation
I am trying to put together an iOS package that can be reused in multiple apps. I would like to be able to bundle it up for others to easily plug in and use, and I would like to obfuscate the code so that no one can read it.
What would you recommend between building a framework, a static library, or another solution to accomplish this and why?
If you're distributing for iOS, you have two options:
Distribute a precompiled binary and headers
Distribute the source
Since you're asking about hiding stuff, I don't think #2 is what you're looking for.
As for #1, the best you can do is just not tell 3rd party users about more stuff. They'll still be able to use the runtime to find methods and properties and instance variables, etc. If you're doing everything in C-land (ie, no Objective-C classes), then they can still use things like otool to dump symbols.
In short:
It's probably not worth trying to "obfuscate" your code. Just tell them about the stuff they need to know about, then give them a .a file and the headers they need.
A framework is the standard Cocoa approach to shared code. You can distribute a framework as a compiled code library and a collection of public headers without making any of the underlying Objective-C soure code visible. Of course, a dedicated hacker could still read the machine code, but this would be a big undertaking, and probably not worth the time they would have to spend on it.
If you are really concerned about sensitive code, you could consider an internet-based service, in which your library calls out to a remote server under your control to perform some business logic. This approach is quite a bit more involved, and does not offer as much flexibility for your customers.
I was wondering if there were a way to extract information from an objective-c app, static or dynamic library and/or framework?
Information such as an array of class names without instantiating or running the target.
I've checked google and the apple developer documentation and haven't found anything.
Frank
F-script appears to be able to do what you want, but I'm no expert. Check out www.fscript.org.
If you want to extract classes from an application/dynamic library, there is a handy tool called ClassDump.
It can even generate the header files in order to get an overview of the classes, protocols, etc.
If you want to do it at runtime, then take a look at the source code to learn how to load and parse the different mach-o segments.
This is an excellent starting point for reverse-engineering Cocoa apps:
http://culater.net/wiki/moin.cgi/CocoaReverseEngineering
It mentions F-Script, class-dump, and a few others.
I want to update/upgrade the standard Leopard install of Sqlite3 to >3.5 to use the new sqlite_xxx_v2 methods from a Cocoa project.
I can't seem to find any information on how to do this. Does anyone have any tips or a site that outlines the update procedure.
Also is 3.5+ supported on the iPhone. I understand it's embedded so shouldn't be an issue...
What you want to do is grab the amalgamation sources from http://sqlite.org/download.html . Then just compile that into / add it to your project. You don't want to replace the system sqlite- that'll have unintended consequences in other applications. Plus, I'm pretty sure the system sqlite isn't a stock sqlite... Apple has probably made their own modifications to it that core data relies on.
You can read up on the amalgamation stuff here: http://sqlite.org/amalgamation.html , but in short: '''The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3 and RTREE extensions'''
I'd also suggest not using the sqlite calls directly, they weren't designed to be used that way (says the author of sqlite). Instead, there are a number of cocoa wrappers out there, including fmdb: http://code.google.com/p/flycode/source/browse/trunk/fmdb/ (which I wrote) :)
-gus
You don't really want to upgrade the system version of SQLite on Mac OS X. The reason is that all Mac OS X software is qualified against the versions of the packages that it includes, as built by Apple's build process. Installing a different version of a package, or even building the same version yourself but doing so slightly differently than Apple does, may result in a system that behaves unexpectedly.
Finally, if you embed a newer version of SQLite — or any Open Source library or framework included with Mac OS X — into your own application, you should be sure to integrate the Darwin changes for it from Apple's public source site. That way you can be sure you'll get as close to the same behavior as possible from the library you've built yourself as the version Apple ships, which is especially important when it comes to functionality like file locking in databases.
I don't believe i've updated my version, but it's currently at 3.4.2, and i'm able to use the new methods with the current version.
And i'm running 10.5.5 with the latest (public) iPhone SDK.
It would likely be easier to just drop the library into your project and link it in from there.