error in process sentinel: Invalid read syntax: "#" #52

Open
sprig opened this Issue Aug 19, 2015 · 6 comments

Projects

None yet

3 participants

@sprig
sprig commented Aug 19, 2015

Hello,

When running the following:

(async-start
(lambda ()
(set-face-font 'default "Source Code Pro for Powerline-11"))
(lambda (result) (message "result: %s" result))
)

The following messages are produced:

error in process sentinel: async-when-done: Invalid read syntax: "#"
error in process sentinel: Invalid read syntax: "#"

To remove the obvious, I do have the correct font installed and when run in a regular buffer, it works fine.

My emacs version:

"GNU Emacs 24.5.1 (x86_64-apple-darwin14.3.0, Carbon Version 157 AppKit 1347.57)
of 2015-08-03 on sprigs-MacBook.local"
Async: "20150817.2321"

@jordonbiondo

I think this is closely related to #17 and #22, the lambda is creating a closure that can't be read. I am also having this problem. #17 and #22 are closed, but I am wondering whether of not a solution was actually implemented.

If this is the same issue, is there any good way around it?

@thierryvolpiatto
Collaborator

Remember you are running code in an emacs batch (a different instance than the one you are on), what do you expect from the piece of code above ?

Of course the closure can't be read because the code you run expect buffers to work against, but it find nothing and fails.

So I see no bug here, just code that should not run async (at least with this implementation).

@sprig
sprig commented Aug 19, 2015

@jordonbiondo this might be related to the previous bugs but I think it isn't (I'll looked into them previously but will do so again in a moment). The issue here is not how values are passed to the batch emacs - you can try running the following and see that it works just fine:

(async-start
(lambda () (version))
(lambda (result) (message "result: %s" result))
)

@thierryvolpiatto, As I've stated above, the closure can be read just fine. The code does fail of course - I'm not arguing that. However, if you run it in an actual batch emacs, you get the following, useful, error message:

Font not available: #<font-spec nil nil Source\ Code\ Pro\ for\ Powerline nil nil nil nil nil 11.0 nil nil nil ((:name . "Source Code Pro for Powerline-11") (user-spec . "Source Code Pro for Powerline-11"))>

And here you see the actual issue - the batch emacs fails, and outputs an error message. The async module tries to eval in some manner the result and chokes up on the '#'. Therefore, what I would expect to happen is for a message similar to the following to appear:

Error in async code. Emacs returned the following error code: <code> and the following error message: <message>

So, you are right in principle that this code should not run async. However it is sometimes (as in my case) hard to split code that should and code that shouldn't, and appropriate error messages would help identify problematic locations.

If you are interested in my particular case:
I like to write papers in org-mode, and I like to see the compiled PDF as I write. If I compile it synchronously, then the process of writing gets interrupted, so I made a function that watches for file changed and thus recompiles every time I save. However, for this and for other purposes I need to load my org configuration which also depends on other parts of the config. I managed to mostly split it correctly so that I can load the just the necessary parts in batch, but those files are part of my regular config and I can sometimes put in (accidentally) changes that make it incompatible with async and thus I get the errors.

@thierryvolpiatto
Collaborator

sprig notifications@github.com writes:

Error in async code. Emacs returned the following error code: and the
following error message:

You have to implement this yourself, communicating with a tmp file with
the two emacs.

If you are interested in my particular case: I like to write papers in
org-mode, and I like to see the compiled PDF as I write.

Probably async is not the good tool for this task, you should look at
deferred and/or epc.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

@sprig
sprig commented Aug 19, 2015

On 19 August 2015 at 12:11, Thierry Volpiatto notifications@github.com
wrote:

sprig notifications@github.com writes:

Error in async code. Emacs returned the following error code: and the
following error message:

You have to implement this yourself, communicating with a tmp file with
the two emacs.

Already looking into this. At least there's no argument that such a thing
would be good :).

If you are interested in my particular case: I like to write papers in

org-mode, and I like to see the compiled PDF as I write.

Probably async is not the good tool for this task, you should look at
deferred and/or epc.

Why not? I've been happily using it for months, and it worked great until I
decided to change my default font.
Would you care to provide specific reasons why you think the other packages
are more appropriate?

@sprig
sprig commented Aug 19, 2015

P.S.

As a temporary workaround to my specific problem, I placed the problem code in a with-demoted-errors block.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment