I am trying to compile PhantomJS to add WebGL. Apparently it is possible because of:
post on groups.google.com
post on trac.webkit.org
However, I have no idea how to do this. I have looked in all the configuration for compiling and I tried and found nothing.
Should I compile QTWebKit separately with the necessary options and then compile PhantomJS with this WebKit?
I'm on Mac OSX Lion.
It would be really nice to have a bit of help.
As you well may know, Phantomjs has is no longer being actively developed.
I suggest you move to Puppeteer which uses Chromium: https://pptr.dev/
This was opened by ariya who also commented on the Google Groups thread as a GitHub issue.
According to this comment by a project collaborator on that issue:
That's not that easy. WebGL requires OpenGL. OpenGL requires XCB on Linux. That means that you will not be able to use PhantomJS in full headless environment. I doubt that this will be implemented in near future.
It seems to me like this is the final answer to the OP's question. The OP has not addressed whether SlimerJS would actually work in their situation.
Related
I am new to Qt. What I understand is Qt is porting webview from webkit. [Correct me if i am wrong]. and I could not able to find which version of the webkit is ported into Qt 5.0 or higher version.
Kindly suggest me how to find?
It's running on WebKit2, which specific version is a bit more tricky to find out, but you should be able to look through the Qt repository on gitorious to determine it. If I remember rightly it changes depending on how you've built Qt5 and where from.
Seems to be a 3-4 months old snapshot, see the git repo for the included commits.
I just started looking into TideSdk and noticed that when I "compile" (or package) a project (in Win-7), I get all of these dependecies which is actually the un-compiled source code for the app.
Is there any way to:
Have Tide SDK package a file to one executable
Not have the source code visible in any way, shape, or form in the final executable?
If none of those are possible, is there an alternative that can to these things?
We are working on a solution. There are a few possibilities. The only thing that is possible currently is to obfuscate your code using google closure library through a tidebuilder option.
I found this on google when trying to do something similar. It is annoying but seems to work.
http://coffeecone.com/post/36127491095/howto-single-exe-for-tidesdk
I use the application virtualization app Cameyo for this purpose. http://www.cameyo.com/
I am trying to build QtCore.lib and I get this weird error.
PRJ0019: A tool returned an error code from "MOC kernel\qtimer.cpp"
I am able to build qtmain.lib but not able tp go any further.
moc.exe is available in bin folder and the path is added to my PATH.
kernel\qtimer.cpp file is also present in corelib folder.
Any help in this regard will be appreciated. I am building with Qt-4.5.2 source.
In Qt 4.5.2 moc.exe has some issues. An email I sent to Qt Support mentions it moc'ing files that were not modified. It could have further issues, which could be related to what you are experiencing.
Sorry I can't recall the exact details. To make things worse the link Qt Support had sent me at the time is broken.
They had suggested using 4.5.3. I think we ended up staying on 4.5.1, which we are still using today, although the move to 4.7.x. is occurring as I write this. :)
How to save firebug changes using Eclipse (Windows)?
I found here that it's possible to save firebug changes if we use Eclipse and FireEclipse
Is anyone using this combination successfully? Can anyone explain the step of Installing?
I'm on Windows7 64 bit
And if FireEclipse works with Eclipse then Will it also work with Aptana port of Eclipse?
First, whether it will work on Aptana? Yes, it should.
Now to the main question: The Fireclipse site claims contrary to what the answer you have linked to cites: the FE site claims that it mainly helps in debugging javascript through Firebug and Eclipse consoles (nothing about exporting/saving CSS changes).
Also, I wouldn't really recommend going with this plugin 'coz it hasn't been updated in a while. According to SourceForge (where the source of this project is hosted), Fireclipse was last updated 2008-10-22. Unless, you are still using Firefox 2 and Eclipse 3.2, you should avoid this plugin.
Try some of the other tools listed in that thread, for example, FireDiff sounds promising.
This is how i save my firebug changes.
https://addons.mozilla.org/en-US/firefox/addon/firediff/
Hope this helps.
I come from UNIX world, I'm quite familiar with Linux, Solaris, Cygwin
and MinGW development. Recently I ported one of my
big projects (cppcms) to support MSVC,
including building static and dynamic libraries with CMake.
And I get all the time absolutely weird issues:
I had CMake build issues because Windows programming
lacks naming convention
for import and static libraries.
Now I discovered that I should use different versions of ICU (debug/release builds) according to the
actual build I do (Debug/RelWithDebInfo -- should use Debug ICU, Release release ICU) and so I should
change actual conventions for searching libraries according to debug/release mode only under MSVC.
Otherwise application just would not start giving a error on missing DLL.
I don't have any such issues under Mingw or Cygwin with GCC, Open Solaris with Sun Studio or Linux with gcc or intel compilers.
And I still have numerous wired issues and wired bugs and very strange behavior -- even some trivial things do not work
under MSVC builds, when everything works absolutely fine under Solaris/Linux/Cygwin/Mingw using GCC from 3.4 up to 4.4,
Sun Studio and Intel compilers). But not under MSVC.
To be honest, I have no idea how to deal with Last one! Because it looks like for me more like environment issues.
I know that the question is not really well defined. I think I'm quite experienced
developer and I know how to write portable and good C++ code. But using Microsoft native
tools drives me crazy with issues I just don't know how to solve.
Question: What should experienced Unix programmer with quite good base in Win32 API should know when it
starts using Genuine Microsoft Tools?
P.S.: Can someone explain why "Release With Debug Info" requires Debug version of MSVC runtime? And why there two versions of runtime exist at all?
P.P.S.: Please note I don't have issues with Win32 API, in fact Windows GCC build works absolutely fine.
Clarifications:
I'm looking for pitfalls that programmer that come from Unix world would may fall into.
For example, when moving from Linux to Solaris: make sure you compile code with -mt or
-pthreads when using multi threaded programs, linking with -lpthread is not enough.
P.S.: Can someone explain why "Release
With Debug Info" requires Debug
version of MSVC runtime?
It doesn't.
And why there
two versions of runtime exist at all?
Because the debug version does more error checking.
And I still have numerous wired issues
and wired bugs and very strange
behavior -- even some trivial things
do not work under MSVC builds,
* What am I doing wrong?
Not telling us what "wired issues and wired bugs and very strange behavior" you get.
* Where should I start?
By telling us the specific errors and problems you encounter.
* What do I miss?
Reading the documentation and learning the tools.
If your question is "What do I read to become a good Windows programmer?" then my answer is: Everything from Jeff Richter, as a start.
There is no magic bullet which will automatically make you an experienced Windows developer. Windows is a very different land compared to Unix. There are lots of quirks, weird behavior, and stuff which is just plain different. The only way to get out with your sanity intact is to tackle the transition one small problem at a time. Concentrate on a specific problem and try to understand the problem. Don't just "get it to work", but really understand what is happening. A good book about Windows programming will help.
There are huge amounts of Windows knowledge and experience accumulated in the SO community, but the only way to access it is to ask concrete questions about specific problems.
The release and debug versions of DLL's use different ways of allocating memory, that is why it is not advisable to mix release and debug versions. If you allocate something in a debug mode DLL and pass it back to the application which was compiled in release mode you may get into trouble.
In the case of your naming issues you may want to have different directories where you place your static / dll's. You can do do this in visual studio by using the configuration manager, not sure how it is under the express version.
I think you need to try and actually understand the new toolset rather than just try and squish it into your current understanding of your existing tools. For that, the best way, IMHO, is for you to try and start to use Visual Studio as Microsoft intended and then once you can build a simple project in the IDE you can move to building it using your preferred make system but do so with an understanding of how the IDE is using its make system to set things up for that build (which WILL work).
So, for example, for part 1 of your question you want to create a simple static library project and a simple dll project and look at the linker options tabs. Jump to the 'Command line' view and you'll see that a DLL uses the /OUT linker option to set the name and location of the dll file and the /LIB linker option to set the name and location of the import library. With a static library only the /OUT option is used and it indicates the name of the static lib. It's true that if you're building a static lib and a DLL from the same source and you have both the /LIB for the dll set to MyCrossPlatformCode.lib and /OUT set to MyCrossPlatformCode.dll then you may have problems if you also build a static lib with an /OUT switch of MyCrossPlatformCode.lib... Simply don't do that; either build the static libs to a different output directory (which is what OpenSSL does), or, better (IMHO), mangle the names somewhat so that you have MyCrossPlatformCode.lib/.dll and MyCrossPlatformCode_static.lib (which is what STLPort does).
Note that you might also want to mangle in (or account for) building with different versions of the Microsoft tool chain (so you might end up with stlport_vc8_x64d_static.5.1, perhaps).
An alternative approach, if you really can't face the thought of understanding your toolset, is that you could take a look at some of the popular open source systems that build quite fine on Windows and Unix systems; OpenSSL and STLPort for a start, perhaps.