I'd like to put arguments on different lines, but I get parse errors on all the variations I try, including adding commas, allwin-style parens, and different indentations.
constructor: (
#a
#b
#c
) ->
Try:
constructor:\
( #a
, #b
, #c
) ->
Both trailing \ and leading , suppress newlines in CoffeeScript.
It appears you are out of luck. If you look at the grammar rules for the function definition, you will see that the rule is defined as:
'PARAM_START ParamList PARAM_END FuncGlyph Block'
The rule for Block allows for TERMINATOR tokens (which are semi-colon or carriage return) but the ParamList rule (the one you are interested in adding a new line in) does not allow for it.
Related
This may sound like a duplicate, but existing solutions does not work.
I need to remove all non-alphanumerics from a varchar field. I'm using the following but it doesn't work in all cases (it works with diamond questionmark characters):
select TRANSLATE(FIELDNAME, '?',
TRANSLATE(FIELDNAME , '', 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'))
from TABLENAME
What it's doing is the inner translate parse all non-alphanumeric characters, then the outer translate replace them all with a '?'. This seems to work for replacement character�. However, it throws The second, third or fourth argument of the TRANSLATE scalar function is incorrect. which is expected according to IBM:
The TRANSLATE scalar function does not allow replacement of a character by another character which is encoded using a different number of bytes. The second and third arguments of the TRANSLATE scalar function must end with correctly formed characters.
Is there anyway to get around this?
Edit: #Paul Vernon's solution seems to be working:
· 6005308 ??6005308
–6009908 ?6009908
–6011177 ?6011177
��6011183�� ??6011183??
Try regexp_replace(c,'[^\w\d]','') or regexp_replace(c,'[^a-zA-Z\d]','')
E.g.
select regexp_replace(c,'[^a-zA-Z\d]','') from table(values('AB_- C$£abc�$123£')) t(c)
which returns
1
---------
ABCabc123
BTW Note that the allowed regular expression patterns are listed on this page Regular expression control characters
Outside of a set, the following must be preceded with a backslash to be treated as a literal
* ? + [ ( ) { } ^ $ | \ . /
Inside a set, the follow must be preceded with a backslash to be treated as a literal
Characters that must be quoted to be treated as literals are [ ] \
Characters that might need to be quoted, depending on the context are - &
Eclipse's built-in help shows #a and #c for some methods, here is an example:
#remarks This creates a window like elm_win_add(), but also puts in a
standard background using elm_bg_add() as well as setting the window
title to #a title. The window type created is of type #c ELM_WIN_BASIC
with #c NULL as the parent widget.
What does #a and #c mean?
Looks like JavaDoc-style markup, which is also supported by Doxygen.
From the doxygen documentation:
All commands in the documentation start with a backslash (\) or an at-sign (#).
...
\a <word>
Displays the argument in italics. Use this command to emphasize words. Use this command to refer to member arguments in the running text.
\c <word>
Displays the argument using a typewriter font. Use this to refer to a word of code. Equivalent to <tt>word</tt>.
I am trying to extract a part of a string and put it into a new variable. The string I am looking at is:
maker-scaffold_26653|ref0016423-snap-gene-0.1
(inside a $gene_name variable)
and the thing I want to match is:
scaffold_26653|ref0016423
I'm using the following piece of code:
my $gene_name;
my $scaffold_name;
if ($gene_name =~ m/scaffold_[0-9]+\|ref[0-9]+/) {
$scaffold_name = $1;
print "$scaffold_name\n";
}
I'm getting the following error when trying to execute:
Use of uninitialized value $scaffold_name in concatenation (.) or string
I know that the pattern is right, because if I use $' instead of $1 I get
-snap-gene-0.1
I'm at a bit of a loss: why will $1 not work here?
If you want to use a value from the matching you have to make () arround the character in regex
To expand on Jens' answer, () in a regex signifies an anonymous capture group. The content matched in a capture group is stored in $1-9+ from left to right, so for example,
/(..):(..):(..)/
on an HH:MM:SS time string will store hours, minutes, and seconds in $1, $2, $3 respectively. Naturally this begins to become unwieldy and is not self-documenting, so you can assign the results to a list instead:
my ($hours, $mins, $secs) = $time =~ m/(..):(..):(..)/;
So your example could bypass the use of $ variables by doing direct assignment:
my ($scaffold_name) = $gene_name =~ m/(scaffold_[0-9]+[|]ref[0-9]+)/;
# $scaffold_name now contains 'scaffold_26653|ref0016423'
You can even get rid of the ugly =~ binding by using for as a topicalizer:
my $scaffold_name;
for ($gene_name) {
($scaffold_name) = m/(scaffold_\d+[|]ref\d+)/;
print $scaffold_name;
}
If things start to get more complex, I prefer to use named capture groups (introduced in Perl v5.10.0):
$gene_name =~ m{
(?<scaffold_name> # ?<name> creates a named capture group
scaffold_\d+? # 'scaffold' and its trailing digits
[|] # Literal pipe symbol
ref\d+ # 'ref' and its trailing digits
)
}xms; # The x flag lets us write more readable regexes
print $+{scaffold_name}, "\n";
The results of named capture groups are stored in the magic hash %+. Access is done just like any other hash lookup, with the capture groups as the keys. %+ is locally scoped in the same way the $ are, so it can be used as a drop-in replacement for them in most situations.
It's overkill for this particular example, but as regexes start to get larger and more complicated, this saves you the trouble of either having to scroll all the way back up and count anonymous capture groups from left to right to find which of those darn $ variables is holding the capture you wanted, or scan across a long list assignment to find where to add a new variable to hold a capture that got inserted in the middle.
My personal rule of thumb is to assign the results of anonymous captured to descriptively named lexically scoped variables for 3 or less captures, then switch to using named captures, comments, and indentation in regexes when more are necessary.
This question already has answers here:
Why aren't newlines being printed in this Perl code?
(3 answers)
Closed 8 years ago.
Let's take the following minimalistic script:
#!/usr/bin/perl
#
# conditional_operator.pl
#
use strict;
print ( 1 ? "true" : "false" )." statement\n";
exit;
I expect the output always to be "true statement". But when I execute this snippet, I see ...
deviolog#home:~/test$ perl conditional_operator.pl
true
The " statement\n" concatenation seems to be ignored.
My perl version is v5.14.2. I read the perlop manual about the conditional operator and think, a string concatenation should be possible.
Can somebody explain this behaviour?
Always include use warnings; at the top of every script.
To get your desired behavior, just add parenthesis so print is called with the entire argument instead of just the first part:
print(( 1 ? "true" : "false" )." statement\n");
If you'd had warnings turned on, you would've gotten this alert:
Useless use of concatenation (.) or string in void context
You can also avoid the undesired behavior by leading with a blank concatenation, or you could put a plus sign before the parenthesis:
print +( 1 ? "true" : "false" )." statement\n";
print ''.( 1 ? "true" : "false" )." statement\n";
Adding use warnings to your code gives this:
print (...) interpreted as function at ./cond line 10.
Useless use of concatenation (.) or string in void context at ./cond line 10.
Even better, add use diagnostics and you get this:
print (...) interpreted as function at ./cond line 11 (#1)
(W syntax) You've run afoul of the rule that says that any list operator
followed by parentheses turns into a function, with all the list
operators arguments found inside the parentheses. See
"Terms and List Operators (Leftward)" in perlop.
Useless use of concatenation (.) or string in void context at ./cond line 11 (#2)
(W void) You did something without a side effect in a context that does
nothing with the return value, such as a statement that doesn't return a
value from a block, or the left side of a scalar comma operator. Very
often this points not to stupidity on your part, but a failure of Perl
to parse your program the way you thought it would. For example, you'd
get this if you mixed up your C precedence with Python precedence and
said
$one, $two = 1, 2;
when you meant to say
($one, $two) = (1, 2);
Another common error is to use ordinary parentheses to construct a list
reference when you should be using square or curly brackets, for
example, if you say
$array = (1,2);
when you should have said
$array = [1,2];
The square brackets explicitly turn a list value into a scalar value,
while parentheses do not. So when a parenthesized list is evaluated in
a scalar context, the comma is treated like C's comma operator, which
throws away the left argument, which is not what you want. See
perlref for more on this.
This warning will not be issued for numerical constants equal to 0 or 1
since they are often used in statements like
1 while sub_with_side_effects();
String constants that would normally evaluate to 0 or 1 are warned
about.
Perl wants to explain the problems to you. You just need to ask it what you're doing wrong :-)
I have a string like this <name>sekar</name>. I want to split this string (i am using perl) and take out only sekar, and push it into an array while leaving other stuff.
I know how to push into an array, but struck with the splitting part.
Does any one have any idea of doing this?
push #output, $1 if m|<name>(\w*)</name>|;
Try this:
my($name) = $string =~ m|<name>(.*)</name>|;
From perldoc perlop:
If the "/g" option is not used, "m//" in list context returns a
list consisting of the subexpressions matched by the
parentheses in the pattern, i.e., ($1, $2, $3...).
Try <(("[^"]*"|'[^']*'|[^'">])*)>(\w+)<\/\1>. Should work, when I get home I'll test it. The idea is that the first capture group finds the contents within a <> and its nested capture group prevents a situation like <blah=">"> matching as <blah=">. The third capture group (\w+) matches the inner word. This may have to be changed depending on the format of the possibilities you can have within the <tag>content</tag>. Lastly the \1 looks back at the content of the first capture group so that this way you will find the proper closing tag.
Edit: I've tested this with perl and it works.