How to debug a Delphi application with redirected output - delphi

I've got a console application that crashes with an I/O error 6 when the output is redirected to a file. It probably has something to do with the fact that the console application changes the text color, which doesn't make much sense in a file.
This works: c:\dir\app.exe
This crashes: c:\dir\app.exe >out.txt
When I supply >out.txt as a parameter in the IDE (run\parameters\parameters\), I just get >out.txt as a parameter.
How can I debug the application with the stdout redirected to a file instead of the console?

Redirection is made by the command line interpreter, in windows it is cmd.exe
To debug the application, just launch a cmd.exe with propers arguments to launch your application and redirect the output, for example:
cmd.exe /c "yourapplication.exe >redirect.txt"
To make this happen from inside IDE in order to debug, configure cmd.exe as the host application (Run/Parameters):
Put a breakpoint where you want to stop, and launch a new cmd.exe (Project/Load process) with "Run to first source" after load action:
And you're done... the debugger must stop the application at your breakpoint.

You could try remote debugging:
at the beginning of the application, add a ReadLn; which gives you time to attach to the process from within Delphi
start the application from a command line (specifying the >out.txt parameter)
in Delphi, connect with the app process (Run | Attach to Process...), set a breakpoint and then switch to the application to enter a key
Hint: a debugger breakpoint can also be set in code:
asm
int 3
end;

Make sure it isn't failing due to directory permissions. Fully-qualify the output file path to somewhere that you're guaranteed to be able to write. Otherwise, Windows7 may be playing games with the directory. (VirtualStore stuff).

Related

Authorize UNIX command to control an application

I want to set up an Automator Quick Action that runs the bbdiff command, and passes it the selected files in the Finder.
I created a Quick Action, and set it to receive "files or folders" in "Finder.app".
Then I added the "Run Shell Script" action, and set the shell to "/bin/bash", and to Pass Input "as arguments". The script is:
/usr/local/bin/bbdiff "$1" "$2"
If I run that script manually from Automator or Terminal (replacing the arguments with real filenames) it prompts me to authorize the host program to control BBEdit, and then it works.
But if I run it from the Finder, I get this error:
The action “Run Shell Script” encountered an error: “You must allow bbdiff to send events to the BBEdit application.
Use tccutil reset AppleEvents to reset the system's permissions, and try again.
bbdiff: error: -1743”
I tried running tccutil reset AppleEvents and running the action again, but it showed the same error.
I also tried adding bbdiff, /bin/bash, and Finder to the Accessibility and Full Disk Access tabs of System Preferences > Privacy, but nothing changed. It looks like you need to add something to the Automation tab, which can't be done manually.
How can I get it to allow a UNIX command like bbdiff to control an application?
UPDATE:
I managed to work around this by using a "Run AppleScript" action, instead of "Run Shell Script", with this script:
on run {input, parameters}
tell application "BBEdit" to compare (item 1 of input) against (item 2 of input)
return input
end run
The first time I ran it, I got the prompt to allow Finder to control BBEdit, and then it worked.
But this wouldn't work for other shell scripts, so the question is still open.
In my case, I was able to fix it simply by closing the currently opened BBEdit then opening it again. In my case, I was doing a BBEdit update before the error appears.

Love2d console on PyCharm only writes to console after closing

I'm using PyCharm community edition to create a love2d application. I've created a hotkey that runs a .bat file to run it with lovec.exe which is opens the console as the app runs, then i've created an external tool to run the .batfile through a keyboard shortcut, when i use it, the console opens within PyCharm, which doesn't write anything, and after closing the app, everything that was meant to have been written appears, when i run the .bat file outside of PyCharm it functions perfectly.
I would like to know if there's either an obvious fix to that or, just how to run the console outside of pycharm through an external tool.
This issue is due to the way Lua delays writing files, known as "buffering." To change it, put the following command at the top of your file:
io.stdout:setvbuf( 'no' ) -- Switches buffering for stdout to be off
Read more in Lua's manual:
file:setvbuf (mode [, size])
Sets the buffering mode for an output file. There are three available modes:
"no": no buffering; the result of any output operation appears immediately.
"full": full buffering; output operation is performed only when the buffer is full or when you explicitly flush the file (see io.flush).
"line": line buffering; output is buffered until a newline is output or there is any input from some special files (such as a terminal device).
For the last two cases, size specifies the size of the buffer, in bytes. The default is an appropriate size.

How to remote debug a Spring Cloud Data flow Task

