I would like to apply uncrustify (via beautify in the Atom editor and a config file) to CUDA code. However, I don't know how to tell uncrustify to recognize CUDA kernel calls which have the following structure:
kernelName <<<N,M>>> (arg0,arg1,...);
However, uncrustify has problems with the <<< >>> and applying it gives the following unpleasant result
kernelName << < N, M >> >
(arg0,arg1,...);
I would like to have it look more like a function call and also avoid the formatting of <<< to << <. Ideally, the result would look like
kernelName <<< N, M >>> (arg0,arg1,
...); // line break if argument list is too long
Which arguments can I add to my config.cfg to achieve the above result?
Thank you very much.
Looking through whole documentation of uncrustify, I have found 2 arguments that could influence in your CUDA kernel style:
sp_compare { Ignore, Add, Remove, Force }
Add or remove space around compare operator '<', '>', '==', etc
And:
align_left_shift { False, True }
Align lines that start with '<<' with previous '<<'. Default=true
You can try to play around with these parameters to be more closely to the solution although I would try something like:
sp_compare = Remove
align_left_shift = False
Related
I'm using yaml-cpp on a for a variety of things on my project. Now I want to write out some data as JSON. Since JSON is a subset of YAML, at least for the features I need, I understand it should be possible to set some options in yaml-cpp to output pure JSON. How is that done?
yaml-cpp doesn't directly have a way to force JSON-compatible output, but you can probably emulate it.
YAML:Emitter Emitter;
emitter << YAML:: DoubleQuoted << YAML::Flow << /* rest of code */;
Jesse Beder's answer didn't seem to work for me; I still got multiple lines of output with YAML syntax. However, I found that by adding << YAML::BeginSeq immediately after << YAML::Flow, you can force everything to end up on one line with JSON syntax. You then have to remove the beginning [ character:
YAML::Emitter emitter;
emitter << YAML::DoubleQuoted << YAML::Flow << YAML::BeginSeq << node;
std::string json(emitter.c_str() + 1); // Remove beginning [ character
Here is a fully worked example.
There's still a major issue, though: numbers are quoted, turning them into strings. I'm not sure whether this is an intentional behavior of YAML::DoubleQuoted; looking at the tests, I didn't see any test case that covers what happens when you apply DoubleQuoted to a number. This issue has been filed here.
If you iterate over .VARIABLES and print each, any true variable can be printed correctly with the following rule:
print_variables: $(foreach V,$(.VARIABLES),print-$(V)) .phony_explicit
print-%: .phony_explicit; #echo "$* = \"$($*)\""
.PHONY: .phony_explicit ...
A 0- or 1-line function will still work, but any more will result in Syntax error: Unterminated quote string. Just one multiline function will break the entire print_variables rule. As a workaround, I have added ;\ to each line in my function definitions, but that won't fix existing multiline functions (either via includes from this makefile or via other makefiles including this one.) What can I do? Is there a container of just function variables, or a way to test if a variable is a function definition?
A simple minimal example would be easier to understand; this has nothing to do with .VARIABLES, pattern rules, etc. (and I'm not sure what the point of the .phony_explicit prereq is..)
define F
foo
bar
endef
print: ; echo "F = $(F)"
will show the problem:
echo "F = foo
/bin/sh: 1: Syntax error: Unterminated quoted string
This is because when make sees a variable that contains newlines in a recipe, it assumes that the newlines mean you want the lines of the variable to become lines in the recipe.
First in general you should use single-quotes around strings you send to the shell, unless you need the shell to expand them; it won't help in this situation but in general it's much safer.
There's no way to undo that, really. You have a number of options.
The first is to not use echo but instead use the make function info:
print-F: ; $(info F = "$(F)")
yields:
F = "foo
bar"
Another option is to use subst to replace the newlines with some other value. The new value cannot itself contain explicit newlines, but you can ask the shell to print a newline for you:
# Create a variable containing a single newline
# Note this must contain TWO newlines!
define NL
endef
print-F: printf 'F = "$(subst %,%%,$(subst $(NL),\n,$(F))"\n'
Yields:
printf 'F = "foo\nbar"\n'
F = "foo
bar"
One final option is to convert your makefile to use the .ONESHELL feature, but I assume that's a step too far just to get this debugging output available :).
In the following code, we can assign the result of a GET-WORD to p through a SET-WORD, and then use it under the new name:
p: :print
p [{Hello} {World}]
But what if you are using COMPOSE, and you find a situation such as this?
do compose [p: (:print)]
p [{Hello} {World}]
That gives an error:
*** ERROR
** Script error: -unnamed- is missing its value argument
** Where: do
** Near: do compose [p: (:print)] p ["Hello" "World"]
So it's like function values in a block are "live" when seen in the interpreter...whether they were fetched as an evaluative result or not. (It would seem they should be inert unless fetched or applied somehow, otherwise such assignments are not possible from within a COMPOSE or similar.)
It seems you have to quote a get-word, such as:
do compose [p: (quote :print)]
p [{Hello} {World}]
That could do the trick to make p the print function. But can you do it without going through a GET-WORD or similar as a proxy?
Yes, you can "disarm" the active function! value with a feature of the DO-dialect:
>> do probe compose [p: quote (:print)]
[p: quote make native! [[
"Outputs a value followed by a line break."
value [any-type!] "The value to print"
]]]
>> p [{Hello} {World}]
Hello World
They key here is the special argument passing mode used for the single argument of QUOTE:
>> source quote
quote: make function! [[
"Returns the value passed to it without evaluation."
:value [any-type!]
][
:value
]]
This argument passing mode, unimaginatively called "get arguments", inhibits evaluation of the argument value. So in our particular case, it prevents the "active" nature of the function! value to come to bear.
For more details about argument passing modes, you might want to have a look at this recent treatise about literal and get arguments, which compares the differences between Rebol 2 and Rebol 3 to give a historical perspective.
Use the following way to create the get-word, it buys you an additional level of indirection:
>> do compose [p: (to-get-word 'print)]
>> p [{Hello} {World}]
Hello World
If you want the assignment to be done using a DO [...] form, then you need a word assigned to the anonymous function in order to manipulate it in a passive way.
An alternative option is to do the assignment outside of the composed block:
p: first compose [(:print)]
The first question is what do you need this for?
Because it works without compose.
Do [p: :print]
P 1
And without a get-word
Do [p: get first [print]]
Edit:
I don't understand the implications for the C++ binding, but 'compose is used to evaluate parts of a block selectively. In your example you want to evaluate a part, but still want it not being evaluated, so you need to stop it from being evaluated too early, for example:
do compose [p1: (to get-word! 'x)]
If you want to use compose, and no get-/lit-word!, you could try quote:
do compose [p4: get quote ( quote print)]
The inner 'quote guards 'print from being evaluated during compose, the outer one guards durng the 'do, so that 'get can get the value.
Good morning fellow programmers!
i'm working on a project using haskell, and i've wanted to know how to run a haskell function without having to type two lines on ghci, for example
ghci filename.hs function
This can only be done doing:
ghci filename.hs
function
????
I'm looking for something like the main () in C,which runs automatically when you compile the program
Is there something like that?
I've been checking the -e option on ghci, but i cant seem to get it to work!
Thank you very much!
Cheers!
You're probably looking for ghc -e instead:
> echo 'foo x y z = x+y*z' > foo.hs % let's make a foo.hs file
> ghc foo.hs -e 'foo 1 2 3' % call the function in foo.hs
=> 7
Also, note that you can also use the :reload command in ghci. Load the file in ghci, edit, type :reload and test again. Also, if this seems too tedious, you can also define a ghci macro which allows you to reload and test your function at the same time:
> :def test \x -> return (":reload\n" ++ x)
> :test foo 1 2 3
=> Ok, modules loaded: Foo.
7
If you're looking to build real programs instead of quickly testing
your functions, then you'd better read the other answers on writing
main functions.
I assume function has the type IO (). Then you can just let main = function, and use for example runhaskell modulename from the command line. As in C, main is a special function.
To clarify a bit, just in case: If your function is a pure one, i.e. one whose type does not invovle IO, you can't really "run it". I guess it's a simplification to say this, but essentially what GHCi does is to call print function. If you want to mimic this, you can use something like main = print function and use runhaskell. This assumes function's type is an instance of Show.
I'm just getting started on F#, and when playing around with operator overloading, I've run into something I don't quite understand. Now, I understand that you can't use, for example, +* as an overloaded prefix operator; it can only be an infix operator. Here's where I get confused, however:
let (+*) a = a + a * a;;
If I run this, fsi tells me that the function (+*) is an int->int. Great, I can dig that -- it's not an overloaded operator, just a normal function named (+*). So, if I do:
printf "%d" ((+*) 6)
I'll get 42, as I expect to. However, if I try:
printf "%d" (+*) 6
or
printf "%d" (+*)6
It won't compile. I can't put the exact error up right now as I don't have access to an F# compiler at this moment, but why is this? What's going on with the binding here?
It's interpreting this:
printf "%d" (+*) 6
Like this:
printf ("%d") (+*) (6)
In other words, passing three curried arguments to printf, the second of which is a reference to the function +*.