For a Ruby project I need an OpenCPU server to process some statistics by R packages. OpenCPU has an JSON REST API, so with Ruby I can easily hook into that to communicate with R. So far, so good.
One of those packages has a strange (at least to me) syntax.
add <- function(.argument1, .argument2) {
return(.argument1 + .argument2)
}
So this is just an example, not the actual function. The part I found weird are those points in front of parameters. When I suggested to remove those points, the developer of the package said that it was meant to hide the variables from the overview of variables in IDE (R-Studio). It sounds to me like he wanted to make the parameters, what we call it, private, or at least to scope it somehow. I searched the internets to explain this feature of R, but found nothing.
The actual problem is: we use Ruby, Ruby translates data into JSON and sends it to OpenCPU. OpenCPU looks up for the right package/function, passes arguments and executes it. Then it returns to OpenCPU which makes a JSON response. Ruby's >1.9 Hash syntax that we prefer to work with looks like:
{ argument1: 4, argument2: 3 }.to_json
# => { "argument1": 4, "argument2": 3 }
instead of older forced by the package arguments:
{ ".argument1" => 4, ".argument2" => 3 }.to_json
# => { ".argument1": 4, ".argument2": 3 }
So in desperate search for an argument to convince the R-developer not to use the dots, my question was still unanswered: does this point in front of the parameters have a real functionality in R or is it just a hack to exclude the variables from the IDE?
I think you will find that the reason comes from the default behaviour of the ls function in R which does not return objects beginning with a point. This can be modified by the all.names parameter:
all.names a logical value. If TRUE, all object names are returned. If FALSE, names which begin with a . are omitted.
It is quite common for more technical functions or variables to be "hidden" in this way, e.g. .Machine, .Options, .Fortran, .dynLibs
Related
I would like to know if there is a message I can override in Pharo so that my custom classes display more descriptive information in the inspector/debuger much like simple variable types do, like Integers or Strings. For instance:
Instead of that, I would like it to show a more custom and informative description consisting of its internal variales so as to have a tighter/tidier view of the variables instead of having to click on it and open another chart (therefore losing sight of the information on the previous chart). I know you can increase the amount of charts shown below, but that is not the point of the question. I would like to achieve something like this:
I have browsed the pharo forums and found nothing, I have also tried overriding over 30 methods hoping that one of them changed the output. Only the class message seemed to change the output, but I could only return an instance of Metaclass and besides messing with this message would break a lot of stuff. Finally I tried to reverse engineer the debugger and then the inspector to see at which point is the table constructed and what values are used or which messages are sent to build said values, but it was just too much for me, the callstack kept growing and I couldn't even scratch the surface.
Luckily, doing this in any Smalltalk is very easy. Types inherited from Object are expected to answer to the message printString, and ultimately printOn: aStream. Those messages are expected to give a description of the object. So, you should just override printOn: in your class (printString uses printOn:) and all the browsers and inspectors will automatically use it. There other possibilities in Pharo, if you want to provide more complex information in different tabs, but I think printOn: will suffice for you.
An example would be:
MyPoint>>printOn: aStream
aStream nextPut: ${.
x printOn: aStream.
aStream nextPutAll: ', '
y printOn: aStream.
aStream nextPut: $}
In Smalltalk, every time you observe something you don't like or understand, you ask the question: Which message is doing this?
In your case, the question would be: Which message creates the string a MyPoint that I see everywhere?
Next, to answer your question you need to find a good place for inserting a halt and then debug from there until you find the culprit. To do this just find the simplest expression that would reproduce the issue and debug it. In your case the right-click command in the Playground will do. So,
Write and select (MyPoint on: 14 and: -5) halt in a Playground.
Right-click and issue the Print it command (I'm assuming you already checked that this command produces the string 'a MyPoint').
Debug
Go over the evaluation of #DoIt, which answers the result
Continue this way alternating between Into and Over to make sure you follow the result to where it's being taken
Eventually you will reach the implementation of Object >> #printString. Bingo!
Now you can open a System Browser and take a look at this method, study how it's been implemented in different classes, etc. Your investigation should show you that the most basic message for printing is #printOn:. You may also want to take a look at other implementors so to better understand what people usually do. (Bear in mind that writing good #printOn:s is a minimalist art)
Overriding printOn: will work for simple cases where you want to just change description.
Pharo allows a lot more than that!
Due the extensible (moldable) nature of our inspector, you do not need to override a method to get your own visualisation of the object.
For example, look this array visualisation:
This is obtained adding this method to Collection:
gtInspectorItemsIn: composite
<gtInspectorPresentationOrder: 0>
^ composite fastList
title: 'Items';
display: [ self asOrderedCollection ];
beMultiple;
format: [ :each | GTObjectPrinter asTruncatedTextFrom: each ];
send: [ :result |
result
ifNil: [ nil ]
ifNotNil: [ result size = 1
ifTrue: [ result anyOne ]
ifFalse: [ self species withAll: result ]
]
]
if you browse for senders of gtInspectorPresentationOrder: you will see there are already a lot of special visualisations in the image.
You can take those as an example on how to create your own, adapted exactly to what you need :)
I just created a new Angular app that installed the new RxJS v6.3 (released 6 days ago), which "fixed" a problem with pipe and strong typing.
With v6.2 I could specify only the final returning value of the pipe (in this case, .pipe<User>, like this:
getStatus(): Observable<User> {
return this.http.get('/user/status')
.pipe<User>(
tap(foo, bar),
finalize(() => this.requestEnded()),
map((resp) => new User(resp.user)));
}
But in the new version they removed that possibility in the Observable class (they fixed this line from v6.2.2, to this in v6.3). The IDE complains with this message:
Expected at least 0 arguments, but got 1 or more.
Now I am forced to specify types for every function in the pipe, something like this:
getStatus(): Observable<User> {
return this.http.get('/user/status')
// If I have 3 piped functions I have to specify all 3 types
.pipe<{}, {}, User>(
tap(foo, bar),
finalize(() => this.requestEnded()),
// I even have to specify type for this parameter (resp)
map((resp: {user}) => new User(resp.user)));
}
Was this really intended? Note that this is a "fix" to pipe, which means to me that pipe was always supposed to work like that. Or am I using it the wrong way?
I even had this function that worked nicely, I just passed in some "common pipes" that I wanted to execute for every request:
logIn(username: string, password: string, remember: boolean) {
return this.http.post('/user/login', { username, password, remember })
.pipe<User>(
...this.commonPipes(),
map(resp => new User(resp.user)));
}
But now, how am I supposed to specify types for that?
This change was introduced in v6.3 which says it "fixes" some error with pipe (it references this issue). I write "fixes" because for me it broke things, it's not backwards compatible, and I haven't found a "how to upgrade" guide that explains how to use the new, fixed pipe().
The problem was that the spread syntax could only be used in a couple of versions in which the signatures for pipe were 'fixed'. However, those 'fixes' essentially broke all type checking for pipe - which was far worse, so they were reverted and changed again.
As noted in this issue, using the spread syntax with pipe requires TypeScript 3.0 - as it supports tuple parameter extraction and spreading.
As an alternative to having commonPipes return an array of operators, you could look at using the static pipe function to compose the operators into a single operator that can then be passed to an observable's pipe method.
Have a look at my Combining Operators article.
I've been working at implementing a simple serial forking described in the TM module's documentation (the Q values are stored as a priority weight in a mysql table) where my proxy is querying a database to determine to what domain to forward to.
I've verified through extensive use of xlog that a variable I'm using to build the new URI to use with seturi is getting everything correctly. I use an append_branch call in a subsequent while loop iterating over my sql query results, which doesn't have any problems with taking a very similarly formatted parameter. However, when I go to restart Kamailio it simply gripes at me that a string is expected. The line it corresponds to from console is just the seturi call. I've tried casting as a string, but that doesn't seem to be part of 4.4 (or my syntax is wrong).
I've thought about building the URI strings and storing into avp, but I suspect I'd have the same problem.
For reference, this is what I'm doing:
$var(basedest) = "sip:" + $var(number) + "#" + $(dbr(destination=>[0,0]))+ ":" + $var(port);
seturi($var(basedest));
And what it's outputting when trying to load the config:
<core> [cfg.y:3368]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 570, column 9-22: syntax error
<core> [cfg.y:3371]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 570, column 23: bad argument, string expected
Naturally, when I put $var(basedest) in double quotes, it's literally interpreted as a string. Single quotes behave similarly. Is there something I can do to work around this? When I feed it an explicit hardcoded string, it's happy as a can be and the routing works fine. When I try to do something very simple like the above, it gets upset. If possible, I'd like to avoid updating as I initially grabbed Kamailio from the yum repo.
Thanks in advance - this has been bugging me a good while.
Apparently, not a new problem. I ended up finding out what I can do to work around it.
For reference, seturi and $ru pseudo variable refer to the same thing. So basically you'd just do:
$var(mynewru) = "sip:user#domain:5060";
$ru = $var(mynewru);
This would achieve the same thing I was originally attempting to do before based on the TM module's documentation. For serial forking, issuing some number of append_branch calls is fine.
As an exercise in python lambdas (just so I can learn how to use them more properly) I gave myself an assignment to sort some strings based on something other than their natural string order.
I scraped apache for version number strings and then came up with a lambda to sort them based on numbers I extracted with regexes. It works, but I think it can be better I just don't know how to improve it so it's more robust.
from lxml import html
import requests
import re
# Send GET request to page and parse it into a list of html links
jmeter_archive_url='https://archive.apache.org/dist/jmeter/binaries/'
jmeter_archive_get=requests.get(url=jmeter_archive_url)
page_tree=html.fromstring(jmeter_archive_get.text)
list_of_links=page_tree.xpath('//a[#href]/text()')
# Filter out all the non-md5s. There are a lot of links, and ultimately
# it's more data than needed for his exercise
jmeter_md5_list=list(filter(lambda x: x.endswith('.tgz.md5'), list_of_links))
# Here's where the 'magic' happens. We use two different regexes to rip the first
# and then the second number out of the string and turn them into integers. We
# then return them in the order we grabbed them, allowing us to tie break.
jmeter_md5_list.sort(key=lambda val: (int(re.search('(\d+)\.\d+', val).group(1)), int(re.search('\d+\.(\d+)', val).group(1))))
print(jmeter_md5_list)
This does have the desired effect, The output is:
['jakarta-jmeter-2.5.1.tgz.md5', 'apache-jmeter-2.6.tgz.md5', 'apache-jmeter-2.7.tgz.md5', 'apache-jmeter-2.8.tgz.md5', 'apache-jmeter-2.9.tgz.md5', 'apache-jmeter-2.10.tgz.md5', 'apache-jmeter-2.11.tgz.md5', 'apache-jmeter-2.12.tgz.md5', 'apache-jmeter-2.13.tgz.md5']
So we can see that the strings are sorted into an order that makes sense. Lowest version first and highest version last. Immediate problems that I see with my solution are two-fold.
First, we have to create two different regexes to get the numbers we want instead of just capturing groups 1 and 2. Mainly because I know there are no multiline lambdas, I don't know how to reuse a single regex object instead of creating a second.
Secondly, this only works as long as the version numbers are two numbers separated by a single period. The first element is 2.5.1, which is sorted into the correct place but the current method wouldn't know how to tie break for 2.5.2, or 2.5.3, or for any string with an arbitrary number of version points.
So it works, but there's got to be a better way to do it. How can I improve this?
This is not a full answer, but it will get you far along the road to one.
The return value of the key function can be a tuple, and tuples sort naturally. You want the output from the key function to be:
((2, 5, 1), 'jakarta-jmeter')
((2, 6), 'apache-jmeter')
etc.
Do note that this is a poor use case for a lambda regardless.
Originally, I came up with this:
jmeter_md5_list.sort(key=lambda val: list(map(int, re.compile('(\d+(?!$))').findall(val))))
However, based on Ignacio Vazquez-Abrams's answer, I made the following changes.
def sortable_key_from_string(value):
version_tuple = tuple(map(int, re.compile('(\d+(?!$))').findall(value)))
match = re.match('^(\D+)', value)
version_name = ''
if match:
version_name = match.group(1)
return (version_tuple, version_name)
and this:
jmeter_md5_list.sort(key = lambda val: sortable_key_from_string(val))
I have the following path:
http://192.168.56.10:4567/browse/foo/bar?x=100&y=200
I want absolutely everything that comes after "http://192.168.56.10:4567/browse/" in a string.
Using a splat doesn't work (only catches "foo/bar"):
get '/browse/*' do
Neither does the regular expression (also only catches "foo/bar"):
get %r{/browse/(.*)} do
The x and y params are all accessible in the params hash, but doing a .map on the ones I want seems unreasonable and un-ruby-like (also, this is just an example.. my params are actually very dynamic and numerous). Is there a better way to do this?
More info: my path looks this way because it is communicating with an API and I use the route to determine the API call I will make. I need the string to look this way.
If you are willing to ignore hash tag in path param this should work(BTW browser would ignore anything after hash in URL)
updated answer
get "/browse/*" do
p "#{request.path}?#{request.query_string}".split("browse/")[1]
end
Or even simpler
request.fullpath.split("browse/")[1]
get "/browse/*" do
a = "#{params[:splat]}?#{request.env['rack.request.query_string']}"
"Got #{a}"
end