Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10224 > unrolled thread

Fav. Memory Stream Impl.

Back to article view | Back to comp.lang.java.programmer

Contents

  Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 18:39 +0100
    Re: Fav. Memory Stream Impl. markspace <-@.> - 2011-11-25 10:34 -0800
      Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 20:59 +0100
        Re: Fav. Memory Stream Impl. markspace <-@.> - 2011-11-25 12:16 -0800
          Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 21:23 +0100
            Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 21:23 +0100
              Re: Fav. Memory Stream Impl. markspace <-@.> - 2011-11-25 13:00 -0800
                Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 22:32 +0100
                  Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 22:36 +0100
                    Re: Fav. Memory Stream Impl. Robert Klemme <shortcutter@googlemail.com> - 2011-11-25 23:22 +0100
    Re: Fav. Memory Stream Impl. Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 17:00 -0500
      Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-26 12:10 +0100
        Re: Fav. Memory Stream Impl. Robert Klemme <shortcutter@googlemail.com> - 2011-11-27 21:43 +0100
          Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-28 00:13 +0100
            Re: Fav. Memory Stream Impl. Robert Klemme <shortcutter@googlemail.com> - 2011-11-28 08:14 +0100
              Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-28 09:10 +0100
                Re: Fav. Memory Stream Impl. Robert Klemme <shortcutter@googlemail.com> - 2011-11-28 02:47 -0800
                  Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-28 14:58 +0100
                    Re: Fav. Memory Stream Impl. Robert Klemme <shortcutter@googlemail.com> - 2011-11-28 19:52 +0100
                      Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-29 00:22 +0100
                        Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-29 00:39 +0100
                        Re: Fav. Memory Stream Impl. Gene Wirchenko <genew@ocis.net> - 2011-11-28 17:03 -0800
                        Re: Fav. Memory Stream Impl. Arne Vajhøj <arne@vajhoej.dk> - 2012-02-06 21:06 -0500
                          Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2012-02-07 09:59 +0100
                            Re: Fav. Memory Stream Impl. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-07 09:59 -0800
                            Re: Fav. Memory Stream Impl. Arne Vajhøj <arne@vajhoej.dk> - 2012-02-07 21:02 -0500
                              Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2012-02-08 09:55 +0100
                                Re: Fav. Memory Stream Impl. "John B. Matthews" <nospam@nospam.invalid> - 2012-02-08 12:18 -0500
                                  Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2012-02-08 20:23 +0100
                                    Re: Fav. Memory Stream Impl. Gene Wirchenko <genew@ocis.net> - 2012-02-08 13:18 -0800
                                  Re: Fav. Memory Stream Impl. Gene Wirchenko <genew@ocis.net> - 2012-02-08 13:18 -0800
                      Re: Fav. Memory Stream Impl. Mayeul <mayeul.marguet@free.fr> - 2011-11-29 12:25 +0100
                        Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-29 14:37 +0100
                          Re: Fav. Memory Stream Impl. Lew <lewbloch@gmail.com> - 2011-11-29 07:37 -0800
                          Re: Fav. Memory Stream Impl. Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-29 20:26 +0000
                            Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-29 21:34 +0100
                              Re: Fav. Memory Stream Impl. Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-29 21:05 +0000
                                Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-29 22:59 +0100
                                  Re: Fav. Memory Stream Impl. markspace <-@.> - 2011-11-29 14:06 -0800
                                    Re: Fav. Memory Stream Impl. "John B. Matthews" <nospam@nospam.invalid> - 2011-11-29 21:23 -0500
                                  Re: Fav. Memory Stream Impl. Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-30 01:08 +0000
                                    Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-30 14:03 +0100
        Re: Fav. Memory Stream Impl. Arne Vajhøj <arne@vajhoej.dk> - 2012-02-06 20:59 -0500
    Re: Fav. Memory Stream Impl. Roedy Green <see_website@mindprod.com.invalid> - 2011-11-26 00:26 -0800
      Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-26 12:05 +0100
        Re: Fav. Memory Stream Impl. Lew <lewbloch@gmail.com> - 2011-11-26 11:22 -0800
          Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-26 20:44 +0100
            Re: Fav. Memory Stream Impl. Lew <lewbloch@gmail.com> - 2011-11-26 17:15 -0800
      Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2012-01-28 00:11 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#10345

