This is still needed so that injectJs() methods work with CoffeeScript
and so that the main script file can be in CoffeeScript.
It causes duplication of code and some consideration is needed as to
how we could refactor the old inject code so that it uses modules
underneath. Lots of the module functionality written in JS could replace
the old C++ code (CSConverter, most functions in Utils).
http://code.google.com/p/phantomjs/issues/detail?id=47
Instead of using a C++ wrapper, I used a Node version of CoffeeScript
with a small JS wrapper (src/modules/_coffee-script.js). This way, since
the module system is similar enough to the Node.js module system, I only
need to require CoffeeScript in bootstrap.js and all the support for
.coffee is added by CoffeeScript itself.
To include a newer version of CoffeeScript in the source tree, see
tools/import-coffee-script.sh.
http://code.google.com/p/phantomjs/issues/detail?id=47
nativeRequire() has been refactored so that native modules are also
wrapped in Module objects. Additionally, native modules are also
cached and included in stack traces if an error occures inside them.
Phantom::loadModuleSource() has been renamed to
Phantom::readNativeModule() so that it's clear that it's used only to
load native modules.
Finally, all the require() code has been move after setting error
handlers in bootstrap.js so that if an error occurs in the require()
code, the stack trace is printed.
http://code.google.com/p/phantomjs/issues/detail?id=47
Instead of trying to use sourceId to determine what module threw an
error, we now load module's source code using modified
QWebFrame::evaluateJavaScript and leverage PhantomJS's stack traces.
http://code.google.com/p/phantomjs/issues/detail?id=47
Most of the tests passed after merging almost unchanged phantomjs-nodify
code, some needed small changes. The one that is still failing is for
CoffeeScript modules.
http://code.google.com/p/phantomjs/issues/detail?id=47
http://code.google.com/p/phantomjs/issues/detail?id=599
Squashed commit of the following:
commit 2cdcf8a47567f3c067958383843cccf858af531c
Author: Jon Leighton <j@jonathanleighton.com>
Date: Sat Jul 7 19:37:38 2012 +0100
Make lib-bundling/brandelf optional in deploy/package.sh
This configuration has had some problems and we don't wish to use it in
the official packages.
Enable it with --bundle-libs.
commit 2a2155a4e1f5873aa8624859cead9d66750747f4
Author: Jon Leighton <j@jonathanleighton.com>
Date: Sat Jul 7 19:24:40 2012 +0100
notify user if upx is missing
commit 9656a99df0ff101150276dc88e0127f68041f617
Author: Jon Leighton <j@jonathanleighton.com>
Date: Sat Jul 7 19:23:36 2012 +0100
stripping symbols after upx probably doesn't work, reorder that
commit c5f425dc17069c89e7d2ff274309006c728ffab4
Author: Jon Leighton <j@jonathanleighton.com>
Date: Sat Jul 7 19:17:07 2012 +0100
fix logical fail
For some reason, it seems that checking CONFIG(static) inside
src/phantomjs.pro is not reliable. That caused the STATIC_BUILD define
not to be set, and hence Q_INIT_RESOURCE would never get called in
main.cpp.
Instead of using Q_INIT_RESOURCE, let's just compile the resources
directly into the phantomjs binary. This means we don't need to detect
whether Qt is linked statically or dynamically.
https://code.google.com/p/phantomjs/issues/detail?id=430
We are linking against e.g. libQtCore.so.4 rather than
libQtCore.so.4.8.2, and this affects symbol generation. (I am not sure
if this changed at some point, but this change should make it generate
the correct symbol files regardless.)
Also makes it less dependent on the Qt version.
Debug mode turns off all optimisations. This make PhantomJS considerably
slower.
Instead, we build in 'release' mode, but generate debugging symbols at
the same time.
This may present some problems analysing crashes, if the optimisations
make that difficult. However, in my testing I was able to get useful
debug output even with optimisations enabled. So we should see how we go
- if it becomes a problem we can produce seperate debug binaries with no
optimisations.
https://code.google.com/p/phantomjs/issues/detail?id=599
This provides support for compiling the breakpad client into PhantomJS,
and generifies that Linux packaging scripts so that they also apply to
OS X and automate the symbol generation.
Building the Breakpad tool programs seems to be less than
straightforward on OS X, and documentation is poor. We have managed to
produce tools/dump-syms-mac.pro which allows building the dump_syms
program for dumping the debugging symbols. This needed a couple of
modifications to breakpad in order to compile successfully.
We have run out of time to work on making the minidump_stackwalk program
build. However, this is solely a developer tool and so it can wait until
after the 1.6 release before we complete this work.
Testing is welcome!
https://code.google.com/p/phantomjs/issues/detail?id=576
When console.error was called, there was a segfault because it was
treated as an uncaught exception, but did not have the correct stack
trace information (I am not sure why, but still...)
Now that we are generating the stackTrace in WebCore::reportException,
the MessageType gets set correctly, so we can use this to differentiate
between uncaught exceptions and other messages.
https://code.google.com/p/phantomjs/issues/detail?id=47
Ariya Hidayat