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.
Related
I really like live smalltalk environment (though I only experimented a bit with Pharo), but there is one thing why I can't really use it for everyday development. It seems that it is not possible to create a native standalone executable from smalltalk system. The native standalone executable means to create a single executable file (PE on windows, ELF on linux, Mach-O on macosx), that a user could run by double clicking it without the need to install any additional execution environments. Am I missing something and it is in fact possible to create native standalone executable with smalltalk?
If we talk about Pharo specifically. I know that Pharo's environment includes efficient just in time compiler (that generates true native code from Pharo's VM bytecode), I know that the VM image can be stripped down by cutting of the code that my application won't ever need. So basically we already have almost everything (except the linker I guess) to be able to create native standalone executables. Cross-compilation shouldn't be a problem too, if we put all code generation stuff (for all target processors) in the image.
I know that in smalltalk world it is considered to be a good thing to deliver the whole VM image separately from the runtime environment, so the user can hack on software he/she is using. However I don't see any good reasons why it shouldn't be possible to deliver your smalltalk software as fully compiled native standalone executable. Could you please explain me why it is not a common thing to do in smalltalk world? Is there any good smalltalk implementation that allow to do it?
To sum all this. I dream of a live smalltalk environment, where I could develop and test my software, but then (when the software is actually ready for delivery) cross-compile it to native executables for windows, linux and macosx from my single development machine. That would be really awesome.
ironically enough there is one thing that an exe needs to be preloaded. Your OS. See the thing is that C/C++ can be so light because already your OS acts pretty much as the image acts with a ton of preloaded libraries. You need to waste several GBs of memory just get a simple calculator starting. Your OS is a collection of C/C++ libraries.
Things are not any prettier with other languages like python, java etc , even if the app is smaller, they still depend on this libs and they come will quite big libraries that would need installation whether your app use them or not.
Pharo and Smalltalk in general is diffirent case because they aspire to be a virtual OS by itself. The diffirence with a real OS , the smalltalk image is made to be hacked the easy way by a user .
Saying that you can rename the pharo executable, change its icon, disable to IDE tools inside Pharo so your user sees only the GUI of your App. Applications like Dr. Geo and Phratch already do this.
Compiling a Pharo project to a native executable will not make much difference, because a) Pharo is already compiled to a native executable b) you dont need to do that since Pharo is already standalone does not need to even be installed.
My advice is stop worrying about things that do not really matter and enjoy learning how powerful and fun Pharo can be.
Not Pharo, but native, compiled (through ANSI C or its own JIT) smalltalk [applications] (with ability to load pre-compiled DLLs or [JIT-]compile code on demand):
Smalltalk/X
http://www.exept.de/en/products/smalltalk-x.html
or (unofficial enhanced development version):
Smalltalk/X JV branch - https://swing.fit.cvut.cz/projects/stx-jv/
Nearly completely open-source. Everything except librun (core runtime - memory management, JIT, etc.) and stc (smalltalk-to-c) compiler is already open-source. Claus Gittinger / Exept also promised/confirmed they would release remaining sources were they to stop further development (AFAIK, those parts are closed only because of concerns of existing clients).
I highly recommend everyone to check it out, it is a wonder such a great implementation is so little known.
You might also check out Dolphin from Object Arts.
It is windows only, but the very best IDE, bar none.
If you do anything in Smalltalk, you should buy a copy.
(They also have a free non-commercial version, but you will
want to support the kind of craftsmanship behind it by buying
the Pro version. An absolutely kick-ass product, IMHO).
It will produce a standalone exe, if that's what you want.
I made an exe of a medium-featured wiki with it - the exe was
less than 1 MB. That is not a typo.
-Jim
The problem is that Pharo, in that case, cannot be compared to any native compiler like C, C++ or others, but more like java, python, ruby and other languages with a Virtual Machine around.
In these languages, you produce jars, eggs or gems to distribute your project.
In Pharo, you produce a "production image" following technics you already mentioned. But nothing prevents you to deliver an artefact including also the PharoVM (it is 2m large, after all), and you can prepare your apps to detect and open your production image (without having to ask for it).
It is about as practical with Smalltalk as with other languages: not very much. As soon as you create a somewhat larger application, you start depending on other libraries/applications being installed. If you compile them statically with the application, you have now created a much larger application that takes longer to download, and needs to be updated at least as soon as a security problem is found in one of the dependencies. If not, your application is no longer double-click startable.
There are two directions for solutions: web applications, and installers and package managers.
Squeak still maintains its one-click installer, allowing the same set of files to work on windows, mac and linux. Pharo used to have that too, but moved to having separate builds. The need hasn't been so large that the one-click build has been reinstated. It is mostly seen as useful to be able to carry around a cross-platform environment on an usb-stick. With the move to the 64-bit spur vm the dependency problems will lessen as more of the needed libraries will come pre-installed on those platforms.
Dolphin Smalltalk can produce a standalone .exe for Windows.
This is a key feature of the Pro version.
Your dream has been around since the mid-80's and it is called Smalltalk/X.
I am currently in a class that is developing applications in Objective-C and Cocoa. I was wondering if there was any way to build and compile Objective-C applications on Windows Vista. During class, we are able to use the Mac machines provided to us, but I was hoping to do some work outside of class, and I only have a Windows Vista machine available to me. I have installed GNUStep. I am looking for a GUI or an IDE that I could use. I have Eclipse, and I tried to install ObjectivEClipse, but that is only for a Mac machine too. Any other suggestions? Thanks.
The compiler is no problem, since gcc includes an Objectve-C frontend. You could simply install Cygwin and use it. the issue is about libraries.
The Cocoa system is very Apple proprietary; but it's a descendant from NeXTStep. For a while (when NeXT was even deeper in debts than Apple) it was named OpenStep, and available as a shell around the NT kernel. Around that time, the GNUStep project was started, and it seems it's still there.
Note, however, that any xxStep libraries gives only a NeXT-like GUI, very different from modern macs. Also, a lot of the newer capabilities are not only new GUI; but new APIs too and these won't be found there.
in short... it's easier to go with a mac.
GNUstep itself offers ProjectCenter, which is a take-off of Project Builder, the NeXTstep IDE that Xcode is derived from. It also maintains the Interface Builder knockoff GORM.
Also, you'll want to bear in mind that GNUstep is a bit limited compared to Cocoa (just because Apple has a whole paid professional development team working on Cocoa full-time and GNUstep does not) and GORM uses a different format from Interface Builder, so if you're taking a class, there may be some Cocoa assignments you won't be able to do with it.
Under the heading of desperation measures:
It's old school but if you have a friend with a mac, you could telnet into the mac and run the dev tools there. You would code in an editor on Vista and then up load to the mac to compile.
That would only let you see the results of command line apps but it would better than nothing.
If the macs in your school lab are accessible you could just screen share from your Vista box. That's another long shot.
Might be easier to beg, borrow or steal a Mac mini.
The Cocoa frameworks are only available on Mac. For anything else, you'll have to use GNUStep.
I'm starting to learn Objective-C and I don't have a Mac (and I don't have plans to get one), but as I see that Cocoa is a very good framework to develop in Objective-C, I want to know: Is it possible to develop using Cocoa in Windows and Linux?
Thanks.
I think that your best bet, if you want to use Cocoa, is to get a Mac. You really won't regret it. GNUstep is a neat solution, but it is impractical to distribute applications built using GNUstep, because (as far as I know), clients must have the runtime installed for it to work.
Cocotron is an amazing project as well, and in the future, it may be useful for you if you want simple apps to run on both Mac OS and Windows. But you would still need a Mac to use it.
If you are interested in using a language like Objective-C with a framework like Cocoa, but don't want to get a Mac, why don't you try web application development with Cappuccino and Objective-J?. Objective-J is an implementation of an Objcective-C-like language in JavaScript, and Cappuccino is a really amazing imitation of the Cocoa framework in Objective-J.
Some examples of what can be created using that framework are 280 Slides and the new, stunningly beautiful EnStore. That's not a perfect solution, and unless you are content to just do web applications, you should buy a Mac.
Take a look at Cocotron
The purpose of the project is to provide an easy to use cross-platform solution for Objective-C development. In particular, source code level compatibility with recent versions of Apple's frameworks (OS X 10.4 and 10.5).
The general goal is to provide complete support on any viable platform, the project is intended to be as portable as possible. However, most of the work at this time is focused on providing support for Microsoft Windows. In particular the NT based versions, 2000 up to Vista.
You can also run Snow leopard Server inside a virtual machine, like VMWare Fusion.
Apple changed it licence in 2008 to allow that, but only with server editions. I have personally used it with some success to deploy iphone applications (Although it was admitably a bit slow).
You will need decent hardware and preferably a dedicated hard-disk drive to be able to use it properly.
And considering the cost of vmware and osx server you might be better off buying a used mac.
I'm in the process of learning Objective-c but would like to run code snippets via some sort of emulator on Windows — preferably web based.
I want to understand Objective-C syntax and walk through common code examples, probably via some sort of console. I would probably leave any framework type learning for when I get onto my MacBook, at home.
I have done a quick Google with no success.
It depends what you mean. Objective-C can be compiled by GCC, so you can happily create Objective-C test apps on Windows. If you are talking about the frameworks though, which contain most of the power when developing on OSX then it's a no unfortunately. You can get libraries compatible with SOME parts from gnustep.org (and run them on Linux/BSD), but it's still not the full OSX "stack".
You can get OS X running in VMWare, but it's illegal, so you best bet is to pickup a cheap Mac that can run Tiger/Leopard and use that.
Looked at GNUStep?
Another possibility is to use Cappuccino.
http://cappuccino.org
It is a cocoa-like framework for javascript, and looks very similar to objective-c.
The language is called objective-j.
AFAIK you can use the GNU compiler to compile Objective-C, so that should be usable on Windows too. This should be sufficient to get you started with programming the language.
For Mac OS X however the language is only part of the equation, you will want to program against the libraries of Mac OS X, and for that you will really need a machine running it.
I'm not sure which libraries are present and which are not but you can run OS X Server in a VM (providing you have an OS X Server license of course). This would allow you to have a virtual Mac environment on your Windows system.
As has been mentioned above, there's no way to achieve what you want natively within Windows as the underlying system is obviously different.
Good luck.
There also is The Cocotron.
Greetings,
I want to write a small cross-platform utility program with GUI in it. What language/GUI-library should I stick to? Is it possible whatsoever?
This is gonna be a small program, so I don't want to make people download JVM or .NET Framework. Is it possible to develop it natively?
Update 1.
By "natively" I mean that the end result will be native code without intermediate layers like Java Virtual Machine or .NET Common Language Runtime
Update 2.
A FREE solution is preferable ;)
If you know C or C++ the first cross platform GUI framework I can think of are:
QT (C++, proprietary but free with the LGPL licensing)
wxWidgets (C++, the most complete and stable but also huge)
FLTK (C++)
FOX (C++)
IUP (C, simpler and cleaner than the ones above)
If you know Pascal, you can try freepascal+Lazarus. I've never used it, though.
The problem is: If you do not want to have a GUI but you do not want to ask the user to download an eternal API, Framework or virtual machine to run it in, be it TCL/TK, Java or QT etc. then you get lost pretty fast.
The reason is: You would have to rebuild all the (GUI) functionality those APIs, frameworks and virtual machines provide you with to be platform independent. And that's a whole lot of work to do... .
On the other side: The Java virtual machine is installed on nearly any operating system from scratch, why not give this one a shot?
You want to develop a cross-platform program natively? Uh...I don't think that'll work, mainly because that phrase is a paradox. If you write native code, it by its very nature will only run on the platform you programmed it for. ;-) That's what the Frameworks are all about.
So what you should do instead is use a very slim framework if your program is going to be so small. itsmatt's idea of Qt is a possibility.
WxWindows? Oh, it's called WxWidgets now: http://www.wxwidgets.org/
wxWidgets has bindings to all sorts of languages - python for instance, if your app is small enough.
Lazarus is great. GTK2 on Linux, win32/64 on Windows, WINCE on euh, Wince. It even uses Carbon on Mac (working on COCOA). Also easy to sell to your boss (the code is Delphi compatible)
How about Python using Qt or Wx and then using PythonToExe to make a 'distributable'
Thought will have to giving to the development to ensure that no native functionality is used (i.e. registry etc.) Also things like line breaks in text files will have different escape characters so will need to be handled
Which OS's do you have in mind when you say cross-platform?
As Epaga correctly points out, native and cross-platform are mutually exclusive. You can either write multiple versions that run natively on multiple platforms, or you need to use some cross-platform framework.
In the case of the cross-platform framework approach, there will always be extra installs required. For example, many here suggest using Python and one of its frameworks. This would necessitate instructing people to install python - and potentially the framework - first.
If you are aiming at Windows and OS X (and are prepared to experiment with alpha-release code for Linux if support for that OS is required), I'd highly recommend you take a look at using Adobe AIR for cross-platform GUI applications.
I agree with Georgi, Java is the way to go. With a bit of work, you can make your desktop application work as a Java applet too (so that users do not need to actively download anything at all). See http://www.geogebra.org as an example of an application with runs smoothly as a cross-platform Java application AND has a simple port to a web applet.
Two other advantages to using Java are:
They have extensive libraries for building the UI, including UI component builders.
The Java runtime framework is generally updated automatically for the user.
One disadvantage:
The version of Java installed on your end users computer may not be totally compatible with your application, requiring you to code to the lowest likely denominator.
Try RealBasic. Visual Basic-like syntax, targets Win32, OS X and Linux. I don't know any details about targetting Linux, but for any cross-platform development I've done between Win32 and OS X its been a dream.
http://www.realbasic.com
Edit: Generates native executables. There is a small cost - $100.
Have you looked at Qt?
Flash? It's installed pretty much everywhere.
If it "HAS" to be Desktop use Qt. Nothing beats it right now.
However personally I gave up on desktop and any UI based project I do is normally Browser/Server based. You can easily write a little custom server that listens to some port so the program can run locally with no need for your users to install Apache or have access to the net. I have a small Lua, Python and C++ framework I made for that purpose (Want to add Javascript for the backend with V8 :)
If you're going to look at Qt and WxWidgets, don't forget to also check out GTK+ !
I agree with David Wees and Georgi,
Java is cross-platformness par excellence. You literally write once and run everywhere. With no need of compiling your code for each target OS or bitness, no worries about linking against anything, etc.
Only thing is, as you pointed out, that a JRE must be installed, but it's quick and straightforward to do even for novice end-users (it's a matter of clicking "Next>" a few times in the installer).
And with Java Web Start deployment gets even easier: the user just clicks the launch button on a webpage and the application runs (if the proper JVM is installed according to what specified in the JNLP descriptor) or the user gets redirected to the Java download page (if no suitable JVM is found).