Quick question:
I have some code that looks like:
if (interactive)
ret = main_interactive(ctx, debug, use_aio);
else
ret = main_server(ctx, debug);
/*
* In case we got here through an error in the main thread make sure all
* the worker threads are signaled to shutdown.
*/
when I run it through clang-format 7.0.1-8 (debian) (with this .clang-format file), I get this:
if (interactive)
ret = main_interactive(ctx, debug, use_aio);
else
ret = main_server(ctx, debug);
/*
* In case we got here through an error in the main thread make sure all
* the worker threads are signaled to shutdown.
*/
You can see that the first line of the comment block is incorrectly indented.
Any suggestions?
I've tried you clang-format config in CLion 2020.RC1 and it seems the problem is comment's first line (/*) is indented with tab (which is 8-spaces wide per your config), while the rest of the comment's lines are indented with 4 spaces.
Here is how you code looks like with "show whitespace: on" in CLion:
This can be fixed with option ReflowComments: true. That way all comment's lines will be indented with tabs.
Related
I'm attempting to constantly read and parse a log file (Minecraft log file) by using io.popen in tandem with Ubuntu's tail command so that I can send some messages upon certain events.
Now, I have mostly everything working here, except one small issue. After a while of reading, the entire program just freezes.
Here is the relevant code:
-- Open the tail command, return a file handle for it.
local pop = io.popen(config.listen_command)
-- Simply read a single line, I've pulled this into its own
-- function so that if this ever needs changing I can do so
-- easily.
local function get_line()
logger:log(4, "READ LINE")
return pop:read("*l")
end
-- For each line in the log file, check if it matches any
-- of a list of patterns, return the matches and the
-- pattern information if so.
local function match_line()
local line = get_line()
logger:log(4, "Line: %s", line)
-- This all works, and I've tested that it's not freezing
-- here. I've just included it for completion of the call
-- -stack.
for event_type, data in pairs(config.message_patterns) do
for event_name, pattern in pairs(data) do
local matches = {line:match(pattern)}
if matches[1] then
return event_type, event_name, matches
end
end
end
end
-- The main loop, simply read a line and send a message
-- if there was a match.
logger:log(4, "Main loop begin.")
while true do
local event_type, event_name, matches = match_line()
-- ...
-- The rest of the code here is not relevant.
config.listen_command = "tail -F --lines=1 latest.log"
The issue is in the get_line function. After a while of reading the log file, it completely freezes on the pop:read("*l"). It prints the READ LINE message, but never prints the Line: <whatever data here> line.
This is a really strange issue that I've been getting really confused about. I've tried swapping to different distributions of Lua (Luvit, LuaJIT, Lua) and a very large amount of debugging, changing small things, rerunning, ... But I cannot think of anything that'd be causing this.
Perhaps there's something small I've missed.
So my question here is this: Why is pop:read("*l") freezing, even though more data is being outputted to the logfile? Is there a way to fix this? Perhaps to detect if the next read will freeze indefinitely, so I can try closing the popen'ed file and re-open it (or to preferably stop it happening altogether?)
I am working on a pexpect script that is running populating an output file name and then a prompt for the file's parameters.
The program that the script runs asks for Device: then Parameters: always on the same line.... so if the file path-name that is entered for Device is long, sometimes the Parameters prompt wraps to the next line.
My code looks like..
child.expect_exact('Device:')
child.sendline('/umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT')
child.expect_exact('Parameters:')
This times out.. and here is what is in child.before
' /umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT Param\r\neters: "RWSN" => '
so the expect fails... (a child.expect('Parameters:') also fails)
How can I ignore the \r\n if it is there, because depending on the length of the path/filename I am using it may not be there at all, or be in a different position.
Thanks!
Actually... I found a way to calculate how much is left on the given line, and dynamically set my expect to how much of the Parameter prompt should be visible... seems to be working
#look for end of line and fix how much of 'Parameters:' we look for in pexpect
dlen = 80-len('Device: /umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT')
pstr='Parameters:'
if dlen > len(pstr):
dlen=len(pstr)
else:
dlen=dlen-3 #remove the /r/n
child.expect(pstr[0:dlen])
Is there a way to set the execution point while debugging Xcode/lldb? To be more specific, after hitting a breakpoint, moving the execution point manually to another line of code?
If you're looking at moving it up or down with in a method you can click and drag the green arrow to a specific point. so if you want to back up a line before the breakpoint. click on the green arrow that is produced and drag it up. If you hit run you'll hit your breakpoint again
In Xcode 6, you can use j lineNumber - see documentation below:
(lldb) help j
Sets the program counter to a new address. This command takes 'raw' input
(no need to quote stuff).
Syntax: _regexp-jump [<line>]
_regexp-jump [<+-lineoffset>]
_regexp-jump [<file>:<line>]
_regexp-jump [*<addr>]
'j' is an abbreviation for '_regexp-jump'
One of the great things about lldb is that it's easy to extend it with a little bit of python scripting. For instance, I threw together a new jump command without much trouble:
import lldb
def jump(debugger, command, result, dict):
"""Usage: jump LINE-NUMBER
Jump to a specific source line of the current frame.
Finds the first code address for a given source line, sets the pc to that value.
Jumping across any allocation/deallocation boundaries (may not be obvious with ARC!), or with optimized code, quickly leads to undefined/crashy behavior. """
if lldb.frame and len(command) >= 1:
line_num = int(command)
context = lldb.frame.GetSymbolContext (lldb.eSymbolContextEverything)
if context and context.GetCompileUnit():
compile_unit = context.GetCompileUnit()
line_index = compile_unit.FindLineEntryIndex (0, line_num, compile_unit.GetFileSpec(), False)
target_line = compile_unit.GetLineEntryAtIndex (line_index)
if target_line and target_line.GetStartAddress().IsValid():
addr = target_line.GetStartAddress().GetLoadAddress (lldb.target)
if addr != lldb.LLDB_INVALID_ADDRESS:
if lldb.frame.SetPC (addr):
print "PC has been set to 0x%x for %s:%d" % (addr, target_line.GetFileSpec().GetFilename(), target_line.GetLine())
def __lldb_init_module (debugger, dict):
debugger.HandleCommand('command script add -f %s.jump jump' % __name__)
I put this in a directory where I keep Python commands for lldb, ~/lldb/, and I load it in my ~/.lldbinit file with
command script import ~/lldb/jump.py
and now I have a command jump (j works) which will jump to a given line number. e.g.
(lldb) j 5
PC has been set to 0x100000f0f for a.c:5
(lldb)
This new jump command will be available both in command-line lldb and in Xcode if you load it in your ~/.lldbinit file -- you'll need to use the debugger console pane in Xcode to move the pc instead of moving the indicator in the editor window.
You can move the program counter (pc) in lldb using the lldb command register write pc. But it's instruction based.
There's an excellent lldb/gdb comparison here that is useful as an lldb overview.
Although I am quite familiar with Tcl this is a beginner question. I would like to read and write from a pipe. I would like a solution in pure Tcl and not use a library like Expect. I copied an example from the tcl wiki but could not get it running.
My code is:
cd /tmp
catch {
console show
update
}
proc go {} {
puts "executing go"
set pipe [open "|cat" RDWR]
fconfigure $pipe -buffering line -blocking 0
fileevent $pipe readable [list piperead $pipe]
if {![eof $pipe]} {
puts $pipe "hello cat program!"
flush $pipe
set got [gets $pipe]
puts "result: $got"
}
}
go
The output is executing go\n result:, however I would expect that reading a value from the pipe would return the line that I have sent to the cat program.
What is my error?
--
EDIT:
I followed potrzebie's answer and got a small example working. That's enough to get me going. A quick workaround to test my setup was the following code (not a real solution but a quick fix for the moment).
cd /home/stephan/tmp
catch {
console show
update
}
puts "starting pipe"
set pipe [open "|cat" RDWR]
fconfigure $pipe -buffering line -blocking 0
after 10
puts $pipe "hello cat!"
flush $pipe
set got [gets $pipe]
puts "got from pipe: $got"
Writing to the pipe and flushing won't make the OS multitasking immediately leave your program and switch to the cat program. Try putting after 1000 between the puts and the gets command, and you'll see that you'll probably get the string back. cat has then been given some time slices and has had the chance to read it's input and write it's output.
You can't control when cat reads your input and writes it back, so you'll have to either use fileevent and enter the event loop to wait (or periodically call update), or periodically try reading from the stream. Or you can keep it in blocking mode, in which case gets will do the waiting for you. It will block until there's a line to read, but meanwhile no other events will be responded to. A GUI for example, will stop responding.
The example seem to be for Tk and meant to be run by wish, which enters the event loop automatically at the end of the script. Add the piperead procedure and either run the script with wish or add a vwait command to the end of the script and run it with tclsh.
PS: For line-buffered I/O to work for a pipe, both programs involved have to use it (or no buffering). Many programs (grep, sed, etc) use full buffering when they're not connected to a terminal. One way to prevent them to, is with the unbuffer program, which is part of Expect (you don't have to write an Expect script, it's a stand-alone program that just happens to be included with the Expect package).
set pipe [open "|[list unbuffer grep .]" {RDWR}]
I guess you're executing the code from http://wiki.tcl.tk/3846, the page entitled "Pipe vs Expect". You seem to have omitted the definition of the piperead proc, indeed, when I copy-and-pasted the code from your question, I got an error invalid command name "piperead". If you copy-and-paste the definition from the wiki, you should find that the code works. It certainly did for me.
Do any editors honer C #line directives with regards to goto line features?
Context:
I'm working on a code generator and need to jump to a line of the output but the line is specified relative to the the #line directives I'm adding.
I can drop them but then finding the input line is even a worse pain
If the editor is scriptable it should be possible to write a script to do the navigation. There might even be a Vim or Emacs script that already does something similar.
FWIW when I writing a lot of Bison/Flexx I wrote a Zeus Lua macro script that attempted to do something similar (i.e. move from input file to the corresponding line of the output file by search for the #line marker).
For any one that might be interested here is that particular macro script.
#line directives are normally inserted by the precompiler, not into source code, so editors won't usually honor that if the file extension is .c.
However, the normal file extension for post-compiled files is .i or .gch, so you might try using that and see what happens.
I've used the following in a header file occasionally to produce clickable items in
the VC6 and recent VS(2003+) compiler ouptut window.
Basically, this exploits the fact that items output in the compiler output
are essentially being parsed for "PATH(LINENUM): message".
This presumes on the Microsoft compiler's treatment of "pragma remind".
This isn't quite exactly what you asked... but it might be generally helpful
in arriving at something you can get the compiler to emit that some editors might honor.
// The following definitions will allow you to insert
// clickable items in the output stream of the Microsoft compiler.
// The error and warning variants will be reported by the
// IDE as actual warnings and errors... which means you can make
// them occur in the task list.
// In theory, the coding standards could be checked to some extent
// in this way and reminders that show up as warnings or even
// errors inserted...
#define strify0(X) #X
#define strify(X) strify0(X)
#define remind(S) message(__FILE__ "(" strify( __LINE__ ) ") : " S)
// example usage
#pragma remind("warning: fake warning")
#pragma remind("error: fake error")
I haven't tried it in a while but it should still work.
Use sed or a similar tool to translate the #lines to something else not interpreted by the compiler, so you get C error messages on the real line, but have a reference to the original input file nearby.