I might as well blog while I'm waiting

to see if Zend Studio crashes again.

I used to be fairly happy with Zend Studio, but these days it seems to be featuring as one of the banes of my working life. As a developer it should be the program I spend most of my time using (and so needs to Just Work), and indeed on my own system at home (smallish codebase, local files & webserver) it does. Usually.

In the office, however, we have a much bigger codebase, shared mounts for sandboxes (as per the ongoing series on this blog), and an occasionally slow or patchy network. This gives Zend Studio (both 5.5.x and 6.0.x) a myriad of ways and reasons to fall over or just seize up. To be honest, I'm not sure Java's a great language for an app of this complexity, but for whatever reason it will frequently just stop dead, fail to open files, or just ignore all input.

So, to work out how to get around this and actually be able to edit my files (with code completion, debugging, code lookup and all those things which make vim Not An Option), I've been trying to debug my way around the problem.

Firstly, I've been trying to work out if it really is the network that's the issue. So, remove that from the equation: read the files from a samba mount with no network latency; in other words, from a local samba server.

As I've recently received a higher-spec machine at work, with parallels supplied, my first step was to create a small internal ubuntu server with a samba share to see what happened.

What happened was that I discovered that ubutu 8.10 server doesn't run under parallels, although it installs fine.

So, I switched to the Ubuntu JeOS distro instead, which does run. A few apt-get's later and I have a local samba share. I check out our codebase, point a new project at it in Studio 5.5.1, open a file deep in the class tree, and do some other work for a while.

Result: ZDE seizes up and can't do code clickthroughs or open files. Great. So it's not the network. (I'm working on the basis that it's not my new intel 8-core mac, either). Maybe the virtual machine's too slow? Check out to local drive, perform same test, same fail. Ok, so ZDE 5.5 needs to be dragged out into a quiet alley and shot. I've suspected that for a while.

So, chuck out 5.5; try 6.0.1 (which I've tended to avoid as the interface, menu and naming is completely confusing, and it still falls down). And it turns out that I can load, edit and clickthrough a local project if I use a local folder as a project (acheived, uninituitively enough, by starting a new PHP project, and overriding first the file location and then the verification dialogue (and finding that in the manual was fun)).

[As an impromptu aside; ZDE 6 is modal. Very modal. It loves nothing more than to throw up an "information" dialogue that prevents you from editing, saving, or quitting. Except possibly for jumping to the foreground when you're working in another app and it wants attention.]

So, yeah... I can edit locally. Unfortunately, my dev server is my local box (yes, I could set it up that way for myself, but the live server is Linux not OSX, and I'm not configuring local servers for the entire team) and I need to save my files to the dev box. The good news here is that ZDE has a myriad of Remote Systems support; the bad news is that they're utterly baffling. FTP only is easy enough to understand, but then there's 'Linux' (which, last time I looked, was not a network protocol), 'Windows' and Unix (ditto), Local (which didn't sound very remote), SSH only (which turns out to mean SFTP), and Telnet Only (Experimental) which just sounds like bad news.

'Linux', btw, turns out to mean some weird perl/java hybrid server that you have to install on a linux server. Personally, I'd rather steer clear...

Having decided that SFTP looked the best bet, I thought I'd give that a go. Fairly easy (despite the interface's best efforts to confuse matters); set up a server, browse, select a folder and right-click to Create Remote Project. Wait while it refreshes, wait a bit longer while the progress bad gets stuck near the end, and wait while runs out of Java Heap space and crashes with an "Insufficient Memory. This advises you to refer to the "Running Eclipse" section of the readme.txt file; a quick glance in there shows that Zend have removed that section, and indeed most of the rest of the file. Might be nice if they updated their code to reflect this?

A quick google later and I find this page, which tells me to burrow into the depths of ZendStudio.app and edit 'eclipse.ini'.

Of course, that wouldn't do for Zend; they had to rename the file ZendStudio.ini. So, edit that instead.

Setting max memory up from 256M to 1024M crashes ZendStudio at startup. Setting it to 512M or 768M means it gets stuck even longer at the end of the "Create Remote Project" progress bar before crashing.

So, ok, abandon SFTP for now - let's try setting it up as a local PHP project on the Samba share. Set name, set directory, hit "finish", and it hangs - fortunately, only briefly. We can now open and edit files... but as yet, no code clickthroughs; the "processing" bar's spinning at the bottom of Eclipse and it's "building PHP Project" and "building workspace". Experience suggests it may do this forever, so I'm going for a cup of tea.

As suspected, it's got stuck at 4% in the depths of the Zend Framework.

Now what to try?

Erm, force-quit Zend Studio, restart it, and watch it all miraculously work, apparently? Ok, that's a complete anti-climax; maybe the extra memory fixed it. I'll update if it fails again.
Posted by parsingphase, 2008-08-22 11:56

Anonymous user



Contact Richard