I'm new to working with Pure Data. I can send messages from Python to Pure Data but I'm interested in trying to get error messages back. There are error messages in Pure Data's terminal window. Is it possible to get at these with a Pure Data object? Or is there another mechanism I can use?
Perhaps this answer by umläute to a related question could be helpful to you: use the -stderr startup flag in Pd and capture the stderrin your Python script.
Related
I'm running mitmproxy on Windows (mitmweb.exe). There is any way to set option not to store captured data?
The problem is in memory consumption when mitmproxy is running long time.
I have not found any solution, so I have wrote a very simple proxy program using https://github.com/justcoding121/Titanium-Web-Proxy
I'm trying to use the lpc1343 as a i2cslave to transmit some data. Writing to the board gives no problems and works exactly as I want it.
However, reading from the board gives problems. It seems I'm not getting any data back although I am sending the right commands. Whenever I try to debug it my board just hangs and I have to reset the driver and my pc to get it running again.
Also, I made a LED go on/off whenever I try to read from it. It only does this once and whenever I try to do it again nothing happens. I think the I2c is stopped then but I have no idea why.
I have found the example code on the website once but now it seems to be gone. Does somebody have an updated I2cslave code?
Which operating system are you writing code for and how can you tell that writing to the i2c chip is successful?
If the write function returns, it could be that the message has been sent but the chip is in a weird configuration that doesn't act on the message received.
I have a perl app which processes text files from the local filesystem (think about it as an overly-complicated grep).
I want to design a webapp which allows remote users to invoke the perl app by setting the required parameters.
Once it's running it would be desirable some sort of communication between the perl app and the webapp about the status of the process (running, % done, finished).
Which would be a recommended way of communication between the two processes? I was thinking in a database table, but I'm not really sure it's a good idea.
any suggestions are appreciated.
Stackers, go ahead and edit this answer to add code examples or links to them.
DrNoone, two approaches come to mind.
callback
Your greppy app needs to offer a callback function that returns the status and which is periodically called by the Web app.
event
This makes sense if you are already using a Web server/app framework which exposes an event loop usable from external applications (rather unlikely in Perl land). The greppy app fires events on status changes and the Web app attaches/listens to them and acts accordingly.
For IPC as you envision it, a plain database is not so suitable. Look into message queues instead. For great interop, pick AMPQ compliant implementation.
If you run the process using open($handle, "cmd |") you can read the results in real time and print them straight to STDOUT while your response is open. That's probably the simplest approach.
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.