I wonder how Jena handle resource closing. For instance when readying a model in-memory from a file, Where is the code, that does the closing of the file, once the model is in memory ?
Can someone point me to a code or any doc that explain, the resource (file) management strategy of Jena?
The parser code is org.apache.jena.riot.RDFParser.
If the app code passes in a InputStream, it is responsible for closing it, e.g. using try-with-resources.
If a parser opens an InputStream, it closes it.
If you think there is a bug, please file a JIRA with a complete, minimal example.
Related
I am trying to add support for iCloud Documents in my existing app, but I am struggling badly with how to do that.
Apple seems to prefer that you use the UIDocument class for that. But UIDocument does not give direct access to the file in the file system, it expects to maintain a copy of the contents of the file in an NSData object instead. That is simply not doable in my case. All my current code and half of the 3rd party libraries that I use, work directly with the file on the file system, not with NSData. Rewriting all that code is simply not doable.
When not using the UIDocument class, Apple expects you to use the NSFileCoordinator to coordinate access to the file's contents. I am trying to do that with my code, but the methods on the NSFileCoordinator seem to expect that all reading and writing will be done in one synchronous sequence. All the methods of NSFileCoordinator take a block as argument, and expect all the reading/writing to be performed inside that block. When the block returns, you are not allowed to make any file access anymore, as far as I understand.
That is not doable in my case as well. Some of my code, and the 3rd party libraries, do the reading / writing in an asynchronous manner on background threads. I can identify the start and end of the period that the code needs access to the file contents, so if there was a separate requireAccess method, and separate relinquishAccess on the NSFileCoordinator, that would enable me to achieve the goal. But that does not seem to be the case.
It is unclear to me what the role of NSFilePresenter in this is. Some of the documentation, especially that of relinquishPresentedItemToReader() in NSFilePresenter seem to indicate that you can actually acquire / relinquish access separately:
If you want to be notified when the reader has completed its task,
pass your own block to the reader and use that block to reacquire the
file or URL for your own uses.
But it does not explain anywhere how to "reacquire" the file.
So the concrete question: I need to do the following steps in an asynchronous manner:
acquire access to the file, and obtain a file: URL for the file on the local file system
do multiple, asynchronous,
read/write operations on the file with normal file system
operations on that file: URL
relinquish access to the file
Does anybody know whether it is possible to do this, and how to do step 1 and step 3 ?
Is it possible to transform big file just posted to controller and start download of transformed file without saving files to disc? I would like to read big .CSV file, do some changes in fields and return transformed .CSV as a stream to user who upload initial file. Main problem is that I should not save file to disc. Is is possible to do with help of or I need to do ajax call?
Of course. So long as the file is not so huge it will cause memory problems on the server side. Even then, you're OK so long as you can transform the file line by line. In fact, most server file transformations are probably done in memory without writing anything to disk. This has nothing to do with "ajax" BTW, which is purely a term which relates to how the user interface is rendered.
Is there a way to open a presentation from a stream, memory file or isolated storage?
I have a presentation file that I want to open in PowerPoint, but do not want to allow user to access the file itself. Unfortunately the Presentations.Open() function of PowerPoint (and Open() of all other Office applications) only accepts a path parameter, which means I must save the file somewhere on the disk and then open it in PowerPoint, which will consequently give user access to the file.
Has anyone done this in any Office application?
You can use the OpenXML SDK to open documents from a stream, but not from within an Office application.
But, if you're motivated enough, you could delete the file after it's closed. It's pretty simple, you just need to create a separate process and wait for the file to not be locked for writing any more. Or, if you know when it's closed (e.g. if you do the closing in code), you may not need a separate process.
Is there a way to load a leveldb store from a data stream?
If I were to take the stream of a leveldb instance and tuck it in a DLL as a manifest resource stream, will I have a way to just load that db from that stream later when I retrieve the manifest resource from my DLL? Essentially, I am looking for a way to build, save, and later load a leveldb without ever writing to a physical file on disk.
Thanks in advance for any useful info.
Raja.
You might have already figured this out since it's been a long time since you asked.
leveldb allows you to override the "Environment" such that reads and writes don't need to access a physical file.
You might want to look at this file:
http://code.google.com/p/leveldb/source/browse/helpers/memenv/memenv_test.cc
in particular the DBTest, for an example.
In a Delphi 7 console application, how can I check whether stdin holds a character, without blocking until one is entered?
My plan is that this console program will be executed by a GUI program, and its stdin will be written to by the GUI program.
So I want my console app to periodically check stdin, but I can't find a way of doing this without blocking.
I have looked at this answer, which gets me a stream pointing to stdin, but there's still no way to "peek" as far as I can see.
I think you have already found the right way to read stdin. It is meant to block when there's nothing more to be read.
The standard way to handle this is to use a separate thread to handle the pipe. When it receives new data from stdin it signals this to the processing thread, for example with a message passing mechanism.
Having said all that, if you really want to poll you can call PeekNamedPipe to check if there is data in the pipe.
You could as the other answer says use threads, but even then you might have problems (using the threading method) unless you also investigate overlapped IO.
I normally use overlapped IO with serial ports rather than stdin, where "read a character if one is ready" is commonly needed, and where non-blocking IO is a usual way of working. You should be able to adapt the technique shown here. However, if I was writing an application that was keyboard driven (instead of purely driven by say, a file redirected to standard input) I would let go of StdIN, and use a CRT type unit. So, if you don't mind letting go of StdIn, and simply want to have a keyboard-driven input model, you could look at console based APIs and abandon the very limiting StdIn capabilities. For an example of a "kbhit" function that uses the Win32 Console APIs see here.
There is no other way (as far as i know), as reading from a pipe inside a separate thread. Otherwise as you already have seen, the readfile operation will block. I wrote an example how to do this, an example project is also available: redirect stdoutput
Edit: Well, reading your question another time, i understand that your problem lies within the console program, not the calling application. I wonder what your console application expects, normally a console application knows when it needs input and cannot proceede until the user enters this information. Do you need to check for an exit?
For a Stream if you .Read() the function result is the number of bytes read which will be zero if there was nothing there even if you asked for more. From the Delphi help for Classes.TStream.Read:
Read is used in cases where the number of bytes to read from the stream is not necessarily fixed. It attempts to read up to Count bytes into buffer and returns the number of bytes actually read.