Drop use of = in parsing arguments in raku - raku

The fact that you can write in raku the following
unit sub MAIN(Int $j = 2);
say $j
is amazing, and the fact that the argument parsing is done for you is beyond
useful. However I find personally extremely unergonomic
that for such arguments you habe to write a = to set the value, i.e.
./script.raku -j=5
I was wondering if there is a way to tell the parser that it should allow options without
the = so that I can write
./script.raku -j 5
I haven't seen this in the docs and this would really be much more intuitive for some people
like me. If it is not currently possible, I think it would be a useful add-on.

You could also use SuperMAIN, a library for CLI processing. This add some new superpowers to MAIN

There has been a lot of discussion of how command line parameters should be parsed. At the moment there are no plans of adding more functionality to what Raku provides out of the box.
If you want more tweakability, you should probably look at the Getopt::Long module by Leon Timmermans

Related

regex limitations within live template / can use live-template functions as replacement?

I'm removing builder pattern on multiple places. Following example would help me with the task, but mainly I'd like to learn how to use live templates more.
Preexisting code:
Something s = s.builder
.a(...)
.b(bbb)
.build();
and I'd like to remove it to:
Something s = new Something();
s.setA(...);
s.setB(bbb);
part of it can be trivially done using intellij regex, pattern: \.(.*)$ and replacement .set\u$1. Well it could be improved, but lets keep it simple.
I can create surround live template using variable:
regularExpression(SELECTION, "\\.(.*)", "\\u$1")
but \\u will be evaluated as u.
question 1: is it possible to get into here somehow \u functionality?
but I might get around is differently, so why not try to use live temlate variable:
regularExpression(SELECTION, "\\.(.)(.*)", concat(capitalize($1), "$2"))
but this does not seem to work either. .abc is replaced to bc
question 2: why? How would correct template look like? And probably, if it worked, this would behave incorrectly for multiline input. How to make it working and also for multiline inputs?
sorry for questions, I didn't find any harder examples of live templates than trivial replacements.
No, there is no \u functionality in the regularExpression() Live Template macro. It is just a way to call String.replaceAll(), which doesn't support \u.
You can create a Live Template like this:
set$VAR$
And set the following expression for the $VAR$ variable:
capitalize(regularExpression(SELECTION, "\\.(.*)", "$1"))

ObjC - Problems with using an NSLog replacement?

Being relatively new to programming--think Programming in Objective-C by Kochan, Chapter 15--I'm wondering if there's a reason why it's a bad idea--especially for a new programmer?--to use an NSLog replacement such as the following:
#define MGLog(format, ...) CFShow([NSString stringWithFormat:\
format, ## __VA_ARGS__])
and then call it as follows:
MGLog(#"Yo' mama wears combat boots.");
It's much cleaner to use this for learning how to manage strings, building a rolodex program, like he's got me doing, but I don't want to get into the habit of doing it this way if there are drawbacks. Thanks for any help, guys & gals.
BTW, if it matters, I'm using XCode 4.
Well, there is ABSOLUTELY no problem with that.
The purpose of log functions is to provide you with as much (useful) information as possible.
If you think that using THIS version of NSLog for debugging is more helpful to you, then how could it be wrong?
Note : The more involved you become with Objective-C/Cocoa program, the more likely it is that you'll set to one or the other log function (perhaps, one you'll write yourself to suit your particular needs).
Here's the one I'm mostly using :
#define _LOG(prefixch, fmt, ...) \
NSLog((NSString*)(CFSTR("%c [%s:%d] " fmt)), prefixch, \
__SRC_FILENAME__, __LINE__, ##__VA_ARGS__)
It shows the FILE we're in, the LINE we're at and anything else I might need...

Source style for Google Code Jam

I plan on doing the Code Jam competition next year. The problem is (something that I can't find anywhere) how do I set up my code to accept input and return an output?
I'm just confused as to how I am supposed to handle everything, say for example that I have to add 1 to the input and make the result the output, how would I handle the input/output?
I plan on using LUA. Thanks if you can. I think a code example would be best!
Go to http://www.go-hero.net/jam/11/solutions and choose the problem and the language. You'll find all the examples you need there. Including Lua ones.
http://www.go-hero.net/jam/
On this page you can see source code for every contestant.
You should be able to answer your question from it.
You can either do I/O on files or on stdin/stdout. It doesn't matter. I've seen examples that used files and examples that used stdin/stdout.
In Python say, you could write
import fileinput
f = fileinput.input()
Then call the script from the shell like this
gorosort.py A-small-practice.in
To save the output to a file
gorosort.py A-small-practice.in > A-small-practice.out

obfuscated way to get "0" in a tcl function, cross platform?

I haven't used tcl before and just need to do one trick, I can do it trivially in something like bash but I need it to work cross-platform (e.g. tcl in cygwin on windows).
Can someone suggest a short (5-10) obfuscated function that just returns 0 after taking two string args? It just can't do something like run shell commands that won't work under Mac/Cygwin.
fwiw, why do this: buying some time in writing a test- the thing generating one of the files is broken but I can't change it, making a hack in the TCL test script until I make extensive changes to use a different 'test core' that isn't broken. For now just declare the first file as 'good' if it exists.
I don't understand the requirement for obfuscation, but the simplest way to create a command that takes two arguments and returns 0 is this:
proc theCommandName {firstArgument secondArgument} {
return 0
}
There are all sorts of ways of making things obscure (e.g., a regular expression that doesn't actually match anything, a complicated expression) but as I said before, I don't understand the requirement in that area; I always try to make my code be the simplest thing that could possibly work…

What's bad about the VB With/End With keyword?

In this question, a user commented to never use the With block in VB. Why?
"Never" is a strong word.
I think it fine as long as you don't abuse it (like nesting)
IMHO - this is better:
With MyCommand.Parameters
.Count = 1
.Item(0).ParameterName = "#baz"
.Item(0).Value = fuz
End With
Than:
MyCommand.Parameters.Count = 1
MyCommand.Parameters.Item(0).ParameterName = "#baz"
MyCommand.Parameters.Item(0).Value = fuz
There is nothing wrong about the With keyword. It's true that it may reduce readibility when nested but the solution is simply don't use nested With.
There may be namespace problems in Delphi, which doesn't enforce a leading dot but that issue simply doesn't exist in VB.NET so the people that are posting rants about Delphi are losing their time in this question.
I think the real reason many people don't like the With keyword is that is not included in C* languages and many programmers automatically think that every feature not included in his/her favourite language is bad.
It's just not helpful compared to other options.
If you really miss it you can create a one or two character alias for your object instead. The alias only takes one line to setup, rather than two for the With block (With + End With lines).
The alias also gives you a quick mouse-over reference for the type of the variable. It provides a hook for the IDE to help you jump back to the top of the block if you want (though if the block is that large you have other problems). It can be passed as an argument to functions. And you can use it to reference an index property.
So we have an alternative that gives more function with less code.
Also see this question:
Why is the with() construct not included in C#, when it is really cool in VB.NET?
The with keyword is only sideswiped in a passing reference here in an hilarious article by the wonderful Verity Stob, but it's worth it for the vitriol: See the paragraph that starts
While we are on identifier confusion. The with keyword...
Worth reading the entire article!
The With keyword also provides another benefit - the object(s) in the With statement only need to be "qualified" once, which can improve performance. Check out the information on MSDN here:
http://msdn.microsoft.com/en-us/library/wc500chb(VS.80).aspx
So by all means, use it.