I am using C in Objective C and I want to capture stdout to UIView from Console.
Here is the line I'm talking about:
print(stdout, v=toplevel_eval(v));
Other than you are writing in C I have no idea how much you know about C, "Unix" and Cocoa I/O - so some of this you may already know.
Here is one possible solution, it looks more complicated than it is.
Reading:
You need to understand the system calls pipe, dup2 and read.
You need to understand the GCD function dispatch_async and how to obtain a GCD queue.
pipe and dup2 are often used in conjunction with fork and exec to launch a process and write/read to/from that process standard input/output. What you will be doing uses some of the same basic ideas so looking up examples of this common pattern will help you understand how these calls work. Here are some notes from a University: Pipe, Fork, Exec and Related Topics.
Outline:
Using dispatch_async schedule a block to handle the reading and writing of the data. The block will:
Use pipe To create a pipe and dup2 To connect stdout - file descriptor 1 - it.
Enter a loop which uses read to obtain the available data from the pipe. Data read will be in a byte array.
Within the loop convert the read bytes into an NSString
Within the loop append that string to your view - you must do this on the main thread as it involves the UI, and you can do that using another dispatch_async specifying the main queue.
That is it. Your block will now execute concurrently in the background reading whatever your C code writes to the standard output and adding it to your view.
If you get stuck you can ask a new question showing the code you have written and describing what doesn't work.
HTH
Related
I am working on a Fortran code with MPI on ray-tracing.
The issue is that the code has a large array that is needed in all processors.
But this array is read-only for all processors at every time step,
then it is updated at the beginning of the next time step.
The current code uses one processor to read this array from an external file,
then simply broadcast it to all processors. In this way, every processor has a copy of this array.
To save some memory, I was planning to use OpenMP, but this question MPI Fortran code: how to share data on node via openMP? shows that MPI3.0 can do the trick.
But in the answers of the above question, unfortunately there is no example on how to broadcast the array to nodes.
I wonder anyone can help to provide an example?
Thanks in advance!
EDIT: I included some more details of the code structure as suggested by Vladimir.
Below is a pseudo-code showing the current treatment in the code:
allocate(largearray,size)
do i=1,10
!!! Update largearray
if(myrank==0) then
~~~read from file~~~ largearray
call MPI_BCAST(largearray,size,MPI_DOUBLE_PRECISION,0,MPI_COMM_WORLD,ierr)
do while(.true.)
call MPI_RECEIVE(results)
call collector(results,final_product)
exit
end do
call output(final_product,i)
else
call MPI_BCAST(largearray,size,MPI_DOUBLE_PRECISION,0,MPI_COMM_WORLD,ierr)
call radiation(largearray,beams)
call raytracing(beams,largearray,results)
call MPI_SEND(results,0)
end if
end do
deallocate(largearray)
In my extension, I need to write a huge file (say around 20 gigs) to the disk. Currently I am doing it in the main thread, but file creation is very expensive operation. I was about to move the whole file creation process to a ChromeWorker, but based on https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Functions_and_classes_available_to_workers I cannot have access to the nsiFile from a ChromeWorker.
So my questions are:
1. Is it possible to access Cc, Ci, and Cu from within a ChromeWorker?
2. If not what would be the most efficient way to create and fill large files in Firefox. Note that I need to write the file based on segments and offsets (Ci.nsISeekableStream).
It's not possible to access nsIFile from ChromeWorker. But nsIFile is horrible synchronus option.
Go with OS.File: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/OSFile.jsm
On that page go to the link for usage on workers: https://developer.mozilla.org/docs/Mozilla/JavaScript_code_modules/OSFile.jsm/OS.File_for_workers
On the mainthread os.file returns promises.
In worker they are synchronus. Wrap your os.file functions in worker with a try-catch, as when an error occurs, (like os.file.remove with option of ignoreAbsent set to false) then the catch will hold the OS.File.Error object.
Great move to ChromeWorker btw! I'm a huge fan of ChromeWorkers. I wrote a simple example of jsm using chromeworker here: https://github.com/Noitidart/jpm-chromeworker
For segments, you'll have to OS.File.open and then on the return value do a .setPosition() then you can read certain number of bytes from that position, or write, or whatever. Its awesome stuff. OS.File is the new way and the recommended way to do file operations. Its been around awhile now though since like Firefox 29 or before that.
I am having trouble using pthreads in my MPI program. My program runs fine without involving pthreads. But I then decided to execute a time-consuming operation in parallel and hence I create a pthread that does the following (MPI_Probe, MPI_Get_count, and MPI_Recv). My program fails at MPI_Probe and no error code is returned. This is how I initialize the MPI environment
MPI_Init_thread(&argc, &argv, MPI_THREAD_MULTIPLE, &provided_threading_support);
The provided threading support is '3' which I assume is MPI_THREAD_SERIALIZED. Any ideas on how I can solve this problem?
The provided threading support is '3' which I assume is MPI_THREAD_SERIALIZED.
The MPI standard defines thread support levels as named constants and only requires that their values are monotonic, i.e. MPI_THREAD_SINGLE < MPI_THREAD_FUNNELED < MPI_THREAD_SERIALIZED < MPI_THREAD_MULTIPLE. The actual numeric values are implementation-specific and should never be used or compared against.
MPI communication calls by default never return error codes other than MPI_SUCCESS. The reason for that is, MPI calls the communicator's error handler before an MPI call returns and all communicators are initially created with MPI_ERRORS_ARE_FATAL installed as their error handler. That error handler terminates the program and usually prints some debugging information, e.g. the reason for the failure. Both MPICH (and its countless variants) and Open MPI produce quite elaborate reports on what led to the termination.
To enable user error handling on communicator comm, you should make the following call:
MPI_Comm_set_errhandler(comm, MPI_ERRORS_RETURN);
Watch out for the error codes returned - their numerical values are also implementation-specific.
If your MPI implementation isn't willing to give you MPI_THREAD_MULTIPLE, there's three things you can do:
Get a new MPI implementation.
Protect MPI calls with a critical section.
Cut it out with the threading thing.
I would suggest #3. The whole point of MPI is parallelism -- if you find yourself creating multiple threads for a single MPI subprocess, you should consider whether those threads should have been independent subprocesses to begin with.
Particularly with MPI_THREAD_MULTIPLE. I could maybe see a use for MPI_THREAD_SERIALIZED, if your threads are sub-subprocess workers for the main subprocess thread... but MULTIPLE implies that you're tossing data around all over the place. That loses you the primary convenience offered by MPI, namely synchronization. You'll find yourself essentially reimplementing MPI on top of MPI.
Okay, now that you've read all that, the punchline: 3 is MPI_THREAD_MULTIPLE. But seriously. Reconsider your architecture.
I'm using flex & bison to parse a custom language and I'm in the situation described here: http://www.gnu.org/software/bison/manual/html_node/How-Can-I-Reset-the-Parser.html.
To be more precise
I invoke yyparse several times, and on correct input it works
properly; but when a parse error is found, all the other calls fail
too. How can I reset the error flag of yyparse?
My parser and scanner run inside a separate thread, but there is only one thread working with the input file. In my understanding I don't need to write a reentrant scanner since there is only one thread working with the input file. In that page the problem is clearly explained but the solution is not clear to me.
It says:
Therefore, whenever you change yyin, you must tell the Lex-generated
scanner to discard its current buffer and switch to the new one. This
depends upon your implementation of Lex; see its documentation for
more. For Flex, it suffices to call ‘YY_FLUSH_BUFFER’ after each
change to yyin. If your Flex-generated scanner needs to read from
several input streams to handle features like include files, you might
consider using Flex functions like ‘yy_switch_to_buffer’ that
manipulate multiple input buffers
My parser thread calls yyparse in order to build my AST. What is not clear to me is when and where I have to call yy_flush_buffer to fix the problem. In my understanding the scanner code (generated by Flex) is called by the parser code (generated by Bison). The Bison generated code is generated by the grammar. As a result the parser code is not under my direct control. This means I cannot include the call to yy_flush_buffer into the parser code since it would be overwritten every time I generate the parser code by the grammar. It means that I should put the yy_flush_buffer in the grammr file somewhere. But where?
I fixed the problem by doing:
...
FILE *f = fopen(_filename, "r");
yyrestart(f);
yyparse();
...
I leave the question since it could be useful for other people.
I'm using a game engine that allows you to program in Lua. The game engine commands are in a DLL created from C. There is a exe created in C that calls a Lua file. This Lua file is where you put all your game code including the main loop. There is no going back and forth with the exe, but you can call functions from the DLL.
So in here before the main loop I create a function which I'm going to create a coroutine from. This function iterates over a pretty big table so every n iterations I yield. This function has an infinite while loop around that because I need this stuff to run every single cycle of the main game loop, but it's OK if it's split between multiple cycles.
I then create a coroutine with this function as the parameter. In the main game loop I then resume this coroutine.
When I run my code I get the error: tempt to yield across metamethod/C-call boundary
I was reading some stuff online but not really understanding what the issue is here. Once the exe calls the Lua file it doesn't go back to the exe at all until the Lua file is finished, and since I have my main loop in the Lua file it never finishes in my test case.
What are my options with this then?
The error is telling you that you are attempting to yield from within Lua code where there is some C function between the Lua code doing the yielding and the Lua code that resumed the coroutine. To hit this error, what you have to have done is call some C function from Lua, which calls back into Lua code, which then calls coroutine.yield().
You can't do that. You must instead restructure your code to avoid this. Since you didn't provide any code, there's not much that can be suggested.
There are several things you can do if you cannot change your code to avoid the C/metamethod boundary:
If you are using standard Lua, and are compiling it yourself, try patching it with Coco — True C Coroutines for Lua.
True C coroutine semantics mean you can yield from a coroutine across a C call boundary and resume back to it.
Try using LuaJIT instead of the standard Lua interpreter. It uses a fully resumable VM meaning the boundary is not an issue.
Try using Lua 5.2. It features yieldable pcall and metamethods which means that it can handle your problem. However, there are some changes and incompatibilities between Lua 5.1 and Lua 5.2.