On Sun, Feb 13, 2011 at 08:31, Ivo van der Wijk <[email protected]> wrote:
>
> I've somewhat learned that by now. The build version is "lean" and
> fast and actually usable, but not very useful for development. I don't
> mind an optimized compressed qooxdoo library, but it would be nice if
> my own code remains readable/debuggable. It's somewhat all or nothing
> right now
You can make the build version debuggable, and that's what I tend to do when
I am forced to develop using a server-based version. (I try to separate my
gui and server-side development by testing the gui code on its own; then
writing the server side and testing it with RpcConsole (I use JSON-RPC, and
RpcConsole allows one-shot or scripted testing of remote procedure calls);
then when both of those are working independently, I switch over to issuing
the requests from the gui code to the server code. At that point, there are
many fewer possible sources of error, so debugging is reasonably easy.
The way you create a debuggable build version is to turn off optimization.
There are four types of optimization, and it's possible you don't need to
disable all types (you can read up on it) but to disable all of it, add this
line to the top-level "let" section of your config.json:
"OPTIMIZE" : [ ]
then do another "generate.py build". You'll find that it then generates a
single file with everything, but the file is readable and debuggable.
Hope that helps.
Derrell
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
