Blog post "Editing Delphi Code on a Mac" at http://blog.marcocantu.com/blog/2016-january-editing-delphi-code-mac.html -- Really interested in feedback, corrections, impressions and the overall usefulness of an "official" effort in this direction.
Blog post "Editing Delphi Code on a Mac" at http://blog.marcocantu.com/blog/2016-january-editing-delphi-code-mac.html -- Really interested in feedback, corrections, impressions and the overall usefulness of an "official" effort in this direction.
http://blog.marcocantu.com/blog/2016-january-editing-delphi-code-mac.html
http://blog.marcocantu.com/blog/2016-january-editing-delphi-code-mac.html
And what about an OSX version of DCCOSX.exe and DCCiOS*.exe ? :D
ReplyDeletePaul TOTH Moving the entire toolchain (compilers, linkers, MSBUILD, etc) on a Mac is a totally different can of worm. It would be easier to do some remote invocation, like an "inverse PAServer"... but still a huge effort, I totally doubt if worth.
ReplyDeleteI-Pascal is worth to be on the list: http://www.siberika.com/siberika/
ReplyDeleteI would love to see Delphi itself on the Mac - cut-down, sure, but code editor, form designer, and compiler/debugger. I only use Windows to use Delphi. It's 2016. Something doesn't add up.
ReplyDeletePaul TOTH Marco Cantù For running the command-line compilers, you may use https://www.winehq.org/docs/winelib-guide/winelib-getting-started (I remember the Kylix IDE used such a trick), or even write your own version of the Windows API interceptions, just as https://crosskylix.untergrund.net did.
ReplyDeleteLast but not least, for editing pascal code under OSX (or almost any platform), you may just run the Lazarus IDE...
ReplyDeleteA. Bouchez AFAIK "KCC" (Kylix compiler) was a Linux application...and CrossKylix let it run under Windows ;)
ReplyDeleteCan WINE be used under MacOSX to execute DCCOSX.exe ?
A. Bouchez They could release a dccosx binary that runs on OS X without something like Wine if the would want to, but that alone does not bring them benefit and so they do not do that. Actually they ship already a camouflaged OS X compiler and the users are just not smart enough to utilize it. Another option is to use the compiler on Windows via telnet. No, I am not going to expand on any of these both options.
ReplyDeleteJust in case you didn't know, the Latest Lazarus 1.7 from getlazarus.org now gets a "docked" window layout (as opposed to the Delphi 7 old style layout).
ReplyDeleteThe OmniPascal language service currently runs on Windows only. Please let me know if you really want to use it on a Mac and vote for it here: https://bitbucket.org/Wosi/omnipascalissues/issues/6/add-rich-language-support-for-mac-and
ReplyDeleteThe development is currently focused on supporting all Delphi language features.
Help me prioritizing the backlog items.
Uwe Schuster Please don't drop interesting info and then say you won't expand! Are you saying there is an OSX build of the compiler already, and it's shipped? And that the compiler has a telnet interface, or do you mean that one approach to using it would be to run on Windows and have a remote command line to control it?
ReplyDeleteDavid Millington Porting the compilers to other platforms is one thing. Presumably a fair amount of effort but orders of magnitude simpler than porting the IDE. A sprawling VCL app with parts implemented in Delphi .net, Visual J# (whatever that is) and so on.
ReplyDeleteIf Embarcadero spend the time to re-write their IDE so that it runs on Mac then they will have not to do something else.
Obviously only Embarcadero can definitely make the judgement call on the trade offs here but I believe that there is an immense cost of making a cross platform IDE for negligible gain.
David Heffernan well Macro told about crossplateform editors...without a crossplateform DCC, they can only use FPC...
ReplyDeleteBeside that, a crossplateform FMX IDE would be a great demonstration of the features of this framework, and a good oportunity to fix one bug or two.
Paul TOTH Wave a magic wand then, and let's see if one materialises. Otherwise, some serious development needs to be done. Which takes development resources away from other things. So, Emba would have to decide that this is of sufficiently high priority.
ReplyDeleteAlso, I spend lots of time in a code editor that is not an IDE. Not all tasks require an IDE.
Trolledge also compiles to Android (and probably IOS) for Android 12 inch tablets and Ipad Pros. Just sayin'. Would cost a few hundred dollars a month to move it forward. Things like syncing projects to Dropbox, PAServer style compiler integration for DCC/FPC/SMS/DWScript, better plugin support, and better mobile support would be on the list. It also has paxCompiler built in which does Object Pascal scripting on all platforms and can compile it's own EXEs on Windows if it were enabled.
ReplyDeleteEli M Very good point about Trolledge.
ReplyDeleteMarco Cantù If you want my feedback, I don't want to see Emba spend any development resources on this. Emba need to focus on the core quality and functionality of their product. Resources spent on x-plat code editors would seem to me to be a waste.
ReplyDeleteBetter to spend resources on more important things, particularly FMX which needs some attention. I develop for the Mac OS and have no problem editing and compiling on Windows and passing the binary across to try Mac, works ok for me. I can see having just a Mac editor would make development easier.
ReplyDeleteIf the goal is to expand the Object Pascal userbase by reaching younger developers with a free Object Pascal tool that leads them to Delphi it may be a good idea. DroidEdit has
ReplyDelete1,000,000 - 5,000,000 installs on Android. https://play.google.com/store/apps/details?id=com.aor.droidedit&hl=en Other Android/IOS editors have hundreds of thousands of downloads. Targeted at existing Delphi developers it may not be so attractive because everyone already has their favorite editor. GetIt or Delphinus could be integrated to provide the Delphi trial download.
The comments about spending development resources on other things like FMX are interesting, because porting Delphi to Mac would involve some serious "dogfooding". Consider how bad WPF was until MS used it in VS, when suddenly lots of bugs got fixed.
ReplyDeleteI still think in 2016, and five years after a Mac compiler was introduced, it's silly I need to fire up Windows to use Delphi.
Atom is fantastic. I have been using it for about a month now. As well as all the features I need, it's quick and it doesn't use a lot of memory
ReplyDeleteHere's one thought: these thin editors, like VS Code and Atom, make sense on mobile. I can easily see pulling up an iPad and browsing a project, compiling it remotely, etc.
ReplyDeleteThe Mac is a first-class computer, though, and it should have a full development environment.
Paul TOTH Yes, I know it was a Linux ELF - which executable was call "dcc" by the was. Just to state that it is possible to use a similar technique to "fake" OS APIs to run a command line tool. This is what WineMake does, on Linux, but also on Mac OSX.
ReplyDeleteOf course, all this is theoretical, and not even worth the effort...
David Millington "compiling it remotely" - Isn't that similar to what CI is? ;)
ReplyDeleteI agree with those that say it would be a waste of resource - more of a "nice to have" than a "need to have". FMX still needs stability - the VCL "just works" from version to version - not FMX. A server-side capability that would be taken seriously for enterprise-class systems would also help - the promised Linux version offers a route to that. And of course a 64bit OS X toolchain...
ReplyDeleteI use a Mac for everything other than Delphi (which I run in VMs). Given finite resources, I'd rather they improve what we already have than give us something on the Mac (much as I'd be using it in a heartbeat).
ReplyDeleteIf I could work with FMX and VCL forms in an IDE on the Mac desktop, running on the Mac and mobile devices from the IDE and just deploying via a reverse PA-server to run the Windows binary somewhere, that would be great.
But I'd rather see them spend more effort on FMX itself, and improve what we have right now to be honest.
Hmm, I find remote debugging from Delphi in a Windows guest to a OS X host to be far more pleasant than using Lazarus natively on the host itself. Or in other words, to those wanting a 'lite' Delphi IDE running on OS X: for me the existing solution works very well, and I'm struggling to see what benefit this alternative would actually provide.
ReplyDeleteDown vote for a Mac IDE.
ReplyDeleteUp vote for FMX stability, core product improvements and quality.
I'm surprised at many of the comments here and on Marco's blog (the no-don't-support-Mac ones.) To me they show a great lack of vision, or even of awareness of coding in 2016. I know many people here may use Windows and Mac users may be a minority, but is a situation where a cross-platform development tool exists on only one platform, and people use that platform in VMs only for it, really normal or acceptable for the majority of coders?
ReplyDeleteI feel like people here say No because... well, I don't know, but there seems a vast difference in view of the IT world to my view. I'm really worried that Marco Cantù will listen to them. We have enough naysayers in Delphi as it is; do we need more about something that might actually be a leading Delphi feature again? Do we collectively have so little awareness of IT in 2016, or vision for where the product might be?
David Millington My personal view is that it comes down to a matter of priorities. I think we all understand and respect Mac as a powerful platform which is perfectly suitable for many development situations, but maybe not all. Delphi has always been a Windows based product and for EMB to move its limited resources to create a Mac IDE would IMHO be a frivolous R&D exercise given the many competing priorities it currently has. As most have already said, core functionality, stability of releases and FMX enhancements/fixes would seem to be the overwhelming issues to be addressed.
ReplyDeleteThat said, if EMB can remain focused on these things for the next couple of years, build a more stable and solid foundation, then I think you would find more community support for these speculative R&D activities such as a Mac IDE. However to change their focus now would surely cause harm to Delphi and EMB at such a critical time when big questions are already being asked. There's the old saying that long after the price is forgotten the quality is remembered - I think this really applies to EMB right now and they should address the basics and let the future take care of itself.
I don't think we are naysayers or doomsdayers, but we have to be realists and hope that EMB makes the right decisions for our collective futures. In a time of unlimited possibilities it remains ever so critical to sharpen our focus to that which is truly important.
Since I am not a Mac user, I don't really care either way but as David Millington said above:
ReplyDelete"Consider how bad WPF was until MS used it in VS, when suddenly lots of bugs got fixed."
Wouldn't/Couldn't the same be applied to FMX - A lot of bug fixes, and possibly features, be done?
If Idera made a cross platform editor (and I am not just talking Mac but Android, Linux, etc), just think of the publicity of having a cross platform editor for making cross platform applications...
Having said that, there is also the ability to improve and enhance the OTA for third-party add-ons, while the rewrite is occurring.
So I can see there could be more benefits in having cross editor IDE platform than just having a Mac platform... but it would take resources.
I think it's the kind of thing that could be a two-person skunkworks project for a year. That's not a huge amount of resources, given their size.
ReplyDeleteRick Wheeler I understand your view about priorities. I disagree though about this: "Delphi has always been a Windows based product and for EMB to move its limited resources..." - IMO that's not a good reason. First, because it's always been Windows-based is not a reason for it to be Windows-based in the future. By that same logic we'd never have got cross-platform compilers. Second, resource planning can be /very/ short-sighted. "What do we need this quarter, this year?" Well, expanding the product is a longer-term thing - you start now, get something out in a year, see the benefits in two or more. It can only fly if you have management who look to the future a long way.
So for that reason I think this comment "if EMB can remain focused on these things for the next couple of years, build a more stable and solid foundation, then..." is the wrong direction. You can always put something off for a couple of years. In a couple of years time, I think you could still write the same comment. So, at some point you have to say No: now is the time. We should have one already. Delphi should be a well-known, respected platform. Windows-only doesn't cut it. We already know this from all the compilers. The IDE is the logical next step. And waiting for years is absolutely the wrong move. It is an easy move, a simple move, a seemingly and perhaps falsely safe move, but the wrong move.
I do have very high expectations for Embarcadero and I do want a sense of vision in the product. I'd settle for not having a Mac version if there was some equally great and amazing move forward that would resound in the tech industry. In a sense, arguing for things like this is not because I want something specific, but because I want /something/ - some visionary, clear, forward-looking movement in the product. I know they have plans, and they're good plans. I just want bigger plans, plans that are (IMO) bigger in scope.