I am pretty new to Informix and I have a program that I am adding some functionality to.
It seems that the program has some existing issues with it though.
When I run make -f makefile.mk I get success and the .4ge gets generated and I am able to run it.
However I am trying to get the program to run within informix 4gl interactive debugger but I get the error: Invalid module name [main] specified.
Any assistance would be greatly appreciated. Unfortunately I am unable to share code as the program contains confidential information
The Informix-4GL Interactive Debugger (ID) is for debugging programs compiled with the Informix-4GL Rapid Development System (RDS). The object files created by RDS (fglpc) have the extension .4go (I4GL p-code object file) and the executables are conventionally given the extension .4gi (I4GL p-code interpretable file — run using fglgo or ID's fgldb).
By contrast, the plain Informix-4GL (c-code) system uses an I4GL compiler to generate first ESQL/C code and then C code, and a C compiler to create regular object files (.o) and to create its executables, which are conventionally given the extension .4ge (I4GL c-code executable).
The ID cannot debug c-code executables. It can only debug p-code interpretable files.
On the face of it, therefore, your problem is that you are using the wrong tool for the job. Either you need to compile with RDS and create an interpretable, or you need to use a C code debugger such as GDB. However, be warned that debugging I4GL code with GDB is mainly an exercise in frustration as the bulk of the code is a series of function calls to library functions — or is an incredibly tortuous sequence of goto statements if you're debugging inside an I4GL report function. It is machine-generated C code; it is not intended to be comprehensible to humans.
Related
In this article it says: "The Dart VM reads and executes source code, which means there is no compile step between edit and run.". Does that mean that you can exchange source-code on the fly in a running Dart system like in Erlang? Maybe the compiler is removed from the runtime system and then this is no longer possible. So that's why I'm asking.
Dart is run "natively" only in Dartium, which is a flavour of Chrome with DartVM. When you develop an application you still need to compile it it to JavaScript. This way you get fast development lifecycle and in the end you can compile code to JS. Because it's compiled code there is lots more room for compiler to run optimisations on the code. So from my perspective, the compiler is still there and I don't think you would be able to replace code at runtime.
You can send around source code and run it, but it would need to be in a separate isolate. Isolates do have some relationship to Erlang concepts.
The Dart VM doesn't support hot swapping (Called live edit in V8). However, based on mailing list discussions, it sounds like this is something that the authors do want to support in the future.
However, as the others have mentioned, it is possible to dynamically load code into another isolate.
Is there any VM for Erlang that allows you to do compilation on the fly instead of compiling before?
There is a possibility to compile from the shell, thanks Martin.
Now, from the Erlang shell (or some other module!):
1> compile:file("mymod.erl").
{ok,mymod}
2> mymod:myfun().
Hello Joe
Is there any pros or cons with doing this?
Will you still be able to hot swap code?
Is it the regular use-case to handle code?
What benefits does the compiler give you in the end then?
From the Erlang shell, you can compile a module on the fly using c("path/to/module.erl"). You can also access this functionality through the compile module, specifically the compile:file/{1,2} functions.
For example, suppose we have a file mymod.erl:
-module(mymod).
-export([myfun/0]).
myfun() -> io:format("Hello Joe~n").
Now, from the Erlang shell (or some other module!):
1> compile:file("mymod.erl").
{ok,mymod}
2> mymod:myfun().
Hello Joe
See Erldocs on the compile module for more information.
You can do a great deal with the Erlang compiler in runtime. For example, you can dynamically generate code for a module (use erl_syntax!) and then compile it without even writing it to a file using compile:forms/{1,2}.
(Insert standard speech on great power and great responsibility.)
Will you still be able to hot swap code?
Yes.
Is it the regular use-case to handle code?
No. Normally Erlang code is compiled ahead of time into BEAM bytecode. Depending on whether Erlang was started in embedded or interactive mode, the modules are either loaded on startup, or dynamically as they are referenced. If you are building a release, you basically have to compile ahead of time.
What benefits does the compiler give you in the end then?
Well, for one thing, we can build compact releases without unnecessary components like the compiler. Of course, we also get all the traditional benefits of ahead-of-time compilation, particularly that of not having to waste time compiling all the time.
To sum it up, unless you fully understand the implications and have a very good reason not to compile your code ahead of time, please follow the standard practices.
The Erlang VM can only run compiled code! If you want to interpret Erlang code then you need an interpreter. The module erl_eval implements an Erlang interpreter and is part of the standard Erlang/OTP distribution. It is used by the Erlang shell to interpret the expressions entered.
All code handling in the Erlang VM, whether compiling, loading or updating, is done at the module level so it is impossible to compile or load a just one function. The Erlang compiler is written in Erlang and always available and can compile to either a file or a binary which can be immediately loaded into the system. As #MartinTörnwall has pointed out compiling a module from the shell using c(module) is in essence compiling on the fly.
So there would be no problems in automatically compiling code on the fly when it is used, at the module level. It is just that the current system is not designed to work that way and by default when it tries to load a module it only looks for the pre-compiled object file, the .beam file.
Erlang has an interpreter escript. Entire Erlang archive can be written in script. Almost all features are available.
By default, the script will be interpreted. You can force it to be compiled by including the -mode(compile). in the script.
Though it depends on the way you design your application, regular practice is to have .erl files which are compiled and run than having escript files.
So now you have many options.
Compile .erl file to .beam using c(my_module) this auto loads the .beam file. So the existing VM can run it on the fly. On in code you can use compile module functions like file, purge and load to load and run it on the fly.
Compile and keep the .erl files using erlc, erl -make, rebar, etc (Erlang has rich support) and then run it. You can build archives, boot scripts, rel etc to manage running and release of the Erlang software. This usually is the practice for production.
Use escript and run everything in interpreted mode.
Use escript and give -mode(compile) option to tell Erlang VM that at runtime (when starting to run escript) compile the code and run the compiled code (in memory)
Is there any pros or cons with doing this?
Compiled code is faster than interpreted code. I dont see any other right now in Erlang as pretty much everything is supported in both. Erlang even supports combination (Calling compiled code from interpreted code)
Will you still be able to hot swap code?
Yes in all cases. Your code also should be able to handle this.
Is it the regular use-case to handle code?
Option 2 for production. Option for 1 for learning / simple development. Option 3 and 4 in need basis for specific requirements (May be one time running).
What benefits does the compiler give you in the end then?
To make it clear, erlc program provides a common way to run all compilers in the Erlang system and compile module gives an interface to Erlang compilers. Compiler gives intermediate binary .beam file which helps in running Erlang code faster than interpreted counterpart. They also catch syntax errors (compilation errors).
My company has a program that uses Lua embedded in its runtime, loading up .lua files from disk and executing functions defined in them repeatedly.
Is there a way to attach to the running process and set breakpoints in my .lua files? (I'd accept either gdb-style command-line debugging as part of the Lua distribution, or perhaps a third-party IDE that provides Visual-Studio-like GUI breakpoints.)
Or is what I'm asking for entirely nonsensical and impossible given the nature of the runtime loading up random files from disk?
Edit: Looks like it's not nonsensical, given that Lua's own debug.getinfo() function can determine the source file for a given function, and debug.sethook() allows a callback for each new line of code entered. So, it's reasonable to load source code from disk and be able to tell when the interpreter is executing a particular line of code from that file. The question remains: how do I latch onto an existing process that has a Lua interpreter and inject my own trace function (which can then watch for file/line number pairs and pause execution)?
If you can modify the .lua files, you can insert the following call just before anything you need to debug:
require 'remdebug.engine'.start()
It starts the RemDebug Lua debugger engine and tries to connect to a controller. If it cannot connect, it will just continue running as normal. I did some fixes to the debugger engine, such as dealing with temporary variables, and my student is working on a debugger GUI (due next year).
In the meantime, you can try if Lua Development Tools works for you. It features a debugger similar to RemDebug, which should be possible to set up as follows:
require("debugger")(host, port, idekey)
Alternatively, you can use SciTE-debug, which is an extension to the SciTE editor, and can serve as a controller to RemDebug. Just make sure you insert the call to remdebug.engine.start somewhere in your Lua code and insert this into the SciTE output window:
:debug.target=remote.lua
When you start your program, SciTE should show the source and current line.
I've been using Decoda editor for that. It allows you to attach to a running C++ application, after that it detects that you're running a Lua Interpreter within your C++ code and show your Lua source code, where you can add beakpoints and inspect variables as usual.
This is an alternative I use after much searching. If you have an external executable that loads lua, I got this working in a few minutes. The op is very responsive, it has an interactive debugger which loads your code you can place debug points interactively. It doesn't have an editor, but I use scite or crimson editor and start the executable, one line in your main lua module enables the debugger.
http://www.cushy-code.com/grld/ - this link seems dead now
I've moved to eclipse.org/ldt it has an ide and integrated debugger, recommended
hth
The Lua plugin for IntelliJ has a working debugger with no special setup required other than pointing to your Lua interpreter.
Here's a screencast of it:
http://www.screencast.com/t/CBWIkoZPg
Similar to what Michal Kottman described, I have implemented a debugger based on RemDebug, but with additional fixes and features (on github: https://github.com/pkulchenko/MobDebug).
You can update your .lua file with require("mobdebug").start("localhost", 8171) at the point where you want the debugging to start. You can then use the command line debugger to execute commands, set breakpoints, evaluate/execute expressions and so on.
As an alternative, you can use ZeroBrane Studio IDE, which integrates with the debugger and gives you a front-end to load your code and execute same debugger commands in a nice GUI. If you want to see the IDE in action, I have a simple demo here: http://notebook.kulchenko.com/zerobrane/live-coding-in-lua-bret-victor-style.
You should probably use Decoda.
Go to Debug -> Processes -> Attach to attach your process. This should work fine.
Well the easiest way is this, thanks to the genius author
https://github.com/slembcke/debugger.lua
you don't need to setup a remote debug server ,just require one file,and simplely call dbg() and it will pause,just like gdb
an tutorial is also shipped with it, check it out.
I have been asked to update a program written in 1987 in Delphi (I guess). I have no documentation about this program only a few side notes the programmer took that don't make too much sense to make.
The cd show this files:
Size | Filename
19956 VP.DTA
142300 VP.LEX
404 VP.NDX
126502 VP.RCS
131016 VP.SCR
150067 VP.XEL
101791 vp.exe
Is anyone of this files a database? If so can I access it's data?
I tried several code decompilers but they show a message saying it was not a Win32 compatible application.
The program run in MS-DOS.
Is it possible to obtain the source code? Can I use this code in any way to build a new application?
Update01: I can run the program in MS-DOS. The program conjugate verbs and shows an example sentence where the verb can be used. The GUI is a little bit confusing and there is no help menu so I can't see all the capabilities of the program.
Update02: In conversation with the owner of the program we found another solution. He ask me if it was possible to have the program in a server and the clients could login in with a user and a password and execute the program in a terminal. I have an account in my university server, which I can access throughout ssh and compile and execute c programs in it. The server is in linux so I couldn't try the program in it. If I set up a windows server, can I have multiple people accessing and executing the program in a terminal? The program is an exe. Doesn't this raise some security issues?
Delphi is from mid nineties, so that probably means Delphi's ancestor Turbo Pascal, not Delphi.
Some extensions sound familiar, as shortened versions of words:
ndx = index
dta = data
scr = screen (?)
lex = lexicon (list of words or deduped strings in general) (?)
Screen was sometimes used for e.g. helpscreens, a medieval form of helpfiles, they are typicall ansi screens that can be loaded directly into screen memory
There is a fair chance that this is something handcrafted, specially if that date of 1987 and the general assumption "pascal" is true, and not generated by some known database package at all.
Reverseengineering the fileformat might be a more worthwhile way than trying to reverseengineering the app.
A good start would to be to take a the unix "file" command to see if it can recognize the file types. (the file command searches for signatures inside files, and there are windows ports. I use Cygwin's)
A devel experienced in such matters can also see a lot from a hexdump (specially the first parts of a file)
Is it possible to obtain the source code?
Probably not, you may want to look at something like IDA Pro which can disassemble applications to C using something like Hex-Rays.
Do you know what the application is supposed to be?
If it's ms-dos, you're probably better off just drawing up new requirements and doing new development.
Look for DeDe to reverse engineering a delphi compiled program. But as far as i know, delphi is a real compiler. So there is no way to de-compiled it. If you are able to read assembler code then you can try de-compile it. Clipper and Foxpro (dos version) are another stories cause they not real compiler.
This is definitely not Delphi. It might be one of the database centric languages like Clipper 1. .SCR probably means "screen" and defines I/O masks. .NDX is a table index and .DTA means "data".
If it is clipper, you might actually be lucky, because as far as I remember these programs were P code, so it could be possible to decompile it.
It looks like CLipper (NDX and SCR). If you have a DBF file then it's Clipper for sure. But some people renamed the DBF to something like DAT. If it is Clipper, I believe there was a decompile named Valkyrie.
How to generate the Symbols file of a PowerBuilder program for dump analysis?
Are you running into a problem with a compiled PowerBuilder application?
I've never used the Microsoft debugger, however, I have used Dependency Walker and ran my app from within that environment. Usually that helps us if we have missing deployables, etc.
If you need a stack dump, have you thought about running the app from the Run window and adding the /debug option after the name of the app? That creates a call stack log that shows all your commands being called, etc. Probably would get you what you need.
Please advise.
You can install Dr. Watson (drwtsn32) to automatically create a crash dump when/if your application dies.
That said, the dump will usually only be useful if you are calling into native DLL's. Otherwise the stack will just include various PBVM calls that will be difficult to correlate back to actual source code lines.