Has anyone used Google's Protocol Buffers when developing applications in Objective-C?
Are there any current projects for compiling .proto files into Objective-C, all the Google docs simply refer to Java, C++ or Python.
I've been working on an fork of Cyrus' project. It's based on protobuf 2.3 and works as a protoc plugin (protoc-gen-objc) instead of requiring a modified protobuf distribution.
You can find it as the protobuf-obj project on GitHub.
The Third Party page lists this Objective-C port. Unfortunately the project appears to be empty at the moment, but it's encouraging to see it anyway. I had heard internal rumours of the project, but hadn't seen it as an open source project before today.
You could get in touch with the project owner (Cyrus Najmabadi) to ask about it though...
(Small piece of trivia - Cyrus used to work on the C# team in Microsoft before he joined Google.)
This may or may not be helpful, but Apache Thrift (originally developed at Facebook) supports Cocoa, and seems to have people attempting to use it in the iPhone.
Thrift officially supports more languages. But Protocol Buffers have 5x the Stack Overflow interest, so who knows if it's a good replacement in terms of maintenance—not to mention compatibility with your own project! Still, maybe it's worth consideration.
I just asked a related question you may find helpful if it gets good answers: Any success using Apache Thrift on iPhone?
Protocol Buffers v3 supports Objective-C
Protocol Buffers v3 supports Objective-C as a first class language.
To generate Objective-C code from a .proto file call the compiler with the objc_out option:
protoc --proto_path=src --objc_out=build/gen src/foo.proto src/bar/baz.proto
I prefer to use c++ generated classes within my objc projects, works just fine.
I did try the objc PB version but without success.
Related
I have a npapi plugin(bundle) for chrome, which use C++ and objective-c. now it needs to be build by google native client.
I wonder that can nacl support objective-c? how to compile o-c file by MakeFile
And if possible, how to build nacl plugin in Xcode? I tried, but i found that the libraries of nacl are " archive with no architecture specification".(use lipo -info *.a)
I hope someone to help me, thanks a lot!!!
If you use Objective-C without any of its usual libraries then you should be able to use the PNaCl toolchain (which is based on LLVM) to have it parse Objective-C. I'm not aware of projects that have done this, so you should definitely let folks on the mailing list know if you get something working (do keep the questions on SO, though!).
It sounds like your application won't be running on the open web (where only architecture-independent PNaCl can run, not NaCl), so you could either use the PNaCl toolchain to create a .pexe, or you could use the same toolchain to create a .nexe for each architecture you target. The documentation I linked to helps with both approaches, but note that using the PNaCl toolchain to create a .nexe is currently being improved. You can therefore follow the instructions on the bug tracker, or try out nacl-clang when it's released (or build it yourself if you're brave).
I am working with erlang project which uses google protobuf via https://github.com/basho/erlang_protobuffs
After some time I've got not such good impresion about it (I've found usage of this technology in erlang very clumsy and inconvenient). But of course, I known that this is because I can not cook it properly.
Which open source erlang project are using erlang_protobuffs? I am interested in best (or at least sufficient) practices of its usage.
I assume that you mean http://github.com/basho/erlang_protobuffs library.
From major opensource projects I know only basho's riak using this library, although
Github code search gives a lot of different projects.
Note, that this library is not only one, take a look at this post
I'm aware of the existence of libobjc2, and I gather that I'll need to use clang rather than GCC, but I can't find any basic instructions of what's different about the compilation process.
Can anyone give explicit, step-by-step instructions on acquiring, configuring, compiling, and using GNUstep with Objective-C 2.0 in Ubuntu?
Since the GNUStep ObjC2 FAQ has already been referenced, I'll assume you've had a look. I would like to point this out, however:
For more advanced features, currently only supported if you compile with Clang, you will need the GNUstep runtime. This is not currently considered production ready. It should work as a drop-in replacement for the GCC runtime, but some of the advanced features are not well-tested.
The FAQ also calls out the following:
If you are using a recent version of GCC to compile your code then you should have a copy of the Objective-C runtime library that came with your compiler.
If you compile with the -fobjc-nonfragile-abi flag then you will use the new ABI. This is only supported with the GNUstep runtime. This adds:
Property introspection
Introspection on optional protocol methods
Non-fragile instance variables
Forwarding proxy support
So, if you're looking for older functionality via GCC, this tutorial would do the job nicely, as would this one. You've explicitly called out that you're looking to do this with the functionality provided by Clang (via libobjc2), which has its own bed of documentation.
Obtaining a release of Clang and getting set up seems fairly cut and dried. The LLVM Getting Started document is exceptionally robust (full documentation archive here), which should provide insight into getting the backend set up and compiling properly. Some additional insight into the expected build procedure can be found here.
However, compiling an Objective-C application in Clang seems extremely underdocumented and untested at the time of this writing. As features become available and the codebase stabilizes, I imagine more user documentation will go live.
According to the GNUstep Wiki, you need just need to compile your code with -fblocks and -fobjc-nonfragile-abi. Then you just use the language features in your code.
I have a plan to build a web-site which running CGI made with Cocoa.
My final goal is develop on Mac OS X, and run on FreeBSD.
Is this possible?
As I know, there is a free implementation of some NextStep classes, the GNUStep.
The web-site is almost built with only strings. I read GNUStep documents, classes are enough. DB connection will be made with C interfaces.
Most biggest problem which I'm concerning is linking and binary compatibility. I'm currently configuring FreeBSD on VirtualBox, but I wanna know any possibility informations about this from experts.
This is not a production server. Just a trial. Please feel free to saying anything.
--edit--
I confused Foundation and Cocoa frameworks. What I said was Foundation. Basic classes which just enough to manipulating strings.
It’s entirely possible to cross-develop using Xcode. The Cocotron does this – and provides an implementation of Foundation – but doesn’t currently target FreeBSD. You could probably use it as a template to set up cross-development for BSD targets using GNUstep, but it won’t be easy.
You should be OK with the GNUstep Foundation on FreeBSD 9.0 with Objective-C 2 (clang). See these instructions.
Note: Do not installing under '/' with a FreeBSD default install, because it has little space on the '/' partition. I've used /usr/local/gnustep instead, and made some links as the instructions suggest.
Note II: GNUstep sources from subversion repository didn't compile for me, so I used the latest stable GNUstep sources.
Yes, you can do this, and I am doing it right now successfully using FreeBSD 8.2 and Xcode 4.0, running the Foundation class from The Cocotron. Here is a link: describing exactly what I did to build the cross compiler and set everything up. I also detail in that post, how I attempted to get AppKit (GUI) to work. I failed, it may work in the future, it doesn't fully work yet.
So far it's great. I use a common codebase to write iPhone App (game client) and FreeBSD Game Server; after my server compiles I even have a target rsync the files to my dev box.
One more note, you mention DB, I'm successfully using mysqlclient libraries within my App and my post details how to do that. Since you're building a cross-compiler with The Cocotron you can use any library. Just install the library on FreeBSD first, then create the platform as described.
Sounds like your trying to shoehorn tools onto OS and hardware they were not designed for. There are hacks to get almost anything running on top of anything else but why ask for all the grief?
The entire point of the entire Apple API is that you have integration from hardware to OS to development tools. You supposed to pay more up front in return for greater robustness and lower over all lifecycle cost. (It doesn't always work just like Linux doesn't always save money and Windows doesn't always provide the software choices you need but that is the design goal.) When you break Apple's hardware-OS-Dev trinity you have to start fighting the API and the hardware instead of letting it work for you.
I don't think what you're doing will work and even if it does it will cost a lot of time and in the end time is money. Unless your being forced by external circumstances beyond your control to use this configuration, I would strongly suggest you do whatever it takes to find another way to accomplish what you want.
You won't get binary compatibility. Mac OS X uses the Mach-O object format and FreeBSD uses ELF, like linux. Cocoa won't work on platforms other than Mac OS, but if you stick to POSIX and open-source libraries though, you shouldn't have too much trouble building your CGI (and any dependencies) on your FreeBSD machine.
Also, Cocoa for a website? It's the Mac OS standard library for GUIs, associated datastructures, and various helpers. Apple used to promote something called WebObjects which was similar to Cocoa for the web, but I haven't heard anything about it in ages. I don't think Cocoa will work for a website, unless you just mean write a custom web server that has a graphical front-end in Cocoa.
I'm planning to write a C library which will act as an umbrella "wrapper" around several other libs. Some of the libraries will be GPL and some will be proprietary. Moreover, some of the libraries may not be available at compile time, so I plan to have autotools detect them during configure. I'm also wondering if I should build in support for these weak dependencies and then also detect them at run-time -- particularly for the proprietary libs. Here's why:
Without going into specifics, the library is intended to provide an API for talking to various devices, some of which don't have open source drivers. Currently it's difficult to program for these devices because there is no standard, easily available API to use. Each vendor provides its own. There are a few other APIs available that attempt to wrap them, but they are by and large
C++-only.
Designed for a Windows environment, with *nix as an afterthought.
Fail to build unless you have dependencies in the right places, i.e., complete lack of a proper configure/build system.
Most importantly, designed in such a way that they often link directly to proprietary libs, making me almost 100% sure it would be impossible to get these APIs into Debian.
Therefore my end-goal is to build a very simple and straight-forward C API that has a chance in hell of making it into distros so that people can actually write programs for these devices with a simple apt-get.
My question is, how should I best design the library to be GPL-compatible and Debian-friendly, but still be able to call out to proprietary libs when necessary?
Ideally I'd like the user to be able to apt-get a program using this library, and then as long as the vendor's user-level driver is installed to the expected place, everything should work out of the box.
My concern is two-fold:
having dependencies on optional, proprietary libs means the binary distro of the library can't be compiled to dynamically link to these libs, since they may or may not be available.
the user should not have to install dependencies for devices he does not have, open or proprietary.
How do other packages handle this problem of linking to proprietary libs and having run-time weak dependencies? Is dlopen the right way to go for everything? Should I dlopen only the proprietary stuff? What are reasons why or cases when Debian might reject such a package?
Lastly, I realize this probably isn't the right forum for this question about Debian policy, so can anyone point to me a better place to ask this question?
Thanks.
I have no relationship to Debian and cannot speak about their policies. However, for your framework, this seems a reasonable approach:
Define a simple header file that expresses the functionality you need from these plugins
Create a useful GPL/LGPL/BSD plugin that uses that interface
Have your main program load that using libdl, as you mentioned (if your main program is GPL, you need to have a licence exception to allow linking proprietary plugins)
Submit those for inclusion in Debian, and don't mention about the proprietary stuff
The main point is that your plugin system should be useful for free software, and not just be a Trojan horse to allow proprietary code to be loaded.
Using dlopen does not change the fact that you are writing a program to deliberately link to proprietary libraries and GPL libraries at the same time, it just shifts the linking from compile time to run time. While common consensus among the masses is that the GPL does not cover linking dynamically at runtime in this way, it is not safe legal advice to rely on such common understanding. The way I would solve the problem is to write a program with a single generic API for plugins (which can use dlopen, but the key is that you have not specifically written this program to link to proprietary libraries). The program must be under a free license that is compatible with all the plugins you eventually want it to be used with (ie LGPL, or GPL with exception for that API). Then write separate plugins for the GPL libraries and the proprietary libraries, and distribute them separately. If only one plugin can be loaded at a time, then there is no legal problem. If it is necessary to allow more than one plugin at once, then you need to be careful to separate your distribution. As the GPL is a distribution license, what the end users do is not a concern.