In my current uncrustify configuration, if a function is called, most of the time the arguments are aligned to the opening parenthesis which is what I want.
However, if the first argument is long such that the line width (code_width) is exceeded the following occurs:
A newline is appended after the opening parenthesis
The arguments are aligned but dedented with respect to the opening brace.
So this:
printf("This is some very large example string, which is so large, it exceeds the max line width",
some_arg1,
some_arg2,
some_arg3);
Becomes this:
printf(
"This is some very large example string, which is so large, it exceeds the max line width",
some_arg1,
some_arg2,
some_arg3);
Is there any way I can ensure that the function call's arguments are all aligned as in my first snippet?
Some of the options in my cfg file which I think might be related:
# True: indent continued function call parameters one indent level
# False: align parameters under the open paren.
indent_func_call_param = false # false/true
# Add or remove newline after '(' in a function declaration.
nl_func_decl_start = remove # ignore/add/remove/force
# Add or remove newline after '(' in a function definition.
nl_func_def_start = remove # ignore/add/remove/force
# Whether to add newline after '(' in a function declaration if '(' and ')' are in different lines.
nl_func_decl_start_multi_line = false # false/true
# Whether to add newline after '(' in a function definition if '(' and ')' are in different lines.
nl_func_def_start_multi_line = false # false/true
# Whether to add newline after '(' in a function call if '(' and ')' are in different lines.
nl_func_call_start_multi_line = false # false/true
# True: indent continued function call parameters one indent level
# False: align parameters under the open paren.
indent_func_call_param = false # false/true
# If an open paren is followed by a newline, indent the next line so that it lines up after the open paren (not recommended).
indent_paren_nl = false # false/true
Related
I'd like to create an script which takes an input file and optionally an output file. When you don't pass an output file, the script uses the same filename as the input but with the extension changed. I don't know how to write a default parameter which changes the extension.
#!/usr/bin/env raku
unit sub MAIN(
Str $input where *.IO.f, #= input file
Str $output = $input.IO.extension("txt"), #= output file
Bool :$copy, #= copy file
Bool :$move, #= move file
);
Unfortunately that doesn't work:
No such method 'IO' for invocant of type 'VMNull'
in block <unit> at ./copy.raku line 5
How can I do something like that?
error message is less than awesome but program not working is expected because you have in the signature
Str $output = $input.IO.extension("txt")
but the right hand side returns an IO::Path object with that extension but $output is typed to be a String. That is an error:
>>> my Str $s := "file.csv".IO.extension("txt")
Type check failed in binding; expected Str but got IO::Path (IO::Path.new("file.t...)
in block <unit> at <unknown file> line 1
>>> sub fun(Str $inp, Str $out = $inp.IO.extension("txt")) { }
&fun
>>> fun "file.csv"
Type check failed in binding to parameter '$out'; expected Str but got IO::Path (IO::Path.new("file.t...)
in sub fun at <unknown file> line 1
in block <unit> at <unknown file> line 1
Sometimes compiler detects incompatible default values:
>>> sub yes(Str $s = 3) { }
===SORRY!=== Error while compiling:
Default value '3' will never bind to a parameter of type Str
------> sub yes(Str $s = 3⏏) { }
expecting any of:
constraint
but what you have is far from a literal, so runtime detection.
To fix it, you can either
change to Str() $output = $inp.IO.extension("txt") where Str() means "accept Any object and then cast it to Str". So $output will end up being a string like "file.txt" available in MAIN.
similar alternative: Str $output = $inp.IO.extension("txt").Str but it's repetitive in Str.
change to IO::Path() $output = $inp.IO.extension("txt"). Similarly, this casts to whatever recieved to an IO::Path object, so, e.g., you'll have "file.txt".IO available in $output. If you do this, you might want to do the same for $input as well for consistency. Since IO::Path objects are idempotent to .IO (in eqv sense), no other part of the code needs changing.
In perl6 grammars, as explained here (note, the design documents are not guaranteed to be up-to-date as the implementation is finished), if an opening angle bracket is followed by an identifier then the construct is a call to a subrule, method or function.
If the character following the identifier is an opening paren, then it's a call to a method or function eg: <foo('bar')>. As explained further down the page, if the first char after the identifier is a space, then the rest of the string up to the closing angle will be interpreted as a regex argument to the method - to quote:
<foo bar>
is more or less equivalent to
<foo(/bar/)>
What's the proper way to use this feature? In my case, I'm parsing line oriented data and I'm trying to declare a rule that will instigate a seperate search on the current line being parsed:
#!/usr/bin/env perl6
# use Grammar::Tracer ;
grammar G {
my $SOLpos = -1 ; # Start-of-line pos
regex TOP { <line>+ }
method SOLscan($regex) {
# Start a new cursor
my $cur = self."!cursor_start_cur"() ;
# Set pos and from to start of the current line
$cur.from($SOLpos) ;
$cur.pos($SOLpos) ;
# Run the given regex on the cursor
$cur = $regex($cur) ;
# If pos is >= 0, we found what we were looking for
if $cur.pos >= 0 {
$cur."!cursor_pass"(self.pos, 'SOLscan')
}
self
}
token line {
{ $SOLpos = self.pos ; say '$SOLpos = ' ~ $SOLpos }
[
|| <word> <ws> 'two' { say 'matched two' } <SOLscan \w+> <ws> <word>
|| <word>+ %% <ws> { say 'matched words' }
]
\n
}
token word { \S+ }
token ws { \h+ }
}
my $mo = G.subparse: q:to/END/ ;
hello world
one two three
END
As it is, this code produces:
$ ./h.pl
$SOLpos = 0
matched words
$SOLpos = 12
matched two
Too many positionals passed; expected 1 argument but got 2
in method SOLscan at ./h.pl line 14
in regex line at ./h.pl line 32
in regex TOP at ./h.pl line 7
in block <unit> at ./h.pl line 41
$
Line 14 is $cur.from($SOLpos). If commented out, line 15 produces the same error. It appears as though .pos and .from are read only... (maybe :-)
Any ideas what the proper incantation is?
Note, any proposed solution can be a long way from what I've done here - all I'm really wanting to do is understand how the mechanism is supposed to be used.
It does not seem to be in the corresponding directory in roast, so that would make it a "Not Yet Implemented" feature, I'm afraid.
I'm writing a "compiler" of sorts: it reads a description of a game (with rooms, characters, things, etc.) Think of it as a visual version of an Adventure-style game, but with much simpler problems.
When I run my "compiler" I'm getting a syntax error on my input, and I can't figure out why. Here's the relevant section of my yacc input:
character
: char-head general-text character-insides { PopChoices(); }
;
character-insides
: LEFTBRACKET options RIGHTBRACKET
;
char-head
: char-namesWT opt-imgsWT char-desc opt-cond
;
char-desc
: general-text { SetText($1); }
;
char-namesWT
: DOTC ID WORD { AddCharacter($3, $2); expect(EXP_TEXT); }
;
opt-cond
: %empty
| condition
;
condition
: condition-reason condition-main general-text
{ AddCondition($1, $2, $3); }
;
condition-reason
: DOTU { $$ = 'u'; }
| DOTV { $$ = 'v'; }
;
condition-main
: money-conditionWT
| have-conditionWT
| moves-conditionWT
| flag-conditionWT
;
have-conditionWT
: PERCENT_SLASH opt-bang ID
{ $$ = MkCondID($1, $2, $3) ; expect(EXP_TEXT); }
;
opt-bang
: %empty { $$ = TRUE; }
| BANG { $$ = FALSE; }
;
ID: WORD
;
Things in all caps are terminal symbols, things in lower or mixed case are non-terminals. If a non-terminal ends in WT, then it "wants text". That is, it expects that what comes after it may be arbitrary text.
Background: I have written my own token recognizer in C++ because(*) I want the syntax to be able to change the way the lexer's behavior. Two types of tokens should be matched only when the syntax expects them: FILENAME (with slashes and other non-alphameric characters) and TEXT, which means "all the text from here to the end of the line" (but not starting with certain keywords).
The function "expect" tells the lexer when to look for these two symbols. The expectation is reset to EXP_NORMAL after each token is returned.
I have added code to yylex that prints out the tokens as it recognizes them, and it looks to me like the tokenizer is working properly -- returning the tokens I expect.
(*) Also because I want to be able to ask the tokenizer for the column where the error occurred, and get the contents of the line being scanned at the time so I can print out a more useful error message.
Here is the relevant part of the input:
.c Wendy wendy
OK, now you caught me, what do you want to do with me?
.u %/lasso You won't catch me like that.
[
Here is the last part of the debugging output from yylex:
token: 262: DOTC/
token: 289: WORD/Wendy
token: 289: WORD/wendy
token: 292: TEXT/OK, now you caught me, what do you want to do with me?
token: 286: DOTU/
token: 274: PERCENT_SLASH/%/
token: 289: WORD/lasso
token: 292: TEXT/You won't catch me like that.
token: 269: LEFTBRACKET/
here's my error message:
: line 124, columns 3-4: syntax error, unexpected LEFTBRACKET, expecting TEXT
[
To help you understand the equations above, here is the relevant part of the description of the input syntax that I wrote the yacc code from.
// Character:
// .c id charactername,[imagename,[animationname]]
// description-text
// .u condition on the character being usable [optional]
// .v condition on the character being visible [optional]
// [
// (options)
// ]
// Conditions:
// %$[-]n Must [not] have at least n dollars
// %/[-]name Must [not] have named thing
// %t-nnn At/before specified number of moves
// %t+nnn At/after specified number of moves
// %#[-]name named flag must [not] be set
// Condition-char: $, /, t, or #, as described above
//
// Condition:
// % condition-char (identifier/int) ['/' text-if-fail ]
// description-text: Can be either on-line text or multi-line text
// On-line text is the rest of the line
brackets mark optional non-terminals, but a bracket standing alone (represented by LEFTBRACKET and RIGHTBRACKET in the yacc) is an actual token, e.g.
// [
// (options)
// ]
above.
What am I doing wrong?
To debug parsing problems in your grammar, you need to understand the shift/reduce machine that yacc/bison produces (described in the .output file produced with the -v option), and you need to look at the trail of states that the parser goes through to reach the problem you see.
To enable debugging code in the parser (which can print the states and the shift and reduce actions as they occur), you need to compile with -DYYDEBUG or put #define YYDEBUG 1 in the top of your grammar file. The debugging code is controlled by the global variable yydebug -- set to non-zero to turn on the trace and zero to turn it off. I often use the following in main:
#ifdef YYDEBUG
extern int yydebug;
if (char *p = getenv("YYDEBUG"))
yydebug = atoi(p);
#endif
Then you can include -DYYDEBUG in your compiler flags for debug builds and turn on the debugging code by something like setenv YYDEBUG 1 to set the envvar prior to running your program.
I suppose your syntax error message was generated by bison. What is striking is that it claims to have found a LEFTBRACKET when it expects a [. Naively, you might expect it to be satisfied with the LEFTBRACKET it found, but of course bison knows nothing about LEFTBRACKET except its numeric value, which will be some integer larger than 256.
The only reason bison might expect [ is if your grammar includes the terminal '['. But since your scanner seems to return LEFTBRACKET when it sees a [, the parser will never see '['.
I have a SREC file which is a simple text file and I want to read it line by line in verilog. How can I do that?
The following reads through a file, 1 line per clock cycle: expected data format is one decimal number per line.
integer data_file ; // file handler
integer scan_file ; // file handler
logic signed [21:0] captured_data;
`define NULL 0
initial begin
data_file = $fopen("data_file.dat", "r");
if (data_file == `NULL) begin
$display("data_file handle was NULL");
$finish;
end
end
always #(posedge clk) begin
scan_file = $fscanf(data_file, "%d\n", captured_data);
if (!$feof(data_file)) begin
//use captured_data as you would any other wire or reg value;
end
end
Thank you for the solution.
I modified it just a little to use 2 .txt file containing 32 HEX numbers on each row and found some difficulties on the way since I didn't understand what each line of code did. My findings were the following.
Just vars and regs declaration
////////I'm using inputs.txt and outputs.txt to read both lines at the same time
module Decryption_Top_Testbench;
////////TEXT DOC variables
integer file_outputs ; // var to see if file exists
integer scan_outputs ; // captured text handler
integer file_inputs ; // var to see if file exists
integer scan_inputs ; // captured text handler
//TXT
reg [127:0] captured_outputs; ///Actual text obtained from outputs.txt lines
reg [127:0] captured_inputs; ///Actual text obtained from inputs.txt lines
Opening both files
initial
begin
// TEXT FILE outputs///////////////////////
file_outputs = $fopen("C:/outputs.txt", "r"); //Opening text file
//you should use the full path if you don't want to get in the trouble
//of using environment vars
if (file_outputs == 0) begin // If outputs file is not found
$display("data_file handle was NULL"); //simulation monitor command
$finish;
end
// TEXT FILE inputs///////////////////////
file_inputs = $fopen("C:/inputs.txt", "r"); //Opening text file (inputs)
if (file_inputs == 0) begin //If inputs file is not found
$display("data_file handle was NULL");
$finish;
end
end
At this part, I will read line by line in HEX format and store it in "captured_outputs" register and "captured_inputs" register.
///Since I'm using it just to simulate I'm not interested on a clock pulse,
/// I want it to happen all at the same time with whatever comes first
always #(* )
begin
if (!$feof(file_outputs))
begin
///!$feof means if not reaching the end of file
///file_outputs is always returning a different number other than "0" if the doc
///has not ended. When reaching "0" it means the doc is over.
///Since both of my docs are the same length I'm only validating one of them
///but if you have different lenghts you should verify each doc you're reading
///
scan_inputs = $fscanf(file_inputs, "%h\n", captured_inputs); //Inputs Line text
scan_outputs = $fscanf(file_outputs, "%h\n", captured_outputs); //Outputs line text
$display ("Line :[inputs: %h _ outputs: %h ]" captured_inputs, captured_outputs);
// Displaying each line at the simulation monitor
///$fscanf means formatted text, $scanf would read text ignoring the format
/// %h\n means it should expect HEX numbers and the end of line character, that means
/// the line is over, but if you want to use a diff criteria
/// you can replace \n to whatever you may need
end
else
begin
$finish;
$fclose(file_outputs); //Closing files just in case to prevent wasting memory
$fclose(file_inputs);
end
end
I just wanted to contribute with something anybody who's starting to code in Verilog could understand and attach this great feature to his/her project.
Enjoy!
Here is a simplified version of the code I'm working on.
main :: IO ()
main = do
args <- getArgs
if null args
then putStr "> " ; userInput <- getLine
else userInput <- readFile $ head args
let conclusion = userInput
This won't work without do notation, the variable won't pass to conclusion below when I do use it, and the putStr, which I'm trying to use to create a kind of prompt, just makes it mad.
Is there something that I'm forgetting to add somewhere?
There are a few problems here. First, you need to include do after then and else:
if null args
then do putStr "> " ; userInput <- getLine
else do userInput <- readFile $ head args
if in do notation is the same as if everywhere else; you have to put an expression after then and else, not statements, and you need do to turn a bunch of statements into an expression. This still isn't quite valid, though; the last statement in a do block must be an expression, but you have a bind here. After all, every statement has to have a result value, but a bind has none.
The second problem is, as you've observed, that this introduces a new scope, and so you can't access variables you bind from outside. This makes sense if you think about it; after all, you could bind the variable on one side and not the other. The solution is to simply move the bind outside the if:
main :: IO ()
main = do
args <- getArgs
userInput <- if null args
then do putStr "> " ; getLine
else readFile $ head args
let conclusion = userInput
So, the action whose result we bind to userInput is still computed depending on the result of null args, but we bind the variable outside the conditional.
Note that I didn't add a do to the else branch this time; it's not required, since there's only a single expression there. (It's still valid, but it's unidiomatic to use do when it's not necessary.)
This code still won't work unless you put something after the let conclusion = userInput line (since, like I said, do blocks must end with an expression), but presumably you already have code there.
As an additional note, you should avoid using functions like head and tail; head is a partial function (not defined for every argument — head [] will produce an error), and those are generally considered unidiomatic. You should use pattern-matching instead, like this:
userInput <- case args of
[] -> do putStr "> " ; getLine
fileName:_ -> readFile fileName
This is just like the pattern-matching used when defining a function, but for a single value rather than any number of arguments.
Any variable bindings you do in the then and else blocks won't be visible in the outer scope, so you need to bind the result from the if clause itself.
main :: IO ()
main = do
args <- getArgs
userInput <- if null args
then do
putStr "> "
getLine
else readFile $ head args