After Googling, I found a lot of HipHop documentation, but plenty was posted between 2011 and 2013.
Earlier this year was launched a new version of HipHop that even supports Drupal and includes a lot of improvements...
I've always used the Zend Guard to deploy my commercial applications, but now I started to consider seriously the use of HipHop in production, but here comes the question:
We can run an application using only the bytecode HHBC (Without .php source code)?
Follows the reference of my research
https://github.com/facebook/hhvm/wiki/FAQ
The question may seem very obvious, but it is not so easy to find this answer in the project documentation.
Thanks in advance!
Well, yes and no.
HHVM has a so-called RepoAuthoritative mode in which the HHVM will no longer check the existence of the PHP files or how up-to-date they are; instead, it will retrieve the HHBC directly from its cache.
Theoretically, you can follow these steps:
pre-generate the HHBC for all your PHP files and insert that HHBC in HHVM's cache. This is the so-called pre-analysis phase (if you ever see it in HHVM documentation, this is what they mean by it)
turn on RepoAuthoritative mode (it's just 1 line in HHVM's config)
delete your PHP code
This way your PHP applications will run just fine without the source code being present. Doing a server restart won't change this since HHVM's bytecode cache lives on disk (it's implemented as an SQLite database).
However, it will be kind of a headache if you:
want to change something in your code. You would have to copy your code, make the change and repeat the pre-analysis phase.
want to upgrade HHVM to a newer version. HHVM uses its build ID as part of the cache key so, if you upgrade it, the bytecode cache becomes unreachable and, since you'll be running in RepoAuthoritative mode, your application will be reduced to a bunch of HTTP 404 errors. To fix this, you would have to repeat the pre-analysis phase as well.
Bottom line: no upside, big downside. There's just no point in doing it.
PS: I hope I answered your question. It's also possible that I misunderstood what you asked; if that's the case, please let me know in a comment.
Related
Can anyone suggest me the steps to apply patch (patch upgrade) on IBM Informix database. Please suggest the best practices available. If possible share me the URL or any documents.
It's a big topic. A good deal depends on how the server is currently set up — there are setups that make it hard and others that make it easier. Another major factor is your level of risk averseness. You need to make an assessment of the amount of down-time you can afford. Also, how often have you practiced recovery from backups — it probably won't be necessary, but you need to cover your bases.
I am assuming you're using Informix Dynamic Server, not Informix Standard Engine (SE). Upgrading SE is much, much simpler.
Preparation
Before you install, make sure you have a good, recent, level 0 archive of your system.
Also, make sure you know where your software is installed, and which disks and files it uses.
Route 1: Simple, but potentially risky
Make sure you have a backup copy of $INFORMIXDIR.
Take down the servers that are currently running using this $INFORMIXDIR.
Install the new version of the software over the existing software.
Restart the server
Why is this risky? At issue is what happens if anything goes wrong, and also the length of time the server(s) is (are) down. If you bring up the server and decide something is wrong and you wish to go back to the old version, you have to take servers down, reinstall the old software (copy off the backup?), and then bring the (old version of the) server back up. This takes time. This isn't often a problem, but it has happened on occasion over the last couple of decades.
Route 2: Parallel install
This is the way I do it, but I ensure that my system is set up so that this is easy to do. In particular, the file names used to identify the chunks used by the server are symlinks to the actual storage. This makes it easier to move or replace storage when necessary — you change the symlink instead of having to modify the server configuration.
Create a new directory (e.g. /opt/informix.new) and install the new version of the software in it.
Copy the configuration files from the current $INFORMIXDIR (e.g. /opt/informix) into the new one.
Ensure any other files or directories under the old $INFORMIXDIR that are needed for the new one are copied across or recreated empty.
Review the parallel setup; as best you can, make sure that when you're ready to switch, everything will work.
Take the old server down.
Move the old $INFORMIXDIR to a new name (i.e. mv /opt/informix /opt/informix.old).
Move the new $INFORMIXDIR to the working name (i.e. mv /opt/informix.new /opt/informix).
Restart the server
Why is this less risky? The primary advantage is that the old software is still on the machine and switching back to the old version is therefore simply a question of undoing the original pair of move commands. Another major advantage is that the down-time for the system is limited to the time taken to stop, switch directories, and restart the system.
What are the potential downsides? If you weren't careful enough about copying the necessary files from the old to the new system, you can find yourself missing something critical.
Note that if your chunks are not symlinks, and especially if they are cooked files stored under the old $INFORMIXDIR, you can run into problems. These are not insuperable; you just have more work to do than simply moving directories. Do not (repeat not) move or copy chunks while the server is running. They will not (necessarily) be consistent.
Variations? I usually needed multiple versions of Informix around, so I'd use sets of directories like /work3/informix/ids-12.10.FC1 and /work3/informix/ids-11.70.FC4 as the real directories. I'd then use a standard symlink name as $INFORMIXDIR, such as /opt/informix which would link to the current version-specific INFORMIXDIR under /work3/informix in this example. (Actually, there were some extra levels of complexity in my setups, but my requirements as an Informix developer were different from those of most customers.). But the key point is that instead of moving directories, I switched a symlink — rm /opt/informix; ln -s /work4/informix/ids-12.10.FC3 /opt/informix to use 12.10.FC3 instead of 12.10.FC1, for example.
Post-installation
Run a new level 0 archive.
General observations
Informix upgrades are usually seamless and smooth. If there is conversion work to do on the upgrade, the server does it automatically when the new version is brought up.
Be aware of the mechanisms for reverting to an older version of the server if that is found to be necessary.
I've done presentations and/or papers on this in years past at IIUG conferences. Check out the IIUG web site, and the IBM Informix documentation.
I'm pretty new to Informix and I'm trying to run a screen with sperform, but it's just seg faulting when I try to query. So far I have:
installed Ubuntu server 12 (64bit)
installed the Dev suite and runtime 7.50
installed the Informix engine 12.10
verified it was all up and running; can connect with dbaccess
created an example database & table and inserted a couple rows
generated a form using isql from the table
ran the generated form with sperform
As soon as I attempt to query with the form, I get a "Segmentation fault (core dumped)" and it exits. Can anyone help me understand why? Isn't this as basic as it gets?
Preliminary answer
Yes; that is as basic as it gets. No; it should not crash. There are essentially no circumstances under which that sequence should crash. You should probably file a bug report with IBM.
The only thing that might conceivably be an issue is that ISQL may have been built with an older version of the CSDK than the server installs and there may be an unexpected incompatibility. It should work, but occasionally flaws creep in. If you want to explore how to prove this possibility, say so. It is a little fiddly, but may get you up and running while the problem is resolved formally.
Extended answer
YES! I'd love to try to fix this.
The first step, it seems to me, is to see whether ISQL (Informix SQL) runs correctly when installed on its own — rather than when mixed with the Informix server code. It should work in both environments, but it is possible that the new server code has changed something that is causing the older tools code to break.
So, reinstall Informix SQL (and the other dev tools if you want, but you could save those until you've got a POC with just ISQL) into a new directory. Let's suppose your server is installed in /opt/informix; you could install your tools in /opt/isql instead. (No need to uninstall the tools from under /opt/informix yet.)
Copy the server sqlhosts file (from /opt/informix/etc/sqlhosts) to the new /opt/isql/etc/sqlhosts.
Change INFORMIXDIR=/opt/isql.
Add the new value to the front of your path (PATH=$INFORMIXDIR/bin:$PATH).
Worry about the setting of LD_LIBRARY_PATH — you want to pick up libraries from under /opt/isql/lib in preference to those under /opt/informix/lib.
Leave INFORMIXSERVER unchanged; you'll still be talking to the same database server.
You should now try to (re)generate the form file and run it. With a small modicum of luck, it will work now.
OK, that works! Don't know if that's a good thing or not, but we're going to try to get that change into production.
It gets you going; that's good. It's also a relief to me that the fundamentals of the QA process for the tools release didn't break down. The product works when run in the environment it was developed for.
It's a nuisance that a later release of the server changed something so that the older build of the tools no longer works with the newer server. It is supposed to be OK. However, running with separate INFORMIXDIR values for tools and server is not unheard of. If the server was on a separate machine, the segregation would be inevitable — the tools would use a separate INFORMIXDIR from the one used by the server (ignoring NFS file systems, etc)
Is it possible that there's some aspect to my steps that cause something to be overwritten?
No. The classic 'Rule of TEN (Tools, Engine, Network)' — install tools before the server (before the network-enabled version of the server) more or less applies and is what you did. The separate network-enabled version of the server ceased to be relevant about 20 years ago, but tools before engine (the 'Rule of TE' just doesn't cut it) is normally correct.
Since the workaround works, we need to look ahead a bit: what does it mean for you?
You have a solution that will work pro tem.
You will need to be careful with environment setting when you run programs.
Programs using the tools (Informix 4GL, Informix SQL) will be run with INFORMIXDIR=/opt/isql and consequential environment settings.
Programs installed by the server (DB-Export, DB-Import, ON-Stat, etc) will be run with INFORMIXDIR=/opt/informix and consequential environment settings.
If you wish, you can set up scripts in /opt/isql/bin for the programs from /opt/informix/bin that you want developers or users to use.
The scripts in /opt/isql/bin will set the environment correctly for the server and then exec the server program.
The scripts in /opt/informix/bin will similarly set the environment correctly for the tools and then exec the tools program.
In each directory, assuming you're careful, you have a single script that actually sets the environment and runs the other program; the program names are simply (symbolic?) links to the master script.
You have two separate master scripts — one to set the server environment, one to set the tools environment.
You should report the problem to IBM (Informix) Technical Support. You can outline what you've had to do to work around the problem. The fact that you have a workaround will lower the urgency, but it is still a problem that should, ideally, be fixed. (The world isn't ideal though, just in case you hadn't noticed; it may take time for the fix to be delivered.)
The list of current NaCl ports is here: https://code.google.com/p/naclports/wiki/PortList
I'm curious if there is (or will be) a repository for PNaCl executables (.pexe files) since they only need a .nmf manifest wrapper to run?
Please list any PNaCl resources here, I'm looking for ImageMagick specifically.
I know I could probably build the .pexe myself but I don't have the time to learn Native Client.
The short answer is: this isn't available yet, but we are working on it.
The long answer:
There isn't currently a binary repository for naclports. We are planning to add that soon (likely this quarter).
I took a quick look at the ImageMagick port, and it looks like it currently only generates libraries, not an application binary (i.e. nexe/pexe). My guess is that it wouldn't be too hard to add this, however.
Even with a pexe, you'll need to have a way to launch the application, give it commandline options, and a set of files to process. I've discussed a way to do this with my team, but we haven't started work on it yet (though again, we'll likely work on this in Q1 2014).
I am trying to use an application called CLUT.exe which is an old application for MS-DOS that can be used to reindex NTX files for DBF databases.
(This is not the main topic, but I am just writing this if someone wants to test the app and don't trust at all about the content).
The problem starts when trying to run the command line version through console (cmd.exe) and this error appears:
C:\>CLUT.exe [arg1] [arg2] [arg3]
run-time error R6009
- not enough space for environment
So, according to what I've searched, this could be a possible solution:
http://support.microsoft.com/default.aspx?scid=kb;en-us;230205
but it doesn't work and every alternative that I found to solve this over the internet is the same.
Another alternative could be to make right-click in the .exe file, go to Properties then Memory tab and increase the Initial environment memory from Auto to the max value but it doesn't work too.
Well, I am stuck and no "possible" solution is working for me. If someone is interested, knows more about this issue and want to test, you can download the application from here (click "Free Download" green button):
http://www.filebasket.com/free/Development-Clipper-programming-language/clut-exe/13996.html
or directly from my DropBox:
https://dl.dropbox.com/u/15208254/stackoverflow/clut_214.rar
Just to know, I am using Windows 7 and the CLUT.exe application is a Clipper based app (old programming language) that may run under windows console (cmd.exe).
Wikipedia does mention other dos emulators but, oddly, doesn't mention BOCHS.
Reindexing NTX files is not a difficult thing to do, and can be done with tools other than CLUT. For example, many of the utilities listed on this part of Download32 could be used. Otherwise, you could write your own using Harbour Project or xHarbour. Or contact me off list and I'll cook up something in Clipper 5.3.
LATER
If I read the README correctly for CLUT, it's a replacement for the DBU utility that comes with Clipper 5.x. I can supply you with a build of that if you're unsuccessful with other approaches.
We have a very important application, but so far no source code. The application was written in COBOL and a compiled version is in our production system and is running.
However, we need to migrate to a new server, and new cobol compiler. We're under the impression that we need to recompile the code to get it to work on the new server. Running the exising compiled program gave runtime memory errors.
We have some source code for the program, but it is old. Not sure what the diff is between it and the compiled program.
Okay, so the question -- what should we do?
Time is not on our side, since we have to send our old server back to get credit for it. Ideas, suggestions, crazy or otherwise? (source control is obvious and its not up to me to do it, so save the lectures)
Create an image of your old server. Then run the old server as a virtual machine on your new server.
However, I agree a better option is probably to keep your production server.
In the short run it would probably be cheaper to arrange to keep the old server. In the semi-long run, you need to make time and budget to reengineer the program, either re-write it or see how much effort it would be to hack the old code into shape doing what the program currently does.
It's sadly. You should consult the Source Recovery Company
If your source code is relatively close to the compiled version, try this:
decompile new version into assembler
compile the old source code into assembler
compare
reconcile as best you can the differences from new version with old version, into the old souce code
repeat
To augment this, and probably as a second step, as it will bring the source code farther from the new compiled version, test with input data and just try reverse-engineering based on the output what would be needed to create that output. The more test input data you have the better this could work.
Good luck!
(I'm not a COBOL programmer but..)
If you know what version the compiler was that compiled the original program, you could at least compile the old cobol source; if the compiled versions is identical you know the source actually is the current version.
If they differ, you could try to (somehow) decompile, or at least disassemble, the working compiled version and the freshly compiled version and use a diff tool to get an idea of how big difference there is.
crazy sugestion: COBOL DECOMPILER --> SOURCE --> NEW COBOL COMPILER...?
(edit: http://juggersoft.com - PAID cobol decompiler)
if you have the .int (intermediate) binary files you can just run on the new server, if not, them you musto to recompile.
The program could have been produced by an external resource and that person or software house or organisation could have the latest source in their repository. It may be held by your parent organisation if you have recently merged, or may be in a different or backup computer installation in your organisation. There may be a copy on the developer's user account and may not have been sent to the production or live site or someone from head office has a copy to assess and try to resolve the situation. You may have success if phone those people or you could always talk to the installation computer operator or support staff and see if they have one on mag tape, CDROM or other backup storage.