On Tue, 29 Nov 2011 22:59:06 +0100, Jan Burse wrote:

> Martin Gregorie schrieb:
>> On Tue, 29 Nov 2011 21:34:54 +0100, Jan Burse wrote:
>>
>>> Martin Gregorie schrieb:
>>>> As you say the individual file sizes are a few tens of bytes, have
>>>> you looked at using ByteInputStream and ByteOutputStream?
>>>>
>>>> If you have considered them, why are they unsuitable?
>>>
>>> They could play a part in the game. But two problems are unsolved:
>>> sharing and positioning.
>>>
>> My bad: I meant ByteArrayInputStream and ByteArrayOutputStream
>>
>> The names are a little confusing: ByteArrayInputStream reads *from* a
>> byte array. The ByteArrayOutputStream writes *into* a byte array.
>>
>> I've used them to move byte arrays to and from CLOB columns in
>> databases,
>> where they were straight-forward to use with CLOB sizes ranging from a
>> few bytes to a few megabytes, though I never had more than one or two
>> instances in use at a time.
>>
>>
> I don't see a constructor where I could hand over a buffer content from
> the memory stream. So that multiple reader and/or writers can share the
> same buffer content.
>
The idea is that you write to the ByteArrayOutputStream, close it, grab 
the byte array using toByteArray() and store that until it is needed. 
Then you construct a ByteArrayInputStream with the byte array as the 
constructor argument. This does, of course, assume that you never want to 
write and read an instance simultaneously. 

I'd think implementing non-simultaneous access should be easy enough to 
bury inside a <MemoryStream> class.

Beyond that I'm guessing since you've said little or nothing about 
whether you need simultaneous read and write access to a <MemoryStream> 
instance, whether an instance gets read more than once and how many 
instances can exist at the same time.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#10357

Martin Gregorie schrieb:
> Beyond that I'm guessing since you've said little or nothing about
> whether you need simultaneous read and write access to a<MemoryStream>
> instance, whether an instance gets read more than once and how many
> instances can exist at the same time.

I only said multiple readers and writers. But idea
is concurrently and simultaneous. Idea is not
sequentially one after the other.

What will transpire between these multiple readers
and writers will be the size of the memory stream,
and eventually a delete status. And of course the
content.

No special limit on the number of memory stream instances,
and no special limit on the number of input / output /
random access objects created from one memory stream.

Bye

[toc] | [prev] | [next] | [standalone]

#11763

On 11/26/2011 6:10 AM, Jan Burse wrote:
> Arne Vajhøj schrieb:
>> Use java.nio.ByteBuffer and handle concurrency in your code.
>
> ByteBuffer does not extend automatically. If I do
> put and reach the size of the byte buffer, I will
> get an exception BufferOverflowException.
>
> That is at least how I interpret the javadoc.
>
> I am not looking for a bounded memory stream, it
> should be unbounded, like (temporary) files are.
> You just write and write and write, thats it.
>
> Size control of the memory stream can be done
> via close truncate for example.
>
> The reference to the memory stream should be
> still valid when an input stream or output stream
> sitting on it does a close. With the same memory
> stream reference I should be able to create new
> input or output streams over it, that will work
> on the previously written content.

Given that memory/available address space is
bounded then what you can store in memory will
be bounded no matter what.

You will just need to code to handle it.

Arne

[toc] | [prev] | [next] | [standalone]

#10263

On Fri, 25 Nov 2011 18:39:23 +0100, Jan Burse <janburse@fastmail.fm>
wrote, quoted or indirectly quoted someone who said :

>Would be interested in a good memory stream
>implementation. Requirement will be multiple
>readers / writers and positioning.

What do you use it for?  What does it do for you?
Is it just an ram-resident InputStream?
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Premature optimization is the root of all evil.
~ Donald Ervin Knuth 1938-01-10 
Unfortunately, some have misread this quotation as optimisation is 
in itself evil, or even that is it wicked to consider speed when 
choosing an algorithm. I counter, it is less work to do it right 
the first time. Knuth was referring to clarity-destroying 
micro-optimisation, now authomatically handled by optimising 
static compilers and HotSpot runtimes.
 

