I am making a Julia wrapper for a C/C++ library. The C/C++ functions that I am wrapping write to standard output. Is there a way to redirect those messages from the Julia side without commenting/removing the write statements from the C/C++ code?
You can use redirect_stdout for this.
oldstd = stdout
redirect_stdout(somewhere_else)
ccall(:printf, Cint, (Cstring,), "Hello World!")
Base.Libc.flush_cstdio() # it might be necessary to flush C stdio to maintain the correct order of outputs or forcing a flush
redirect_stdout(oldstd) # recover original stdout
You may want to use redirect_stdout(f::Function, stream) method instead. Here, f should be a function taking no parameter (i.e. like () -> do_something(...)). This method automatically recovers the stream to stdout. Using do syntax;
redirect_stdout(somewhere) do
ccall(:printf, Cint, (Cstring,), "Hello World!")
Base.Libc.flush_cstdio() # might be needed
end
Related
I am writing a tool in Julia that requires a package with a deprecated function.
My script is called from the command line and takes many arguments so I would like to avoid using --depwarn=no to suppress deprecation warnings.
Instead, I'd like to embed this --depwarn=no or somehow signal this into my script so the user doesn't have to type it in, or worry about it whenever they run the script.
Does anyone know how can I do this using only Base Julia without installing any another package like Suppressor.jl?
I wrote Suppressor initially, as far as I know there is no other way right now, which is why I started Suppressor.
You could always copy paste verbatim the suppress* macro you need, into your code (but I would advise just to use Suppressor honestly, in case of updates), all the Suppressor macros are self contained and require only Base (if you are on 0.6.x this macros shouldn't need Compat).
#suppress_err (latest version):
"""
#suppress_err expr
Suppress the STDERR stream for the given expression.
"""
macro suppress_err(block)
quote
if ccall(:jl_generating_output, Cint, ()) == 0
ORIGINAL_STDERR = STDERR
err_rd, err_wr = redirect_stderr()
err_reader = #async read(err_rd, String)
end
value = $(esc(block))
if ccall(:jl_generating_output, Cint, ()) == 0
redirect_stderr(ORIGINAL_STDERR)
close(err_wr)
end
value
end
end
If you just want to get rid of the deprecation warnings, then #suppress_err is all you need. There have been improvements recently on the current Julia master branch related to logging, but I haven't checked out those yet.
I'd like to fancy up my embedding of Julia in a MATLAB mex function by hooking up Julia's STDIN, STDOUT, and STDERR to the MATLAB terminal. The documentation for redirect_std[in|out|err] says that the stream that I pass in as the argument needs to be a TTY or a Pipe (or a TcpSocket, which wouldn't seem to apply).
I know how I will define the right callbacks for each stream (basically, wrappers around calls to MATLAB's input and fprintf), but I'm not sure how to construct the required stream.
Pipe was renamed PipeEndpoint in https://github.com/JuliaLang/julia/pull/12739, but the corresponding documentation was not updated and PipeEndpoint is now considered internal. Even so, creating the pipe up front is still doable:
pipe = Pipe()
Base.link_pipe(pipe)
redirect_stdout(pipe.in)
#async while !eof(pipe)
data = readavailable(pipe)
# Pass data to whatever function handles display here
end
Furthermore, the no-argument version of these functions already create a pipe object, so the recommended way to do this would be:
(rd,wr) = redirect_stdout()
#async while !eof(rd)
data = readavailable(rd)
# Pass data to whatever function handles display here
end
Nevertheless, all of this is less clear than it could be, so I have created a pull request to clean up this API: https://github.com/JuliaLang/julia/pull/18253. Once that pull request is merged, the link_pipe call will become unnecessary and pipe can be passed directly into redirect_stdout. Further, the return value from the no-argument version will become a regular Pipe.
Each process is building some array and is writing this array in the "correct" place, using mpi_file_write_at().
After writing to the file I read from the same place and it is not what I wrote. The code is attached. I am just a beginner in MPI, so sorry if the question is not clever.
program output
use mpi
implicit none
integer :: ierr,i,proc_num,file,intsize
integer :: status(mpi_status_size)
integer,parameter :: count=10
integer,dimension(count) :: buf
integer,dimension(3*count) :: arr
integer(kind=mpi_offset_kind) :: disp
call mpi_init(ierr)
call mpi_comm_rank(MPI_COMM_WORLD,proc_num,ierr)
do i=1,count
buf(i) = proc_num*count+i
enddo
call mpi_file_open(MPI_COMM_WORLD,'out.txt',mpi_mode_wronly+mpi_mode_create,mpi_info_null,file,ierr)
call mpi_type_size(mpi_integer,intsize,ierr)
disp = proc_num*count*intsize
call mpi_file_write_at(file,disp,buf,count,mpi_integer,status,ierr)
if (proc_num==0) then
call mpi_file_read_at(file,0,arr,3*count,mpi_integer,status,ierr)
write(*,*),arr
endif
call mpi_file_close(file,ierr)
call mpi_finalize(ierr)
end program output
Thank you!
You are using mpi_mode_wronly to open the file. As stated here, it corresponds to "write only". Consequently, mpi_file_read_at() is likely to fail. It can be checked by looking at the output parameter ierr.
Could you try the mpi_mode_rdwr flag ? This should enable both read and write operations.
Moreover, MPI_File_write_at() is a noncollective operation. So process 0 can call mpi_file_read_at() before process 1 exited MPI_File_write_at(). A mpi_barrier() can be added to prevent that. Take a look at http://www.mpi-forum.org/docs/mpi-2.2/mpi22-report/node305.htm . It features various examples using MPI_File_write_at(). It is likely that additional calls to MPI_File_sync() and MPI_File_set_view() are required as well.
Notice that the code you provided is equivalent to a call to the function MPI_Gather().
I have two options for printing to the console in ClojureScript. Which is the more idiomatic?
(.log js/console "Hello World!")
or
(enable-console-print!)
(println "Hello world!")
My question is: Which is the more idiomatic method in ClojureScript for printing to the console?
(enable-console-print!) just sets *print-fn* to console.log. After calling (enable-console-print!) both (println ...) and (.log js/console ...) are functionally equivalent.
However use of println has 3 benefits:
There is no explicit interop with JavaScript which makes code cleaner
You have possibility to change logging functionality in one place - just set *print-fn* to something different (for example, use alert in browser, write logs to DB in Node.JS, etc)
In case of common Clojure/ClojureScript code it's the only option (you cannot use .log function)
I'm using a local emacs instance (aquamacs) to run R processes on a remote server, and I'd like to automate the process of connecting to my server. The process is as follows:
[in emacs]
M-x shell
[in the resulting console]
TERM=xterm
ssh -Y -C <my remote server>
screen -rd [and/or] R
[in emacs]
M-x ess-remote
r
I discovered this general approach here: http://blog.nguyenvq.com/2010/07/11/using-r-ess-remote-with-screen-in-emacs/. The -Y -C options allow you use xterm to view plots. I don't know lisp and tho I've googled around a bit, I can't seem to piece together how to actually define a function to automate this (e.g., in .emacs.el). Has anyone implemented anything like this?
Let's assume you just want to call shell in code. In Lisp, everything is prefix notation surrounded by parentheses. So we enter this into a buffer (say, the scratch buffer):
(shell)
Move your pointer to the end of the line after the close-paren, and type <C-x C-e> to execute the Lisp code. You should see that the shell function is called.
Now, let's make it a function, so we can add other things to it. The command to create a function is defun, and it takes the name of the function, the argument list (in parentheses), and then the body of the function:
(defun automate-connection ()
(shell))
Move your cursor to the end of the code, hit <C-x C-e>, and the function will be defined. You can call it from Lisp by executing
(automate-connection)
Ok, now we just need to put some text into the shell buffer.
(defun automate-connection ()
(shell)
(insert "TERM=xterm"))
Now, when we run that, we get "TERM=xterm" put into the shell buffer. But it doesn't actually send the command. Let's try putting a newline.
(defun automate-connection ()
(shell)
(insert "TERM=xterm\n"))
That puts in a newline, but doesn't actually make the command run. Why not? Let's see what the enter key does. Go to your *shell* buffer, and type <C-h c>, then hit the return key. (<C-h c> runs describe-key-briefly, which prints the name of the function invoked by hitting the given key). That says that when you hit RET, it's not putting a newline, but actually calling comint-send-input. So let's do that:
(defun automate-connection ()
(shell)
(insert "TERM=xterm")
(comint-send-input))
Now, when you run `(automate-connection) from any Lisp code, you should get the given thing sent. I leave it as an exercise to the reader to add your other commands.
But wait! We're not really done, are we? I assume you don't want to have to move to a Lisp scratch buffer, type in (automate-connection), then evaluate that code. You probably just want to type , and call it a day. You can't do that by default with the function we just created. Luckily, it's simple to allow that: just add a call to (interactive) in your function:
(defun automate-connection ()
(interactive)
(shell)
(insert "TERM=xterm")
(comint-send-input))
Now you can call it as you want, and it'll open the *shell* buffer, put in the text, and tell Emacs to tell the shell to run that text.