We are using Spring XD for executing some batch jobs and considering to use Spring Cloud Dataflow. For this I wanted to remote debug a execution of a Task and I was not able to make it working.
I tried to export the following environment variable before the SCDF server is started:
spring.cloud.deployer.local.javaOpts=Xdebug -Xrunjdwp:transport=dt_socket,address=12201,server=y
Also tried to pass as argument in the GUI while invoking the task:
app.<appname>.local.javaOpts=Xdebug -Xrunjdwp:transport=dt_socket,address=12201,server=y
Nothing seems to be working.
I'm able to debug the composed-task-runner launched by SCDF using the listen debugger mode, this will also work for your task as well.
Run Debugger in your IDE in listen mode on port 5006. (this project's classpath should have composed-task-runner sources, put break point some where )
Run SCDF with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 option, attach debugger to the SCDF process in your IDE on port 5005 (attach mode).
Put breakpoint at this line :
String javaOptsString = getValue(deploymentProperties, "javaOpts");
in JavaCommandBuilder class (for spring-cloud-deployer-local v.1.3.0.M2 it's line #83).
Launch your task - debugger stops at breakpoint.
Step Over once in your IDE, the value of javaOptsString is null now. Using IDE, set the value of javaOptsString to
-agentlib:jdwp=transport=dt_socket,server=n,address=localhost:5006,suspend=y
Press Resume in IDE.
Your breakpoint set in #1 should be hit in few seconds.
If you know how to pass javaOpts as deployment properties of your task - you will be able to debug in listen mode without this nightmare ;-). I've not found a way to escape = and , characters in the -agentlib:jdwp=transport=dt_socket,server=n,address=localhost:5006,suspend=y javaOpts deployment property.
We are working on an improved solution for the local-deployer - you can follow spring-cloud/spring-cloud-dataflow#369 for tracking purpose.
There is, however, the following option that exists to aggregate all the application logs into the server console directly, which might be useful while in active development.
stream deploy --name myStream --properties "deployer.*.local.inheritLogging=true"
Finally I was able to remote debug a composed task or regular task. Follow the below steps:
In scdf UI go to tasks and click on the definition section
Click play button (invoke) on the task/composed task that you want to invoke.
On the launch task page define your task arguments
Add the following properties by clicking 'Add Property' button:
- deployer.composed-task-runner.local.debugPort=12103
- deployer.composed-task-runner.local.debugSuspend=y
Now launch the task
You can now see in the log that when the composed task's java process is launched it is called with the debug parameter.
If you want to control the heap memory or any java options you can do by adding the following property:
deployer.composed-task-runner.local.javaOpts=Xmx2048M
Note that 'composed-task-runner' is the name of the App (Not the name of the task).

how can I stop my server from freezing when powershell is in 'select' mode?

I didn't believe this until I tested it a few times, but it's really happening.
Start rails server and app from powershell: 'rails s'
open a web page from that server
note how long the page took to get served up
now in powershell, select some text
reload the webpage from step 2
note that the webpage is taking forever to load
set up the windows so that you can see the powershell window and web page at the same time
go back to powershell and hit 'Enter' (so that the selected text is copied)
note that the web page loads as soon as the powershell window leaves select mode
TLDR: Rails server started via powershell won't serve pages while powershell is in 'Select' mode.
Is there some setting in powershell that will stop it from doing this? I can see it being helpful when selecting text in the middle of a bat run but when it stops my server it's flipping obnoxious.
Open a powershell window that you would normally start rails in. Open the properties dialog for the window and deselect QuickEdit Mode on the Options tab.
I had commented thinking it was just a general issue with the console system, and it probably still is as I cannot see how powershell is involved here as it's just a parent process, but it appears to be isolated to code that is watching for input. I think the rails server might be looking for input during its main loop, and perhaps selecting text in the console is blocking this. Take this simple script that loops - but does not watch for input - on a single thread, writing to a debug listener:
ps> $i = 0
ps> while (1) { sleep -seconds 1; [diagnostics.trace]::writeline("ping: $i"); $i++ }
Now, run sysinternals/microsoft's free DbgView tool to watch the output. I am using a separate tool instead of writing to the console because this is more like your scenario where web pages are being served in the background to a socket. You can get DbgView from:
http://technet.microsoft.com/en-us/sysinternals/bb896647
When I select the text in the console, the script does not pause. I even stuffed in a check in the key buffer, and it still did not stop.
I think the Rails server is doing some kind of key checking which is being blocked somehow and interfering with its ability to process requests. It seems retarded, but my script doesn't fail even if I stuff in a check for [console]::keyavailable
ps> while (1) {
>> sleep -seconds 1;
>> [diagnostics.trace]::writeline("ping: $i");
>> $i++
>> $dummy = [console]::keyavailable
>> }
Looks like it's Rail's fault, albeit unintentionally of course.

Using the spawn command inside of IDL

I'm very new to IDL (trying to do a POC for someone using it) and I am trying to run an external command. The line of code I have added is this:
spawn, 'C:\Program Files\ITT\IDL\IDL80\products\envi48\save_add\visual.exe'
I thought this was all that was needed to launch an external command. When I run the app, i can use the debugger to step through the code, and when I get to this line and Step over, my executable does not run. I see no messages in the debugger indicating any type of error.
I put the file visual.exe in the directory and can run it by hand with no issues. It just seems to step right over the code without executing it or reporting any error.
You can use the form:
spawn, cmd, result, errResult
to get the any error messages that might be generated from the cmd. In your particular case, I think you need to quote the path to the executable because of the space in the path.
Your usage of the spawn command is correct. Perhaps visual.exe is exiting prematurely
for some reason (for example, maybe the working directory when run via spawn isn't what
your external program is expecting.)
You might try writing a little script that starts visual.exe, then does a pause,
and then spawn the wrapper script instead of visual.exe directly. That might
give you a chance to see any error messages before the DOS window disappears.

Resources