[toc] | [prev] | [next] | [standalone]

#10264

Roedy Green schrieb:
> On Fri, 25 Nov 2011 18:39:23 +0100, Jan Burse<janburse@fastmail.fm>
> wrote, quoted or indirectly quoted someone who said :
>
>> Would be interested in a good memory stream
>> implementation. Requirement will be multiple
>> readers / writers and positioning.
>
> What do you use it for?  What does it do for you?
> Is it just an ram-resident InputStream?

 From my post 25.11.2011 21:23:

 > But I guess the .NET memory streams are not cyclic. I am
 > looking for something like the .NET memory streams, so
 > that I can get rid of temporary file names in my
 > application.

[toc] | [prev] | [next] | [standalone]

#10268

On Saturday, November 26, 2011 3:05:27 AM UTC-8, Jan Burse wrote:
> Roedy Green schrieb:
> > On Fri, 25 Nov 2011 18:39:23 +0100, Jan Burse<janb...@fastmail.fm>
> > wrote, quoted or indirectly quoted someone who said :
> >
> >> Would be interested in a good memory stream
> >> implementation. Requirement will be multiple
> >> readers / writers and positioning.
> >
> > What do you use it for?  What does it do for you?
> > Is it just an ram-resident InputStream?
> 
>  From my post 25.11.2011 21:23:
> 
>> But I guess the .NET memory streams are not cyclic. I am
>> looking for something like the .NET memory streams, so
>> that I can get rid of temporary file names in my
>> application.

GREAT!  Now we have to do homework just to understand your question!  That's a *real* inducement to help you.

How about you answer the question here, hm?

What about these "memory streams" do you want to recapitulate?  What is the purpose in your project?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10269

Lew schrieb:
> GREAT!  Now we have to do homework just to
 > understand your question!  That's a*real*
 > inducement to help you.

My grandmother did understand it in a blink.

Bye

[toc] | [prev] | [next] | [standalone]

#10272

Jan Burse wrote:
> Lew schrieb:
>> GREAT!  Now we have to do homework just to
>> understand your question!  That's a*real*
>> inducement to help you.
> 
> My grandmother did understand it in a blink.

You're just piling on the inducements, ain't'cha, Dale Carnegie?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#11623

Roedy Green schrieb:
> On Fri, 25 Nov 2011 18:39:23 +0100, Jan Burse<janburse@fastmail.fm>
> wrote, quoted or indirectly quoted someone who said :
>
>> Would be interested in a good memory stream
>> implementation. Requirement will be multiple
>> readers / writers and positioning.
>
> What do you use it for?  What does it do for you?
> Is it just an ram-resident InputStream?

Dear All,

I found an interesting implementation. On linux
level there is ashmem for Android. And then on Java
level there is an implementation of a class called
MemoryFile. The memory file acts as a factory for
input/output streams:

 
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.2_r1.1/android/os/MemoryFile.java#MemoryFile

     public InputStream getInputStream() {
         return new MemoryInputStream();
     }

     public OutputStream getOutputStream() {
         return new MemoryOutputStream();
     }

The above two streams account for sequential access,
and via mark/release some pseudo random access.
But there is also an api for random access. Namely
the following two beasts:

     public int  readBytes(byte[] buffer, int srcOffset,
          int destOffset, int count);

     public void writeBytes(byte[] buffer, int srcOffset,
         int destOffset, int count)

Compare to a normal read/write there is an additional
parameter for the offset inside the memory file. But
the implementation is not really light weight. Namely
the memory file can shared accross processes, which
I do not need:

     http://elinux.org/Android_Kernel_Features#ashmem

But at least it gives an idea how to bootstrap a
memory file implementation. Namely the input/output
streams are implemented based on the read/write with
the extra argument. Makes for examples mark/release
quite simple....

Cool!

Bye

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.java.programmer

csiph-web