Re: Rapid Turnaround - RESOLVED BUT RUNS SLOW -
Re: Rapid Turnaround - RESOLVED BUT RUNS SLOW -
- Subject: Re: Rapid Turnaround - RESOLVED BUT RUNS SLOW -
- From: Ricardo Parada <email@hidden>
- Date: Thu, 14 Feb 2008 08:53:08 -0700
Well, I found the mail where Mike Schrag talks about the slowness and
so I decided to turn on the PB.project generation in the preferences.
Then did a clean build. Quit and restarted Eclipse. And now it goes
faster. :-D The lines in the console about will locate resources in
'.../some/path' that were taking several second to print in the
console, one for each framework, now they simply don't print and the
app launches so much faster now.
So maybe that did it for me. I had no PB.project files and I had that
option for generating them turned off. So a clean build had the
effect of generating all those PB.project files for all my zillion
projects that this app uses. I also turned on .xcodeproj file
generation just in case. But maybe the PB.project generation was all
that was needed.
Thanks
On Feb 14, 2008, at 1:19 AM, Alexander Spohr wrote:
Am 14.02.2008 um 04:47 schrieb Ricardo Parada:
On Feb 13, 2008, at 8:38 PM, Ricardo Parada wrote:
I figured it out. It turned out that the superclass for my
application has this in there in the constructor:
this.setCachingEnabled(true);
So I just changed that to true and now it works.
Oops... I meant to say that I changed that to false and now it
works. So now the component definitions are read from the file
system everytime.
You can take that line out anyway. In development it is false by
default, in deployment true.
Now it seems to run slow. I seem to recall Mike Schrag saying that
was caused by some IPC (inter-process-communication) code in there
that is used by the rapid turn around stuff.
Usually not. You should not see any problems in development. It
_will_ be slow if you do that in deployment, as it loads the
template every time again from the disk.
Your problem must be something else. It could be ipc, but then you
have a wrong setup somewhere.
atze
On Jan 23, 2008, at 11:11 AM, Mike Schrag wrote:
I had disabled them (see other thread asking if they were needed
anymore). I figured that maybe this is what was causing my problem,
so I re-enabled the .xcodeproj, but not the PB.project file.
Turns out Rapid Turnaround needs the PB.project file to be there.
So the official story here:
WO has this sort of crazy package called com.webobjects._ideservices.
This is the code that implements support for your WO app talking with
your IDE. The implementation that is built into WO <= 5.4 does
something like:
1) talk to an xml rpc service running in the IDE to get a list of
projects
2) ... if that succeeds it continues to use this service or
3) ... if that fails it tries to read out of PB.project files
WOLips has a really bad partial implementation of the webservice in #1
-- You can turn this on and off in WOLips Prefs=>PB Server
Preferences. A major problem with this server is that it's SUPER
chatty. You'll take a huge performance hit in development with this
thing running. If you turn it off, but continue to generate
PB.project files, then your success hinges on how well WOLips
generates PB.proj's. Honestly I haven't seen in this code in so long
that I just don't recall what its state is.
So there's actually a secret #0 in this list, which is that I have a
new implementation of rapid turnaround that is designed for WOLips,
but it's based on source that I can't release (if I decompiled ......
which i don't ...... it might be based on decompiled code). This has
been submitted to Apple, but I'll let Pierre comment on if/when/
whether that will go into WO proper. I can possibly release this as a
binary-only jar in the meantime that people can drop into their
projects ...... That might work out.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden