I'm writing a major mode for a language and I want to offer completion after '.', or following a keypress. Completions are determined by sending a request to a backgound process using process-send-string and set-process-filter. The returned list of completions is dependent on the background process parsing the current state of the file and being instructed to give completions at that particular point.
I have tried using the popular autocomplete package, but it is really not written with this use case in mind. This is partly because it offers automatic suggetions (i.e. without keypress), which is a nice feature that I don't need. The function that you offer it to call needs to be called synchronously, and emacs process control is asynchronous. I have coded something up along the lines of https://github.com/Golevka/emacs-clang-complete-async, but it doesn't feel robust at all, and has been very fiddly to get it working.
I like the menus used in autocomplete, and would like to know what would fit best with my use-case, preferably while also looking nice.
You can wait synchronously for a background process's output with accept-process-output. You might like to take a look at gud-gdb-completions and gud-gdb-run-command-fetch-lines in a recent enough version of gud.el.
Related
I need to know when posting completes after eglSwapBuffers. I was thinking eglWaitNative might halt execution until positing is complete, but I find it unclear reading the spec, chapter 3.8:
https://www.khronos.org/registry/egl/specs/eglspec.1.5.pdf
It would appear eglWaitNative is used to synchronizing "native" rendering API such as Xlib and GDI. However as far as I know eglSwapBuffers might be running on top of Wayland which can´t render shit. Still, it would seem reasonable to believe the EGL_CORE_NATIVE_ENGINE engine always points out the "marking engine" doing buffer swaps...
From 3.10.3 I read:
Subsequent client API commands can be issued immediately, but will not
be executed until posting is completed.
I suppose I could do something like this but I´d rather use "pure" egl if possible:
eglSwapBuffers(...);
glClear(...); // "Dummy" command.
My project is using OpenGL Safety Critical profile 1.0.1, EGL 1.3 and some vendor specific extensions. Sync objects are not available.
I'm new to iOS development (and Obj-C), and I'm trying to port an existing C program to iOS.
The C program usually runs in the console, but I want to make a UI for it on the iPhone. I've already ported the C code, and when the simulator is run I can get the printf output in the console window. I want to avoid changing the original code as much as possible, so this is my plan:
The program takes some time to execute, so I think I need to run it on a seperate thread. It look likes I'll only need an NSInvocationOperation to call it's main method.
I will redirect stdout to a pipe.
On another thread, I will read from the pipe, and throw this to the UI. I'm not sure what might be the best concurrancy API to use for this.
Is this a good strategy for the iOS, or is there a better alternative for porting this? Are there any pitfalls I should look out for?
For concurrency, use the dispatch queues for quickest programming. See this guide: http://developer.apple.com/library/ios/#documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html
To print to the screen, you could do this in many different ways, but just use a UILabel if you just want get text up there right away. You can also format it nicely later.
Main pitfalls for multithreading are like on any OS - locking any data models that have simultaneous read/write. You can use #synchronize or make your dispatch queues thread safe by using dispatch barriers also noted in the linked guide above.
I'm writing the docs of my program online, in a wiki, and my intent is to rip that content from the program itself, either from time to time or on demand.
For extra leetness, it would be cool to the get the display functions themselves online, but this I cannot do unless I'm assured that they are safe to run, ie, they won't modify important variables, make system calls, nor steal information from the user. Is this implemented on Elisp or implementable?
It sounds like you want to be able to run your elisp code in a sandbox. A bit of googling lead me to sandbox.el. I haven't tried it, but it might be a good place to start.
is there any thing for providing remote procedure call in emacs to the outside world ?
is there anyone working on a bert, messagepack, thrift, even xml-rpc server in emacs ?
here is my work in progress using json to communicate with emacs. https://github.com/tinku99/elisp_rpc
i wonder if json-rpc is used for cross language work out of the box... it seems like the specification stops short of managing the connection... which seems like half the battle.
Elnode works as an HTTP server.
It shouldn't be too hard to build a handler that receives JSON or XML or whatever you like, unpacks it and does something interesting.
Elnode includes an example handler called "insideout" that publishes the buffer list of the emacs instance via http. If you browse to http://localhost:8028/ you get an HTML page that gives an itemized list of the active buffers.
Starting with that you could do something interesting I suppose. For example, you could build a handler that slurps in and emits json, using Edward O'Connor's json.el
One issue with using Emacs as an rpc server would be the lack of threading in Emacs. The Distel library "extends Emacs Lisp with Erlang-style processes and message passing"; so, you can use it to provide an rpc mechanism. A while back, I wrote a number of blog posts on Distel:
Distel = Erlang-like Concurrency in Emacs
Distel = Emacs erlang-mode++
Concurrent/Parallel Programming - The Next Generation - Part 2 (the bottom of that post)
They will give you a bit of a "feel" for what it's like to use Distel in Emacs.
I found this stompl implementation also https://github.com/jwhitlark/Stompem/blob/master/stompem.el
I wonder how hard it would be to write a zeromq or rabbitmq implementation in emacs.
I am using the wonderful AnyEvent for creating an asynchronous TCP server (specifically, a MUD server).
In order to keep everything running smoothly and with as few blocking/synchronous pieces of code possible, I have replaced some modules I was using with their asynchronous counterpart, for example AnyEvent::Memcached and AnyEvent::Gearman. This allows the main program to be quite speedy, which is desirable. I have coded around the need for some of these calls to be synchronous.
One problem I currently have, and the focus of this question, is logging.
Before turning to AnyEvent for this server program, I was using Log::Log4perl as it allows me to fine-tune which modules or subroutines should be logged, at which level and to which log output (screen, file, etc).
The problem here is that the Log4perl actions (warn, info, etc) are currently performed synchronously but I have no requirement for that as long as the log lines eventually end up on the screen / file (and in the correct order).
Is Log::Log4perl still the right choice when using an asynchronous event handler such as AnyEvent, or should I look at a different module? If so, which is recommended?
AnyEvent::Log, which comes with AnyEvent, uses AnyEvent::IO, which appends to files asynchronously when IO::AIO is available (and synchronously when not).
What you are trying to avoid? If it's synchronous file IO (writing to log files/stdout etc.) then your problem would probably be solved with an asynchronous and/or buffering appender(s) rather than replacing all use of Log4perl in your code.
Log::Log4perl::Appender::Buffer seems like it might be a good start, but a completely async appender doesn't appear to exist anymore.