Setting up Fire

Elements Fire
1

Setting up Fire

Updated July 24.

Welcome to Fire. this post will run you thru what’s needed to get set up, Now, remember that Fire is still in beta, and the first place that shows is in actually getting it all set up so you can fully use it. Here’s the steps:

When you download Fire, it will be a zip file. Inside that zip file, you’ll find two things: Fire.app and a second zip, called “ RemObjects Elements - Mac Zip Distro - X.X.X.X.zip ” or some such thing.

Now, the .app itself will be ready to run as is. Just copy it to your /Applications folder and run it. Fire is a native Cocoa app, 95%, but it does (for now) use Mono to host the compiler, so that it can provide IDE smarts such as code completion, without us rewriting all that in Cocoa. You don’t need to install Mono separately for this, Fire comes with its own copy of 64-bit Mono inside. So you should be able to just run Fire.app and get the full experience (limited as it is for now), except for one thing: to build.

Right now, Fire just shoots off to xbuild, Mono’s implementation of MSBuild, and for that it uses the regular, global Mono install. So in order to build apps from inside Fire (and/or the command line, as well), you need to do two things:

  1. install Mono 3.x from http://www.go-mono.com/mono-downloads/download.html. (someone has reported they needed the full MDK download)

  2. install and register the Elements compiler with Mono. To do this, extract the .zip mentioned above to a permanent location (i.e. the place where you can/want to keep these files, don’t just unzip them to ~/Downloads and then delete the folder when done), go to the folder in Terminal.app and run ./install.sh. (this last step will add some compiler dlls to the Mono GAC, and create some XML files that will help the compiler find references.

The nice thing is that you can update the compiler and Fire independently from each other. So you can just grab a new compiler .zip (or indeed take the compiler .dlls from the Elements install on windows), install it, and the next time you hit Build in Fire, it will use the new compiler.

Please also do note that if you ever update Mono, that clears it’s GAC, so you will need to rerun the ./install.sh script afterwards.

Also note that you will need to have Xcode 5.1 installed (get it here) and have started it at least once.

What about CrossBox?

I’m pleased to say you won’t need CrossBox to build from Fire (or the command line), as the compiler chain has been updated to support “local” builds, when run on Mac (in Fact, current Fire doesn’t even expose access to rmeote CrossBoxes currently, and may not for 1.0). Just select “Local” form the CrossBox menu, and the build will happen ll locally, w/o network traffic.

That’s a lot of manual setup!

Yes. did i mention this is still pre-alpha? :wink:

The plan is that When Fire RTMs (probably even when it hits Beta for everyone), the external Mono and compiler install will no longer be needed, and Fire.app will have everything inside to work. Also, longer-term, I want Fire to not depend on Mono at all (except maybe for debugging Mono apps), as we’re switch to our internal InfraRed technology to run the managed parts natively. But let’s not worry about that just yet.

But enough talk, lets start cooking!

2

Ooohhhhh!

3

Or even - Aaaaahhhh! Well, after all, we seeing Fire work(s) :wink:

4

So will the compiler always be .NET-based, then, or will there be a native OSX binary eventually?
And - just to be clear - I can always copy all of the .dll’s from a build of Oxygene for VS (e.g. a beta) to the folder where I initially put the .dlls you shipped with Fire, re-run ./install.sh, and be good to go?

5

Any particular reason why tab indents are not selectable (grayed out)/configurable for Oxygene but only for C#?

6

It will always be .NET-based. It might eventually not require mono anymore, thanx to Infrared.

should be, yes. i’ll also start making that compiler .zip file available with all beta downloads.

First. this isn’t hooked up yet anyways, as you probably found out. Secondly: is there really anyone insane enough to use tabs wit Pascal? :wink:

7

G-d no - but I typically use 3 spaces instead of 2 for Pascal coding and some editors do that (space-based) indenting for you.

Thanks for the compiler answers.

8

oh, god, that’s even worse :wink:

9

Actually, I like it better. But it means that in Fire right now I have to look at stuff like this (i.e., those red lines since I’m using 3 spaces and the default spacing is set to 2). You would probably not find my code style familiar (it’s not like the traditional Borland style from years gone by) but having 3-space indents works very well with it. My colleagues and I have used this style for about 15 years now…

And btw will the dots always appear or will they be configurable?

10

Noted. i’ll look at exposing the option.

11

I see that I can now add a 3-space indent in Preview 2 - thanks. However, I still get the red lines even when I’ve got a multiple of 3 space at the start of the line.

12

As per the change log notes, you cannot change the tab setting yet (you cna change the combobox, but it will have no effect). that’s coming soon, but needs some more refactoring than i had time for for now, given how tabs are handled on a file buffer level, and are not just a display attribute for the editor.

you CAN however disable “draw tabs” to get rid of the red lines, for now.

13

Sorry - my misunderstanding. I thought you literally meant tabs, but I guess you meant “tabs or space indent.” No worries.

14

Both settings — indent size, and “tabs vs. spaces” are currently not hooked up yet, i’m afraid.