Firstly, I saw some topics about these two but weren't my answer.
I'm looking for a good FPC(Free Pascal Compiler) IDE on GNU/Linux.
There are some IDE's like Lazarus and CodeTyphon. I need suggestion to choose one of those.
I've tried Lazarus once but all windows was separated. It looks messy and not interesting.
I would like to know what are the distinguishes between these two ?
I would like to know advantages / disadvantages each of those. Thank you
CodeTyphon is a distro of Lazarus, like Ubuntu and Debian are distros of Linux.
CodeTyphon comes with a large package of components and plugins, that otherwise you would have to google and download and install.
CodeTyphon have their own idea what are stable versions and what are not stable yet for both of FPC (compiler) and Lazarus(IDE). Whether their assessment is better or worse than upstream's Lazarus Team's, I don't know.
What about one-single-window plugin, it is work-in-progress and it doesn't seems to me it is ready for production use, no matter would you get it as part of CT or download and add it to vanilla Lazarus. However maybe it better works on Linux than on Windows, I don't know.
There were however issues with code legality in CT grande bundle. It is widely believed that Orca (if I remember the name) violates copyrights of glScene/vgScene, which also happened in early Delphi FMX releases but was fixed by EMBA later. There also were disputes in FPC forums/wiki about CodeTyphon pirating some open-source components. See answer by Peter Dunne below.
Your question is akin to asking the difference between Linux and Ubuntu. Lazarus is an IDE/component library, based on FreePascal (FPC). And CodeTyphon is a distribution of Lazarus and FPC. So CodeTyphon is just one way to install a functioning installation of Lazarus.
Lazarus uses the same floating window design as older versions of Delphi. Installing from CodeTyphon won't change that.
Myself and several friends highlighted several licensing issues with codetyphon
most of which could have been corrected by sourcing the included files from known good source and ensuring the correct license headers were included
PirateLogic refused to correct the issues which means they are using code in direct violation of the original license terms
The fact its open source code does not change the fact they are pirating the code by not including the correct license even after the issue was highlighted
I also found several instances of copyright code included which appears to be proprietary and not FOSS at all
They also changed the path & file names on some libraries so that source is no longer compatible with standard lazarus/component installs
This in my view is totally illogical
These 2 factors heavily undermine what was potentially the best FPC/Lazarus distro
Hardly professional
Lazarus can be a daunting installation process due to it's nature as a cross compiling environment. You don't just download an installer and click ok. A typical "installation" is actually a bootstrap FPC compiler doing a three-pass compilation of an "install". There are plenty of good installation scripts/methods from the official Lazarus/FPC team and in the community for a . But, understandably, the installation process is a skill in itself.
CodeTyphon is a a different/separate branch of an installer system, which is more of a utility suite/tools/third party code compilation library. If you want the simplest installation experience go with CodeTyphon. It has the nice graphical front end for managing the compiler. You can conveniently do the fancy stuff like build "cross-compilers" for almost every "target" operating system out there. It also is jam packed with hundreds of the best components/libraries pre-installed. It is a very actively maintained project and very professional. A whole lot of work is done for you.
Even if you want to be learn the low level compiler capabilities, CodeTyphon is a good place to start. It is written in FCP/Lazarus and is open source. Simply study it as "working demo app" and the other info on the compiler details. If you crash it, at least you don't have to learn to climb the hill. You get to get to start from the top and lose control on the way down. Start from scratch (and a three hour reinstallation) Hahaha
Lazarus also has a package "AnchorDock" which allows you to dock all the windows into one. Either install the anchor dock design package after installing Lazarus, or install Lazarus using the script at getlazarus.org which will do it for you.
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 extensively use Cygwin on a Windows 8 environment (I do not want to go ahead and boot/load Linux directly on the machine). I use the OCamlIDE plug-in for Eclipse and have experienced relatively no problems using this workflow setup.
However, I would like to use Batteries so that I may make use of use of its dynamic arrays among a few other interesting features that will speed up my development process.
I have tried this method: http://ocaml.org/install.html, but I get the following error:
$ sh ./opam_installer.sh /usr/local/bin
No file yet for i686:CYGWIN_NT-6.2-WOW64
What am I missing and how would I configure Cygwin so that it can accept the Opam installer? When I tried yet a different way of building Opam, I got:
'i686-w64-mingw32-gcc' is not recognized as an internal or external command,
as a Makefile error and reason for building failure. It seems something is wrong related to mingw32-gcc, what do I need to install and/or configure for my Cygwin to get it to compile/build things properly. I have wget and curl installed as well.
My overall question: What is the best way to get Batteries installed on my system with the minimum of time spent tracing all of its dependencies by hand? Is there a way I can just build the library module, such as BatDynArray and the includes:
include BatEnum.Enumerable
include BatInterfaces.Mappable
That way I can just call them directly in my code with open...;; and/or include...;;;
OCaml works beautifully on Windows with WODI, which is a Cygwin-based distribution that includes Batteries and tons of other useful packages (which are a pain to install manually on Windows).
I urge you to take a shot at WODI, which I believe to be an indispensable tool for the
rest of us, the forgotten souls, who have to deal with Windows.
First of all, include does not do what you think it does. open Batteries should be exactly what you're looking for. OPAM is not yet solid on windows (maybe Thomas could give an update on where things stand).
Frankly, I would recommend to install a linux on a VM, you should be able to get started with OPAM instantly then. Otherwise, take a look at this package manager for OCaml which focuses on cross platform support: http://yypkg.forge.ocamlcore.org/. I've never tried it myself however. The last package manger you could try is GODI, I'm not sure about its windows support though.
Finally, if none of these options work then it should be possible to install batteries from the source. All you need is OCaml and make. And if there are problems with this approach then you should definitely follow up on them either here or on the bug tracker because batteries does intend to support windows AFAIK.
Have a C++ source I probably can't build in Code::Blocks. If I use it as an editor, would it be helpful in gaining understanding of the code? (Like Intellisense).
How does it compare to Visual Studio in this respect?
How should I go about doing it?
Can it somehow utilize gdb information (When I run it in gdb, there is a lot of information available)
It is Linux gcc/Makefile based.
The main executable is in one directory, but there are many includes, libraries etc.
If I just included all sources I would get sources for other executables (with similar code).
I expect to increase my understanding about where things are located over time.
Note 1: This is Linux, but I can easily edit on Windows. And I am trying to build under Cygwin.
Code::Blocks sounds too light weight for your tastes. Try NetBeans. It has very good hinting tools, doesn't have the infamous copy+paste bug, Its easier to navigate files, and can deal with makefiles better then C::B. Additionally it has a nice interface for debugging, and an exceptional one for performance monitoring.
I would reccomend you install a linux distro through WUBI and forgo using Windows.
I have used NetBeans, Eclipse, Visual Studio, Code::Blocks, and CodeLite. I don't normally write software under Windows anymore, but when I did CodeLite was the most elegant one I found. Debugging was a snap (mingw + GDB), all the meta information about your project is stored in an sqlite db (which I think is a great design), and it supports makefiles.
I think NetBeans would work great as well, but definitely give CodeLite a shot.
http://www.codelite.org/
Our C++/QT desktop application for Mac, Windows and Linux needs an installer. I'd rather we have a single installer for all three platforms. I do know it's a bit tricky, I guess what I wanted ask is if a framework already exists for that (Java maybe?).
I'd really like to avoid having to write three different installers.
The link that Kyle mentions is pretty comprehensive, but I wanted to provide a bit more of information about InstallBuilder for Qt (Disclaimer, I am one of the developers) since most of the cross platform installation programs referenced there are Java-based. This requires bundling a JRE, etc. and adds a significant overhead that is not required with a Qt-based installer, like ours. It is able to generate wizard-like executable installers for all platforms from a single project file as well as native packages such as DEB and RPM. If you ship your software in DVDs, you can create a single multi-platform DVD that shares data across platforms but still have native launchers.
Having said this, since your application is Desktop-oriented, for the particular case of OS X if it does not require complex installation you may be better off creating a .app file and package it inside a DMG. Users can then drag the file directly to the Applications folder.
Finally, I wanted to mention that InstallBuilder is commercial, but we offer free licenses for open source projects and discounts for small development firms.
IzPack rocks: http://izpack.org. It is truly crossplatform, very lightweight, easy to master, and produces excellent results.
After fully integrating both Izpack and InstallBuilder into our builds (using Windows, OSX, and Ubuntu 14 build servers for testing purposes), I will say I believe InstallBuilder is well worth the money (and free for open source projects according to wojciechka).
Izpack is a bit slow, a bit large if you need to package a JVM, and has an amateurish user interface. Version 5 (release candidate 3) was also not generating uninstallers properly. That said, as long as you use a 4.x version and require a JVM anyway, it may be enough for your needs. The extension interface is not terribly easy to deal with, but is almost infinitely flexible. The Windows installers do not register with the Control Panel uninstaller list.
InstallBuilder has a great, fast UI in the produced installers and has a serviceable UI for creating installers. The XML is pretty easy to deal with, too. Downloads are about as small as possible. It also includes nice hooks for doing all sorts of custom stuff easily. The only slightly annoying thing I ran into was that the Windows server required that I manually add some configuration to set executable bits on the other systems' packages (other systems didn't require this configuration).
Note: I was using the three-platform version of standard InstallBuilder (not InstallBuilder for QT).
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).