I have a function to retrieve an IP from a github repo. I get the error "Symbol's value as variable is void: response" the first time I call the function, but any subsequent calls after the first are successful. I tried adding (require 'url) but to no avail.
(defun get-ip ()
(let ((url-request-method "GET")
(url-request-extra-headers
'(("Authorization" . "token xxxxxxxxx")
("Accept" . "application/vnd.github.v3.raw"))))
(progn (url-retrieve "https://api.github.com/repos/xxxxxxx"
(lambda (status)
(progn (setq response (buffer-substring (point-min) (point-max)))
(kill-buffer (current-buffer))))
nil
'silent)
(string-match "\\([0-9]*\\.[0-9]*\\.[0-9]*\\.[0-9]*\\)" response)
(match-string 0 response))))
You should not create a global response variable. Add it to your let form instead, so that it is local to the defun. See also https://www.gnu.org/software/emacs/manual/html_node/elisp/Local-Variables.html
More fundamentally, url-retrieve is an asynchronous function: the code which attempts to set response will not yet have a buffer to operate on when url-retrieve has finished evaluating (it will continue in the background, and eventually call its callback in the lambda, but there is no guarantee that this happens during the execution of your form). The simple but slightly clunky solution is to switch to url-retrieve-synchronously and live with the fact that it could take a while.
You also need to take care to avoid clobbering the user's buffer, their position within that buffer, or the regex match history.
With these fixes, it is also natural to factor out response entirely.
(defun get-ip ()
(let ((url-request-method "GET")
(url-request-extra-headers
'(("Authorization" . "token xxxxxxxxx")
("Accept" . "application/vnd.github.v3.raw"))))
(save-match-data
(save-current-buffer
(set-buffer
(url-retrieve-synchronously "http://www.google.com/" 'silent))
(goto-char (point-min))
(if (search-forward-regexp "\\([0-9]*\\.[0-9]*\\.[0-9]*\\.[0-9]*\\)" nil t)
(match-string 0) "")))))
Related
In order to use some online service, I need to call an API three times.
Upload the file
Request an operation
Download the file
I can handle all operations individually but I have hard times to sequence them as they are asynchronous. I wish I can handle all operations in one function call and all I am asking here is some advice to start on the right foot.
I have been playing with promises but got lost in the progress.
function main(){
//Pseudo code
calling async step1
exit if step1 failed
calling async step2
exit if step2 failed
calling async ste3
exit if step3 failed
return OK
}
Thanks in advance.
Since you've given us no real code and no specific information on your APIs, I will offer an answer assuming that the APIs return promises or can be made to return promises. In that case, sequencing and doing error handling is quite simple:
ascync function main() {
let step1Result = await step1();
let step2Result = await step2();
let step3Result = await step3();
return finalValue;
}
// usage
main().then(finalResult => {
console.log(finalResult);
}).catch(err => {
console.log(err);
});
Some things to know:
Because main is declared async, it can use await internal to its implementation.
Because main is delcared async, it will always return a promise
This code assumes that step1(), step2() and step3() return promises that are linked to the completion or error of one or more asynchronous operations.
When the function is executing, as soon as it hits the first await, the function will return an unresolved promise back to the caller.
If any of the await stepX() calls reject (e.g. have an error), that will abort further execution of the function and reject the promise that was previously returned with that specific error. It works analogous to throw err in synchronous programming, but the throw is caught automatically by the async function and turned into a reject for the promise that it already returned.
Your final return value in the function is not actually what is returned because remember, a promise was already returned from the function when it hit the first await. Instead, the value you return becomes the resolved value of that promise that was already returned.
If your API interfaces don't currently return promises, then you can usually find a wrapper that someone has done to create a version that will return promises (since promises are the modern way of working with asynchronous interfaces in Javascript). Or, you can create your own wrapper. In node.js, you can use util.promisify() or you can manually make your own wrapper (just takes a few lines of code).
If you need to catch an error within the function in order to handle it and continue, you can either wrap a given await call in try/catch or use .catch() on the promise and "handle" the error and continue processing, again similar to handling exceptions in synchronous code.
If any of the steps had an error and rejected their promise, then main() will abort and reject similar to throwing an exception in synchronous code.
See also:
How to chain and share prior results with Promises
I get a Cannot access a disposed object error when running the following code (MyClient is a WCF client generate by a service reference in a C# project).
type Action =
| Add
| Update
let addStuff (myClient:MyClient) arg = async {
let! response = myClient.AddAsync arg |> Async.AwaitTask
return response.ID
}
let updateStuff (myClient:MyClient) arg = async {
let! response = myClient.UpdateAsync arg |> Async.AwaitTask
return response.ID
}
let doStuff arg =
use myClient = new MyClient()
match arg.Action with
| Add -> arg |> addStuff myClient
| Update -> arg |> updateStuff myClient
let args = [Add, Add, Update, Add]
let results =
args
|> List.map doStuff
|> Async.Parallel
It seems the client is being disposed before I expect it to. If I change doStuff to:
let doStuff arg = async {
use myClient = new MyClient()
return!
match arg.Action with
| Add -> arg |> addStuff myClient
| Update -> arg |> updateStuff myClient
}
The return type of both functions is Async<int>. Why is the client being disposed early in the first example? I would think both examples are logically identical. My understanding is that the async workflow is only necessary if you need to use the ! bindings which I do not think is necessary in this case as the actual await is happening in the specific functions.
The problem is with doStuff:
let doStuff arg =
use myClient = new MyClient()
match arg.Action with
| Add -> arg |> addStuff myClient
| Update -> arg |> updateStuff myClient
You are passing myClient into an async function which captures the MyClient instance. However, when doStuff returns it calls Dispose on the MyClient instance and disposes the client. When your async method gets around to running it is using a disposed instance.
Making doStuff works because the dispose becomes part of the async workflow.
Another option would be to not use the MyClient instance but instean have addStuff and updateStuff create their own MyClient instance.
What the async { ... } block gives you in this case are two things:
It delays the execution of all the code inside it until the async computation is executed,
It handles the use keyword accordingly (i.e. the IDisposable will be disposed after the nested addStuff/updateStuff workflow executes).
As to whether the pattern you use is wrong - yes, it is.
F# async and C# async-await are two very different constructs with very different semantics, and experiences from one don't carry easily to the other.
C# async-await is a way of chaining Tasks. A Task<'t> is a future, that is, a container for a value of type 't that becomes available at a later time. The computation that produces that value is, by default, scheduled immediately to execute on a background thread, accessing the value is a blocking operation until that computation finishes, and further attempts to access it return a cached value.
On the other hand, F# Async<'t> is value that represents an abstract specification of a computation that, once executed, yields a value of type 't. The execution however is deferred to the caller - who can make a choice how (and if at all) to execute the computation. Unlike a task, async doesn't carry a value of type 't - each execution yields a new (and potentially different) value.
Going back to your sample:
let doStuff arg =
use myClient = new MyClient()
match arg.Action with
| Add -> arg |> addStuff myClient
| Update -> arg |> updateStuff myClient
What you have here is a function that does some work and returns an Async<'t> value to the caller. The caller is then free do to whatever they want with it - execute it, ignore it, or pass it further without executing.
The reason why it fails is because myClient is being disposed when doStuff returns - which is before the caller has a chance to execute the async.
The problem comes from the fact that this pattern you use splits execution of a particular piece of logic into two - one part executes when the function is called, the other when the async is executed, whereas the code is written with the intent that everything there executes as a single unit.
It is a pattern that invites more or less subtle bugs, even if in many cases there would be no easy to observe effects of this discrepancy - especially if async is unconditionally executed immediately after the function returns.
I'm using spacemacs: https://github.com/syl20bnr/spacemacs
I've tried both user hook places for overriding cmd-k to be kill-buffer rather than delete-window. However, when I restart, neither works.
(defun dotspacemacs/user-init ()
"Initialization function for user code.
It is called immediately after `dotspacemacs/init'. You are free to put any
user code."
(defun dotspacemacs/user-init ()
(global-set-key (kbd "s-k") 'kill-buffer)
)
)
(defun dotspacemacs/user-config ()
"Configuration function for user code.
This function is called at the very end of Spacemacs initialization after
layers configuration. You are free to put any user code."
(global-set-key (kbd "s-k") 'kill-buffer)
)
What's the best way to debug this?
I just noticed that you have defined defun dotspacemacs/user-init inside defun dotspacemacs/user-init.
Rather than that, I test (global-set-key (kbd "s-k") 'kill-buffer) in dotspacemacs/user-init and dotspacemacs/user-config and works it both places.
Maybe the error it's something related to your config file.
Did you have enabled osx layer?
I should use Objective-C to read some slowly growing file (under Mac OS X).
"Slowly" means that I read to EOF before it grows bigger.
In means of POSIX code in plain syncronous C I can do it as following:
while(1)
{
res = select(fd+1,&fdset,NULL,&fdset,some_timeout);
if(res > 0)
{
len = read(fd,buf,sizeof(buf));
if (len>0)
{
printf("Could read %u bytes. Continue.\n", len);
}
else
{
sleep(some_timeout_in_sec);
}
}
}
Now I want to re-write this in some asynchronous manner, using NSInputSource or some other async Objective-C technique.
The problem with NSInputSource: If I use scheduleInRunLoop: method then once I get NSStreamEventEndEncountered event, I stop receiving any events.
Can I still use NSInputSource or should I pass to using NSFileHandle somehow or what would you recommend ?
I see a few problems.
1) some_Timeout, for select() needs to be a struct timeval *.
2) for sleep() some_timeout needs to be an integer number of seconds.
3) the value in some_timeout is decremented via select() (which is why the last parameter is a pointer to the struct timeval*. And that struct needs to be re-initialized before each call to select().
4) the parameters to select() are highest fd of interest+1, then three separate struct fd_set * objects. The first is for input files, the second is for output files, the third is for exceptions, however, the posted code is using the same struct fd_set for both the inputs and the exceptions, This probably will not be what is needed.
When the above problems are corrected, the code should work.
Is it possible to use Async CTP to emulate continuations and tail recursion?
I'm thinking something along the lines of:
async Task Loop(int count)
{
if (count == 0)
retrun;
await ClearCallStack();
//is it possible to continue here with a clean call stack?
Loop(count -1)
}
I guess one needs a custom scheduler and such, but would it be possible?
(that is, can it be used to recurse w/o blowing the call stack)
Yes, this is entirely possible.
In the newest Async CTP (Refresh for VS2010 SP1), there's a "GeneralThreadAffineContext" class in the Unit Testing sample (either in VB or C#). That provides the requisite helper code for just running an async method in a general purpose thread-affine manner.
By thread affinity, we mean that the async continuations get processed on the same context as the original thread, similarly to the behavior for WinForms/WPF, but without spinning up the real WPF or WinForms message loop.
Task.Yield()'s design is to defer the rest of the current method to the SynchronizationContext, so you don't even need to write your own await ClearCallStack(). Instead, your sample will boil down to:
async Task DoLoop(int count)
{
// yield first if you want to ensure your entire body is in a continuation
// Final method will be off of Task, but you need to use TaskEx for the CTP
await TaskEx.Yield();
if (count == 0)
return;
//is it possible to continue here with a clean call stack?
DoLoop(count -1)
}
void Loop(int count)
{
// This is a stub helper to make DoLoop appear synchronous. Even though
// DoLoop is expressed recursively, no two frames of DoLoop will execute
// their bodies simultaneously
GeneralThreadAffineContext.Run(async () => { return DoLoop(count); });
}