I'am using the WAMPServer, and it's located in d:/wamp/. Is there a way to show logging window or console in realtime as I'am crawling on my server web ?
On unix/linux boxes I tend to use the tail command to watch logs as I browse for debugging. Of course, Windows has no equivalent, but there are a few options. The one I settled with was mTAIL. It's a standalone app and not a command line program, but it does exactly what you'd expect:
I was going to suggest using unxtools, a suite of ported GNU tools that can be used on the command line, but it's out of date and trying it on more recent versions of Windows I had problems. You can download them from sourceforge if you want to take a look. Also tail for Windows, is another Windows app that unfortunately doesn't seem to work on later versions, but included here in case it saves anyone the time looking.
Of course, you may find that if you prefer the command line you want to look at getting cygwin installed, which contains a host of commands you could use for the task you have.
Related
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.)
I am having problems saving the Python code in Anaconda. I write code, Go to File Save as the file is saved but when I open it is empty, no code. I read that IDLE does not save code, it erases it when I close Anaconda.
I have searched in books, youtube tutorials and nothing. I could not find this topic. I can find advanced topics, but this one no.
Thank you for your help!
Best,
Tiberiu
This somewhat depends on what OS you are on. I can speak from my experience. I would highly recommend using PyCharm as an IDE.
But more fundamentally than that, lets talk about saving files. On Mac OS X or Ubuntu 14.04 (or the like), lets say you want to create a python file. One way is to do the following in a terminal:
nano hello.py
This opens up a text editor whose instructions for use are on the bottom of the screen. On Windows you could do:
notepad hello.py
In both cases you then write your code. Lets say the content was:
#content of hello.py
print "Hello World!"
Then you need to save the file and execute it with Python.
Which brings us to the Python issue.
Once you have installed Anaconda, and assuming that there are no other Python installations on your computer. The Anaconda Python should be the active Python on system.
Suffice to say that there are other ways of saving files rather than using IDLE. Personally I have found PyCharm to be a much better IDE for writing Python code.
To address the IDLE issue more directly once you type in the terminal/command prompt idle to launch an IDLE session, likely the IDLE Shell will open up. Perhaps you are trying to save this, in which case you will only save the Shell session.
So go to File - New - Save. This should work without any problem (it does on my system). Good luck! Hope this helps.
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.
I have made a simple installer application in Delphi, nothing fancy. Basically I include files into the Exe, and then extract them to a user specified path.
I stumbled across a problem however, and I have noticed this works with ANY Windows Executable, it does not matter if it is an installer or not.
If an Exe is named, or contains the following words in the filename, "Setup", "Build", "Install" and maybe others, then.. whenever the Application is run and closed, Windows pops up a Product Compatibility Assistant dialog, saying the Application may not have installed correctly.
This is a problem, as even though the Files from my installer have actually extracted, and in my eyes the installer has done its job, Windows is complaining about it.
The only idea I have regarding this, is that Windows must check the filename of the Applications when executed, and in this case has identified it as an Installer. Windows must of then set a flag or something on the System, my Installer must then update this flag to say that the installation was a success?
Windows does not complain about this when debugging from the IDE, so it cannot be code related, it must be the OS - this only happens when launching the Application from Windows, not Delphi.
You can try this easily, either create an Application or rename one as Setup.exe, Run it and then close it - wait a few seconds and the Product Compatibility Assistant Dialog will show.
I don't know where to start investigating how to stop this dialog, or where a setting may be to tell Windows the Installer was completed correctly.
Appreciate your thoughts and solutions thanks.
If I recall correctly, this happens when your install app does not include an application manifest. When UAC was introduced, MS introduced a heuristic detection for installers and shows the UAC elevation dialog. The heuristic checks for names like setup.exe, install.exe. The simple solution is to include an application manifest. If it is an installer you probably want to use the requireAdministrator setting.
The feature is known as Installer Detection and is discussed here.
For what it is worth, I would always build an installer with a dedicated install tool like InnoSetup for example.
As David pointed out, MS uses some fuzzy logic to try to guess if the program is an installer. I wouldn't rely on this, as this is only for supporting legacy installer applications.
All new applications should have a manifest file, specifying whether it requires elevated privileges.
If an application has a manifest file that includes the requestedExecutionLevel directive, then Windows does not attempt Installer Detection.
Any program that is detected as an installer program but does not add a registry entry to the Add Remove Programs section of the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) will get the message "This program might not have installed correctly".
My problem is to create an ant target for automating our installer running in console mode.
The installer is created using InstallAnywhere 2008, which UniversalExtractor recognizes as a 7-zip archive. Once I have the archive unpacked, it appears that the task can use an input file to drive the console (at the very least, it appears that emitting a quit shuts everything down correctly, and output is captured).
So it looks to me as though I have all of the pieces I need for proving out this idea except a clean way to perform-self-extraction-then-stop. Searching for a command-line argument to stop the auto execution has not produced a likely candidate, and the only suitable ant task I've found ( http://www.pharmasoft.be/7z/ ) isn't so clearly documented that I have a lot of confidence in it.
The completed completed is expected to work in Windows, Linux, and a small handful of other Unix environments.
What's the best practice to use here?
Since you control the installer creation, can you run the self-extraction step on your machine, package the results before the installer is launched in a ZIP file, etc. and use that instead of the single file executable? Not very elegant but it may work.
Also, I am a bit hesitant to blatantly promote my project :) but since it has been a while since you asked the question and nobody has answered, have you considered an alternative? Our project InstallBuilder allows you to install in unattended mode directly, without having to autoextract the contents. Just invoke the executable with --mode unattended, pass any additional options you may need from the command line or an external file and you are good to go. We have a lot of ex-InstallAnywhere customers :)